Code sharing between compositors and some anti-FUD (Re: [PATCH weston 0/5] Touchpad support)

Pekka Paalanen ppaalanen at
Fri May 11 00:41:26 PDT 2012

On Thu, 10 May 2012 09:45:44 -0700
Christopher James Halse Rogers < at>

> This brings up something that I've been wondering: what (if anything) is
> the long-term plan for input in Weston - and Wayland compositors in
> general?
> Is Weston going to essentially fold in all the interesting bits from all
> the input DDXs to the core (and require this to be duplicated in all
> other compositors), or should these conceptually be modules, eventually
> crystallising as an input-module ABI compositors could share?
> I think I'd like the latter to happen, but what are others thinking
> about this (if anything ☺)?

There is also one approach no-one mentioned here yet.

All compositors that will be interesting to the user, that are session
compositors, could have a Wayland backend only. Therefore they
would not care about the hardware driving at all.

Session compositors would run on top of a system compositor, that
interfaces with the kernel input devices, and does the basic
interpretation into Wayland events: normal and raw input events.

I'm not suggesting to put things like gesture recognition into the
system compositor, it would probably get too complex protocol-wise,
since gestures are probably a per-user thing (or a per-app, so we need
the protocol supporting local gesture detection in a client anyway).

Also this approach won't fit for all Wayland uses, but I expect it to
become a dominant one on the desktop and similar high-power systems,
especially ones that may have more than one real user account.

So if someone thinks about writing a new Wayland compositor, my advice
would be to begin with a Wayland backend only, for an easy and fast
start. Well, if we just had a reference system compositor.

And if someone else starts to feel fear, uncertainty and doubt about
desktop performance, you should check my new writing:


More information about the wayland-devel mailing list