input transformations

[Felix Bellaby]

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