With the F22 release, the Thinkpad yoga 15, which has a touchpad similar to *50 thinkpads, the "areas" mode works fine. However, I am seeing some strange behavior in the lower 1 cm of the touchpad when in "fingers" mode (gsettings set org.gnome.desktop.peripherals.touchpad click-method "fingers"). The upper part of this 1 cm gives a right-click when pressing one finger across the whole width of the touchpad. The lower part of the 1 cm gives a left-click accross the whole touchpad. I would expect the whole touchpad to behave equally when in clickfinger mode, needing a two-finger click to yield a right-click. Here is the result from running touchpad-edge-detector: sudo touchpad-edge-detector /dev/input/event6 Touchpad AlpsPS/2 ALPS DualPoint TouchPad on /dev/input/event6 Move one finger around the touchpad to detect the actual edges Kernel says: x [0..4095], y [0..2047] Touchpad sends: x [111..3968], y [99..1963] |\ Touchpad sends: x [109..3970], y [96..1963] - Touchpad sends: x [106..3970], y [96..1963] | Touchpad sends: x [105..3974], y [96..1963] / Touchpad sends: x [105..3974], y [96..1963] | Touchpad sends: x [105..3974], y [96..1963] \^C
Just to clarify, the touchpad buttons work, two-finger right-click works on the whole touchpad, except for the bottom 1 cm mentioned above.
install evemu please and run sudo evemu-record against the touchpad, then record one sequence of each click that generates the wrong events and attach them here.
Created attachment 1032218 [details] single-click left One single-click bottom left. This generates a right-click behaviour, which I did not expect.
Created attachment 1032219 [details] single-click right Same thing for single-click right.
Both logs were captured with gsettings get org.gnome.desktop.peripherals.touchpad click-method 'fingers' I did not bother logging the tiny strip of left-click all the way at the bottom for now, since this is a marginal issue compared to the "right-click problem".
Definitely a kernel issue, the touchpad data is bogus. If you look at the very first event in both recordings, you see that you get a second touch in slot 1 with a location of: E: 0.000000 0003 0035 4080 # EV_ABS / ABS_MT_POSITION_X 4080 E: 0.000000 0003 0036 0000 # EV_ABS / ABS_MT_POSITION_Y 0 So libinput legitimately thinks that there are two fingers on the touchpad. I wonder if this is related to this bug here: https://bugzilla.redhat.com/show_bug.cgi?id=1221200, maybe you can test the kernel scratch build provided there?
Hi, this works much better with the scratch build, so it could probably be marked as a duplicate of that bug. I am still seeing some issues in the 4-5 lowest mm of the touchpad. I remember seeing this: "On some touchpads, notably the 2015 Lenovo X1 Carbon 3rd series, the very bottom end of the touchpad is outside of the sensor range but it is possible to trigger a physical click there. To libinput, the click merely shows up as a left button click without any positional finger data and it is impossible to determine whether it is a left or a right click. libinput ignores such button clicks, this behavior is intentional." under "software button areas" here: http://wayland.freedesktop.org/libinput/doc/latest/clickpad_softbuttons.html and I am indeed seeing this behavior when in "areas" click-method mode with the Thinkpad yoga 15. But since this behavior is not mentioned under "Clickfinger behavior", I attach some info on this as well.
Created attachment 1033610 [details] double-click left bottom This does not register as a right-click in gnome.
Created attachment 1033611 [details] double-click right bottom does not register as a right-click by gnome
(In reply to Peter Hutterer from comment #6) > Definitely a kernel issue, the touchpad data is bogus. If you look at the > very first event in both recordings, you see that you get a second touch in > slot 1 with a location of: > > E: 0.000000 0003 0035 4080 # EV_ABS / ABS_MT_POSITION_X 4080 > E: 0.000000 0003 0036 0000 # EV_ABS / ABS_MT_POSITION_Y 0 Yes those are the same "magically wrong" coordinates as in bug 1221200, definitely the same issue. (In reply to Tommy from comment #7) > Hi, this works much better with the scratch build, so it could probably be > marked as a duplicate of that bug. > > I am still seeing some issues in the 4-5 lowest mm of the touchpad. I > remember seeing this: > > "On some touchpads, notably the 2015 Lenovo X1 Carbon 3rd series, the very > bottom end of the touchpad is outside of the sensor range but it is possible > to trigger a physical click there. To libinput, the click merely shows up as > a left button click without any positional finger data and it is impossible > to determine whether it is a left or a right click. libinput ignores such > button clicks, this behavior is intentional." > > under "software button areas" here: > http://wayland.freedesktop.org/libinput/doc/latest/clickpad_softbuttons.html > > and I am indeed seeing this behavior when in "areas" click-method mode with > the Thinkpad yoga 15. > > But since this behavior is not mentioned under "Clickfinger behavior", I > attach some info on this as well. For the clickfinger case when clicking in the area of the pad which does not actually contain a sensor we simply always report a left click, there is nothing else we can do since when you have your fingers where there is no sensor we do not know how much fingers you are using. For clickfinger we've chosen to always do a left click instead of ignoring the click when we see no fingers since many people click at the edge with their thumb, and when they do so they want a left click. So for right clicks with clickfinger you will simply need to avoid using the bottom edge. *** This bug has been marked as a duplicate of bug 1221200 ***
Ok, thanks for the effort guys!