XComposite input redirection/transformation proposal
Dennis Kasprzyk
onestone at opencompositing.org
Sun Feb 17 09:58:02 PST 2008
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
More information about the xorg
mailing list