input transformations

[David Reveman]

On Sun, 2007-02-04 at 12:13 -0800, Keith Packard wrote: 
> 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.

Why do we need a quad mesh to represent projective transforms? As far as
I could understand all we would get out of using a quad mesh instead of
a tri mesh would be that we could do some fancier interpolation. But I
though that most OpenGL implementations were decomposing all GL
primitives to triangles anyhow and it seemed most useful to have the
input match the output. We could have an additional request for setting
a quad mesh if that's desirable of course. Am I missing something here?

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

Exactly.

- David