Event Control Miscellany for an Input Redirection Client

[Deron Johnson]

Keith Packard wrote On 01/18/06 18:54,:

> Until we have at least two, and preferrably more, advanced event
> redirecting applications like LG, I'd like to discourage attempts at
> standardization of these kinds of operations. They'd be most welcome to
> exist on a branch in public CVS, but we're just not ready to try and
> evaluate what the problems are and how best to fix them.

There is a definite, demonstrated need for "advanced event redirecting
apps" to associate additional information with each event. It is true
that the content and representation of this information can vary between
redirection clients but there is a proven case (LG) that it is necessary
and it's hard to argue that it doesn't have general applicability to
other types of redirection clients. You yourself made a similar
suggestion at last years X conference.

So we need to provide input redirection clients with a way of
associating additional information with each event. One possibility
is to add additional client-defined data fields to X events. But this
would be very invasive to the server and prohibitive to implement.

A better method is for the redirection client to store the information
in its own address space and include an opaque reference to the data
in an otherwise unused field of each event. In my implementation, I
chose to place this in the sequence number field. However, this forced
me to skip the normal setting of the event's sequence number when
writing to this client. Perhaps using the subwindow field might work
better. Is there another field in the event you would recommend for this
purpose.

In my mind the question is not whether we need such a feature, the
question is what is the best way to implement such a feature.

As to the issue of forcing the button events to be sent to the
Picker-chosen window, I withdraw my earlier suggestion that we add a
new window option for this--I now realize that this is just something
we need to address as part of defining input redirection. The semantics
of the Picker (i.e. the input redirection client) should be that if the
Picker fully resolves which window the event should be sent to then the
X server should send the event to that window in all cases (except for
grabs). When an input redirection client is active, having the X
server send motion events to the Picker-chosen window and button
events to the sprite window is the wrong behavior.

> Certainly any such future work would do well to look at how you've
> solved the problems, but without a concrete environment to work in, it's
> impossible for any of us to seriously expect to discover alternate
> mechanisms.

LG provides such a concrete environment. You are welcome to download its
current branch and experiment with it.