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 _______________________________________________ xorg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xorg
