Robert North 7ownq0k402@sneakemail.com writes:
But note that this would reqire some patching to the x11drvdll to do the following 1. decode the messages. 2. enable the messages for a given window and display. But I'm assuming that changing the x11drv code could cause severe regressions to wine. I'm therefore assuming that it's good manners to avoid fiddling with x11drv code till the wintab driver implementation is known to be adequate.
I don't think it would necessarily cause regressions to simply add handling for new events, since it shouldn't require changing the existing event handling. But anyway writing a separate prototype first is certainly a good idea.
Now, as it turns out, the methods to interrogate a wintabmessage queue are extremely similar to those to interrogate an X11 message queue. So that's +1 to giving wintab it's own X11 message queue. (Or possibly even one X11 msg queue per tablet context!). A simple X11<->wintab mapping can be implemented, and no additional queue data structs are needed in the wintab implementation.
I'm not convinced you can avoid managing an event queue for wintab events; from a quick look at the spec I doubt you can simply map the wintab functions to X11 queue functions.
I think after all that complexity, that's +4 or more toX11 message queue implementation, and for wintab at least, avoid the wine message queue.
I agree you probably don't want to store wintab events in the Windows message queue. But that doesn't mean you have to create your own X connection and event loop, you can simply retrieve the events from the normal X event loop and store them into the wintab queue.