Bug 1264453

Created attachment 1074920 [details]
screencast on linux

First I move a few times from left to right in a normal speed. Then I try to do as slow and fluent movements as I can. Please note that I'm *not* moving a bit and then stopping, then moving a bit again. I'm really trying to do one slow fluent movement from one side to the other.

Created attachment 1074921 [details]
screencast on windows

The same test on Windows, covering roughly the same distances. See how fluent and non-jumpy the slow movement is.

Created attachment 1074923 [details]
touchpad photo

The touchpad itself is very small and the surface is covered with bumps. Due to this, it does feel to be less precise from a hardware standpoint. But experience on Windows shows that it does not limit functionality significantly.

Created attachment 1074924 [details]
evemu-describe

Created attachment 1074925 [details]
xinput-props

Created attachment 1074926 [details]
modalias

Created attachment 1074927 [details]
rpm-qa

pls attach a bad event sequence recorded with evemu-record, makes it easier to analyze. I have a x220 test box here but haven't noticed it being that bad.

Created attachment 1082925 [details]
touchpad movement recorded by evemu-record

Something like this? I tried to slowly move the cursor, but it performs mini-jumps instead. When I play it with evemu-play, I see it well.

attach your dmesg as well please. 

The evemu output looks like the one we've seen from the x230 - that touchpad only sends x/y events every 50 device units. libinput has a custom acceleration method for that, look at 
/lib/udev/hwdb.d/90-libinput-model-quirks.hwdb and change the x230 line to match your touchpad. then restart, make sure the udev property LIBINPUT_MODEL_LENOVO_X230 is set on the device (udevadm info /sys/class/input/eventX)

when it's set, the touchpad should behave a bit better, can you confirm that?
if so, we need to figure out why your x220 behaves like a x230, hopefully the dmesg has some hints there.

I'm sorry, I tried editing 90-libinput-model-quirks.hwdb, but it doesn't seem to apply. I changed this line:
libinput:name:SynPS/2 Synaptics TouchPad:dmi:*svnLENOVO:*:pvrThinkPadX230*
to this line:
libinput:name:SynPS/2 Synaptics TouchPad:dmi:*svnLENOVO:*:pvrThinkPadX220*
and even to this line:
libinput:name:SynPS/2 Synaptics TouchPad:dmi:*LENOVO:*:pvrThinkPadX220*
(because I'm not sure how exactly the star wildcards are implemented), but it has no effect. With this:

libinput:name:SynPS/2 Synaptics TouchPad:dmi:*svnLENOVO:*:pvrThinkPadX220*
 LIBINPUT_MODEL_LENOVO_X230=1

and reboot, I still don't see the property in udevadm:

$ udevadm info /dev/input/event6
P: /devices/platform/i8042/serio1/input/input5/event6
N: input/event6
S: input/by-path/platform-i8042-serio-1-event-mouse
E: DEVLINKS=/dev/input/by-path/platform-i8042-serio-1-event-mouse
E: DEVNAME=/dev/input/event6
E: DEVPATH=/devices/platform/i8042/serio1/input/input5/event6
E: ID_INPUT=1
E: ID_INPUT_HEIGHT_MM=31
E: ID_INPUT_TOUCHPAD=1
E: ID_INPUT_WIDTH_MM=70
E: ID_PATH=platform-i8042-serio-1
E: ID_PATH_TAG=platform-i8042-serio-1
E: ID_SERIAL=noserial
E: LIBINPUT_DEVICE_GROUP=11/2/7/1b1:isa0060/serio1
E: LIBINPUT_MODEL_SYNAPTICS_SERIAL_TOUCHPAD=1
E: MAJOR=13
E: MINOR=70
E: SUBSYSTEM=input
E: USEC_INITIALIZED=51873

Yet the quirk definition seems to match my evemu-describe output:
# DMI: dmi:bvnLENOVO:bvr8DET68WW(1.38):bd04/11/2013:svnLENOVO:pn4291EJ3:pvrThinkPadX220:rvnLENOVO:rn4291EJ3:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:
# Input device name: "SynPS/2 Synaptics TouchPad"

Of course the touchpad behavior hasn't changed after these adjustments. What am I doing wrong?

Created attachment 1084870 [details]
dmesg

oh, sorry, I forgot: you need to update the hwdb when you edit it (it's a binary database and doesn't auto-generate). sudo udevadm hwdb --update

Rather than rebooting, you should be able to run sudo udevadm test /sys/class/input/event6 after the update - if the property shows up then everything works (still, reboot once after that).

your dmesg shows:
[  +0.005261] psmouse serio1: synaptics: Touchpad model: 1, fw: 8.1, id: 0x1e2b1, caps: 0xd002a3/0x940300/0x123800, board id: 1611, fw id: 1099905

different firmware to the x220t I have here:
[    1.525878] psmouse serio1: synaptics: Touchpad model: 1, fw: 8.0, id: 0x1e2b1, caps: 0xd001a3/0x940300/0x120c00, board id: 1611, fw id: 774180

I wonder if that's a later version of the x220 that has the same touchpad as the x230?

The new setting is awesome! After applying the change, I had to increase the touchpad movement speed, but the result is that the movement is now very smooth and precise, and I'm completely happy with it. Let's make it the default :)

