Help wanted: Implementing Wine dlls that need access to X11 commands.
Robert North
7ownq0k402 at sneakemail.com
Tue Jan 14 14:13:35 CST 2003
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 at sneakemail.com> writes:
>
>
>> 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.
>
>
> 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 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.
>
>
> 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 to
>>X11 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.
More information about the wine-devel
mailing list