Weston multitouch support?

[Peter Hutterer]

On 3/06/2014 20:25 , Shawn Rutledge wrote:
> On 3 June 2014 01:25, Peter Hutterer <peter.hutterer at who-t.net> wrote:
>> On Mon, Jun 02, 2014 at 12:45:51PM +0100, José Expósito wrote:
>>> Hi Peter,
>>>
>>> I have checked the libinput implementation and, correct me if I'm wrong, I
>>> have seen that 2 fingers click is interpreted as right click, 3 fingers
>>> click is  interpreted as middle click and there are some special rules for
>>> specified trackpads, like corner clicks.
>>
>> there are some special rules for clickpads, specifically a click with a
>> finger resting on one of the software-button areas will produce a right
>> or middle click.
>>
>>> Does that mean that the other MT events are not sent to the clients? Could
>>> it be possible to get the 2 fingers pinch gesture from a QML client for
>>> example?
>>
>> not from a touchpad, not at this point. There are some rough plans but we've
>> pretty much deferred them until we had the basics sorted with libinput.
>
> Qt Quick was designed to take touch points directly and do its own
> gesture interpretation.  But we know that we need to support gesture
> events too, for OSX.  So it will be OK if pinching in Wayland is a
> gesture event rather than two touchpoints, but we really do need to
> have one or the other approach working.  It's unfortunate if a lot of
> time goes by in which neither way works.  (Caveat: I've had a lot of
> trouble getting a qtwayland compositor working well enough to use as
> my main environment, although I'd really like to, so I'm not
> up-to-date on what works and what doesn't at this moment)
>
> Also in X11 I do not have multi-touch interaction with the trackpad on
> my Thinkpad Helix.  I suppose it's because the synaptics driver is not
> going to provide touch events, because it can only interpret a fixed
> set of gestures.  The upside is that I can flick even in rxvt; the
> downside is I can't do pinch gestures anywhere, because X11 protocol
> definition is such a slow process that 7 years after the iPhone
> introduced pinching, we still don't have a pinch event.  At some point
> I was testing Qt Quick with the plain evdev driver with an Apple
> Bluetooth touchpad, that used to provide the actual touch points.  It
> was a better experience for Qt Quick and a worse one for everything
> else.

the synaptics driver does support multitouch and gives you the same type 
of events as any MT device will (if you disable the in-driver gestures). 
It has done so for about 2 years now, no-one ever cared enough about it 
to implement the client stack so this could actually work. Here's the 
thing about the X protocol: it's not this magical self-aware thing, it's 
written by people. If no-one works on it, it doesn't change, which is 
pretty much why it updates so slowly.

So here's a request: write down what exactly you need, what the 
use-cases are, how you want it to behave, etc. That way we can actually 
implement something useful. It's not that we're not listening, it's more 
that no-one is talking until it's too late.

> We do need to have a good strategy for how this stuff is going to work
> better in the future.  That's one purpose for the touch & gestures
> session at the upcoming Qt Contributors Summit:
> https://qt-project.org/groups/qt-contributors-summit-2014/wiki/Program
> although I would be glad to delve deeper into X11 and Wayland
> specifics beyond that session.  It would be good if any of you who
> know the details could attend.
>
> Flicking is a weird case because Qt Quick does its own physics: the
> flicking continues after you release your finger, and there is the
> bounce-back at the end.  On Apple platforms the QtQuick behavior
> doesn't match the native one, so there are discussions about how to
> fix that.  Are you thinking that on wayland the flicking should be
> driven by extra events beyond the actual finger release, which keep
> driving the UI to the end and then sending reversed events to generate
> the bounce-back?  I think the main reason for having a flick gesture
> at all is to enable flicking in legacy applications which were
> designed to handle mouse wheel.  The trouble is that there then has to
> be a mechanism to tell it where the "end" is, for non-legacy
> applications which actually want to have the "bounce" or some other
> end-of-flick behavior.  IMO that's an unfortunate break in
> encapsulation; but if the applications alternatively do their own
> flick physics, they are free to do it differently and inconsistently.
> Same thing with other gestures.  It would be nice to put the gesture
> and related behavioral stuff into a library, so that it's modular and
> optional and can be replaced with an alternate one, and yet if the
> same library is used everywhere, then it's consistent.  Putting this
> stuff at too low a level (like inside the synaptics driver) tends to
> mean that the gestures will be a fixed set, whereas it would be nice
> to be able to invent new ones.

.... and you've just arrived at your favourite holiday destination. on 
your left you can see the rock ("I can't change anything!"), on your 
right the hard place ("Everyone does it differently and nothing behaves 
the same!"). The cooking class starts at 5 and we've got shuffleboard on 
the top deck.

Cheers,
   Peter


(Not that there is any framework which
> makes it easy, yet...)  I think it's unfortunate if there is no way to
> get the actual touch points.  It would be an acceptable compromise if
> the shared gesture library can get them, and applications can get them
> only by explicitly asking for them, and bypassing the gesture library.
>   Then at least everyone knows of a couple of accessible places to do
> the hacking to add new ones or tweak the existing ones, rather than
> having to hack the things that are fixed for most users, such as
> device drivers and compositors.
>
> Wayland (and Qt on Wayland) should end up being more hackable than
> Cocoa, and offer the same or better feature set, not limp along like
> X11 has been.