Implementing right click and middle click drag

Sagar Tewari iaansagar at
Fri Jul 20 05:40:32 UTC 2018

On Wed, Jul 18, 2018 at 1:52 PM Peter Hutterer <peter.hutterer at>

> I'm not sure about the WITH_LOCK and POTENTIAL_UNLOCK parts, they should be
> (in theory) the same as the existing ones where DRAGGING_WAIT goes back to
> DRAGGING or DRAGGING_OR_TAP. Can you double-check this please whether it
> would work out?

​I've modified the state diagram so that the logic and nomenclature are
equivalent to the already present left tap drag logic.

> Right now, there's a dead end in it:
> TOUCH_2_DRAGGING -> finger up -> draglock enabled -> WITH_LOCK -> finger
> If the finger is now labelled as palm or thumb, you're stuck in
> DRAGGING_WITH_LOCK until the next finger is down, never releasing.
> This seems to be intended (your point 2.) but we definitely need a timeout
> here. Imagine doing this, waiting 10 sec and then still continuing with the
> dragging on the next touch - not what the user would expect.
> so DRAGGING_WITH_LOCK needs a timeout to go to the button 2 release.
> then to make it more consistent to the 1fg case.
> And TOUCH_2_DRAGGING_DOWN for no other reason than it's more expressive of
> the state and closer to the MULTITAP_DOWN naming scheme.
> oh, found another one: in POTENTIAL_UNLOCK you may get a second finger down
> - what do we do then? Either we go all the way back to TOUCH_2 which gives
> us the ability to right-click-drag and right-click. Or we go to some new
> state and resolve the 2fg tap as "end the draglock" tap. I really don't
> know
> which one is the more obvious one here.
> This has the potential to interfere with 2fg scrolling too:
> - draglog is enabled
> - 2 fingers down and up
> - 1 finger down, dragging
> - 1 finger up
> - 2 fingers down and dragging (2fg scrol
> ​
> l)
> ​
​In synaptics driver it's possible to scroll by putting down a second
finger while dragging with a tap, it's super useful for selecting large
texts on webpages and in tools like blender. Would it be possible for
libinput to behave similarly? It looks like this too would require
duplicating the code and states for left, right and middle clicks.

As a side note, would it be possible to make the state machine more
abstract, so that the similar behaviors for all the mouse buttons could be
handled with the same code? Maybe it won't be worth it, since the state
machine is a relatively short part of the libinput source.

Right now, this would... uhm, land us in TOUCH_2_DRAGGING, so it'd be a 2fg
> scroll with the right button held down. And (hopefully) a warning in the
> code about an invalid state ;)
> Oh, and once you handle the second finger down in POTENTIAL_UNLOCK you now
> have to resolve a third finger down in whatever state comes next. Good
> luck :)

Best Regards
Sagar Tewari
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: touchpad-tap-state-machine (5).svg
Type: image/svg+xml
Size: 212248 bytes
Desc: not available
URL: <>

More information about the wayland-devel mailing list