[PATCH libinput v2 0/4] touchpad gestures support

[Carlos Garnacho]

Hey Peter :),

On Mon, Apr 27, 2015 at 6:01 AM, Peter Hutterer
<peter.hutterer at who-t.net> wrote:
> On Fri, Apr 24, 2015 at 02:39:07PM +0200, Carlos Garnacho wrote:
>> On Fri, Apr 24, 2015 at 1:49 PM, Hans de Goede <hdegoede at redhat.com> wrote:
>> > Hi,
>> >
>> > On 24-04-15 13:39, Carlos Garnacho wrote:
>> >>
>> >> Hey Hans :),
>> >>
>> >> On jue, 2015-03-26 at 10:04 +0100, Hans de Goede wrote:
>> >>>
>> >>> Hi All,
>> >>>
>> >>> Here is v2 of my touchpad gestures support patch series, changes
>> >>> since v1:
>> >>> - Merge the gesture capability flag and event-debug patched into
>> >>>    the "touchpad: Add an API for touchpad gesture events"
>> >>> - Update the swipe and pinch/rotate implementations to work with the
>> >>> new
>> >>>    typesafe device and normalized coordinates (rebased on latest
>> >>> master),
>> >>>    this results in a nice cleanup
>> >>
>> >>
>> >> During the last days I played with these last patches on Clutter, and
>> >> found the gestures to work nicely. I gathered some observations though:
>> >>
>> >>        * Higher level gesture implementations usually have a "cancel"
>> >>          signal/vfunc, it feels kind of weird not being able to fully
>> >>          map the behaviors. I thought about some "this gesture maybe
>> >>          continues onto something else" flag in *_END events, although
>> >>          I see this working better on touchpoints being added than
>> >>          lifted, given how things seem to work. Anyway, just a remark,
>> >>          I see cancellation being more important in the protocol
>> >>          additions this would bring, when this involves client vs
>> >>          compositor handling.
>> >
>> >
>> > As discussed at Fosdem, adding a flag to indicate of the gesture
>> > ended normally (all fingers lifted) or by transitioning into something
>> > else is easy code wise. If you see a need for that I can do so for v3
>> > of the patch-set.
>>
>> That would be great, I guess my concern is mostly being consistent
>> with wl_touch.cancel, and being able to undo ongoing actions in
>> clients if the compositor is taking over.
>>
>> >
>> >>        * I think it is a bit unfortunate that distance in pinch
>> >>          gestures is relative. Higher level equivalent "zoom" gestures
>> >>          usually offer absolute scale values (taking the initial
>> >>          distance as 1x). We do lack some information there to
>> >>          translate from one to the other, I guess either knowing the
>> >>          initial distance (does pointer acceleration apply here?), or
>> >>          offering similar info right away would be nice.
>> >
>> >
>> > I've been ping-ponging between giving deltas or an absolute distance
>> > in mm. I can change the patch-set to report a distance in mm instead
>> > of delta from the previous distance, with the caveat that on some
>> > touchpads we do not know the resolution so the unit there will
>> > not be mm, but instead unknown stepsize.
>>
>> Hmm, that's indeed a drawback. I guess having an additional
>> libinput_event_gesture_get_scale() is not as stateless as you'd want?
>> If we have to choose between deltas or abs distance, I feel the latter
>> is most useful though...
>
> right, so if I read this right what you want is have the first gesture event
> with a scale value of 1.0 and then every subsequent one as a fraction or
> multiple of that initial value. so 0.5 means the fingers moved together by
> 50%, 2.0 would mean twice as far apart now.

Yeah, that's 1:1 with how Clutter/Gtk+ equivalent "zoom" gestures work.

> that'd easy enough to add and be independent of the resolution, though it
> obviously can't work on swipe gestures.

My concern here is mainly about relative distance on pinch. Relative
angle changes are workable, dx/dy values are too as long as there's
some relation between these and pointer movement, which there seems to
be.

Cheers,
  Carlos