XComposite input redirection/transformation proposal

[Dennis Kasprzyk]

Hi,

because a lot of people seem not to like the server side quad/triangle based
input transformation proposals, I decided to make my own proposal for a
client side system. Please correct me if something would not work or is
completely wrong, because I don't know the xserver well enough.

To start the input redirection the client/composite manager will call
XCompositeEnableInputRedirection (Display *dpy, Window id). The window id
means that this client wants to do input redirection for this window and
it's child windows (The composite manager will call it usually with the
root window id). In the following text I will call this window InputRoot
and it's child windows InputChild. I will also use "int" as data type for
the cooridinates, but maybe we should use something like Xfixed/float due
to XInput and it's higher resolution input devices.

If the input processing of the xserver reaches an InputRoot window, it will
send an event to the requesting client. This event may look like this.
event->type = FreeInputRedirect
event->serial = an id to identify the value that the client returned
event->x/y = coordinates of the pointer int the InputRoot coordiante space.
event->window = InputRoot

The client will use a function like XCompositeReplyInputRedirection (Display
*dpy, Window id, unsigned int serial, int x, int y, Bool propagate);

Serial will always be the the event->serial provided id and x,y the
transformed coordinated in the InputRoot coordinate space. The client has
now 4 possible ways to reply.

id = None / propagate = unimportant = The server should ignore this input

id = InputRoot / propagate = TRUE = The server will use the returned
coordinates to go down the InputRoot window tree to process the input.
Returning unchanged coordinates here would result in the same behavior like
without input redirection.

id = InputRoot / propagate = FALSE = The server will process this input
directly to the InputRoot window. It would be the same behavior if the
InputRoot window would not have any child windows.

id = InputChild / propagate = unimportant = The server will use the returned
coordinates to go down the InputChild window tree to process the input.

This should basically work with one exception. The InputClient may use
XShape to have an input shape or keiths proposal for pixel color/alpha
based input shaping. It such case the server will return an
FailedInputRedirect event with the same serial, the untransformed pointer
coordinates and the failed InputChild window id. The client will then have
the possibility redirect the input to another window.

Now how should we handle grabs? I'm thinking here about cases like clicking
on a scrollbar, where as long as the button is pressed, the pointer can
leave the window, but it will be still processed by the window. I'm not
sure that this will work, but my proposal would be, that if any child of an
InputChild window causes a grab, then an GrabbedInputRedirect event will be
send to the client with the InputChild id as window parameter. The client
will then have 2 possible ways to reply.
1. Reply with id = None to let the server ignore this input
2. Reply with id = the same InputChild and the transformed coordinates in
InputRoot coordinate space

A XQueryPointer request should then be handled in the same way like grabs.

With XCompositeDisableInputRedirection (Display *dpy, Window id) the client
will then be able to turn off input redirection.

It should be clear that only one client can register the input redirection
for the same window, but it still leaves the possibility that a composite
manager uses input redirection on the root window, and other clients use it
on their own window to do in application input transformations or
redirections.

The whole system does not care about what input event we are prosessing
(pointer movement / button press or release) and also ignores the MPX
multiple pointer case, because it's unimportant for the redirection. This
proposal also leaves the creation of the enter, leave, motion, and button
events in the server to make it simple for the redirecting client.

- Dennis