| Summary: | libinput 1.3.2 freezing pointer | ||
|---|---|---|---|
| Product: | Wayland | Reporter: | brent s. <brent.saner> |
| Component: | libinput | Assignee: | Wayland bug list <wayland-bugs> |
| Status: | RESOLVED NOTOURBUG | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | benjamin.tissoires, brent.saner, peter.hutterer |
| Version: | 1.3.0 | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
event1's evemu record
event9's evemu record |
||
|
Description
brent s.
2016-06-27 02:56:43 UTC
Created attachment 124732 [details]
event1's evemu record
Created attachment 124733 [details]
event9's evemu record
Comment on attachment 124733 [details]
event9's evemu record
marking as obsolete, this is an unrelated touchscreen device
(In reply to Peter Hutterer from comment #3) > Comment on attachment 124733 [details] > event9's evemu record > > marking as obsolete, this is an unrelated touchscreen device AHA! that makes sense. thank you for clarifying that confusion! (In reply to brent s. from comment #1) > Created attachment 124732 [details] > event1's evemu record The first event here may show the issue: E: 0.000001 0001 0145 0000 # EV_KEY / BTN_TOOL_FINGER 0 E: 0.000001 0001 014d 0001 # EV_KEY / BTN_TOOL_DOUBLETAP 1 This indicates that from the kernel's POV the device switched from single finger to two-fingers down. In libinput that usually stops pointer motion (depending on finger position it may start 2fg scrolling). Was this recording started with your fingers off the touchpad? All other BTN_TOOL_FINGER events point at a potential hardware issue, whenever the device switches to single-finger down (FINGER is 1) it immediately switches to two fingers in the subsequent event (DOUBLETAP is 1). So we either have the hw not noticing that one finger was released or in-kernel tracking getting confused. (In reply to Peter Hutterer from comment #5) > The first event here may show the issue: > > E: 0.000001 0001 0145 0000 # EV_KEY / BTN_TOOL_FINGER 0 > E: 0.000001 0001 014d 0001 # EV_KEY / BTN_TOOL_DOUBLETAP 1 > > This indicates that from the kernel's POV the device switched from single > finger to two-fingers down. In libinput that usually stops pointer motion > (depending on finger position it may start 2fg scrolling). Was this > recording started with your fingers off the touchpad? Yes; i don't think I bumped into the pad or anything either with the heel of my thumb/palm. I tried to keep as far away from it as I could when starting. I can always generate another one via SSH and then try to reproduce while that's running so I can be sure I had no physical contact with the machine when starting, but it's fairly sporadic (though often) and a little bit difficult to reproduce intentionally. > All other BTN_TOOL_FINGER events point at a potential hardware issue, > whenever the device switches to single-finger down (FINGER is 1) it > immediately switches to two fingers in the subsequent event (DOUBLETAP is > 1). So we either have the hw not noticing that one finger was released or > in-kernel tracking getting confused. Hrm.. the hardware's fairly new (laptop was purchased/unboxed about two? three? weeks ago). That doesn't of course rule out faulty manufacturing but it does certainly make it being a hardware-level issue less likely, I'd presume. Anything I can try to help narrow it down? sorry, was on holidays and this fell under the radar. try checking for this symptom, if it happens every single time then it's definitely hw related or a bug in the kernel. The device may simply need a quirk. we do patch against faulty hw in libinput but in this case we'd have to put this into the kernel, the touchpad would otherwise be completely useless in any other userspace stack. Have you tried Windows on that thing? did that work? ping? closing after too much silence. See comment #7, this is something that needs to be fixed in the kernel if we can fix it at all |
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.