Alexandre Julliard julliard-at-winehq.com |Wine Mailing Lists| wrote:
Robert North 7ownq0k402@sneakemail.com writes:
The one difference will be that wintab will create it's own X11 Display objects. It will interrogate a gdi's X11 Display object to ensure it talks to the same screen.
The wintab code will also require multiple message queues. To implement this I intend to use one display object per queue. (Much as wine uses one display object per thread)
Hmmm... I have a feeling you would be better off using the existing message queues and display connections. Could you give a bit more details on how you have to implement it, or send us pointers to the relevant documentation?
That's what I thought, and I have proof of concept patch that hack the x11drv code to insert & read XInput events from wine's X11 event loop.
Unfortunately this doesn't fit well with the way wintab works. So, here's an explanation, why I've made these decisions. It's far longer than I'd wish, but the issues involved in the design are complex.
So here goes......
***Quick recap of what wintab does*** The wintab dll will takes messages from a graphics tablet, and provides them to the user. But isn't that what a mouse does? A mouse provides information on the X & Y screen coords, and buttons pressed. A tablet provides all the above, plus extra axes defining the tilt of a pen, the pen's pressure, rotation of a mouse, (and possibly more). All this can be provided at resoloutions much higher than screen resoloution.
***The XInput side of the implementation ***
The official way to get tablet data for an X display is to use the XInput extension.
The XInput extension defines a specialised set of event classes to represent tablet data, which enter the normal X11 message queue. These messages are initially disabled. XInput provides a function to enable them for a given display and window.
OK, So far it looks as if the XInput messages could be injected into the wintab messaging system. But note that this would reqire some patching to the x11drv dll 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.
*** The wintab side of the implementation ***
To access tablet, a "tablet context" is created that maps a window to a particular tablet device.
For each tablet context the application is given a separate tablet message queue, which provides 2 ways to access the tablet message queue. a. A set of functions that get or peek, or otherwise interrogate the message queue for queue size, message at index etc. b. Posting messages into the windows(wine) message queue. To complicate matters, it appears that it's possible to use both methods in the same program.
At present, I will only implement method a. as this is the one used by Painter5 and Photoshop6.
Now, as it turns out, the methods to interrogate a wintab message 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. As the wintab dll implements it's own message queue, an implementation using the wine message queue would give a number of problems: 1. All wintab messages would have to be hidden from the application's windows(wine) message queue. Could be done with one specific thread, or threads for wintab. This becomes similar, but more complicated to the X11 message queue implementation. 2. Filtering methods would have to be implemented to only access the messages appropriate to the reqired tablet context. X11 provides all the filtering necessary. While windows provides enough filtering for ranges of messages. But this would mean 3 message mappings X11->windows(wine)->wintab. 3. All the queue management functions, and any necessary data structs to manage the queue will have to be implemented specifically in wintab, as the windows queue doesn't give much control over the message queue, and what's more, may need to copy data into a wintab specific message queue before the application can access it.
I think after all that complexity, that's +4 or more to X11 message queue implementation, and for wintab at least, avoid the wine message queue.
Well, that's the end of my whistle stop tour of the issues I've been cosidering with this part of the design. I've omitted any reference to function names, to keep this document as breif and readable as possible. If you wish, I can annotate it with the relevant function names.
Please feel free to comment on anything.
And finally, Some references:
For the wintab spec see the following location: http://www.pointing.com/FTP.HTM For XInput see ftp://ftp.x.org/pub/R6.4/xc/doc/hardcopy/Xi/lib.PS.gz (Much of the doccumentation will probably be bundled with your xfree86 implementation too)
Well, that's all for now, -Rob.