Implementing right click and middle click drag

[Peter Hutterer]

On Sat, Jul 14, 2018 at 03:09:40PM +0530, Sagar Tewari wrote:
> Hi,
> 
> This is the proposed design of state machine for implementing right click
> drag as double tap followed by a single tap. I intend to implement the
> middle tap drag in a similar way. The new stuff in inside the dashed
> boundaries. This is the intended behaviour:

Thank you! You're almost there :)
> 
> 1. A double tap followed by a single tap and move will act as a right click
> drag.

first, terminology so we're talking about the same thing: "double", "triple"
etc. always refers to the tap count, "2fg" or "two finger" or some variation
refers to the number of fingers. So a double-tap are two taps in short
succession with one finger. A 2fg triple tap are 3 taps in a row with 2
fingers.

afaict from the state diagram, you mean a 2fg tap followed by a single tap
and move. 

there's a slight error: TOUCH_2_RELEASE -> TOUCH_2_TAPPED should
remove the "second finger down" part because when we get here, there is only
one finger left. In the state diagram, "first/second" unfortunately doesn't
refer to which one was down first, it's more of a finger count. Not sure if
that was your addition or in the current diagram, it should be fixed either
way.


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?

Right now, there's a dead end in it:
TOUCH_2_DRAGGING -> finger up -> draglock enabled -> WITH_LOCK -> finger
down -> POTENTIAL_UNLOCK

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.
I think I'd prefer "TOUCH_2_DRAGGING_WAIT" over TOUCH_2_DRAGGING_WITH_LOCK
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 scroll)

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 :)


> 2. If drag lock is enabled, the user will have to tap to end the right
> click drag.

see above, I think we should have a timeout here as well, just as we have
for the single-finger case. Otherwise it's a bit too unpredictable.

and the code should be fairly straightforward anyway once the diagram is in
shape. but oh boy, the test cases aren't going to be trivial.

Cheers,
   Peter

> Please review it and let me know of any required modifications.
> 
> 
> On Thu, Jul 12, 2018 at 8:22 AM Sagar Tewari <iaansagar at gmail.com> wrote:
> 
> > Thanks, I'll get myself working on it.
> >
> > On Thu, Jul 12, 2018, 08:19 Peter Hutterer <peter.hutterer at who-t.net>
> > wrote:
> >
> >> On Tue, Jul 10, 2018 at 01:06:17PM +0530, Sagar Tewari wrote:
> >> > I would like to work on implementing right and middle click drag as
> >> > two/three finger tap followed by a single tap drag, the way it works in
> >> > synaptics driver. I found that this topic has been discussed previously:
> >> >
> >> https://lists.freedesktop.org/archives/wayland-devel/2017-September/034926.html
> >> >
> >> > But this was the single main on that topic in the archives.
> >> >
> >> > To Peter Hutterer, where can I find the patch being discussed in that
> >> mail?
> >> > Would it be better to start from scratch since the patch was apparantly
> >> > flawed?
> >>
> >> I've forwarded the attachments from that thread to you off-list.
> >>
> >> Basically, that patch was incomplete and didn't handle some states and
> >> transitions. It also wasn't documented clearly, in that it didn't explain
> >> what it *intended* to do. For hairy stuff like this, knowing what the
> >> intention was is more important than the code so we know what is a bug and
> >> what isn't.
> >>
> >> Note that the state machine is the main source of information here, the
> >> actual tapping code is just a bunch of switch statements based on the
> >> state.
> >>
> >> Cheers,
> >>    Peter
> >>
> >
> 
> -- 
> Best Regards
> Sagar Tewari