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