Changes to XInput Proto Number of Events Cause Xlib WireToEvent Vector Mismatch

[Nathan Kidd]

Peter Hutterer wrote:
> On Thu, Nov 26, 2009 at 01:43:25PM -0500, Nathan Kidd wrote:
>> Either approach fixes the WireToEvent case when considering events being
>> generated by the server, but I don't think there's anything that can be
>> done about the EventToWire (SendEvent request) case.  Your choice is to
>> use the wrong EventToWire function for either the overlapping extension
>> events, or the following extension events.  The former is preferred I
>> think since it will only break very new code (using new events).
> 
> I think EvToWire should match WireToEv. If a client is trying to send an
> event that the server doesn't know about then that's a bug in the client
> anyway. I don't really see a way out to prevent a client from doing this in
> a safe manner.

Agreed.  This is another reason that an (event-using) extension *must* 
provide a QueryVersion type request or otherwise a mechanism to 
determine how many events the server supports.   My quick grepping over 
*proto suggests that XKB is the only current extension which doesn't 
seem to provide such a mechanism.  But it falls into the special case of 
still using just the one event it was first published with.

>> +	    if (XEGetWireToEvent (dpy, j) != _XUnknownWireEvent)
>> +                break;
>> +
>>  	    XESetWireToEvent (dpy, j, hooks->wire_to_event);
>>  	    XESetEventToWire (dpy, j, hooks->event_to_wire);
>>  	}
> This only works in one case - if the higher one is initialized first. It
> fails the other case. Given two extensions - base 80 + 20 and base 90 + 5.
> If extension 1 registers first, range [80,100] would be occupied and cannot
> be taken by the second extension. The server would still send events for the
> second extension and they'd be processed by the wrong library extension.

Ah, doh.  Yes, my patch totally missed the 2nd case.  Yours looks good!

-Nathan