On Thu, 2007-02-01 at 18:26 -0500, David Reveman wrote: > I spent some time this week trying to add support for input > transformations to the server. I tried a few different approaches. The > patches I've attached are what's currently working best for me.
Thanks for getting started on this; I believe this is the largest remaining problem with a composited desktop. > In this approach I allow every window to have it's own root window > coordinate space. A window's root window coordinate space is affected by > all it's ancestors. Composite clients can set a triangular mesh that > maps root window coordinates from a composite window to one of its > redirected child-windows. Event coordinates are generated in the event > windows root coordinate space. I was thinking we'd want a quad mesh instead of a tri mesh so we could represent projective transforms, but otherwise, this stuff looks like it's moving in the right direction. Note that Deron Johnson is working in this space from an entirely different direction (for looking glass); I asked him to try and construct an interface layer within the server that would allow both the polygonal decomposition mechansim and their own java adventures. > The compositing manager can make a decent guess > from the window location but without any hint telling the compositing > manager which top-level window it's related to, it's hard. Let's work out what the problems are and start experimenting with changing toolkits to solve this correctly. Obviously having heuristics which work for legacy apps will be necessary, but I don't want to rely on guess work when applications can provide definitive answers. -- [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
_______________________________________________ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz