input transformations

[Felix Bellaby]

On Wed, 2007-02-28 at 19:04 +0200, Daniel Stone wrote:
> On Wed, Feb 28, 2007 at 11:07:15AM +0000, Felix Bellaby wrote:
> > 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
> 
> Yes, that would be bad, and require some kind of SIGIO-style preemption
> (possibly a backchannel) for the compositor to hand the events back,
> pre-empting rendering.

Later in my post, I suggested the possibility of passing the input
device events through the compositor before they even get to the server.
This would avoid the need to send every input event over a back channel.

> But the really problematic part is the semantics.  Right now, when an
> event's left the server, it's left the server.  But we need the ability
> to freeze the input queue pending transformations. If you transform a
> mouse, then all subsequent relative events need to be dealt with
> relative to the transformed co-ordinates, and so on. 

True, but when the compositor alters the arrangement of the windows on
the screen then the basis on which you have to transform the pointer
coordinates also changes. You can not expect to transform the pointer
coordinates within the server independently of what is going on in the
compositor and get the right results. The server and compositor have to
agree on how each and every event is transformed before either one can
hope to process the event. What we need is the least bad solution to a
horrible coordination problem.

> What exactly do you do with grabs?
>
> It's this part that's quite complex to deal with.  Anyone that has a
> roughly-working implementation that works with all kinds of grabs (e.g.
> popup menus) is a king. :)

Let us assume that the compositor receives all events directly from the
input device, transforms them and sends the results onto the server,
whilst simultaneously placing a copy of the untransformed event into an
internal queue. When it recieves an event from the server then it would
flush input events occuring before that event from its input queue.

I think that the server would normally be able to pass the transformed
coordinates onto the targeted clients immediately without any worries.
However, there would be occasions when the basis for transforming the
input events would need to be altered following the receipt of a request
by the server. Grabs would be one example, window maps would be another.
When these requests were received then the server would flush any input
events from its input queue, send an event relaying the request to the
compositor and wait for a response.

The compositor would then flush all input events occuring before the
relayed request from its input queue, alter the scene graph to reflect
the event, retransform all of the events in its queue based on the new
graph and resend the events to the server (keeping copies as before).

The server would recommence processing immediately after recieving the
first of the newly transformed input events from the compositor. 

I think that this might work, but it would mean delegating the input
device event processing to the compositor and suspending the server
whenever it received a request that would alter the basis for
transforming the input events.

I can not see an alternative to suspending input processing in the
server while the consequences of a request that alters the basis for
input processing is calculated. Nor can I see how the server can be
expected to calculate the consequences of such a request independently
from the compositor. Therefore, I do not think that this protocol would
impose any costs over and above the those that are unavoidable.

I am not sure at present which requests would need to be relayed to the
compositor so that it could change the input transformation basis, but
this will need to be resolved before the true costs of any form of input
transformation can be properly assessed.

Felix