TLDR: as of libinput 0.16 you can end a touchpad tap-and-drag with a final additional tap
libinput originally only supported single-tap and double-tap. With version 0.15 we now support multi-tap, so you can tap repeatedly to get a triple, quadruple, etc. click. This is quite useful in text editors where a triple click highlights a line, four clicks highlight a paragraph, and 28 clicks order a new touchpad from ebay. Multi-tap also works with drag-and drop, so a triple tap followed by a finger down and hold will send three clicks followed by a single click.
We also support continuous tap-and-drag which is something synaptics didn't support provided with the LockedDrags option: Once the user is in dragging mode (x * tap + hold finger down) they can lift the finger and set it down again without the drag being interrupted. This is quite useful when you have to move across the screen, especially on smaller touchpads or for users that prefer a slow acceleration.
Of course, this adds a timeout to the drag release since we need to wait and see whether the finger comes down again. To help accelerate this, we added a tap-to-release feature (contributed by Velimir Lisec): once in drag mode a final tap will release the button immediately. This is something that OS X has supported for years and after a bit of muscle memory retraining it becomes second nature quickly. So the new timeout-free way to tap-and-drag on a touchpad is now:
tap, finger-down, move, .... move, finger up, tapUpdate 03/06/25: add synaptics LockedDrag option reference
15 comments:
Is there any way to disable tap to drag? I've only just discovered this when I moved from a thinkpad to one with no trackpoint. The tap to drag feature is incredibly frustrating but I've been unable to find any information about how to disable it.
Synaptics does support continuous tap-and-drag. It's just not enabled by default. You can enable it by adding Option "LockedDrags" "1" to 50-synaptics.conf file. It's also possible to define a timeout with Option "LockedDragTimeout" "{desired timeout in ms}".
On Fedora 22 KDE, mouse click-emulation (one-click for left button and two clicks for right button) options are disabled and horizontal scroll can't be disabled. Are these functions not supported in libinput?
veljo: oops, forgot about that option, amended now. Thanks!
Sudhir: horizontal scroll is always on in libinput, it's up to the widgets to decide if it applies or not. Not sure what you mean by mouse-click emulation but the answer is probably here: http://wayland.freedesktop.org/libinput/doc/latest/clickpad_softbuttons.html
> Sudhir: horizontal scroll is always on in libinput, it's up to the widgets to decide if it applies or not.
Not sure what you mean by mouse-click emulation but the answer is probably here: http://wayland.freedesktop.org/libinput/doc/latest/clickpad_softbuttons.html
The settings are grayed out in KDE that would let me disable horizonal scrolling or let set mouse-click emulation. https://imgur.com/20FN49u,oshx9WF#0
Mouse-click emulation means that single tap is assigned as left button, double tap is assigned as right button, and triple click is assigned as middle button. So the touchpad can emulate mouse. libinput seems to support it but again the options are grayed out in KDE.
Do you think this is a KDE problem?
Sudhir: the settings are greyed out because they can't be configured. you can enable/disable tapping but you can't change the button assignment. same with horizontal scrolling - it'll work but you can't turn it on/off separately.
Thanks Peter. So I was breaking out the sweat for no reason :).
About the lack of configuration. Is that something being worked out for future releases?
no plan to add these, they're unnecessary. the horizontal scrolling is something to be handled at a widget level, and I don't see the point of re-arranging the tap buttons.
> I don't see the point of re-arranging the tap buttons.
That's reasonable. Unnecessary configuration leads to problems.
When you say horizontal scrolling is to be handled at widget level do you mean each app should decide how it wants to handle that or if the GUI toolkit should decide how to handle that.
What I notice with horizontal scrolling enabled is that sometimes folks post a 4K picture that spans like 5 pages wide horizontally on a small screen or someone posts code but doesn't use code folding. In that case when you scroll down it also scrolls horizontally, making it hard to focus, because it is not possible to perfectly scroll down human hands. My solution has been to disable horizontal scrolling with touchpad and use mouse when I have to do it.
So, should I assume there is no way to turn off tap-to-drag?
I know I could install *-synaptics but that's only going to work for a few more releases (likely).
Would a bug report be useful?
liam: you can file a bug report, but I don't expect this to change, sorry. All I'll do in the bugreport is close it with a more explanatory message
Hm, that's... rather problematic for me.
I often use my laptop on the bus, and specifically turn off all tapping (at all times, since switching between tap-style usage and button-style usage is silly) because it results in an enormous number of spurious clicks, drags, etc - some of which actively ruin what I'm trying to do, on occasion permanently, when it highlights across an EOL in the terminal and then pastes it from selection.
It's a large part of why I only purchase laptops with physical buttons.
Alex: if you switch off tapping anyway, it shouldn't matter that there's no separate toggle to turn of tap-to-drag, right?
Note that the toggle to turn off tapping is still there and will remain there.
Ah, missed that. Cool, thanks!
I tend to agree with @liam, there really should be a way to turn off "tap and drag". I am constantly accidentally dragging browser tabs to a new window. Peter, what is the rationale for not providing an option to turn this off?
Other than this problem I find libinput much better than synaptics and really appreciate the enormous and quality work you have put in to this.
Post a Comment