Help wanted: Implementing Wine dlls that need access to X11 commands.

[Robert North]

Alexandre Julliard julliard-at-winehq.com |Wine Mailing Lists| wrote:

>Robert North <7ownq0k402 at 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.