Bug 106204

nope, this is a problem with the hardware/firmware of the touchpad. If you look a the evemu record output you attached, there is exactly one event with x/y updates after the initial touch (at E: 0.000001). The rest is 8 seconds of pressure and touch size updates without any changes in the x/y position. So this isn't libinput's fault, we cannot move the cursor when we don't get position updates from the kernel.

I notice you're using SMBus/RMI4 for the touchpad. Try booting with PS/2 instead in case that makes a difference. On the grub command line, add psmouse.synaptics_intertouch=0. That gives you a SynPS/2 Synaptics Touchpad device instead of "Synaptics TM3289-021" but otherwise it should more-or-less be the same.

The reason why I think this might be a libinput issue is that I used synaptic driver before and never experienced any problem like this. Is libinput only good for PS/2 devices?

I tested it a bit, basically the synaptic driver feels a little bit better. I am not quite sure whether this relates to the acceleration curve. However, I can confirm that there is a "dead zone" set by the firmware. And switching to PS/2 basically makes no differents other then increasing the lag for the mouse. I have set the minimum speed for the synaptic driver to 0.3 but I can't find any option for libinput to set the minimum speed.

synaptics and libinput use exactly the same events as input. the switch between RMI4 and PS/2 is largely because different series of devices have different firmware bugs.

the cause of the issue is, most likely, that the firmware filters out the events at low speeds. synaptics has a slower acceleration by default, requiring more/faster movement, and is thus less likely to trigger that bug.

Bug 101139 is probably of interest here, it contains a branch for different touchpad acceleration in libinput.

> but I can't find any option for libinput to set the minimum speed.

the "libinput Accel Speed" property has a [-1, 1] range, that should work. Or just the mouse speed handle in the desktop evironment as long as it supports libinput.

Seems you are right... I was hoping for the same experience on a Micorsoft device... Thanks for you help.

Something I don't understand is that when I boot with psmouse.proto=imps, the mouse is super responsive. However, all the functionality is lost. How I understand this is that this proto will bypass all the drivers and use a standard mouse driver instead and with this driver, no hardware hysteresis exists with this driver.

Does this indicate that this is actually a kernel bug?

no, the kernel doesn't do anything other than forward the events. If you switch to imps, the kernel doesn't switch the touchpad to touchpad mode so the firmware emulates a PS/2 compatible mouse. You can verify this by running evemu-record, you should see BTN_LEFT, etc. as well as REL_X/Y.

It's more of a firmware bug in that the device is only ever tested with windows and if it works there, they ship it. If we don't have the same behaviour as the windows driver we trigger bugs that windows doesn't have to care about. as you could see from the libinput vs synaptics behaviour - different pointer acceleration suddenly shows up a bug that's effectively unfixable without emulating that behaviour (which can break other devices, yay).

So basically this is the issue for the kernel's driver? Should I report this to them maybe?

Actually is it the case that there is basically no way to make the touchpad more responsive? Do all the touchpads have to suffer from this issue? Is there any potential fix for this?

Did you try the test branch from Bug 101139?

It's not really a kernel bug because the kernel doesn't do anything with the events unless a fuzz is set (not the case here). So the most likely workaround is going to be to change the pointer acceleration curve. Again, Bug 101139 may help. If not, we have support for custom pointer acceleration curves now if you grab libinput from git and xf86-input-libinput from git too.

I don't really think that helps. I am pretty much satisfied with the current default curve. Good job by the way, very appreciated. So basically if I want this fix I will have to go to either lenovo or synaptics. I don't really think they might help me however...

Just figured out that the touchpad pad has some huge deadzones at the bottom and at the left and right edge...

what's the output from the touchpad-edge-detector? the deadzones are the software buttons and the palm zones, see https://wayland.freedesktop.org/libinput/doc/latest/palm_detection.html

The output of `touchpad-edge-detector` is :

Touchpad Synaptics TM3289-021 on /dev/input/event15
Move one finger around the touchpad to detect the actual edges
Kernel says:	x [0..1936], y [0..1057]
Touchpad sends:	x [0..1936], y [0..1057] -^C\-

Touchpad size as listed by the kernel: 96x52mm
User-specified touchpad size: 100x58mm
Calculated ranges: 1936/1057

Suggested udev rule:
# <Laptop model description goes here>
evdev:name:Synaptics TM3289-021:dmi:bvnLENOVO:bvrN23ET37W(1.12):bd02/27/2018:svnLENOVO:pn20KHCTO1WW:pvrThinkPadX1Carbon6th:rvnLENOVO:rn20KHCTO1WW:rvrSDK0J40709WIN:cvnLENOVO:ct10:cvrNone:*

I think the palm detection deadzone makes sense.

Is there a way to determined whether the software hysteresis is off or not?

And, maybe there is a way to check the fuzz?

Have a look at your 60-evdev.hwdb, there are instructions to test local changes. This snippet should bring your device closer to real measurements, reducing the size of the palm zones.

evdev:name:Synaptics TM3289-021:dmi:*svnLENOVO:*pvrThinkPadX1Carbon6th:*
 EVDEV_ABS_00=::19
 EVDEV_ABS_01=::18
 EVDEV_ABS_35=::19
 EVDEV_ABS_36=::18

run libinput debug-events --verbose and wait for the "hysteresis enabled" message. If it shows up, then the hysteresis enables. The fuzz is listed in the evemu-record, it's 0 for your device. So no hysteresis by default but the detection is enabled and may enable it later.

Unfortunately it seems that the hysteresis is not enabled for my touchpad... Seems that I am running out of options. Synaptics does not seems to be caring linux users that much.

The hysteresis shouldn't be enabled for your touchpad, not unless you're seeing pointer jitter. Which also means that the lack of pointer movement isn't caused by the hysteresis, but we've already established that you're not getting events in comment #1. So we're going round in circles here, the only way to work around this bug is by lowering acceleration so you have to move your finger faster, thus not triggering the bug.

Just a heads up. Since the latest update from arch (Today), the trackpad seems to be much responsive. However, it seems that when the laptop first boots up, the trackpad is responsive. After I open some software such as chrome, the trackpad becomes non-responsive.

libinput isn't aware of whether other processes are running, so this is more likely a compositor issue. or something else really really screwed up.

I totally understand that. I am wondering whether I have a way to test it out.

I am actually wondering whether the trackpad has the same hysteresis under Windows... To be honest, I have pretty high expectations for windows precision trackpad. I am a little bit disappointed.

Is there a way to update trackpad firmware under Linux?