Using onscreen keyboard can trigger swipe gestures #296
Comments
|
What is this dual finger scroll from bottom gesture you are talking about? Oxide only has single finger gestures. Could you post some of the tarnish logs for when this happens? |
|
Also, could you clarify what you mean by "Oxide is triggered"? Is it returning to the launcher, opening the task switcher, or something else? |
|
Here are the logs: (from journalctl -u tarnish) |
|
Sorry, I meant slide from bottom (single finger), which I never did in the sequence above, the observed returned to launcher at 18:00:59 is due to the bug from hitting backspace key too often. Oxide launcher appears unexpectedly and I have to click on xochitl icon to return to work. |
|
Tarnish (the system service that handles gestures, application switching, buttons, etc) is likely interpreting the button press holding the home/middle button on a rM1. Could you use evtest to check the output of that button press? It would also be useful to get some more information on the sysfs for the keyboard to see if there is a way to identify it, so that it can be handled differently. |
|
Based on the code here, tarnish interprets the following keycodes: map[105] = PressRecord("Left", Qt::Key_Left);
map[102] = PressRecord("Middle", Qt::Key_Home);
map[106] = PressRecord("Right", Qt::Key_Right);
map[116] = PressRecord("Power", Qt::Key_PowerOff);So I would expect the backspace key to be sending the 102 key code somehow. Likely it's also bugging out and thinking it's being held down due to you pressing it fast enough to be causing a timing bug with the code that handles locking and unlocking events. At this point Oxide doesn't support the new keyboard folio, but I'm happy to work through issues with it. I don't have a rM2, or the new keyboard folio myself so I can't really do much lots more help. |
Eeems
added
help wanted
Eeems
changed the title
|
I don't have the keyboard folio. I'm talking about the "virtual keyboard" that's displayed when you use the new text feature. I'll try to capture some events later today. |
|
Here's the last output of the bug with evtest running like this: # evtest
No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0: 30370000.snvs:snvs-powerkey
/dev/input/event1: Wacom I2C Digitizer
/dev/input/event2: pt_mt
Select the device event number [0-2]: 2
Input driver version is 1.0.1
Input device ID: bus 0x0 vendor 0x0 product 0x0 version 0x0
Input device name: "pt_mt"
Supported events:
Event type 0 (EV_SYN)
Event type 1 (EV_KEY)
Event code 59 (KEY_F1)
Event code 60 (KEY_F2)
Event code 61 (KEY_F3)
Event code 62 (KEY_F4)
Event code 63 (KEY_F5)
Event code 64 (KEY_F6)
Event code 65 (KEY_F7)
Event code 66 (KEY_F8)
Event type 2 (EV_REL)
Event type 3 (EV_ABS)
Event code 25 (ABS_DISTANCE)
Value 0
Min 0
Max 255
Event code 47 (ABS_MT_SLOT)
Value 0
Min 0
Max 31
Event code 48 (ABS_MT_TOUCH_MAJOR)
Value 0
Min 0
Max 255
Event code 49 (ABS_MT_TOUCH_MINOR)
Value 0
Min 0
Max 255
Event code 52 (ABS_MT_ORIENTATION)
Value 0
Min -127
Max 127
Event code 53 (ABS_MT_POSITION_X)
Value 0
Min 0
Max 1403
Event code 54 (ABS_MT_POSITION_Y)
Value 0
Min 0
Max 1871
Event code 55 (ABS_MT_TOOL_TYPE)
Value 0
Min 0
Max 1
Event code 57 (ABS_MT_TRACKING_ID)
Value 0
Min 0
Max 65535
Event code 58 (ABS_MT_PRESSURE)
Value 0
Min 0
Max 255
Properties:
Property type 1 (INPUT_PROP_DIRECT)
Testing ... (interrupt to exit)
[...]
Event: time 1678978358.561605, type 3 (EV_ABS), code 25 (ABS_DISTANCE), value 1
Event: time 1678978358.561605, -------------- SYN_REPORT ------------
Event: time 1678978358.561623, type 3 (EV_ABS), code 25 (ABS_DISTANCE), value 2
Event: time 1678978358.561623, -------------- SYN_REPORT ------------
Event: time 1678978358.561640, type 3 (EV_ABS), code 25 (ABS_DISTANCE), value 1
Event: time 1678978358.561640, -------------- SYN_REPORT ------------
Event: time 1678978358.561657, type 3 (EV_ABS), code 25 (ABS_DISTANCE), value 2
Event: time 1678978358.561657, -------------- SYN_REPORT ------------
Event: time 1678978358.561672, type 3 (EV_ABS), code 25 (ABS_DISTANCE), value 1
Event: time 1678978358.561672, -------------- SYN_REPORT ------------
Event: time 1678978358.561726, type 3 (EV_ABS), code 25 (ABS_DISTANCE), value 2
Event: time 1678978358.561726, -------------- SYN_REPORT ------------
Event: time 1678978358.561741, type 3 (EV_ABS), code 25 (ABS_DISTANCE), value 1
Event: time 1678978358.561741, -------------- SYN_REPORT ------------
Event: time 1678978358.561756, type 3 (EV_ABS), code 25 (ABS_DISTANCE), value 2
Event: time 1678978358.561756, -------------- SYN_REPORT ------------
Event: time 1678978358.561770, type 3 (EV_ABS), code 25 (ABS_DISTANCE), value 1
Event: time 1678978358.561770, -------------- SYN_REPORT ------------
Event: time 1678978358.561784, type 3 (EV_ABS), code 25 (ABS_DISTANCE), value 2
Event: time 1678978358.561784, -------------- SYN_REPORT ------------
Event: time 1678978358.561798, type 3 (EV_ABS), code 25 (ABS_DISTANCE), value 1
Event: time 1678978358.561798, -------------- SYN_REPORT ------------
Event: time 1678978358.561812, type 3 (EV_ABS), code 25 (ABS_DISTANCE), value 2
Event: time 1678978358.561812, -------------- SYN_REPORT ------------
Event: time 1678978358.611534, type 3 (EV_ABS), code 57 (ABS_MT_TRACKING_ID), value 1521
Event: time 1678978358.611534, type 3 (EV_ABS), code 25 (ABS_DISTANCE), value 0
Event: time 1678978358.611534, type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 1258
Event: time 1678978358.611534, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 248
Event: time 1678978358.611534, type 3 (EV_ABS), code 58 (ABS_MT_PRESSURE), value 75
Event: time 1678978358.611534, type 3 (EV_ABS), code 48 (ABS_MT_TOUCH_MAJOR), value 17
Event: time 1678978358.611534, type 3 (EV_ABS), code 52 (ABS_MT_ORIENTATION), value 4
Event: time 1678978358.611534, -------------- SYN_REPORT ------------
Event: time 1678978358.693143, type 3 (EV_ABS), code 57 (ABS_MT_TRACKING_ID), value -1
Event: time 1678978358.693143, -------------- SYN_REPORT ------------ |
|
Notice that it's a lot harder to reproduce when the evtest is running (but it still happens, sparsely). It doesn't depend on which key you press, it happened while I was entering usual text. I'm almost sure it should be reproducible on your remarkable 1 too (provided you could run the 3.2 firmware). |
|
Ah, so this sounds like the gesture handling is just triggering due to being too close to the bottom of the screen and the taps confusing it? |
|
Maybe adding a When I want to start the launcher, I'll do the bottom slide gesture only. If it gets ignored because I just did some touch on the screen, I'll redo it and it's unlikely I can do it in 500ms anyway. |
|
Did you try adjusting the swipe length to see if that mitigates it? |
|
Nope it doesn't work. I've already a huge length of 400 set up and it happens anyway... |
|
You can add |
Eeems
changed the title
|
Here are the last logs just before it happened with debug mode: Input is very slow in this mode, I have to type multiple time to get it to react. |
|
I don't see anything in the log here saying that a swipe happened. It keeps logging |
|
That's what I did ( |
Using |
|
Here it is: |
|
And with debug: Mar 24 13:22:03 reMarkable tarnish[30234]: Not swiping
Mar 24 13:22:04 reMarkable tarnish[30234]: DOWN (<Touch 4424 (1200, 229) pressed>)
Mar 24 13:22:04 reMarkable tarnish[30234]: UP (<Touch 4424 (1200, 229) released>)
Mar 24 13:22:04 reMarkable tarnish[30234]: Not swiping
Mar 24 13:22:04 reMarkable tarnish[30234]: DOWN (<Touch 4425 (1210, 221) pressed>)
Mar 24 13:22:04 reMarkable tarnish[30234]: MOVE (<Touch 4425 (1208, 222) pressed>)
Mar 24 13:22:04 reMarkable tarnish[30234]: UP (<Touch 4425 (1208, 222) released>)
Mar 24 13:22:04 reMarkable tarnish[30234]: Not swiping
Mar 24 13:22:04 reMarkable tarnish[30234]: DOWN (<Touch 4426 (1187, 237) pressed>)
Mar 24 13:22:04 reMarkable tarnish[31828]: ERROR: ld.so: object '/opt/lib/librm2fb_client.so.1' from LD_PRELOAD cannot be preloaded (internal error): ignored.
Mar 24 13:22:04 reMarkable tarnish[31831]: ERROR: ld.so: object '/opt/lib/librm2fb_client.so.1' from LD_PRELOAD cannot be preloaded (internal error): ignored.
Mar 24 13:22:04 reMarkable tarnish[31832]: ERROR: ld.so: object '/opt/lib/librm2fb_client.so.1' from LD_PRELOAD cannot be preloaded (internal error): ignored.
Mar 24 13:22:04 reMarkable tarnish[31836]: ERROR: ld.so: object '/opt/lib/librm2fb_client.so.1' from LD_PRELOAD cannot be preloaded (internal error): ignored.
Mar 24 13:22:04 reMarkable tarnish[31840]: ERROR: ld.so: object '/opt/lib/librm2fb_client.so.1' from LD_PRELOAD cannot be preloaded (internal error): ignored.
Mar 24 13:22:04 reMarkable tarnish[30234]: MOVE (<Touch 4426 (1187, 239) pressed>)
Mar 24 13:22:04 reMarkable tarnish[30234]: MOVE (<Touch 4426 (1187, 239) pressed>)
Mar 24 13:22:04 reMarkable tarnish[30234]: MOVE (<Touch 4426 (1187, 239) pressed>)
Mar 24 13:22:04 reMarkable tarnish[30234]: MOVE (<Touch 4426 (1187, 239) pressed>)
Mar 24 13:22:04 reMarkable tarnish[30234]: MOVE (<Touch 4426 (1185, 239) pressed>)
Mar 24 13:22:04 reMarkable tarnish[30234]: UP (<Touch 4426 (1185, 239) released>)
Mar 24 13:22:04 reMarkable tarnish[30234]: Not swiping
Mar 24 13:22:04 reMarkable tarnish[30234]: DOWN (<Touch 4427 (1179, 245) pressed>)
Mar 24 13:22:04 reMarkable tarnish[30234]: UP (<Touch 4427 (1179, 245) released>)
Mar 24 13:22:04 reMarkable tarnish[30234]: Not swiping
Mar 24 13:22:04 reMarkable tarnish[30234]: DOWN (<Touch 4428 (1180, 0) pressed>)
Mar 24 13:22:04 reMarkable tarnish[30234]: Swipe started 3
Mar 24 13:22:04 reMarkable tarnish[30234]: UP (<Touch 4428 (1180, 0) released>)
Mar 24 13:22:04 reMarkable tarnish[30234]: Swipe Cancelled
Mar 24 13:22:04 reMarkable tarnish[30234]: Write touch move <Touch 4428 (1180, 0) released>
Mar 24 13:22:04 reMarkable tarnish[30234]: Write touch up <Touch 4428 (1180, 0) released>
Mar 24 13:22:04 reMarkable tarnish[30234]: DOWN (<Touch 4429 (1184, 246) pressed>)
Mar 24 13:22:05 reMarkable tarnish[30234]: UP (<Touch 4429 (1184, 246) released>)
Mar 24 13:22:05 reMarkable tarnish[30234]: Not swiping
Mar 24 13:22:05 reMarkable tarnish[30234]: DOWN (<Touch 4430 (0, 245) pressed>)
Mar 24 13:22:05 reMarkable tarnish[30234]: Swipe started 1
Mar 24 13:22:05 reMarkable tarnish[30234]: UP (<Touch 4430 (0, 245) released>)
Mar 24 13:22:05 reMarkable tarnish[30234]: Swipe Cancelled
Mar 24 13:22:05 reMarkable tarnish[30234]: Write touch move <Touch 4430 (0, 245) released>
Mar 24 13:22:05 reMarkable tarnish[30234]: Write touch up <Touch 4430 (0, 245) released>
Mar 24 13:22:05 reMarkable tarnish[30234]: DOWN (<Touch 4431 (1185, 243) pressed>)
Mar 24 13:22:05 reMarkable tarnish[30234]: UP (<Touch 4431 (1185, 243) released>)
Mar 24 13:22:05 reMarkable tarnish[30234]: Not swiping
Mar 24 13:22:05 reMarkable tarnish[30234]: DOWN (<Touch 4432 (1200, 237) pressed>)
Mar 24 13:22:05 reMarkable tarnish[30234]: UP (<Touch 4432 (1200, 237) released>)
Mar 24 13:22:05 reMarkable tarnish[30234]: Not swiping
Mar 24 13:22:05 reMarkable tarnish[30234]: DOWN (<Touch 4433 (1197, 236) pressed>)
Mar 24 13:22:05 reMarkable tarnish[30234]: UP (<Touch 4433 (1197, 236) released>)
Mar 24 13:22:05 reMarkable tarnish[30234]: Not swiping
Mar 24 13:22:05 reMarkable tarnish[30234]: DOWN (<Touch 4434 (1201, 229) pressed>)
Mar 24 13:22:05 reMarkable tarnish[30234]: MOVE (<Touch 4434 (1199, 228) pressed>)
Mar 24 13:22:05 reMarkable tarnish[30234]: UP (<Touch 4434 (1199, 228) released>)
Mar 24 13:22:05 reMarkable tarnish[30234]: Not swiping
Mar 24 13:22:05 reMarkable tarnish[30234]: DOWN (<Touch 4435 (1200, 236) pressed>)
Mar 24 13:22:05 reMarkable tarnish[30234]: MOVE (<Touch 4435 (1197, 236) pressed>)
Mar 24 13:22:05 reMarkable tarnish[30234]: UP (<Touch 4435 (1197, 236) released>)
Mar 24 13:22:05 reMarkable tarnish[30234]: Not swiping
Mar 24 13:22:06 reMarkable tarnish[30234]: DOWN (<Touch 4436 (1191, 237) pressed>)
Mar 24 13:22:06 reMarkable tarnish[30234]: UP (<Touch 4436 (1191, 237) released>)
Mar 24 13:22:06 reMarkable tarnish[30234]: Not swiping
Mar 24 13:22:06 reMarkable tarnish[30234]: DOWN (<Touch 4437 (1206, 226) pressed>)
Mar 24 13:22:06 reMarkable tarnish[30234]: MOVE (<Touch 4437 (1206, 224) pressed>)
Mar 24 13:22:06 reMarkable tarnish[30234]: UP (<Touch 4437 (1206, 224) released>)
Mar 24 13:22:06 reMarkable tarnish[30234]: Not swiping
**Mar 24 13:22:06 reMarkable tarnish[30234]: DOWN (<Touch 4438 (0, 227) pressed>)**
Mar 24 13:22:06 reMarkable tarnish[30234]: Swipe started 1
Mar 24 13:22:06 reMarkable tarnish[30234]: MOVE (<Touch 4438 (1205, 224) pressed>)
Mar 24 13:22:06 reMarkable tarnish[30234]: UP (<Touch 4438 (1205, 224) released>)
Mar 24 13:22:06 reMarkable tarnish[30234]: Pausing "/codes/eeems/oxide1/apps/d941cc3512975cd9beb7dde71108afce"
Mar 24 13:22:06 reMarkable tarnish[30234]: Saving screen...
Mar 24 13:22:06 reMarkable tarnish[30234]: Compressing data...
Mar 24 13:22:06 reMarkable tarnish[30234]: Screen saved 337263 bytes
Mar 24 13:22:06 reMarkable tarnish[30234]: Paused "/codes/eeems/oxide1/apps/d941cc3512975cd9beb7dde71108afce"
Mar 24 13:22:06 reMarkable tarnish[30234]: Unable to find current application
Mar 24 13:22:06 reMarkable tarnish[30234]: Resuming "/codes/eeems/oxide1/apps/d3641f0572435f76bb5cc1468d4fe1db"
Mar 24 13:22:06 reMarkable tarnish[30234]: Uncompressing screen...
Mar 24 13:22:07 reMarkable tarnish[30234]: Recalling screen...
Mar 24 13:22:07 reMarkable tarnish[30234]: Screen recalled.
Mar 24 13:22:07 reMarkable tarnish[30234]: Resumed "/codes/eeems/oxide1/apps/d3641f0572435f76bb5cc1468d4fe1db"
Mar 24 13:22:07 reMarkable tarnish[30234]: Resuming previous application "codes.eeems.oxide"
Mar 24 13:22:07 reMarkable tarnish[30234]: Previous Applications ("xochitl")
Mar 24 13:22:07 reMarkable tarnish[30234]: Write touch move <Touch 4438 (-1, -1) released>
Mar 24 13:22:07 reMarkable tarnish[30234]: Write touch up <Touch 4438 (-1, -1) released>
Mar 24 13:22:07 reMarkable tarnish[30234]: Swipe direction 0
Mar 24 13:22:07 reMarkable tarnish[30234]: DOWN (<Touch 4439 (1198, 235) pressed>)
Mar 24 13:22:07 reMarkable tarnish[30234]: UP (<Touch 4439 (1198, 235) released>)
Mar 24 13:22:07 reMarkable tarnish[30234]: Not swiping
Mar 24 13:22:07 reMarkable tarnish[30234]: DOWN (<Touch 4440 (1200, 237) pressed>)
Mar 24 13:22:07 reMarkable tarnish[30234]: UP (<Touch 4440 (1200, 237) released>)
Mar 24 13:22:07 reMarkable tarnish[30234]: Not swiping
Mar 24 13:22:07 reMarkable tarnish[30234]: DOWN (<Touch 4441 (0, 227) pressed>)
Mar 24 13:22:07 reMarkable tarnish[30234]: Swipe started 1
Mar 24 13:22:07 reMarkable tarnish[30234]: UP (<Touch 4441 (0, 227) released>)
Mar 24 13:22:07 reMarkable tarnish[30234]: Swipe Cancelled
Mar 24 13:22:07 reMarkable tarnish[30234]: Write touch move <Touch 4441 (0, 227) released>
Mar 24 13:22:07 reMarkable tarnish[30234]: Write touch up <Touch 4441 (0, 227) released>
Mar 24 13:22:07 reMarkable tarnish[30234]: UP (<Touch -1 (0, 0) released>)
Mar 24 13:22:07 reMarkable tarnish[30234]: Not swiping
Mar 24 13:22:07 reMarkable tarnish[30234]: UP (<Touch -1 (0, 0) released>)
Mar 24 13:22:07 reMarkable tarnish[30234]: Not swiping
Mar 24 13:22:07 reMarkable tarnish[30234]: UP (<Touch -1 (0, 0) released>)
Mar 24 13:22:07 reMarkable tarnish[30234]: Not swiping
Mar 24 13:22:07 reMarkable tarnish[30234]: UP (<Touch -1 (0, 0) released>)
Mar 24 13:22:07 reMarkable tarnish[30234]: Not swiping
Mar 24 13:22:07 reMarkable tarnish[30234]: UP (<Touch -1 (0, 0) released>)
Mar 24 13:22:07 reMarkable tarnish[30234]: Not swiping
Mar 24 13:22:07 reMarkable tarnish[30234]: UP (<Touch -1 (0, 0) released>)
Mar 24 13:22:07 reMarkable tarnish[30234]: Not swiping
Mar 24 13:22:07 reMarkable tarnish[30234]: DOWN (<Touch 4443 (0, 238) pressed>)
Mar 24 13:22:07 reMarkable tarnish[30234]: Swipe started 1
Mar 24 13:22:07 reMarkable tarnish[30234]: UP (<Touch 4443 (0, 238) released>)
Mar 24 13:22:07 reMarkable tarnish[30234]: Swipe Cancelled
Mar 24 13:22:07 reMarkable tarnish[30234]: Write touch move <Touch 4443 (0, 238) released>
Mar 24 13:22:07 reMarkable tarnish[30234]: Write touch up <Touch 4443 (0, 238) released>
Mar 24 13:22:07 reMarkable tarnish[30234]: DOWN (<Touch 4444 (1198, 224) pressed>)
Mar 24 13:22:07 reMarkable tarnish[31843]: ERROR: ld.so: object '/opt/lib/librm2fb_client.so.1' from LD_PRELOAD cannot be preloaded (internal error): ignored.
Mar 24 13:22:07 reMarkable tarnish[31846]: ERROR: ld.so: object '/opt/lib/librm2fb_client.so.1' from LD_PRELOAD cannot be preloaded (internal error): ignored.
Mar 24 13:22:07 reMarkable tarnish[31847]: ERROR: ld.so: object '/opt/lib/librm2fb_client.so.1' from LD_PRELOAD cannot be preloaded (internal error): ignored.
Mar 24 13:22:07 reMarkable tarnish[31851]: ERROR: ld.so: object '/opt/lib/librm2fb_client.so.1' from LD_PRELOAD cannot be preloaded (internal error): ignored.
Mar 24 13:22:07 reMarkable tarnish[31855]: ERROR: ld.so: object '/opt/lib/librm2fb_client.so.1' from LD_PRELOAD cannot be preloaded (internal error): ignored.
Mar 24 13:22:07 reMarkable tarnish[30234]: UP (<Touch 4444 (1198, 224) released>)
Mar 24 13:22:07 reMarkable tarnish[30234]: Not swipingThis one shows a swipe detection. I've marked with ** the line with a suspicious down event with a X=0 value (in an ocean of X ~= 1200) |
|
By looking at the capture above, it seems that not all ABS_MT_POSITION_Y evdev's event are in pair with the ABS_MT_POSITION_X event, so it would confirm my suspicion. Maybe the event isn't send if there isn't any change in the value itself. Yet, the deserializing code to |
It shouldn't be possible to miss events unless you create enough events to rotate through the ring buffer. I read them in a while loop with a yield to make sure the events are processed by the rest of the QT framework. Having a sentinel value might not be a bad idea, but with the rest of the complexity around handling this, especially if we have the touch input grabbed where we have to echo it back after ungrabbing, we still need to be writing valid events instead of skipping them. The
Have you looked at the evtest output while this happens to confirm that it's missing events? Currently, you are only making guesses as to what might be happening without validating your hypothesis. On the reMarkable 1, ABS_MT_POSITION_X and ABS_MT_POSITION_Y are always sent, even if they haven't changed. |
|
Look at what I've posted last week, above. It contains the evtest output and it's missing the pair in multiple places. |
|
Looking at it, I don't see any missing pairs other than updates to existing touch slots, which would mean that both the x and the y are already populated. My code keeps track of the slots and just updates the existing https://github.com/Eeems-Org/oxide/blob/master/applications/system-service/systemapi.h#L482-L523 |
|
Look at this extract: The slot is selected in A, the track become active and X and Y is set. Then the slot is changed in B and immediately, the track become unactive. So typically, the code might be writing a (wrong) X or Y value to slot 0 because it has seen a tracking id set to -1 anywhere before, and as such, erasing what true X or Y value in slot 0 that should have been. Or worse, it would use a stale data when slot 1 is selected but track id is set to -1 (so |
|
Having stale data shouldn't be a problem, as My code also only uses the slots to identify the Since handling is single threaded, and each event is handled all the way through to the end before reading the next event, there should be no timing issues. That said, since this is on a rM2, and not a rM1, where the CPU is dual-core, it could be putting the threads on different cores and making this no longer work as expected. It might be worth trying to change the Qt::ConnectionType to |
|
Okay, when a From the logs you used as an example, this is what the state of the two slots would be, as well as when touchDown/touchUp are called. I included a little more of the context to show how it works. |
|
Ok, nice step by step. (with MT_SLOT set to value 1 instead of 0), like these: The -1 will cause the good touchUp event, but the next events will use slot 0's Touch instance (instead of slot 1 since it wasn't unselected) to be filled and will corrupt it. This might break what's set previously when the next MT_SLOT=0 / TRACKING_ID=-1 lines follow. This could happen: Here, the touch for slot0 that happened at (1,2) is virtually moved to (8,9) because it's wrongly selected by the touch up event. This could cause an unwanted/wrong swipe. Also, we do observe half-filled touch instance, with either X or Y set to 0. So there's clearly some corruption going on here. |
|
Ah, I see what you are saying. I do believe that setting it to slot 0 is intentional, as things didn't work right if I didn't. I believe that I was seeing events where the slot wasn't changed to slot 0 even though it should have been after the touch was cleared. Looking through the multi-touch-protocol, it doesn't talk about the slot changing after clearing a touch, so it is probably safe to assume that it shouldn't. I'll have to check with that line removed to see if things work as expected on my rM1. There is still the possibility of timing problems present on a rM2 that I can't replicate on a rM1. |
|
Okay, a quick test with the following steps:
Produces the following: So it does seem to match what you've identified. I've removed the Also, thank you for sticking with me through trying to explain this. I'm not operating at 100% right now, so it was quite difficult to keep my head around what we were talking about. |
|
@X-Ryl669 would you be able to test the PR that should fix this? I'd like to know if it works or not. |
|
Tried with the linked PR and while it's better, it still happens (less often). I'm getting these logs now: So it's clearly the x=0 or y=0 that triggers the issue. Another shot, this time with both evtest and the tarnish logs: and evtest output running at the same time: If you look at problematic touch with id 2552, a syn_report happens before the Y value is sent, and it seems tarnish handles it before it's complete. |
|
So, I've made this patch: diff --git a/applications/system-service/systemapi.h b/applications/system-service/systemapi.h
index 112d044..3e6dd29 100644
--- a/applications/system-service/systemapi.h
+++ b/applications/system-service/systemapi.h
@@ -43,8 +43,8 @@ struct Inhibitor {
struct Touch {
int slot = 0;
int id = -1;
- int x = 0;
- int y = 0;
+ int x = -1;
+ int y = -1;
bool active = false;
bool existing = false;
bool modified = true;
@@ -55,6 +55,9 @@ struct Touch {
string debugString() const{
return "<Touch " + to_string(id) + " (" + to_string(x) + ", " + to_string(y) + ") " + (active ? "pressed" : "released") + ">";
}
+ bool valid() const{
+ return x != -1 && y != -1;
+ }
};
QDebug operator<<(QDebug debug, const Touch& touch);
QDebug operator<<(QDebug debug, Touch* touch);
@@ -433,6 +436,9 @@ private slots:
QList<Touch*> pressed;
QList<Touch*> moved;
for(auto touch : touches.values()){
+ if(!touch->valid()){
+ continue;
+ }
if(touch->id == -1){
touch->active = false;
released.append(touch);And relaunched tarnish and it works. I actually ignore |
|
Maybe the position for the valid touch test should be moved after the diff --git a/applications/system-service/systemapi.h b/applications/system-service/systemapi.h
index 112d044..a202b09 100644
--- a/applications/system-service/systemapi.h
+++ b/applications/system-service/systemapi.h
@@ -43,8 +43,8 @@ struct Inhibitor {
struct Touch {
int slot = 0;
int id = -1;
- int x = 0;
- int y = 0;
+ int x = -1;
+ int y = -1;
bool active = false;
bool existing = false;
bool modified = true;
@@ -55,6 +55,9 @@ struct Touch {
string debugString() const{
return "<Touch " + to_string(id) + " (" + to_string(x) + ", " + to_string(y) + ") " + (active ? "pressed" : "released") + ">";
}
+ bool valid() const{
+ return id == -1 || (x != -1 && y != -1);
+ }
};
QDebug operator<<(QDebug debug, const Touch& touch);
QDebug operator<<(QDebug debug, Touch* touch);
@@ -428,6 +431,10 @@ private slots:
case SYN_REPORT:
// Always mark the current slot as modified
auto touch = getEvent(currentSlot);
+ // Ignore spurious SYN_REPORT if the event isn't complete
+ if(!touch->valid()){
+ break;
+ }
touch->modified = true;
QList<Touch*> released;
QList<Touch*> pressed; |
|
Okay, so this seems to be the problem event: For some reason, the touch event is sent with only ABS_MT_POSITION_X and then the ABS_MT_POSITION_Y is sent in the next report. This doesn't seem valid at all to me, and seems to be a bug with the driver. Since this is possible, I'll concede to adding a guard value. |
|
I've pushed an update with the guard in place. |
|
Sentry issue: OXIDE-4 |
|
I think your patch doesn't work. I've tried a similar approach at first, but it fails, some swipe aren't detected anymore. Please check my review of your patch for the explanation. |
|
I had a crash report come in while you were testing. Since nobody other than you and I would have it report as v2.6, since I fixed the version number reporting in the PR, and since I have a rM1, not a rM2, my guess is that this was from you @X-Ryl669. I don't have debug symbols for the PR uploaded, so I didn't get a ton of information. Did you happen to notice a crash at all? The breadcrumbs don't really give a ton to work with either: |
I don't see anything on the PR yet, did you forget to hit submit? |
|
Right, that was me. I didn't know it had telemetry. You can probably ignore those since I've played with the code with multiple fixes until I had something working correctly. Also, I don't really understand the relation between tarnish and oxide startup sequence, so I've started oxide without stopping tarnish, updated the former, the latter and that crashed. I had to reboot to get the tablet to work again. Also, Xochitl crashes a lot with the new text feature, but I guess it's not due to tarnish, but on poorly tested code from them. |
Did you not get the opt-in prompt on first launch? If not, that would be a bug. Telemetry starts enabled by default just in case it crashes out before you can get to the opt-in prompt, but then there is an opt-in prompt that lets you specify what level of telemetry you want:
You can trigger this flow with the following steps: xdg-settings set firstLaunch true
rot apps call getApplicationPath "QString:\"codes.eeems.decay\"" \
| jq -cr | sed 's|/codes/eeems/oxide1/||' \
| xargs -I {} rot --object Application:{} apps call stop
xdg-open oxide:codes.eeems.decay
Tarnish is the only thing you need to launch, it'll start everything else. You can think of it as a mini-init system. Oxide and other applications use the DBus API provided by tarnish, and will fail to run if it's not running. They also have to be started from tarnish so that tarnish is aware of the application and can manage it properly. At some point I'll get around to implementing a re-parenting system and let applications register themselves as running under tarnish.
I've heard that the betas have been crashing a lot recently. They have their own crash reporting, so in theory they should be working on it. I don't get crash reports for xochitl, only oxide applications if you have telemetry enabled. |
|
I'm not running their beta software, only the official release (currently 3.2 something IIRC). Maybe I had the telemetry dialog when I first installed Oxide, but it was years ago, I don't remember. Anyway, it's ok for me if it's helpful. As for xochitl crashing, I haven't kept the tarnish log (sorry, I didn't know it would be useful), but tarnish was crashing too when it's happened. And since I haven't started it with systemctl, it didn't restart and only a reboot saved the day. There are multiple issue with locking reported in the logs, and sometime the screen is corrupted (see the rm2fb issue thread for more details). I haven't figured out the exact sequence to reproduce it. I know that it happens when restarting tarnish a lot. You need to start Xochitl too. Sometimes it fails spectacularly (you'd get half the screen rendered by Oxide and half the screen by xochitl) and in that case, it crashes easily by touching everywhere. I guess it would be another issue report then. |
Sounds like you somehow have the tarnish and xochitl service running at the same time. If tarnish crashes, it can also leave behind some of the running applications, and they might hold onto the lock as they are in a paused state. You can always just check the running processes and |
Eeems
added a commit
that referenced
this issue
Apr 24, 2023
* Fix #296 * Add code to handle skipping SYN_DROPPED events * Fix version reporting to sentry * Handle invalid touch events * Add install-lib methods, don't set existing if invalid touch event
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
I've updated the device to latest 3.2.3.1595 firmware (the 3.1 firmware wasn't working for me).
I'm running tarnish and oxide out of the chroot (if that has any impact on the bug).
Since version 3 of the firmware, a new Text tool was added to xochitl.
When you add some text via this tool and press the backspace key multiple time to erase one or more line of text, Oxide is triggered.
It shouldn't be triggered, since I haven't applied the "dual finger slide from bottom" gesture, yet it's very painful to have to go back to xochitl.
The same happens if you press "Enter" key multiple times too.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
The gesture recognition algorithm shouldn't interpret single repeated press as a "dual finger scroll from bottom" gesture.
Version Information:
Additional context
I had to run Tarnish out of chroot, else it crash the tablet (see here)
The text was updated successfully, but these errors were encountered: