On Sun, 23 Jan 2011 21:03:58 -0500 Chase Douglas <chase.doug...@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 _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
