Some of my thoughts on input for wayland

[Jesse Barnes]

On Sun, 23 Jan 2011 21:03:58 -0500
Chase Douglas <chase.douglas at canonical.com> wrote:
> 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 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.

Yes, but in that small statement "window regions and hierarchy" lie
dragons. :)

One of the main reasons we don't have input transformation in X is due
to this very problem.  Having the compositor separate from the server,
with all that implies (split input handling, duplicated window
hierarchy, etc.) makes doing transformed input very difficult (so much
so that no one's really tried).

Keeping input and display together makes this much easier.

If they were split out for Wayland, the input process would have to
communicate with the display server, and duplicate window region data
(including transforms), and also handle potential races between input
handling and display updates (animations and the like).  So we'd end up
with a potentially very complex inter-process protocol.

So overall, I think splitting input and display would create more
problems than it would solve.  I largely agree with your goals though:
you want it to be as simple and easy to change as possible, I just
don't think splitting it out as radically as you propose would achieve
that.

> As input devices are advanced into true 3 dimensional space, we may find
> a need for even more intricate input service mechanisms. A more future
> proof model may involve the ability to dynamically slot in input systems
> as plugins. In this way, we might also be able to deprecate older input
> protocols over time.

I heard something like that was proposed at the recent Khronos meeting;
it sounded like STREAMS but for input, maybe krh can point you at the
proceedings or something, it seemed like a potentially reasonable way
of handling the variety of input needs we have out there today, while
preserving flexibility for the future.

-- 
Jesse Barnes, Intel Open Source Technology Center