| |||||||||||||
LCA: Catching up with X.orgLCA: Catching up with X.orgPosted Jan 26, 2009 1:16 UTC (Mon) by njs (guest, #40338)In reply to: LCA: Catching up with X.org by wingo Parent article: LCA: Catching up with X.org
Input redirection is mostly unrelated to GPUs, but last I heard (6 months ago, maybe?), this was somewhat stalled -- the first approach, of the server handing off input events to a special client (the compositing manager) and letting it do the coordinate conversions, turned out not to work. (They ran into problems coordinating everyone during e.g. grab handling.) The new idea is for the compositing manager to actually upload a triangle mesh to the server and then have the server use that to do the coordinate transformation itself... but no-one was actively working on this, and there's a limited quantity of keithp-types to go around.
Someone else may have more detailed/up-to-date information.
(Log in to post comments)
LCA: Catching up with X.org Posted Jan 26, 2009 17:53 UTC (Mon) by yokem_55 (subscriber, #10498) [Link] Qt 4.5 seems to have some support for input redirection. See the WolfenQt demo for an example. But I'm not sure if this is quite the same thing.
LCA: Catching up with X.org Posted Jan 30, 2009 2:46 UTC (Fri) by jamesh (guest, #1159) [Link]
This isn't something a toolkit could implement itself.
Imagine a compositing window manager that takes a particular window and renders it at twice its original dimensions. Input redirection is needed to let the user interact with this zoomed window in a way that the underlying application can understand (halve the x and y coordinates and translate to match the real window position).
All this has to happen before the input reaches the application. After all, we want clicks that occur outside the application's window to be directed to it.
|
|||||||||||||