Event redirection adventures

[Keith Packard]

Ok, I've spent about two weeks thinking about event redirection and
haven't come up with an obvious simple plan. Either I'm dense, or this
is a whole lot harder than I want it to be.

We're talking here about the mapping inside the server between various
coordinate spaces for the purpose of processing and delivering mouse
events. This is currently done by assuming a simple translation
transformation between screen and window coordinate spaces.

With Composite'd environments starting to explore projectively
transformed 2D applications,  our trivial transforms aren't going to
hack it any longer. We clearly need to place the transformations under
application control and permit some pretty wild stuff at the same time.

There are two basic computations needed in this environment. The first
is to transform an arbitrary screen position to a position relative to a
specific window (coord transformation). The second is to detect which
window is directly under a specific screen position (hit detection).

The problem is that coordinate transformation and hit detection are
currently synchronous wrt event processing, which means that decoupling
these and letting an external client help figure out the right answers
turns out to be really hard.

Consider a simple case -- Pointer in Window A and Pointer grabbed by
Window B. In this case, events must be delivered wrt Window B, which
means that the server must have coord transformation data that computes
positions relative to Window B, even though the cursor is not inside it.

Now, consider a harder case -- the Pointer is frozen and events are
backing up. The window manager reconfigures windows and calls
AllowEvents. Events must now be *reinterpreted* wrt the new window
configuration for appropriate delivery.

This latter case means that our plan for placing event redirection right
at the raw event delivery mechanism *will not work*. Instead, for this
to work, it must happen far later in the event processing pipeline. Hit
detection must occur in XYToWindow, which happens even with replayed
events. Coordinate transformation must occur in FixupEventForWindow,
which occurs right as events are being send to the client.

To make XYToWindow able to redirect pointer positions to clients, we
must make it possible for it to pend the processing of an event and
stick it somewhere until an answer is received from the client.

For transforming coordinates while the pointer is grabbed, we need the
input redirect client to be told which window to return information for.

One thing I'd like to see discussed here is whether it makes any sense
to try and stuff suitable transformation data inside the X server.

Cosider a simple 32-bit pixmap 'painted' with Window IDs. This could be
used for efficient hit detection and would make XYToWindow at least as
fast as it is today.

Now, consider a separate per-window list of quad->quad mappings which
define a piecewise projective transforamtion for each window. This would
allow the X server to perform FixupEventForWindow without need to defer
to a client.

Does it make sense to explore this server-resident redirection solution?
Or should we only consider solutions which involve pumping events
through an external client?

-keith

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20060109/e4fa978d/attachment.pgp>