I've been thinking about the XI2 a fair bit since the last time we discussed it on the mailing list, and a few things have come to mind, which I think need sanity checking before I explore any harder.
I'm assuming we want one X11 connection turning XI2 events into WH_*_LL events, RawInput events, and DirectInput events, simply because WH_*_LL events are actually sent out by wineserver to all processes, so we only want one of those per XI2 event.
This leads me to retaining the current WH_*_LL-based implementation of DI, but with cursor management and control (ie all the stuff Exclusive mode brings to the table) handling via a graphics driver hook or similar.
However, the mechanism for feeding the XI2 events to the wineserver as WH_*_LL events is a little tricky.
XI2 events need their own thread and hence X connection, as we cannot rely on a WinMain loop hitting X11DRV_MsgWaitForMultipleObjectsEx in a timely manner, or in fact all.
The three possibilities I see are:
*) Most recent foreground application catches XI2 events in its own spawned thread. Need to elect a replacement on process exit. Easiest to co-ordinate with non-XI2 hook-feeding code.
*) Wineserver gains an X11 connection, for XI2 use only. This is generally bad, only here for completeness.
*) A new process (ala services.exe) which grabs XI2 events from X11 via its own connection and feeds them to the wineserver.
I'm inclined to think the latter one is the best option of the three, and it requires simply that the winex11.drv detect XI2 presence and if found, it disable its own WH_*_LL feeding code and spawn the XI2 process if it is not already running.
It avoids the complicated coordination dance you would need for the first option to avoid losing messages.
Mind you, I've been thinking this away from the codebase, so it's mostly mindwork right now. But unless I get any better suggestions or criticism, I'll prolly knock up a sample implementation of the third option next time I play with this, and see if I can get the DI keyboard interface implemented.
Paul TBBle Hampson Paul.Hampson@Pobox.com writes:
The three possibilities I see are:
*) Most recent foreground application catches XI2 events in its own spawned thread. Need to elect a replacement on process exit. Easiest to co-ordinate with non-XI2 hook-feeding code.
*) Wineserver gains an X11 connection, for XI2 use only. This is generally bad, only here for completeness.
*) A new process (ala services.exe) which grabs XI2 events from X11 via its own connection and feeds them to the wineserver.
It should run in the context of the explorer process, no need for a new process.
On Mon, Jun 22, 2009 at 12:57:35PM +0200, Alexandre Julliard wrote:
Paul TBBle Hampson Paul.Hampson@Pobox.com writes:
*) A new process (ala services.exe) which grabs XI2 events from X11 via its own connection and feeds them to the wineserver.
It should run in the context of the explorer process, no need for a new process.
Sounds good, I'll proceed on that basis.
Am Monday 22 June 2009 13:12:40 schrieb Paul TBBle Hampson:
*) A new process (ala services.exe) which grabs XI2 events from X11 via its own connection and feeds them to the wineserver.
It should run in the context of the explorer process, no need for a new process.
Sounds good, I'll proceed on that basis.
I am curious, does that mean that any Xinput based input will need two network roundtrips from explorer->wineserver->actual app?
Stefan Dösinger wrote:
Am Monday 22 June 2009 13:12:40 schrieb Paul TBBle Hampson:
*) A new process (ala services.exe) which grabs XI2 events from X11 via its own connection and feeds them to the wineserver.
It should run in the context of the explorer process, no need for a new process.
Sounds good, I'll proceed on that basis.
I am curious, does that mean that any Xinput based input will need two network roundtrips from explorer->wineserver->actual app?
All hardware messages go into wineserver. And some parts of dinput calling functions that result in few calls to X-server. So I'm guessing extra round trip isn't an issue.
Besides, two fix few remaining problems all input have to come in into helper thread/process anyway.
Vitaliy.
-
Alexandre Julliard -
Paul TBBle Hampson -
Stefan Dösinger -
Vitaliy