Some of my thoughts on input for wayland

[Chase Douglas]

On 01/24/2011 01:57 PM, Jesse Barnes wrote:
> 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.

I'm not extremely well versed in multi-process communication, but I was
thinking we may be able to do something like rcu in the kernel, but
apply it to the compositor window hierarchy. Keep the window hierarchy
in shared memory with the input server. Then wrap the IPC mechanism into
an easy to use shared library for both wayland and input server sides.
The compositor would be the only process with write capabilities to the
memory region, so it would never have to wait for locking. The input
server(s) should be fast since most input isn't occurring while windows
are moving (I think :).

This would be somewhat complex in implementation, but if it's a shared
library then the complexity is hidden away. The ultimate question in my
mind is: will this be performant enough?

(And if it's really obvious that I don't have a clue what I'm talking
about with regards to shared data and IPC, please flame gently :)

>> 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.

Interesting... I would be grateful if someone could find it.

Thanks!

-- Chase