Thanks for your reply...
It's really got me thinking, and unforunately, has caused more questions than answers.
Luckily many of the questions may be useful to the wine developer community at large.
Alexandre Julliard julliard-at-winehq.com |Wine Mailing Lists| wrote:
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.
Hmm. Interesting....
This raises the issue of code separation: For any new wine dll, that needs new X11 calls, what code should go into x11drv dll and what into the new dll? I tried to make sense of this issue by referring to direct draw and open gl dlls, but just got more confused.
The danger I see is that 90% of the wintab code, (and there could be quite a bit) might end up in x11drv, and 10% in wintab! This is especially likely if the policy is expose no X11 structs through the dll exports of x11drv.
The issue of prototyping brings me to issues about how to release patches to wine, which I think I'll discuss in a future e-mail.
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'm about to have a final look at this, see if there is a clear mapping from X11 functions to wintab.
More on this once I've completed my investigations.
One mismatch is that wintab uses a fixed size message queue which can be defined as, as opposed to Wine or X11. (I'm assuming wine or X11 are either extremely large queues, or dynamically sized.).
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.
Which is initially how I was going to implement it.
The issue I came up against is how to inject the messages into the wintab queue?
In wine, messages are currently injected into the for each thread, when GetMessage() is called.
As wintab has it's own equivalent of GetMessage (named WTPacketsGet) the which seems to have direct access to the driver, it would look like wintab needs an alternative method to inject messages into it's queue.
The only one I could come up with, in wine style, was to have a worker thread whose sole purpose is to inject messages into the wintab message queue. It might call GetMessage(), but all this would do is cause the wine message loop to insert a message into the wintab loop.
The problem with this system is that it means that the queue has to be accessed by multiple threads, and therefore will lead to the usual thread synchronisation hassles.
It was the fact that I could avoid synchronisation which lead me to think about building my own message loop.