Description of problem: After upgrading libinput from 0.19.0-3 to 0.20.0-1, two-finger scroll stopped working on my rather old MacBook (white model, touchpad with just one physical button). All other features (two / three finger click) do work, even though the pointer velocity is far higher than before the update. I had to tweak the velocity slider in the gnome control panel in the first 5-10% of the range to get a somewhat result. However, moving the pointer a small distance is still very difficult. Before the update, my velocity setting was about 75%. Version-Release number of selected component (if applicable): 0.20.0-1 Additional info: $ journalctl -b | grep -i touch Jul 24 20:48:46 HOSTNAME kernel: appletouch 2-2:1.1: Geyser mode initialized. Jul 24 20:48:46 HOSTNAME kernel: input: appletouch as /devices/pci0000:00/0000:00:1d.0/usb2/2-2/2-2:1.1/input/input15 Jul 24 20:48:46 HOSTNAME kernel: usbcore: registered new interface driver appletouch Jul 24 20:49:12 HOSTNAME gnome-session[1292]: libinput error: kernel bug: appletouch: non clickpad without right button? Jul 24 20:49:44 HOSTNAME /usr/libexec/gdm-x-session[1774]: (II) config/udev: Adding input device appletouch (/dev/input/event9) Jul 24 20:49:44 HOSTNAME /usr/libexec/gdm-x-session[1774]: (**) appletouch: Applying InputClass "evdev touchpad catchall" Jul 24 20:49:44 HOSTNAME /usr/libexec/gdm-x-session[1774]: (**) appletouch: Applying InputClass "touchpad catchall" Jul 24 20:49:44 HOSTNAME /usr/libexec/gdm-x-session[1774]: (**) appletouch: Applying InputClass "Default clickpad buttons" Jul 24 20:49:44 HOSTNAME /usr/libexec/gdm-x-session[1774]: (**) appletouch: Applying InputClass "libinput touchpad catchall" Jul 24 20:49:44 HOSTNAME /usr/libexec/gdm-x-session[1774]: (II) Using input driver 'libinput' for 'appletouch' Jul 24 20:49:44 HOSTNAME /usr/libexec/gdm-x-session[1774]: (**) appletouch: always reports core events Jul 24 20:49:44 HOSTNAME /usr/libexec/gdm-x-session[1774]: (II) input device 'appletouch', /dev/input/event9 is tagged by udev as: Touchpad Jul 24 20:49:44 HOSTNAME /usr/libexec/gdm-x-session[1774]: (EE) kernel bug: appletouch: non clickpad without right button? Jul 24 20:49:44 HOSTNAME /usr/libexec/gdm-x-session[1774]: (II) input device 'appletouch', /dev/input/event9 is a touchpad Jul 24 20:49:44 HOSTNAME /usr/libexec/gdm-x-session[1774]: (II) XINPUT: Adding extended input device "appletouch" (type: TOUCHPAD, id 11) Jul 24 20:49:44 HOSTNAME /usr/libexec/gdm-x-session[1774]: (**) appletouch: (accel) selected scheme none/0 Jul 24 20:49:44 HOSTNAME /usr/libexec/gdm-x-session[1774]: (**) appletouch: (accel) acceleration factor: 2.000 Jul 24 20:49:44 HOSTNAME /usr/libexec/gdm-x-session[1774]: (**) appletouch: (accel) acceleration threshold: 4 Jul 24 20:49:44 HOSTNAME /usr/libexec/gdm-x-session[1774]: (II) input device 'appletouch', /dev/input/event9 is tagged by udev as: Touchpad Jul 24 20:49:44 HOSTNAME /usr/libexec/gdm-x-session[1774]: (EE) kernel bug: appletouch: non clickpad without right button? Jul 24 20:49:44 HOSTNAME /usr/libexec/gdm-x-session[1774]: (II) input device 'appletouch', /dev/input/event9 is a touchpad Jul 24 20:49:44 HOSTNAME /usr/libexec/gdm-x-session[1774]: (II) config/udev: Adding input device appletouch (/dev/input/mouse0)
pretty sure this is caused by the new size handling, see http://who-t.blogspot.com.au/2015/07/libinput-and-handling-resolution-less.html please attach the evemu-describe output of your device, together with the physical size of the touchpad in mm
Created attachment 1056731 [details] output of evemu-describe The touchpad has a physical size of 100x48mm.
give this one a try please. It should set the LIBINPUT_ATTR_SIZE_HINT property on the device which translates into a resolution. http://koji.fedoraproject.org/koji/taskinfo?taskID=10500592 After installing, run udevadm info /sys/class/input/eventX to check if the property appears (for your touchpad device), then restart X and it should work better
udevadm reports the LIBINPUT_ATTR_SIZE_HINT and pointer movement feels a lot better now, thanks. Was this supposed to also fix two-finger scroll? And should the nonzero resolution values also be reported by evemu-describe? I just noticed that the reported maximum values of ABS_X / ABS_Y are lower than the actual highest values. Are the max. values used somewhere? The reported ones are 1215 and 575, whereas a quick try with evemu-record gave values up to 1468 for ABS_X and 825 for ABS_Y. Further, the pointer does not move when I put my finger down at the right ~15%-20% of the touchpad and move it left. However, I can use this area of the touchpad when I start in the center and also for edge scrolling, if I enable that.
(In reply to Simon Lanzmich from comment #4) > udevadm reports the LIBINPUT_ATTR_SIZE_HINT and pointer movement feels a lot > better now, thanks. thanks for testing, I'll get that upstream then > Was this supposed to also fix two-finger scroll? And should the nonzero > resolution values also be reported by evemu-describe? no, I think you're seeing the same as bug 1246868, i.e. a distance too big to be detected as scrolling. You can verify that running libinput-debug-events and check if you get gesture pinch events when you should be getting scroll events. The udev property is only used by libinput, it doesn't modify the kernel device. so evemu-describe wouldn't see it. > I just noticed that the reported maximum values of ABS_X / ABS_Y are lower > than the actual highest values. Are the max. values used somewhere? The > reported ones are 1215 and 575, whereas a quick try with evemu-record gave > values up to 1468 for ABS_X and 825 for ABS_Y. right, I'll get that fixed too then. run the touchpad-edge-detector tool from libevdev-utils and let me know about the dimensions you find. > Further, the pointer does not move when I put my finger down at the right > ~15%-20% of the touchpad and move it left. However, I can use this area of > the touchpad when I start in the center and also for edge scrolling, if I > enable that. yeah, not suprising, looks like the max value is off by about 20%. will go away once we fix the max values, but I'll have a look anyway for that case.
libinput-0.20.0-5.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/libinput-0.20.0-5.fc22
(In reply to Peter Hutterer from comment #5) > no, I think you're seeing the same as bug 1246868, i.e. a distance too big > to be detected as scrolling. You can verify that running > libinput-debug-events and check if you get gesture pinch events when you > should be getting scroll events. libinput-debug-events does not show any events when I try to scroll. When I (try to) scroll, the distance between the two fingers should be well under 30 mm. I'll attach output from evemu-record from a single two-finger scroll attempt in case that helps. > right, I'll get that fixed too then. run the touchpad-edge-detector tool > from libevdev-utils and let me know about the dimensions you find. $ sudo touchpad-edge-detector /dev/input/event8 Touchpad appletouch on /dev/input/event8 Move one finger around the touchpad to detect the actual edges Kernel says: x [0..1215], y [0..575] Touchpad sends: x [256..1471], y [256..831] Apparently, these values seem to be just 256 higher than the reported ranges.
Created attachment 1057216 [details] output of evemu-record for a single two-finger scroll attempt
haha, found it. your touchpad is a partial multi-touch touchpad [1] and can only track one finger but detect up to 3. The gesture code that now handles scrolling too only looked at real tracked touches, not the others. give this one a try please: http://koji.fedoraproject.org/koji/taskinfo?taskID=10521896 [1] http://who-t.blogspot.com.au/2015/07/a-short-overview-of-touchpad-devices.html
Yes, that one makes scrolling work again. Thanks. On the issue of the ABS_X / ABS_Y values apparently being 256 too high: Is that a driver issue or something to be worked around in libinput?
it's a kernel driver issue, but it can be fixed through systemd's hwdb. I just need to backport that part to F22 first before we can add it (got it locally already). For the upstream file that manages these things see: http://cgit.freedesktop.org/systemd/systemd/tree/hwdb/60-evdev.hwdb just bear with us, it's a couple of pieces that we need to fall into place before it works.
libinput-0.20.0-6.fc23 has been submitted as an update for Fedora 23. https://admin.fedoraproject.org/updates/libinput-0.20.0-6.fc23
libinput-0.20.0-6.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/libinput-0.20.0-6.fc22
Sure, I just was curious, and thanks for the hint. Sorry if that sounded impatient. If you need a proper name for that hwdb file: my computer is a Macbook2,1 (Late 2006).
no worries, didn't interpret it as such. the update package above is the libinput bit which should make things work, except for the 256 offset. The pull request for upstream systemd is here: https://github.com/systemd/systemd/pull/783 And keep an eye out on systemd updates for F22, one of the next ones should pull the infrastructure in to override this.
Package libinput-0.20.0-6.fc23: * should fix your issue, * was pushed to the Fedora 23 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing libinput-0.20.0-6.fc23' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-12385/libinput-0.20.0-6.fc23 then log in and leave karma (feedback).
libinput-0.20.0-6.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
libinput-0.20.0-6.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.