Event Control Miscellany for an Input Redirection Client
Deron Johnson
Deron.Johnson at Sun.COM
Wed Jan 18 17:20:11 PST 2006
In addition to needing to work out the issues surrounding input
redirection to an external picking client (sending events to the
client and back, FixupEventFromWindow changes, and XYToSubWindow)
there are several miscellaneous changes that I believe we will need to
make to the X server event pipeline in order for LG to work properly.
Specifically, I will need the following:
1. What: Ability to disable the default button grab testing for
specified windows.
Why: If the pick operation for an event doesn't hit any window, the
LG Picker assigns the window ID of a special "miss window" to
the event. When the event comes back to the LG Event Delivererer
LG will no that the event didn't hit anything and will be able
to toss the event at the appropriate time. No grabs, even the
default button grab, should trigger on the miss window because
this would improperly interfere with the ability of X clients
to actively grab the X server.
2. What: Prevent the writing of client sequence numbers into events
delivered to clients.
Why: The LG Picker and EventDeliverer the sequence number field of
events for their own purposes. Specifically, the Picker stores
a "pick sequence number" which refers to various 3D information
calculated for the event. The EventDeliverer uses this information
when the event comes back to the Display Server.
3. What: By default, button events are always sent to the current sprite
window. LG needs them to instead be sent to the window chosen by
the Picker
Why: The choice of what window or 3D object to send events to should
be centralized in one place--the Picker. Other X server code should
not be making decisions about where button events are sent because
the information that the X server has may not always be in sync with
the information that the Picker has.
4. What: Ability to force grab trigger/termination enter/leave events
to always be generated for specific windows.
Why: DoEnterLeaveEvents does not generate an Enter event with
mode==NotifyGrab if the grab window equals the sprite
window. In order to properly map X grabs into 3D grabs
LG needs to know when a grab triggers (and terminates)
regardless of what window is the sprite.
There is no real major theme to these requirements other than the
fact that they deal with the X event pipeline and that they are
needed by a 3D input redirection client which supports the notion
of 3D grabs and that they are all features which are specific to
certain windows.
Perhaps one way to deal with this is to introduce the notion of
"event control" window attributes into the input redirection
extension. These can be a set of bits that can be enabled or
disabled. All of these window attributes would default to the
current Xorg behavior but would be configurable by the
input redirection client. Or we could maybe put these into
the X fixes extension.
I'm interested to hear if anyone out there has any alternate
ideas about how to solve this problem. I'm also interested in
hearing about ways that the number of attributes can be reduced
(although I doubt we can find a way to eliminate all of them).
More information about the xorg-arch
mailing list