Some of my thoughts on input for wayland

[Kristian Høgsberg]

On Sun, Jan 23, 2011 at 9:03 PM, Chase Douglas
<chase.douglas at canonical.com> wrote:
> Hi all,

Hi Chase,

> I haven't been involved in wayland development at all yet :), but I have
> been working on XInput 2.1 multitouch additions and gesture work in
> Ubuntu. I have a few thoughts on how a new input system for wayland
> might work.
>
> To go along with that, I have no idea if these ideas have been discussed
> before or not, nor whether the wayland architecture would allow them.
> These are just some generic thoughts I've had on an input service
> architecture.

Thanks for jumping in and sharing your thoughts.

> First I'd like to address what I think we can learn from X. X11 has a
> core protocol and an XInput extension with two major versions. To
> develop additions to the input system in X you must meet two obligations:
>
> 1. Develop alongside all the other work going on in X
> 2. Be backwards compatible with the previous input systems
> 3. Be integrated into the same display server source code

I think this is true of any mature, successful project...

> I think we could take a different approach with Wayland: separate input
> from display. What does the input system need from the rest of X?
> Nothing really other than window regions and hierarchy on the screen.

and I don't belive splitting input out into a separate project and/or
process changes that.  Putting input handling in a separate process
doesn't make it any easier to swap in a new input system.  The bulk of
the work will be in porting clients and toolkits and dealing with
backwards compatibility to the old system(s).  Also, the mix-and-match
idea will certainly lead to fragmentation - it's bad enough that we're
introducing a new display server to the world, but it's certainly
better than "a new display server with a choice of 3 different input
systems".  Jesse already pointed out some of the problems with the IPC
between input and output servers - you have to share the entire
compositor scene graph with the input server, wobbly windows, picking
algorithm and all.  Handling input in the compositor and getting input
redirection right was one of the main ideas that prompted Wayland.

Once of the things that X got right was the extension model.  Wayland
takes it one step further by making everything an extension: the only
thing that's fixed in the Wayland protocol is an interface for
discovering other interfaces.  If it turns out that we need to update
the input model, we have versioning built in for incremental updates,
and we can add an entire new model if we need to start from scratch.
Finally, a compositor can expose its own interfaces in addition to the
Wayland interfaces, so it's possible to add extra functionality
specific to a given compositor.  It's even possible for a compositor
to define its own input system if it comes to that, but the aim of
Wayland is to be a generic input/output multiplexor that scales from
handhelds up to full-blown desktops.  I hope you can help make that
happen!

Kristian