On 01/24/2011 05:31 PM, Kristian Høgsberg wrote: > 2011/1/24 Chase Douglas <chase.doug...@canonical.com>: >> I'm not advocating a free for all when it comes to input systems where >> you pick and choose what you want. I think we should strive for an input >> system to be extended rather than rewritten from scratch as much as >> possible. Maybe we'll get lucky and never have to rewrite the input >> system again :). However, every decade or so it seems we need to extend >> input in ways that break backwards compatibility in the protocol. So >> essentially, my argument can be boiled down to: I don't think we should >> explicitly specify a "Wayland" input protocol. Let the input side be >> provided through extensions, and perhaps ordain a specific extension or >> set of extensions as the canonical input system at any given time. > > What you describe here is basically how Wayland works. As I said > above, the only fixed interface in the Wayland protocol is how to > discover other interfaces. When you connect to the compositor, you > will receive a series of events, each event introduces an available > object by giving you its id, interface name and version. Right now, > one of these interfaces is "input_device", you can see the details > here: > > http://cgit.freedesktop.org/wayland/tree/protocol/wayland.xml#n386 > > The "input_device" interface describes the entire input protocol as it > is now. Obviously, there's work to do, right now it's sort of like > core input + mpx. But the point is, we can phase this out in favour > of "input_device2", which can completely replace the "input_device" > interface. Then we can keep "input_device" around for a few years > while we port the world to "input_device2" and then eventually dump > it. If X had let us phase out core fonts, core rendering and core > input as extensions, I think X would have lasted even longer. It was > one of the mistakes in X I didn't want to carry over. > > That said, we need to have an input protocol for Wayland 1.0 (or > whenever it's "ready"). I don't want it to be an out-of-tree project > or external protocol, I want it to be there as one of the interfaces > in the Wayland protocol, for applications to rely on.
Ok, I think that satisfies the major issue I saw. >> Second, splitting input into a separate thread or process. We are >> hitting the serialization challenge with gestures today. We need to be >> able to analyze multitouch input and determine gestures, but this is >> dependent on where the touches fall within regions on the screen. There >> may be two separate compositing windows that want to know about gestures >> at the same time. Think of two documents open side by side. >> >> As we recognize gestures, we must map them to the windows on screen. If >> the windows move, we have to keep track of that. We are very limited on >> how we get both of these pieces of data in X. This has forced us to go >> completely serial in approach. We begin to worry about what performance >> impacts there will be on the window manager or the window server. >> However, if we keep the window hierarchy in shared memory with >> appropriate IPC mechanisms, we can minimize serialization. > > I think it could be feasible to split the gesture recognition out into > a separate thread, but that's really an implementation decision for a > given compositor. As long as it's allowed then I'm happy. We would need to develop some synchronization mechanisms, but that's just another implementation decision. Thanks for following up; I'm glad to see where wayland is heading :). -- Chase _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
