input transformations

[Daniel Stone]

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.

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.  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. :)

(I've thought about it before, but it would take a lot more time than I
 have to implement.)

Cheers,
Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg/attachments/20070228/ffe4d726/attachment.pgp>