I can't really tell why my X220 has a different touchpad than your X220, but I'll be happy to supply any lshw or dmidecode or whatever output can help you in identifying this better.

question: did you ever update your bios? or did it come out of the box like this?

Yes, it seems I did. I received the notebook in 2012, but I have firmware 1.38 from 2013, according to dmidecode and http://support.lenovo.com/us/en/downloads/ds018807 . I don't see any touchpad changes in the changelog, though, except for 1.12 firmware from 2011: https://download.lenovo.com/ibmdl/pub/pc/pccbbs/mobiles/8duj25uc.txt

My dmidecode says:

BIOS Information
        Vendor: LENOVO
        Version: 8DET68WW (1.38 )
        Release Date: 04/11/2013
        <snip>
        BIOS Revision: 1.38
        Firmware Revision: 1.24

System Information
        Manufacturer: LENOVO
        Product Name: 4291EJ3
        Version: ThinkPad X220
        UUID: 69D0A381-5147-11CB-AEF3-FD88CA80982B
        Wake-up Type: Power Switch
        SKU Number: Not Specified
        Family: ThinkPad X220

I googled around a bit and there appear to be a number of people that have jumpy cursors on the x220. Apparently the first thing to check is: is the cursor still jumpy when unplugged and on battery power?

This article here suggests a firmware flash:
https://forums.lenovo.com/t5/ThinkPad-X-Series-Laptops/X220-Touchpad-jumpy-response-when-used-with-90w-slim-AC-adapter/ta-p/766543

However, those mostly talk about a jittery cursor, not necessarily a jumpy cursor. A bit more googling shows that the x230 seems to have the same fw version as you do. So this may be a fw version bug, the HW is the same on these two models iirc.

So I think I'll adjust the udev magic to hook on the the FW version too. But long-term your best hope is probably another fw update that fixes this issue.

Benjamin: afaict we don't export the fwversion that dmesg spits out to userspace anywhere. It's privy to the synaptics kernel driver, so there isn't anything we can hook onto. Any suggestions?

(In reply to Peter Hutterer from comment #17)
> I googled around a bit and there appear to be a number of people that have
> jumpy cursors on the x220. Apparently the first thing to check is: is the
> cursor still jumpy when unplugged and on battery power?

The behavior is the same whether it is on AC or battery. 

> So I think I'll adjust the udev magic to hook on the the FW version too. But
> long-term your best hope is probably another fw update that fixes this issue.

Should that be included in UEFI update, or some specific touchpad firmware update (I haven't found any of that on Lenovo support site)? I can try updating to latest UEFI, provided I borrow a USB DVD drive.

tbh, not sure how lenovo does the updates, so your guess is as good as mine. may be included with the UEFI update, but from the link above it looks like the touchpad fw can be separate too. sorry.

Update: this is not something we can fix automatically, we simply can't get the touchpad firmware version in userspace. Since the x220 is now over 3 years old and this is a rather niche case we've decided not to put hacks int the kernel, udev, and libinput just to handle this. Instead, it'll be left to the user to install a local config snippet. The patch to go upstream is here:
http://lists.freedesktop.org/archives/wayland-devel/2015-December/026093.html

For the x230 which has the same issues we have an automatic solution, but for those updating the x220 with this firmware version we can't do much. Then again, you may be the only one to need this ;)

I understand, thanks for all your effort. (I'd think that getting the firmware version string in userspace might be useful even in the future for other devices, but you can definitely estimate this better than I).

For others reading this bug report: IIUIC, the next version of libinput will contain specific X220 instructions in /lib/udev/hwdb.d/90-libinput-model-quirks.hwdb (just search for X220). It will guide you how to switch libinput behavior for your touchpad.

Please do not comment any further on this bug to make this comment the last one and easily visible to anyone who stumbles across this bug. Any related bugs about touchpads not working correctly should go in separate bug reports.

SOLUTION TO THIS BUG:
libinput 1.1.3 is now released with the patch listed in comment #21 merged. A description of the cause, solution/workaround and how to set it up locally is available here:

http://who-t.blogspot.com.au/2015/12/libinput-and-lenovo-x220-touchpad-v8.1.html

libinput-1.1.3-1.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2015-b8f71b31d1

libinput-1.1.3-1.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
$ su -c 'dnf --enablerepo=updates-testing update libinput'
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-b8f71b31d1

libinput-1.1.4-1.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2015-b6079f1f7e

libinput-1.1.4-1.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-b6079f1f7e

libinput-1.1.4-1.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.