[RFC libinput] Add an API for touchpad gesture events

[Hans de Goede]

Hi,

On 28-01-15 19:18, Carlos Garnacho wrote:
> Hey,
>
> On mié, 2015-01-28 at 15:51 +0100, Hans de Goede wrote:
>> Hi,
>>
>> On 28-01-15 13:59, Carlos Garnacho wrote:
>>> Hey Hans!,
>>>
>>> (sorry for chiming in late, things got busy around Fosdem...)
>>>
>>> On jue, 2015-01-22 at 16:52 +0100, Hans de Goede wrote:
>>>> +	LIBINPUT_EVENT_GESTURE_SWIPE_START = 600,
>>>> +	LIBINPUT_EVENT_GESTURE_SWIPE,
>>>> +	LIBINPUT_EVENT_GESTURE_SWIPE_END,
>>>>    };
>>>>
>>>
>>> One thing I'm unsure about this approach. Is there any plan to support
>>> continuation and chaining-up of gestures?
>>>
>>> Eg. what would happen if a 3fg gesture is started and the user rests a
>>> 4th finger on the touchpad? would you get SWIPE_END for 3fg and
>>> SWIPE_START for 4fg?
>>
>> If we detect that the finger is just resting, e.g. we think it is a palm,
>> then the 3fg gesture continues. If we believe it is an active finger
>> then yes you would get a SWIPE_END for 3fg and SWIPE_START for 4fg,
>> note that the implementation will ignore short (in duration) changes,
>> so e.g. a quick accidental brush with an extra finger, or shortly
>> lifting one finger will be seen as the gesture continuing as normal.
>>
>>> How would the compositor know whether the gesture
>>> finished in a non misleading way?
>>
>> By the LIBINPUT_EVENT_GESTURE_SWIPE_END, if we send that too soon, then
>> that would be a libinput implementation bug.
>>
>>> What I would expect it to happen is that the compositor cancelled the
>>> reaction to the 3fg swipe in this situation.
>>
>> Right.
>
> My concern is, where is this expected to happen? If you get SWIPE_END
> for 3fg before SWIPE_BEGIN for 4fg, how can you tell whether the gesture
> actually finished or shifted into something else, other than waiting if
> something else happens after?
>
>>
>>> If OTOH gestures aren't continued, it would seem to me like confusing
>>> behavior, esp if this already happens between 1fg and 2fg (moving the
>>> pointer and then scrolling, although not back)
>>
>> The plan is to use the same code for all "mode" switches, so you will
>> be able to go back from 2fg scrolling to controlling the pointer by
>> lifting only a single finger (and then waiting for the accidental
>> change timeout, likely 200ms or so. Note that Peter has already fixed
>> this particular case independent of the gesture stuff.
>
> Ah, that's great.
>
> I was making though a concrete example of the more general case. Let me
> go through what happens as fingers come and go in a gesture:
>
> * Switching from pointer movement to two finger scrolling implies no
> cancellation of operations whatsoever, you just stop moving the pointer.
>
> * Switching from scrolling either back to 1fg pointer movement or
> farther to 3fg swipe most likely won't bring in anything to cancel
> (kinetic scrolling triggered on clients might be something, but not that
> you'd usually cancel in these situations,  the story changes if you
> switch to 2fg pinch/zoom though, you don't want to zoom *and* keep
> scrolling)
>
> * Going forward, things change somewhat, compositor level gestures would
> rather usually trigger actions when the gesture finishes, furthermore
> these actions could force you into a completely different context (think
> workspace switching, or session locking). Here is where I find it
> crucial to know the terms in which a gesture finished.

I think you're mixing up API vs implementation here. From an API user
point of view, which the compositor is the gesture is finished when you get
a LIBINPUT_EVENT_GESTURE_FOO_END event, simple as that.

If it turns out that in some cases we're sending a LIBINPUT_EVENT_GESTURE_FOO_END
event before the user is really finished with the gesture and then end
up also sending a bunch of other events which should have been part of
the gesture, then that is an implementation bug, which we should (and
can) fix if / when we encounter such issues.

Regards,

Hans