Bug 105409

Created attachment 137922 [details]
evemu-describe output

Also attached, the evemu-describe output

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

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/

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.

Created attachment 138006 [details]
touchpad edge detector output

Attached is the touchpad-edge-detector output

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

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

> 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.

Created attachment 138017 [details]
corrected touchpad-edge-detector output

I reran touchpad-edge-detector with the correct physical measurements (105x64) and reattached the output.

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.

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

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.

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/

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

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.

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?

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.

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?

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.

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

Just to confirm, after my finger passes through the deadzone, only MSC_TIMESTAMP records appear, even when I continue moving it.

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).

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.

So far so good, will keep you posted

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.