On Thu, 2007-02-01 at 18:26 -0500, David Reveman wrote: > It seems to me like we need to experiment a bit before we can decide > what's the best solution. My current patches are at least something to > start with and I look forward to discussing it more next week at > xdevconf.
The compositor decides what goes where on the screen. As a result, it always has the information needed to perform input transformation. Locating input transformation within the server has to involve the transfer of that information from the compositor to the server. Whatever protocol you establish, it is likely to stifle the development of better solutions in the future and will prove a long term hassle to all involved. Furthermore, transfering the essential details of a complex and rapidly changing scene graph might easily prove expensive. User inputs are simple and infrequent. Their transfer costs are low and will remain low. The argument against placing input transformation within the compositor is founded on the assumption that it introduces an unnecessary round trip into the process: input device event -> server -> compositor -> server -> client. versus input device event -> server -> client However, some input device events might be directed at the compositor itself or at a non-X client of the compositor. In these cases the routes become identical and the server becomes nothing more than a hinderance to input transformation: input device event -> server -> compositor (-> non X client) Furthermore, the compositor will almost always reside on the same host as the input device. This provides a better solution to the round trip problem - establish a direct link from the input device to the compositor. This mirrors the direct rendering approach to cutting out the X server. The longest path then becomes: input device event -> compositor -> server -> client. whilst the shorter paths become input device event -> compositor (-> non X client) The X server changes required to implement compositor based input transformations are relatively simple. A partially working model can be implemented entirely within the compositor with an unpatched server: 1) capture X input events by selecting them on a child of the overlay. 2) pick the target client window and transform to its texel coordinates 3) send the transformed event to the target window using XSendEvent. This works with sufficiently simple X clients. However, there remain two obstacles to this approach: 1) Client pointer grabs are unavailable. 2) Clients typically ignore synthetic events. Both of these obstacles could probably be removed reasonably easily within the server. It just needs a means for the compositor to hide its role in transforming the pointer from the X clients. Felix _______________________________________________ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz