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 _______________________________________________ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz