I'm about to start serious implementation on the wintab32 dll. I now need some guidance as to how best to implement it's access to X11 calls.
My current thoughts on how to do this are given below. Are they reasonable??
I need to access a number of X11 calls, largely in the XInput extension. None of these are exposed by the x11drv dll.
My intention is currently to change nothing in the x11drv dll.
The only hints I can find about how to do this are from the direct draw and open gl dlls.
These dlls can do the following: Get the X11 Display object of a gdi context. Get the X11 window handle given a win32 window handle. Synchronise with the x11_drv code for multi threading.
My wintab code will do the same.
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)
Hope I'm on the right track -Rob.
Robert North 7ownq0k402@sneakemail.com writes:
The one difference will be that wintab will create it's own X11Display 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?
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.
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.
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.
I tried to make sense of this issue by referring to direct draw and open gl dlls, but just got more confused.
Do NOT look at DirectDraw or OpenGL for references as how it is done... The current stuff there are mostly hacks to get the DLL separation to work (ie for DDraw, it should go through a proper HAL and for OpenGL, it's not documented how Windows did it, so we did our own hacks).
Lionel
Lionel Ulmer lionel.ulmer-at-free.fr |Wine Mailing Lists| wrote:
I tried to make sense of this issue by referring to direct draw and open gl dlls, but just got more confused.
Do NOT look at DirectDraw or OpenGL for references as how it is done... The current stuff there are mostly hacks to get the DLL separation to work (ie for DDraw, it should go through a proper HAL and for OpenGL, it's not documented how Windows did it, so we did our own hacks).
So, that explains why I got confused ;-)
But I face a similar problem of dll separation. Infact anyone who has to access X11 features not exposed in x11drv will face dll separation problems.
So, in hindsight, what advice would the DirectDraw or OpenGL developers give to someomne facing dll separation problems?
Thanks -Rob.
Robert North 7ownq0k402-at-sneakemail.com |Wine Mailing Lists| wrote:
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've re-checked the X11 code, and you're right, the only sane way to map X11 events to a wintab queue is by coding an event queue for wintab.
Thanks -Rob.
Hi, On Wednesday 15 January 2003 19:09, Robert North wrote:
Robert North 7ownq0k402-at-sneakemail.com |Wine Mailing Lists| wrote:
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've re-checked the X11 code, and you're right, the only sane way to map X11 events to a wintab queue is by coding an event queue for wintab.
Thanks -Rob.
Sorry if this seems like a stupid question. Could you please elaborate what the problems between X11, DirectDraw, OpenGL and accessing X11 functionality are. I am not an expert in either area but like to understand the problem.
Thanks Enrico
Enrico Horn farmboy1-at-subdimension.com |Wine Mailing Lists| wrote:
Hi, On Wednesday 15 January 2003 19:09, Robert North wrote:
Robert North 7ownq0k402-at-sneakemail.com |Wine Mailing Lists| wrote:
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've re-checked the X11 code, and you're right, the only sane way to map X11 events to a wintab queue is by coding an event queue for wintab.
Thanks -Rob.
Sorry if this seems like a stupid question.
Don't think it is, It's the question I've ended up trying to answer when looking at how best to implement wintab.
Could you please elaborate what the problems between X11, DirectDraw, OpenGL and accessing X11 functionality are. I am not an expert in either area but like to understand the problem.
I'm not the person to answer this, but answering it will help me clarify my own thoughts, and allow people to correct me :-)
Well, it seems that wintab now has the concept of drivers, at least for graphics (&sound??)
As I currently see it the problem is a question of policy: What should be in the x11drv dll (a private? dll) and what should be in the application facing dlls.
Currently, the x11drv dll does not appear export any X11 data stuctures, or handles. Therefore my assumption is that code that interfaces with the X11 system should go in x11drv. This means that x11drv could become horribly bloated with support for specialist dlls like x11drv. Also, as I've mentioned before, x11drv is so important to the functioning of wine, unnecessary tinkering here gould cause nasty regressions.
As Alexandre points out, wintab code need not interact much with current x11drv code, and therefore if well designed, will cause minimal regression risk.
And yet, DirectDraw, OpenGL dlls do access the X11 system directly. How? By some clever hacks to get X11 display objects from gdi and X11 window handles from Wine window handles. And is this good policy? No. Lionel has pointed out that these dlls are bad examples of how to do it.
So, what is the policy? I dunno. Maybe it's use your head?
Hope this helps -Rob.
Thanks Enrico
-
Alexandre Julliard -
Enrico Horn -
Lionel Ulmer -
Robert North