| Summary: | Pointer doesn't move on rare occasions | ||
|---|---|---|---|
| Product: | Wayland | Reporter: | Cyril B. <lagoon42> |
| Component: | libinput | Assignee: | Wayland bug list <wayland-bugs> |
| Status: | RESOLVED NOTOURBUG | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | benjamin.tissoires, peter.hutterer |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
evemu recording of a pointer refusing to move
hid record of an undetected move evemu recording matching the hid record |
||
E: 30.993357 0003 0039 0667 # EV_ABS / ABS_MT_TRACKING_ID 667 E: 30.993357 0003 0035 1202 # EV_ABS / ABS_MT_POSITION_X 1202 E: 30.993357 0003 0036 0530 # EV_ABS / ABS_MT_POSITION_Y 530 E: 30.993357 0001 014a 0001 # EV_KEY / BTN_TOUCH 1 E: 30.993357 0001 0145 0001 # EV_KEY / BTN_TOOL_FINGER 1 E: 30.993357 0003 0000 1202 # EV_ABS / ABS_X 1202 E: 30.993357 0003 0001 0530 # EV_ABS / ABS_Y 530 E: 30.993357 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +27108ms That's a finger down in the right bottom corner. The next event is 33 seconds later: E: 63.629946 0003 0035 0722 # EV_ABS / ABS_MT_POSITION_X 722 E: 63.629946 0003 0036 0263 # EV_ABS / ABS_MT_POSITION_Y 263 E: 63.629946 0003 0000 0722 # EV_ABS / ABS_X 722 E: 63.629946 0003 0001 0263 # EV_ABS / ABS_Y 263 E: 63.629946 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +32636ms So what appears to happen is that that touch was detected as a palm (correctly). Since it doesn't trigger any of the palm release requirements (e.g. moving out of the palm zones), it is treated like a palm even when it starts moving around on the touchpad. This looks like either buggy hardware or some kernel tracking issue. We could put additional triggers in to prevent this in libinput, but this is the first time I've seen something like that. Can you verify this is what's happening every time you see the issue? I have caught 4 more occurrences of the bug, and each time, there's no 'finger up' event. However, the previous finger down isn't always in the palm area. Here are 2 excerpts of the bug: E: 21.602669 0003 0039 -001 # EV_ABS / ABS_MT_TRACKING_ID -1 E: 21.602669 0003 002f 0001 # EV_ABS / ABS_MT_SLOT 1 E: 21.602669 0003 0039 -001 # EV_ABS / ABS_MT_TRACKING_ID -1 E: 21.602669 0001 014a 0000 # EV_KEY / BTN_TOUCH 0 E: 21.602669 0001 014d 0000 # EV_KEY / BTN_TOOL_DOUBLETAP 0 E: 21.602669 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +26ms E: 40.659982 0003 002f 0000 # EV_ABS / ABS_MT_SLOT 0 E: 40.659982 0003 0039 12413 # EV_ABS / ABS_MT_TRACKING_ID 12413 E: 40.659982 0003 0035 0020 # EV_ABS / ABS_MT_POSITION_X 20 E: 40.659982 0003 0036 0471 # EV_ABS / ABS_MT_POSITION_Y 471 E: 40.659982 0001 014a 0001 # EV_KEY / BTN_TOUCH 1 E: 40.659982 0001 0145 0001 # EV_KEY / BTN_TOOL_FINGER 1 E: 40.659982 0003 0000 0020 # EV_ABS / ABS_X 20 E: 40.659982 0003 0001 0471 # EV_ABS / ABS_Y 471 E: 40.659982 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +19057ms E: 165.969897 0003 0035 0745 # EV_ABS / ABS_MT_POSITION_X 745 E: 165.969897 0003 0036 0360 # EV_ABS / ABS_MT_POSITION_Y 360 E: 165.969897 0003 0000 0745 # EV_ABS / ABS_X 745 E: 165.969897 0003 0001 0360 # EV_ABS / ABS_Y 360 E: 165.969897 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +125310ms and: E: 93.906453 0003 0039 -001 # EV_ABS / ABS_MT_TRACKING_ID -1 E: 93.906453 0001 014a 0000 # EV_KEY / BTN_TOUCH 0 E: 93.906453 0001 0145 0000 # EV_KEY / BTN_TOOL_FINGER 0 E: 93.906453 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +47ms E: 110.826926 0003 0039 11856 # EV_ABS / ABS_MT_TRACKING_ID 11856 E: 110.826926 0003 0035 0000 # EV_ABS / ABS_MT_POSITION_X 0 E: 110.826926 0003 0036 0491 # EV_ABS / ABS_MT_POSITION_Y 491 E: 110.826926 0001 014a 0001 # EV_KEY / BTN_TOUCH 1 E: 110.826926 0001 0145 0001 # EV_KEY / BTN_TOOL_FINGER 1 E: 110.826926 0003 0000 0000 # EV_ABS / ABS_X 0 E: 110.826926 0003 0001 0491 # EV_ABS / ABS_Y 491 E: 110.826926 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +16920ms E: 135.413510 0003 0035 0749 # EV_ABS / ABS_MT_POSITION_X 749 E: 135.413510 0003 0036 0278 # EV_ABS / ABS_MT_POSITION_Y 278 E: 135.413510 0003 0000 0749 # EV_ABS / ABS_X 749 E: 135.413510 0003 0001 0278 # EV_ABS / ABS_Y 278 E: 135.413510 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +24587ms Do you know if I have a way to find out if it's a kernel issue rather than a hardware bug? the touch down is in the palm area in both cases - x of 20 and 0 are in the palm zones. Try to get a hid-recording from the device and attach it here, Benjamin may be able to make sense of it. I'm suspecting a hardware issue though. http://bentiss.github.io/hid-replay-docs/ I've forced my touchpad to use PS/2 rather than I2C (by blacklisting the i2c_hid module), and I'm pretty sure that specific issue is gone (it hasn't occurred for a few hours now). However, the touchpad is behaving very diffently. The speed/acceleration is very different, and the triple tap is very erratic (despite seeing BTN_TOOL_TRIPLETAP when recording). 1. Do you still think it could be a kernel issue? 2. Regarding the triple tap, do you want me to open a new bug with details? I'm on Linux 4.4.1 by the way. tripletap is erratic on ps2, that's a (unrelated) problem we already know of. The speed should not be any different though. Is it faster or slower? The only reasoning I can think of here would be if the ps/2 advertises a higher axis range than i2c and thus the average motion is higher, triggering the pointer acceleration code earlier. Again, please try to get a hid-recording first. Created attachment 121678 [details]
hid record of an undetected move
Created attachment 121679 [details]
evemu recording matching the hid record
I've finally managed to take a recording that is short enough. Both recording were made simultaneously (using hid-recorder and evemu-record).
We can see the 'finger down' event, with no matching 'finger up' (although I did it soon after):
E: 16.526484 0003 0039 21428 # EV_ABS / ABS_MT_TRACKING_ID 21428
E: 16.526484 0003 0035 0000 # EV_ABS / ABS_MT_POSITION_X 0
E: 16.526484 0003 0036 0306 # EV_ABS / ABS_MT_POSITION_Y 306
E: 16.526484 0001 014a 0001 # EV_KEY / BTN_TOUCH 1
E: 16.526484 0001 0145 0001 # EV_KEY / BTN_TOOL_FINGER 1
E: 16.526484 0003 0000 0000 # EV_ABS / ABS_X 0
E: 16.526484 0003 0001 0306 # EV_ABS / ABS_Y 306
E: 16.526484 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +1681ms
E: 56.993248 0003 0035 0681 # EV_ABS / ABS_MT_POSITION_X 681
E: 56.993248 0003 0036 0316 # EV_ABS / ABS_MT_POSITION_Y 316
E: 56.993248 0003 0000 0681 # EV_ABS / ABS_X 681
E: 56.993248 0003 0001 0316 # EV_ABS / ABS_Y 316
E: 56.993248 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +40467ms
The following move events are not moving the cursor, until I lift my finger up and down again, which makes the cursor move normally again.
Thanks for both logs, it helped. However, it is rather problematic, because if you parse the hid-recording[1], we receive: 14.845206 ReportID: 3 / Confidence: 1 | Tip Switch: 0 | Contact Id: 0 | # | X: 627 | Y: 364 | ... | Contact Count: 1 | B1: 0 | # 16.526414 ReportID: 3 / Confidence: 1 | Tip Switch: 1 | Contact Id: 0 | # | X: 0 | Y: 306 | ... | Contact Count: 1 | B1: 0 | # 56.993181 ReportID: 3 / Confidence: 1 | Tip Switch: 1 | Contact Id: 0 | # | X: 681 | Y: 316 | ... | Contact Count: 1 | B1: 0 | # Which matches the evemu-record (finger up at 14.845206, then down in (0, 306), wait 40 seconds, and move to (681, 316)). So this means that it is either a firmware problem of the touchpad, or a I2C error. Do you have any errors/warnings in your dmesg when this error occurs? I am not sure it is a firmware issue because PS/2 works, and the PS/2 binding should be using the same raw data than the I2C binding. You might have more luck with a 4.5-rc4. Meanwhile, I'll try to talk to the synaptics engineers about the issue. [1] use tools/parse_hid.py in the hid-replay repo Thanks. I have no kernel error when it occurs. One more thing: it seems to happen a lot more when I do some tasks which involve the keyboard. Actually, I'm pretty sure that issue only occurs AFTER I type on the keyboard (not all the time, obviously). I'll try a 4.5 kernel. Does testing under Windows would also help (I already have a Windows partition) to determine if it's a firmware issue? (In reply to Cyril B. from comment #9) > Thanks. I have no kernel error when it occurs. :( > One more thing: it seems to happen a lot more when I do some tasks which > involve the keyboard. Actually, I'm pretty sure that issue only occurs AFTER > I type on the keyboard (not all the time, obviously). Might be of interest for the Synaptics guys. However, if your keyboard is connected over PS/2, such interactions would be very weird. > > I'll try a 4.5 kernel. Does testing under Windows would also help (I already > have a Windows partition) to determine if it's a firmware issue? Yes, if you can reproduce under Windows, that will tell that Dell needs to update the hardware. However, if the I2C controller has some (silent) errors, the chances that the bug is not shown under Windows are great. How can I know if my keyboard is using PS/2 or not? This is what dmesg says about it: [ 0.554185] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input0 (In reply to Cyril B. from comment #11) > How can I know if my keyboard is using PS/2 or not? This is what dmesg says > about it: > > [ 0.554185] input: AT Translated Set 2 keyboard as > /devices/platform/i8042/serio0/input/input0 Yep, that's a PS/2 one (using the i8042 chip which provides a serio bus). We got a reply from Synaptics. They said that the touchpad and its firmware are the same than the one found in the 9343, and they never seen this. Your laptop is a Skylake model (Intel 6th gen), and it's not uncommon to have issues with the embedded I2C chipset this early after a release. I will not be able to help on this particular issue as I am not too comfortable with the I2C subsystem. Maybe try to see if someone on the linux-i2c LKML could help you here. Thanks Benjamin, I'll try that. I guess the bug can be closed as it's obviously not due to libinput. Closing as NOTOURBUG then In case someone stumbles upon this bug, it's fixed on Linux 4.5-rc5. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Created attachment 121424 [details] evemu recording of a pointer refusing to move Rarely, but still quite regularly, the pointer doesn't move even though I move my finger on the trackpad. I have to lift my finger up and put it back on the touchpad for the pointer to start moving again. I would say it happens maybe once every 10 minutes. I haven't been able to determine precisely what circumstances trigger that bug, but I'm pretty sure it only happens when I haven't touched the touchpad for some time (say, a few dozens seconds). I have attached an evemu recording of the bug, and evemu-play does reproduce it. Since I cannot reproduce the bug when I want to, I had to let evemu-record run until the bug showed up, so the first 63 seconds of the recording are irrelevant. At the 63rd second (32 seconds after the previous event), I start moving my finger, but the pointer doesn't move. I've kept moving my finger for several seconds, still nothing. Only near the end of the recording did I lift my finger up, put it down, and move again. That last move does move the pointer. I'm using a Dell XPS 13 9350 with libinput 1.1.5 and the disable tap-to-drag patch, but I'm pretty sure it happened on 1.1.4 without the patch.