[PATCH weston v2 3/5] compositor: Emit wl_pointer_gesture_* events on libinput gesture events

Jonas Ådahl jadahl at gmail.com
Wed Jul 29 19:10:45 PDT 2015


On Wed, Jul 29, 2015 at 06:38:10PM -0700, Bill Spitzak wrote:
> On Wed, Jul 29, 2015 at 6:02 PM, Jonas Ådahl <jadahl at gmail.com> wrote:
> 
> >
> > We are not going to just provide libinput events via Wayland. It simply
> > doesn't work. Also the Wayland protocol is different and needs to be
> > different because it has to deal with protocol objects, destruction etc.
> >
> 
> What I meant is that there would be a wayland protocol object (perhaps
> wl_pointer_gestures) and it would deliver a wayland-style event
> (wl_gesture_event), but the contents of the event would be a copy of the
> libinput_gesture_event fields, including the enumeration saying what
> gesture it is and whether it is a begin or end. It seems that the current
> design means that every time a new gesture is added to libinput, the
> wayland server will need to be rewritten to pass that new event through,
> and so would every intermediate library such as toolkits. Also it is
> producing a lot of code bloat (every new method and protocol object and
> event adds a fairly large table to the api library, especially libraries
> written for languages other than C) and the possibilities of mistakes.

libinput is an implementation detail in a potential compositor. Some
compositors may not want to use libinput. Some compositors may not have
any use for it because they are purely remote desktop capable
compositors. I don't think it is a good idea to just forward libinput
evens partly for this reason. Another reason is that the protocol would
not be properly versioned. There would be no way for the client to know
what version would emit what events. To make it versioned, the protocol
would be bumped to "synchronize" with libinput versions and somehow copy
this version separation in the input layer. Another reason is that it is
not possible "just copy" the fields since the types are incompatible.
Another reason is that libinput events are extendable. A swipe gesture
has different fields than a pinch gesture. A potential protocol event
would need to contain all potential fields and only a few would be valid
for any event, without the possibility to specify this in the protocol.
Introducing new types of gestures would not work either, since they'd
most likely contain new fields, and we'd need to update the protcol
anyway.


Jonas


More information about the wayland-devel mailing list