|Summary:||Touchpad deadzone on Razer Blade Stealth|
|Component:||libinput||Assignee:||Wayland bug list <wayland-bugs>|
|Status:||RESOLVED MOVED||QA Contact:|
|i915 platform:||i915 features:|
libinput-debug-events output when holding finger in deadzone
touchpad edge detector output
outpu of evemu record while finger is in deadzone
output of evemu record when cursor is shaking
corrected touchpad-edge-detector output
udevadm info output after making evdev.hwdb changes
udevadm info output with fuzz 8
full dmesg output
hid-recorder output for touchpad
hid-record output take 2
kernel patch to remove the deadzone and palm detection
output of evemu-describe when no deadzone was observed
output of hid-record of the touchpad on custom kernel
Description Dave 2018-03-09 04:35:55 UTC
Created attachment 137921 [details] libinput-debug-events I've noticed with the touchpad on the late-2017 Razer Blade Stealth (with the i7-8550U), there's a deadzone slightly off-center. Running kernel: 4.16.0-041600rc4-generic libinput: built from master at cd966460 The touchpad works fine in Windows, however does not work under Ubuntu (tested 17.10 and 18.04) or Fedora 27. It also occurs on both Wayland and X, and with both the Synaptics drivers and libinput. The issue appears less significant when using libinput, but still constant. If a finger enters this zone, it will register the following in the logs: > touch 0 from BUTTON_STATE_AREA, event BUTTON_EVENT_UP to BUTTON_STATE_NONE Occasionally, when a finger is held in that zone, the cursor will seemingly vibrate. The device information is: Device: 1A586753:00 06CB:8323 Touchpad Kernel: /dev/input/event16 Group: 9 Seat: seat0, default Size: 102x60mm Capabilities: pointer gesture Tap-to-click: disabled Tap-and-drag: enabled Tap drag lock: disabled Left-handed: disabled Nat.scrolling: disabled Middle emulation: disabled Calibration: n/a Scroll methods: *two-finger edge Click methods: *button-areas clickfinger Disable-w-typing: enabled Accel profiles: none Rotation: n/a
Comment 1 Dave 2018-03-09 04:37:13 UTC
Created attachment 137922 [details] evemu-describe output Also attached, the evemu-describe output
Comment 2 Dave 2018-03-10 18:45:34 UTC
Created attachment 137971 [details] libinput-debug-events output when holding finger in deadzone Attached is the libinput debug-events output when a finger is held in the deadzone, when the "shaking" or "vibrating" behaviour is observed
Comment 3 Dave 2018-03-11 16:27:33 UTC
Also worth mentioning that this is not an isolated case, there are multiple reports of users with the same laptop having touchpad issues: https://insider.razerzone.com/index.php?threads/ubuntu-17-10-blade-stealth-late-2017-issues.28967/
Comment 4 Peter Hutterer 2018-03-12 03:44:48 UTC
Run the touchpad-edge-detector tool please and attach the whole output here. And an evemu-record output of the finger in that dead zone.
Comment 5 Dave 2018-03-12 04:02:13 UTC
Created attachment 138006 [details] touchpad edge detector output Attached is the touchpad-edge-detector output
Comment 6 Dave 2018-03-12 04:02:54 UTC
Created attachment 138007 [details] outpu of evemu record while finger is in deadzone Attached is the output of evemu-record for the touchpad with finger in the deadzone
Comment 7 Dave 2018-03-12 04:09:03 UTC
Created attachment 138008 [details] output of evemu record when cursor is shaking Attached is the output of evemu-record when the "shaking cursor" behavior is active
Comment 8 Peter Hutterer 2018-03-12 04:42:53 UTC
> User-specified touchpad size: 64x105mm I'm assuming this is supposed to be 105x64? Please re-run so I don't have to do the calculations in my head. From attachment 138006 [details]: > E: 4.936156 0004 0005 5075200 # EV_MSC / MSC_TIMESTAMP 5075200 > E: 4.936156 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +8ms All we're getting from the device are timestamps but no finger movements. So either you held your finger perfectly still or the device/firmare/kernel driver is buggy and doesn't send input events. Either way, this bit isn't something we can fix in libinput. The jitter in attachment 138009 [details] is crazy, but the fixes for bug 104828 would detect it if we'd switch to y-based jitter (not sure why it only jitters on the y axis here, very strange). But we also need a tool for measuring fuzz (see bug 105202) so we can use this in the hwdb.
Comment 9 Dave 2018-03-12 12:36:15 UTC
Created attachment 138017 [details] corrected touchpad-edge-detector output I reran touchpad-edge-detector with the correct physical measurements (105x64) and reattached the output.
Comment 10 Peter Hutterer 2018-03-12 22:43:13 UTC
PR sent to systemd, please give it a test: https://github.com/systemd/systemd/pull/8436. Instructions are at the top of the 60-evdev.hwdb file. Once you've done this, please also test this entry: EVDEV_ABS_00=0::12:8 EVDEV_ABS_01=0::11:8 EVDEV_ABS_35=0::12:8 EVDEV_ABS_36=0::11:8 Note the trailing ":8", the rest stays identical. This should set the fuzz on the device. Install libinput git master, reboot. This should make LIBINPUT_FUZZ udev properties show up (udevadm info /sys/class/input/eventX for your event node) and reduce or remove the jitter. It there's still light jitter, increase from 8 to 12 and try again.
Comment 11 Dave 2018-03-13 00:47:19 UTC
Created attachment 138049 [details] udevadm info output after making evdev.hwdb changes Added the lines from the systemd PR to my local 61-evdev-local.hwdb file and ran updates. Running build of libinput from latest master commit. Deadzone still occurs, jitter is very obvious. Fuzz value of 8 to follow
Comment 12 Dave 2018-03-13 00:48:42 UTC
Created attachment 138050 [details] udevadm info output with fuzz 8 Updated local 61-udevadm-local.hwdb file to include a fuzz value of 8. Jitter seems to have disappeared or be unnoticeable. Deadzone issue still exists.
Comment 13 Peter Hutterer 2018-03-13 00:54:40 UTC
Thanks for testing. The fuzz value is now in the systemd PR, so that should close the bug once merged. The deadzone - there isn't anything we can do in libinput, we're not getting any events from the hardware. This may be possible to fix in the kernel but I'm not putting any hopes on that. Please attach a dmesg and a hid-record log as well. https://bentiss.github.io/hid-replay-docs/
Comment 14 Dave 2018-03-13 00:58:48 UTC
Created attachment 138051 [details] full dmesg output Here's the full dmesg output, let me know if I can filter out something specific for you. Output from hid-record coming soon
Comment 15 Dave 2018-03-13 01:07:33 UTC
Created attachment 138052 [details] hid-recorder output for touchpad Here's the hid-recorder output for the touchpad, at approximately timestamp 1.5 my finger enters the deadzone, and the cursor stops moving.
Comment 16 Peter Hutterer 2018-03-13 03:39:50 UTC
How long did you keep you the finger there? The events stop at 1.84s and there are a few events that have the same coordinates and would thus be filtered. But afaict the recording stops 300ms after you say you entered the deadzone?
Comment 17 Dave 2018-03-13 04:39:53 UTC
Created attachment 138056 [details] hid-record output take 2 Here's a longer hid-record output, this time I made an S shape that passed through the deadzone, and a counter-clockwise half-circle around the touchpad. The cursor stops moving at approximately 5.5s, which was at the end of the S shape, and did not track the half-circle afterwards.
Comment 18 Peter Hutterer 2018-03-13 06:23:30 UTC
Weird, there certainly are events coming out of the device and the coordinates move slightly. Benjamin, any guess? Dave, can you confirm with evemu-record that whenever the finger stops moving, you only get MSC_TIMESTAMP but not x/y updates?
Comment 19 Benjamin Tissoires 2018-03-13 09:51:01 UTC
The problem here is that the touchpad sends events with a confidence of 0. This usually means the touchpad considers the touch to be a palm. Currently hid-multitouch ignores such events so that's why the kernel filter them out. Theoretically, we could forward such events with the tool MT_TOOL_PALM, but IIRC we already discussed about that and this might break user space which doesn't expect the ABS_MT_TOOL to change.
Comment 20 Peter Hutterer 2018-03-13 22:32:15 UTC
oh, right, confidence bit. Forgot to look at that. Anyway, even with a perfect userspace it wouldn't really fix the issue because we'd just be ignoring a palm touch anyway... So IMO this is something the kernel needs to sort out
Comment 21 Dave 2018-03-14 03:36:13 UTC
Just to confirm, after my finger passes through the deadzone, only MSC_TIMESTAMP records appear, even when I continue moving it.
Comment 22 Benjamin Tissoires 2018-03-14 19:43:11 UTC
Created attachment 138113 [details] [review] kernel patch to remove the deadzone and palm detection Would it be possible for you to try the attached patch on a recent kernel? I locally tested it with your recording, and I now see all of the events. However, the things I am not so sure are for the reporting of the buttons, and if disabling the device palm detection is worse than having it (like if you get ghosts events).
Comment 23 Dave 2018-03-15 00:13:32 UTC
Created attachment 138118 [details] output of evemu-describe when no deadzone was observed I haven't had a chance to try the patch yet, but I've noticed that the issue isn't present 100% of the time anymore. After resuming from suspend, there was no apparent deadzone for a couple minutes, but it eventually returned. I ran evenmu-describe when it was working, to highlight what changes have been made, hoping it might point to something. Since the issues has returned, I'll try the patch now.
Comment 24 Dave 2018-03-15 03:36:52 UTC
So far so good, will keep you posted
Comment 25 Dave 2018-03-15 23:06:23 UTC
Created attachment 138149 [details] output of hid-record of the touchpad on custom kernel Still no return of the deadzone, it's much more usable now. I haven't noticed any issues with palm detection, but if there's anything you want me to test just let me know. One thing I have noticed, is that movement through the former "deadzone", is that the movement seems off, in almost a "jumpy" manner. It seems like while passing through the former zone, the cursor stops moving, but after exiting the zone the cursor jumps to the current position of my finger. I've attached the output of hid-record while making circles on the touchpad that pass through the zone. Maybe this will provide some insight.