Event Control Miscellany for an Input Redirection Client

[Deron Johnson]

Keith Packard wrote On 01/23/06 15:18,:
> On Mon, 2006-01-23 at 12:05 -0800, Deron Johnson wrote:
> 
> 
>>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.
> 
> 
> We cannot change the wire encoding of events

Ok. I buy that. Could we use the 'child' field to hold the opaque reference?

> I will not like any suggestions that involve changing the core data on
> the wire; these are extensions, after all. Sending additional events is
> more than possible, and would provide a less scary mechanism.

It sounds like what you are suggesting is that for each
key/button/motion event sent by the Picker not bound for an X app that
the Picker should send after it an extension event containing the opaque
reference for the preceding event. Is this correct?

The disadvantage of this is that it doubles the amount of event data
going to the X server and coming back to the event deliverer.

The advantage, however, is that it can be done with no server changes
other than to define a new extension event.

But one issue comes to mind. First of all, call these extension events
"Input Redirector Augmented" (or IRA) events. What happens to IRA
events while a conventional X11 app has a grab? Do the IRA events get
grabbed by that app? If not, will the app gracefully ignore the IRA
events? It was for this reason I encoded the opaque reference in the
core protocol events in my protocol

Another issue is that if the IRA events don't get grabbed, then will
they end up going back to the LG Event Deliverer and confusing it? We
probably can deal with this by having the Event Deliverer ignore
IRA events which arrive without a preceding key/button/motion event.

> No doubt. That's why I want to see several different implementations
> before we even start thinking about what might be the best standard one.
> What we've got now isn't sufficient, but we must take some care to
> ensure that we don't choose something that we will regret in the
> future. 

I think that in this area there aren't that many possible
implementations that do what we want. It's fairly easy to
rule out the completely grotesque ones and there are very few
possibilities left over.

Goal: the Picker wants the ability to optionally add some information
to each event that it performs a pick on and which it sends back to the
X server. This information is opaque to the X server. This information
must be ignored by conventional X11 applications should a grab force
the event to be sent to one of these applications.

Approach #1: Add one or more fields to core X11 events.
    This is a non-starter because of the massive, global changes it
    would involve.

(In all of the following approaches, the Picker stores the augmented
event data within the address space of the input redirection client and
uses an opaque reference to this data. When the Event Deliverer portion
of the input redirection client receives such an opaque reference it
will know how to dereference it to access the data).

Approach #2: Encode the opaque reference inside the core
key/button/motion event for every event which is sent to the Event
Deliverer.
    Encoding it in the sequence number field is a bad idea as this
    messes around with the X protocol. But encoding it in the
    child field might be a possibility, but I agree that this should
    be avoided if at all possible.

Approach #3: Have the Picker use the pick-processed event contents
as a hash key and use that as the opaque reference to the augmented
data.
    Not reliable enough. Not all pick-processed events have unique
    bit contents.

Approach #4: The Picker knows when an event is going to be sent back
to the Event Deliverer in the input redirection client. For each
pick-processed key/button/motion event will will end up getting
sent to the event deliverer it sends an extension event containing the
opaque reference.
    This is the approach which is least invasive to the server, but it
    has an issue: does it correctly handle grabs by conventional
    X11 apps?

Approach #5: Define extension "augmented" versions of the core
key/button/motion events and include another field in these structures
for the opaque reference.
    Problem: unfortunately, these types of events will not be properly
    grabbed by conventional X11 apps.
    Possible solution: we might be able to avoid this problem if we
    have the X server convert these extension events to normal core
    events before sending them to this type of app. But this is more
    invasive to the DIX event code.

How many other possible conceivable implementation approaches are there?
An external input redirection client implies the necessity of a
per-event opaque reference to data in the input redirection client's
address space. This means that the opaque reference either has to be
encoded in the event structure itself or trail along behind it in some
way. But we need to make sure that in either case (encoded within or
trailing) that the extra information does freak out conventional X11
apps. I believe that we should be able to zero in on the correct
implementation approach by a straightforward process of enumeration and
elimination.