[RFC libinput] Add an API for touchpad gesture events

[Carlos Garnacho]

Hey Hans,

On mié, 2015-01-28 at 08:38 +0100, Hans de Goede wrote:
> Hi,
> 
> On 23-01-15 14:57, Hans de Goede wrote:
> > Hi,
> >
> > On 23-01-15 14:53, Jonas Ådahl wrote:
> >> On Fri, Jan 23, 2015 at 12:18:01PM +0100, Hans de Goede wrote:
> >>> Hi,
> >>>
> >>> On 23-01-15 05:21, Peter Hutterer wrote:
> >
> > <snip>
> >
> >>>>> +double
> >>>>> +libinput_event_gesture_get_absolute_x(struct libinput_event_gesture *event);
> >>>>
> >>>> this is a bit inconsistent with the other API where absolute_x returns a
> >>>> value in mm. I think we should do that here as well and provide
> >>>> get_absolute_x_transformed - callers that need it in relation to the
> >>>> touchpad size can just provide 1.0 as width/height.
> >>>
> >>> I don't think mm is really interesting on a touchpad, and in many cases if we
> >>> say this is in mm we would be lying as we do not know the exact dimensions. I
> >>> see using (fake) mm-s here and then having users call get_absolute_x_transformed
> >>> with 100 or 1.0 to get the percentage they very likely want from the beginning
> >>> as just adding baggage without any gain.
> >>>
> >>> The intend behind these absolute coordinates is for them to be used in e.g.
> >>> a virtual desktop switching animation when switching using a swipe, this way the
> >>> user can start a swipe, see the new virtual desktop, realize it is the wrong one
> >>> and abort, or if it is the right one continue, and then past say 2/3ths of the
> >>> touchpad the animation will show the new virtual desktop locking into place, and
> >>> the user will know he can stop swiping. Notice the key thing here is the swipe
> >>> reaching the 2/3th threshold, not some magical amount of (fake) mm-s.
> >>>
> >>> Carlos, Jonas what do you think ?
> >>
> >> That would still be possible with a mm based absolute coordinate as we
> >> can retrieve the physical dimension of the touchpad with
> >> libinput_device_get_size(). And as long as the driver gives us reasonably
> >> correct physical dimension data, the mm-s aren't fake; or do you mean
> >> most drivers lie to us? It'd be better also not to have it simply 1.0 x
> >> 1.0, as that'd make making a circle on the device result in an ellipse in
> >> the API.
> >>
> >> Since we already do mm-s everywhere, I don't see it that horrible to not
> >> drop that information here in order for some smart future usage, or at
> >> least consistency.
> >
> > Ok, I'll change this to mm for v3 then (just send v2 addressing the other
> > review comments and adding a core implementation).
> 
> So I've been thinking more about this and I'm still not fully convinced, let
> me explain.
> 
> The problem is that the edges where a swipe begins and end may vary based
> on config settings and even per swipe.
> 
> e.g. If a clickpad is using softbutton areas on the bottom, and the user
> swipes up, the swipe gesture will not start until the fingers have left the
> bottom button area, because before that they are seen as fingers resting to
> click the buttons, so for that gesture the bottom edge would be the top edge
> of the button area.
> 
> But if the user swipes down, he can use the bottom button area because fingers
> are only not counted as active there, when they've started there.
> 
> Now we could always only count the non soft-button area as the area to which
> absolute gesture coordinates should be compared to see where on the touchpad
> the gesture is, but what if clickfinger is enabled, then there is no soft
> button area?  Then what if the user changes the clickfinger setting ?
> 
> A solution to this would be putting the relevant area in the gesture event,
> and documenting that it may differ per event and that users should always
> compare absolute coordinates to the area relevant for that device. But this
> does not sound like a very nice API to me, and also makes me worry about the
> wayland protocol.

I'm maybe missing something, but how is the area relevant for anything
else than finding out whether a touch is eligible to start a gesture?
After that all that should matter is the relative position of the
involved touches.

> 
> All in all this sounds very much NOT kiss, and I'm a big fan of kiss, so I
> really believe that the initially proposed 0.0 - 1.0 scale is much better,

But we get back here to the stretched rectangle case :(. IMO there
should be a way to know about the proper w/h ratios at least.

> it already gives apps way more info then the current gtk and mac os x api-s
> do, as those both only give deltas, while turning all the above into an
> implentation detail, rather then something which we need to explain in API
> docs. The above is exactly why we want to do the gesture handling inside
> libinput in the first place, and exporting absolute event data in mm, unhides
> all the nitty gritty we're trying to abstract away in the first place.

I don't think it's incompatible, given that libinput determines first
whether the touch is part of a gesture before letting know of it.

Cheers,
  Carlos