Weston multitouch support?

[Peter Hutterer]

On Tue, Jun 03, 2014 at 02:13:47PM +0200, Shawn Rutledge wrote:
> On 3 June 2014 13:16, Peter Hutterer <peter.hutterer at who-t.net> wrote:
> > On 3/06/2014 20:25 , Shawn Rutledge wrote:
> ...
> > 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.
> 
> But is disabling in-driver gestures a global thing or can it be done
> only for specific windows?  (Even doing it per-window is not quite an
> ideal solution but could work some of the time)

it's a per-device thing, so effectively global. The driver has no knowledge
of windows, clients or anything like that. So to get this working properly
you'd have to integrate it into the toolkit, and then only use applications
from that toolkit. X having a history of everyone using whatever toolkit
they like (or none at all) this means that you can't really get a meaningful
coherent desktop experience here.

> > 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.
> 
> OK I can try.  In what form and forum would be most helpful?

just here will do, or email me directly if you just want to have some rough
discussion first.

> >> 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.
> 
> But I think a suitable degree of modularity might solve it.  It seems
> in the wayland spirit, just like the debate about window decorations:
> if you want common ones, use a shared library.  If you want to
> decorate your own window, that's easy too.  As long as most
> applications agree to use the same shared library with the same theme,
> unless they have a real reason not to, then the whole desktop
> experience will end up being just as consistent as in X11 when the
> window manager decorates all the windows the same, but with the
> advantage that some of the X11 mess goes away.

yes, but do realise that X comes from a time where this was not realistic.
The presence of half a million window mangers are living proof.
Recent years and the emphasis on this by Wayland hopefully changed the
political landscape enough that we can expect more now, or at least ignore
those that want to go off do their own thing.

> But maybe you are going to say libinput is that library.  If the
> architecture is that you can have multiple compositors and each one
> can use a different modified version of libinput, that sounds kindof
> hackable, but it still might end up mingling device handling and
> gesture recognition and the related physics a bit too much.

I'm saying that ideally all compositors use libinput for the input stack,
without the need to hack around too much of it. libinput is suppposed to be
the "one size fits all", even if in reality this will be "one size doesn't
quite fit anybody but at least it doesn't hurt anymore".

Cheers,
   Peter