Very user friendly. [LWN.net]

Very user friendly.

Posted Jun 11, 2025 6:12 UTC (Wed) by DemiMarie (subscriber, #164188)
In reply to: Very user friendly. by LtWorf
Parent article: Ubuntu 25.10 to drop support for GNOME on Xorg

Has a bug been reported to upstream?

to post comments

Very user friendly.

Posted Jun 11, 2025 8:48 UTC (Wed) by LtWorf (subscriber, #124958) [Link] (9 responses)

Of course. https://gitlab.freedesktop.org/libinput/libinput/-/issues...

User-unfriendly hardsoftware

Posted Jun 11, 2025 10:22 UTC (Wed) by jengelh (subscriber, #33263) [Link] (2 responses)

If anything, touchpad scrolling functions seems so arbitrary, as in, every hard-software combination seems to do their own style.

With the contemporary touchpad model I have, scrolling is done by two-finger dragging, anywhere on the pad.
I remember a time when the touchpad area was divided into two sections, like 90%-10%, and scrolling vertically would be accomplished by dragging a single finger in the 10% region, mimicing dragging a sliderbar on the edge of the screen. (Maybe that's still the case for trivial touchpads that don't support multi-finger gestures?)
So, it's interesting to see that you use a third method of holding one finger and dragging the second. Not sure if it's a case of xkcd.com/927 (Standards) or xkcd.com/1172 (Workflow).

sigh. Everyone should just use the PgDn key, but at the same time, laptop keyboards have turned garbage in the past 25 years, first shrinking movement keys and then moving it to a Fn shift sequence. Outrageous. (Framework, you're in this as well!)

User-unfriendly hardsoftware

Posted Jun 11, 2025 11:27 UTC (Wed) by whot (subscriber, #50317) [Link] (1 responses)

> I remember a time when the touchpad area was divided into two sections, like 90%-10%

This is called "edge scrolling" and is one configuration setting away: https://wayland.freedesktop.org/libinput/doc/latest/scrol...
Touchpads are barely little more than touchscreens with a button behind the hinge (if that) and virtually all functionality is purely implemented in userspace.

User-unfriendly hardsoftware

Posted Jun 11, 2025 14:00 UTC (Wed) by Wol (subscriber, #4433) [Link]

> This is called "edge scrolling" and is one configuration setting away:

This is the problem. It sounds like the *default* has been "deprecated", and if you don't know where it went, you're up s*** creek.

This is far too much the norm nowadays.

Cheers,
Wol

Very user friendly.

Posted Jun 11, 2025 12:45 UTC (Wed) by zdzichu (subscriber, #17118) [Link] (5 responses)

I can't comprehend what's going on with libinput. From my understanding of the ticket:
– it cares about pressure user's finger exerts on touchpad
– based on pressure, it decides if user used thumb or other finger
– if it decides it was a thumb, then libinput behaves differently than if it was other finger.

I may be wrong, but above sound like very hacky and terrible heuristics.

(FTR, I had many thinpads, currently using t480s and T15 AMD gen2, and the touchpads work fine, although trackpoint is the primary pointing device in them)

Very user friendly.

Posted Jun 11, 2025 15:05 UTC (Wed) by LtWorf (subscriber, #124958) [Link]

I have another much older thinkpad that works ok with libinput (not better, or equally, so I use Xorg and no libinput).

Very user friendly.

Posted Jun 13, 2025 13:33 UTC (Fri) by mgedmin (guest, #34497) [Link] (3 responses)

AFAIU from bug comments there what's happening there is that libinput implements gestures (such as pinching), and so it waits a bit more (4 mm of motion in one finger) before starting to scroll, while the Xorg synaptics drive doesn't support gestures and can start scrolling immediately. And then the suggested workaround to disable gesture support doesn't work for unclear reasons.

Very user friendly.

Posted Jun 13, 2025 16:10 UTC (Fri) by LtWorf (subscriber, #124958) [Link] (2 responses)

That's the hypothesis. But I don't think that's it. It takes centimeters to trigger it.

Very user friendly.

Posted Jun 13, 2025 17:17 UTC (Fri) by LtWorf (subscriber, #124958) [Link] (1 responses)

So in the end the issue is closed but 2 finger scrolling does not work. Do you see any willingness to fix it?

Very user friendly.

Posted Jun 13, 2025 23:06 UTC (Fri) by whot (subscriber, #50317) [Link]

> So in the end the issue is closed but 2 finger scrolling does not work. Do you see any willingness to fix it?

The first bugbot comment explicitly states: "we close it, you re-open it when whatever above has been addressed and
then we know we need to look at it again." (and why we use this approach).

So if it's still an issue please re-open and supply any useful log files because writing a statement like "It takes centimeters to trigger it." deep inside LWN comments instead of the gitlab report is not usually going to help getting things fixed. You didn't mention this when I explained the 4mm threshold.

Reading through this again, the answer of "Is there's a chance that you're seeing the erratic behaviour because the second finger may rest in the button area? If you change to clickfinger (--set-click-method=clickfinger in debug-events) does this fix the issue?" was met with a statement about libinput having the wrong default for buttons for you. But that question is still pending.

But, from a personal POV: complaining multiple times in other forums about a project instead of providing the info in the issue trackers is not going to make the maintainers more eager to help. The time I spent writing this could've been spent triaging or fixing some other issue...