XComposite input redirection/transformation proposal

[Dennis Kasprzyk]

Am Sonntag, 17. Februar 2008 17:22:22 schrieb Daniel Stone:
> On Sun, Feb 17, 2008 at 05:16:29AM +0100, Dennis Kasprzyk wrote:
> > David Reveman made patches for such a system a long time ago, but no one
> > with enough xserver knowledge tried to finalize the patches for xserver
> > inclusion. Everyone is saying that we need it, but it's always only moved
> > to the todo list for the next xserver version.
>
> Myself and Peter have just had other stuff on our plate.  I may need it
> for work, so might have time to clean it up and merge it (just a couple
> of small problems remaining), but if you worked on it, I'm sure you
> could get it to a mergeable state orders of magnitude faster than a
> client-based system.
>
Sorry, but I don't have enough xserver knowledge to do it, but let me at least 
summarize my thoughts about how it should work.
We should always use the root window coordinate space for all the triangle 
mappings, even if they are applied to not direct child's of the root window. 
This should make some grab calculation easier. We know what window caused the 
grab, so that we can go down the stack and transform the input to deliver the 
correctly transformed coordinates to the grabbing window. XQueryPointer 
should do the same.

Also one disadvantage (at least I think so) of the old patch was that it tried 
all the transformation triangles and if this failed to hit the window, it 
tried the "normal" window position based way. I think that we should only use 
the triangles if they are defined for a window.

My last and maybe a little more complicated addition would be a destination 
window id, that would allow some kind of input redirection. With such a 
system, a composite manager could create an input only window, and redirect 
all of it's input to another real window. This would allow us to 
create "clones" of windows and place them different positions in the stack.
This has the disadvantage, that it complicates the handling of grabs. With 
redirection windows we will get multiple paths to the same window, so that if 
an input caused a grab we will need to use exactly the same path to transform 
further input.

I think an example is the easiest way to explain it:
The composite manager draws the normal window stack but also small thumbnails 
of each window on the desktop background. It uses InputOnly windows to 
redirect the input of the small thumbnails to the real window. If a user 
clicks on the scrollbar of the thumbnail, then the input should be 
transformed using the InputOnly window transformation mapping. 

I'm not sure that such addition would work, but it would allow to do more 
interesting stuff with it. 

> Bear in mind that client-based means that you're going to have
> unacceptably latent events, due to every pointer movement now being
> dependent on a round trip.
>
I know, I made this proposal only because it seemed that some people don't 
like a server side solution.

- Dennis