(Resend, the first email never arrived. I didn't realise one of my patches was 33k >_<)
I've thrown together a rather-rough-but-working-in-a-limited-sense implementation of XInput2-based DirectInput.
It's got a fair few problems, I'm mainly interested in feedback on the approach, although obviously any code or style criticisms are welcome.
Current limitations: * Doesn't check for XInput2.h, so it won't build without it. (Laziness) It will _run_ without XInput2, falling back to the current dinput WndProc hooks even if compiled with XInput2 support.
* Doesn't send button-ups; XI2 can't distinguish button up from down
* Doesn't send events after button-down until after button-up on a window. I'm pretty sure this is an XI2 bug, but it might be a design feature.
* Doesn't support exclusive mode. XI2 bug (grabs not yet implemented) Hopefully this can be implemented entirely within the dinput code in winex11drv (ie disabling and hiding the mouse on acquire. dinput already takes care of unacquiring when we are no longer the foreground app)
* Mouse buttons aren't remapped nicely downwards. Need to look harder at this, my mouse reports buttons 1, 2, 3, 4, 5, 8, 9, 10, 11 and 12 under X. 4 and 5 are scroll, 6 and 7 might be horizontal scroll in which case if this is always the case we can just remap downwards. Might need to implement device querying to confirm mouse button mapping...
* Only supports the Mouse. Adding keyboard support should be really trivial compared to actually getting the framework right.
* Doesn't detect capabilities... A mouse with a horizontal scroll wheel'd have four axes. I haven't looked to see if DirectInput can support that, or if our dinput code can easily accomodate more axes or buttons than the current 3/8 setup. This the point we'd need another callthrough from gdimouse to the graphics driver.
* Assumes a process will only try and acquire the mouse once. I'm not sure that this is a bad assumption, and it might be that dinput makes this a valid assumption for us.
* Assumes no one else wants GenericEvents. Some day we'll need a GenericEvent handler system inside WineX11, particularly if wintab gets converted to XInput 2 support. Easy enough to do now if wanted.
* gdimouse uses Wine Mouse GUID value. I'm not sure where these come from, if anywhere. Trivial to fix before submission.
If this format is fine, then the first patch is basically ready to go, the latter two patches may need to be re-split or merged more sensibly.
In the libs folder I've also attached a couple of fixes for the XI2 stuff if anyone wants to try it. One only affects 64-bit builds, and one fixes XCB locking assertions which you could probably otherwise ignore. So they're both kinda optional in the Wine context.
Also one more patch, against the xinput utility from whot's git tree, to fix a compile failure in the XI2 test functionality.
Am Sonntag, 19. April 2009 10:41:34 schrieb Paul TBBle Hampson:
(Resend, the first email never arrived. I didn't realise one of my patches was 33k >_<)
I've thrown together a rather-rough-but-working-in-a-limited-sense implementation of XInput2-based DirectInput.
It's got a fair few problems, I'm mainly interested in feedback on the approach, although obviously any code or style criticisms are welcome.
Current limitations:
- Doesn't check for XInput2.h, so it won't build without it. (Laziness) It will _run_ without XInput2, falling back to the current dinput WndProc hooks even if compiled with XInput2 support.
I'm not that much into all the input code, but I always understood it the way that dinput should always use WndProc hooks, and winex11.drv implements the relative movement part either with XI2 or warping if XI2 is not available. Ie, there should be no difference between XI2 and legacy operation in dinput.dll. That would, I think, make native dinput work as well as the builtin one, and help apps that rely on hooks the same way native dinput does(if there are any).
The problem is that this means the warping has to be moved to winex11, which is something Vitaliy tried before and failed
I could be entirely wrong with that though. And I have no idea how that would affect mouse grabbing, or window focus issues etc.
On Sun, Apr 19, 2009 at 12:46:20PM +0200, Stefan Dösinger wrote:
Am Sonntag, 19. April 2009 10:41:34 schrieb Paul TBBle Hampson:
I've thrown together a rather-rough-but-working-in-a-limited-sense implementation of XInput2-based DirectInput.
- Doesn't check for XInput2.h, so it won't build without it. (Laziness) It will _run_ without XInput2, falling back to the current dinput WndProc hooks even if compiled with XInput2 support.
I'm not that much into all the input code, but I always understood it the way that dinput should always use WndProc hooks, and winex11.drv implements the relative movement part either with XI2 or warping if XI2 is not available. Ie, there should be no difference between XI2 and legacy operation in dinput.dll. That would, I think, make native dinput work as well as the builtin one, and help apps that rely on hooks the same way native dinput does(if there are any).
The problem is that this means the warping has to be moved to winex11, which is something Vitaliy tried before and failed
I could be entirely wrong with that though. And I have no idea how that would affect mouse grabbing, or window focus issues etc.
A WndProc hook can only work for Foreground-mode DI. In background mode, you still expect to get movement messages without being in a position to receive WM_MOUSEMOVE or WM_KEYPRESS.
An example of an application that we could fix _now_ with the DI stuff I've posted is Ventrilo, if we implemented gdikeyboard and the relevant X11 entry points. That would allow Ventrilo's press-to-speak key to operate irrespective of what program has the current focus. Right now it only works if a Wine window has the focus in non-DI mode, and not at all in DI mode.
Moving the WndProc hook and mouse-warping behaviour to X11 would certainly be possible, and I suspect it'd end up somewhat with a mouse driver in dinput which is almost exactly what my gdimouse is, which is basically the existing mouse driver except that it feeds Acquire and Deacquire to X11drv and receives messages from X11drv when an event happens.
I haven't read Vitaly's old patches for moving mouse warping to X11drv recently, but I did read them a while ago. The problem with moving the warping to X11drv is that then every graphics driver _must_ implement the hooks I've added in my patches, where as right now we have a fallback mouse support mode which will work with any graphics driver, and in fact would also work on Windows (I believe) because it simply hooks WndProc, and does not need "real hardware" access, and has well-documented and under-documented limitations because of it.
At best, any graphics driver except X11 w/out XI2 could have a non-warping version of exclusive mouse operation, and a comprehensive version of background mouse operation. At worst, only the XI2-enabled X11 path would do anything except WndProc hook-based mouse warping, and we'd just duplicate the existing code across all graphics drivers.
I'm blithely ignoring the fact that there's only one graphics driver in-tree. ^_^
I'm attaching my DirectInput test program. It demonstrates both the MSDN sample way of doing a background DI mouse reader, and also as it happens a maybe-bug in Wine's DirectInput headers, in that you can't use DIMOFS_X and similar as case labels.
It also demonstrates another problem with current Wine DI. If you put its window up to the edge of the screen, and push your mouse against the edge of the screen, your mouse movement against the edge of the screen is lost.
I prolly should open bug reports for these other facets of DI that don't work, but should, but I haven't checked to see if they have been reported and just haven't had the exposure of the mouse-warping bug. I was hoping that the one DI fix would take care of everything, I guess. ^_^
On Sun, Apr 19, 2009 at 09:46:17PM +1000, Paul TBBle Hampson wrote:
I'm attaching my DirectInput test program. It demonstrates both the MSDN sample way of doing a background DI mouse reader, and also as it happens a maybe-bug in Wine's DirectInput headers, in that you can't use DIMOFS_X and similar as case labels.
It also demonstrates another problem with current Wine DI. If you put its window up to the edge of the screen, and push your mouse against the edge of the screen, your mouse movement against the edge of the screen is lost.
And now, the program.
Paul TBBle Hampson wrote:
On Sun, Apr 19, 2009 at 12:46:20PM +0200, Stefan Dösinger wrote:
Am Sonntag, 19. April 2009 10:41:34 schrieb Paul TBBle Hampson:
I've thrown together a rather-rough-but-working-in-a-limited-sense implementation of XInput2-based DirectInput.
- Doesn't check for XInput2.h, so it won't build without it. (Laziness) It will _run_ without XInput2, falling back to the current dinput WndProc hooks even if compiled with XInput2 support.
I'm not that much into all the input code, but I always understood it the way that dinput should always use WndProc hooks, and winex11.drv implements the relative movement part either with XI2 or warping if XI2 is not available. Ie, there should be no difference between XI2 and legacy operation in dinput.dll. That would, I think, make native dinput work as well as the builtin one, and help apps that rely on hooks the same way native dinput does(if there are any).
The problem is that this means the warping has to be moved to winex11, which is something Vitaliy tried before and failed
I could be entirely wrong with that though. And I have no idea how that would affect mouse grabbing, or window focus issues etc.
A WndProc hook can only work for Foreground-mode DI. In background mode, you still expect to get movement messages without being in a position to receive WM_MOUSEMOVE or WM_KEYPRESS.
Not necessarily. Hook is for raw mouse & keyboard events, and they are being generated by the devices themselves. On native this works regardless of where the pointer is.
Moving the WndProc hook and mouse-warping behaviour to X11 would certainly be possible, and I suspect it'd end up somewhat with a mouse driver in dinput which is almost exactly what my gdimouse is, which is basically the existing mouse driver except that it feeds Acquire and Deacquire to X11drv and receives messages from X11drv when an event happens.
It would need to go into X11drv to implement another input API - RawInput.
I haven't read Vitaly's old patches for moving mouse warping to X11drv recently, but I did read them a while ago. The problem with moving the warping to X11drv is that then every graphics driver _must_ implement the hooks I've added in my patches, where as right now we have a fallback mouse support mode which will work with any graphics driver, and in fact would also work on Windows (I believe) because it simply hooks WndProc, and does not need "real hardware" access, and has well-documented and under-documented limitations because of it.
You'll always have current option of receiving standard pointer events. This doesn't go away.
It also demonstrates another problem with current Wine DI. If you put its window up to the edge of the screen, and push your mouse against the edge of the screen, your mouse movement against the edge of the screen is lost.
Yup, that's one of the biggest problems with current implementation. Which can't be resolved in non-exclusive mode without XI2.
Vitaliy.
On Sun, Apr 19, 2009 at 10:48:11AM -0600, Vitaliy Margolen wrote:
Paul TBBle Hampson wrote:
On Sun, Apr 19, 2009 at 12:46:20PM +0200, Stefan Dösinger wrote:
Am Sonntag, 19. April 2009 10:41:34 schrieb Paul TBBle Hampson:
I've thrown together a rather-rough-but-working-in-a-limited-sense implementation of XInput2-based DirectInput.
- Doesn't check for XInput2.h, so it won't build without it. (Laziness) It will _run_ without XInput2, falling back to the current dinput WndProc hooks even if compiled with XInput2 support.
I'm not that much into all the input code, but I always understood it the way that dinput should always use WndProc hooks, and winex11.drv implements the relative movement part either with XI2 or warping if XI2 is not available. Ie, there should be no difference between XI2 and legacy operation in dinput.dll. That would, I think, make native dinput work as well as the builtin one, and help apps that rely on hooks the same way native dinput does(if there are any).
The problem is that this means the warping has to be moved to winex11, which is something Vitaliy tried before and failed
I could be entirely wrong with that though. And I have no idea how that would affect mouse grabbing, or window focus issues etc.
A WndProc hook can only work for Foreground-mode DI. In background mode, you still expect to get movement messages without being in a position to receive WM_MOUSEMOVE or WM_KEYPRESS.
Not necessarily. Hook is for raw mouse & keyboard events, and they are being generated by the devices themselves. On native this works regardless of where the pointer is.
OK, I'm a little confused. What message is sent on native to all windows (or at least all windows with a DI Background Acquire on the mouse?) for a WndProc hook on the Acquiring process to handle?
Or does native work by having a hook on every WndProc which picks up the WM_MOUSEMOVE and feeds it to DI for redistribution to acquired software?
My understanding of Wine's current method is that a background process only gets events when they happen over its window, not when they happen over other Wine windows. My mousetest program produces such results with stock 1.1.19. Which explains why Ventrilo in DI mode can't get keyboard input even when different Wine applications are in the foreground.
Either way, that doesn't work for Wine because not every window on screen has a WndProc for us to hook. Unless I've missed something, that's the basis of my position that you cannot do correct background DI using only a WndProc hook, because you miss all the events that do not get fed to _any_ WndProc hook.
Moving the WndProc hook and mouse-warping behaviour to X11 would certainly be possible, and I suspect it'd end up somewhat with a mouse driver in dinput which is almost exactly what my gdimouse is, which is basically the existing mouse driver except that it feeds Acquire and Deacquire to X11drv and receives messages from X11drv when an event happens.
It would need to go into X11drv to implement another input API - RawInput.
OK. Sounds good. I'll have a play with that if and when I iterate these patches again if no one else has gotten there sooner.
I'll review your earlier patches for this change as well at that time, and make sure I understand how to go about this correctly.
I just skimmed the RawInput API on MSDN, and it looks like it provides data like DirectInput, but notifications through the Windows message loop rather than whenever the code feels like it or using an Event, like DI.
So from my reading, my suggestion above probably makes sense, to keep the current pair of methods I added for DI (wine_directinput_AcquireMouse and wine_dinput_MouseUnacquire), make it non-optional for a graphics driver to provide such methods and a system mouse, rename them without directinput, and then add RawInput to user32 such that it also takes an acquire on mouse and keyboard if those're what's asked for by the client software.
How do RawInput and DI interact? Is that known at this point?
Like directinput, things that aren't keyboard, mouse or similar are of no interest to the graphics driver. I assume RawInput can handle graphics tablets, although from the look of it it really distinguishes Mouse, Keyboard and HID devices, so it might make sense to do all HID devices via libusb or equivalent libraries, if such provide useful APIs.
winex11.drv gains the WndProc-hook method of generating DI events, in the non-XI2 case, but I still don't see why we'd want to use a WndProc hook if we have XI2 available.
Then again, I haven't looked hard at exclusive-mode grabbing, so there may be some need. I'd hoped we could just tell winex11 to ignore MotionNotify, ButtonPress and ButtonRelease when the mouse is taken in exclusive mode, and grab it so it effectively stays exactly where it is, modulo the window moving around beneath it shouldn't lose the grab.
I haven't read Vitaly's old patches for moving mouse warping to X11drv recently, but I did read them a while ago. The problem with moving the warping to X11drv is that then every graphics driver _must_ implement the hooks I've added in my patches, where as right now we have a fallback mouse support mode which will work with any graphics driver, and in fact would also work on Windows (I believe) because it simply hooks WndProc, and does not need "real hardware" access, and has well-documented and under-documented limitations because of it.
You'll always have current option of receiving standard pointer events. This doesn't go away.
I don't understand that in context of this paragraph.
Paul TBBle Hampson wrote:
On Sun, Apr 19, 2009 at 10:48:11AM -0600, Vitaliy Margolen wrote:
Paul TBBle Hampson wrote:
On Sun, Apr 19, 2009 at 12:46:20PM +0200, Stefan Dösinger wrote:
Am Sonntag, 19. April 2009 10:41:34 schrieb Paul TBBle Hampson:
I've thrown together a rather-rough-but-working-in-a-limited-sense implementation of XInput2-based DirectInput.
- Doesn't check for XInput2.h, so it won't build without it. (Laziness) It will _run_ without XInput2, falling back to the current dinput WndProc hooks even if compiled with XInput2 support.
I'm not that much into all the input code, but I always understood it the way that dinput should always use WndProc hooks, and winex11.drv implements the relative movement part either with XI2 or warping if XI2 is not available. Ie, there should be no difference between XI2 and legacy operation in dinput.dll. That would, I think, make native dinput work as well as the builtin one, and help apps that rely on hooks the same way native dinput does(if there are any).
The problem is that this means the warping has to be moved to winex11, which is something Vitaliy tried before and failed
I could be entirely wrong with that though. And I have no idea how that would affect mouse grabbing, or window focus issues etc.
A WndProc hook can only work for Foreground-mode DI. In background mode, you still expect to get movement messages without being in a position to receive WM_MOUSEMOVE or WM_KEYPRESS.
Not necessarily. Hook is for raw mouse & keyboard events, and they are being generated by the devices themselves. On native this works regardless of where the pointer is.
OK, I'm a little confused. What message is sent on native to all windows (or at least all windows with a DI Background Acquire on the mouse?) for a WndProc hook on the Acquiring process to handle?
WndProc hook is strictly to detect focus losses. The actual input comes from LL_HOOKs: WH_KEYBOARD_LL & WH_MOUSE_LL.
My understanding of Wine's current method is that a background process only gets events when they happen over its window, not when they happen over other Wine windows.
Not exactly correct. ATM Wine gets only those mouse & keyboard events that happen over _any_ Wine window (for mouse) and when Wine has focus (for keyboard).
Which explains why Ventrilo in DI mode can't get keyboard input even when different Wine applications are in the foreground.
This is not true. You probably running then from different prefixes.
Either way, that doesn't work for Wine because not every window on screen has a WndProc for us to hook. Unless I've missed something, that's the basis of my position that you cannot do correct background DI using only a WndProc hook, because you miss all the events that do not get fed to _any_ WndProc hook.
You missing something (see above). This doesn't work because lots of games buggy and think they acquire mouse in exclusive mode, while in fact they end-up using non-exclusive foreground mode.
The problem is not hooks, the problem is Wine (being a regular X application) not receiving pointer events when pointer is not over the application window(s). With using XI2 it wouldn't matter where the pointer is, Wine should always be receiving mouse & keyboard events and feed them to whatever asks for them either via LL hooks or RawInput or even global hot-key implementation.
I'll review your earlier patches for this change as well at that time, and make sure I understand how to go about this correctly.
That might be waste of time. I was trying to make x11org do all the magic (warping & grabbing pointer). This won't be aplicable as much with XI2.
I just skimmed the RawInput API on MSDN, and it looks like it provides data like DirectInput, but notifications through the Windows message loop rather than whenever the code feels like it or using an Event, like DI.
Yeah something like that. But I haven't looked deep enough to see if it can be implemented same way as DI or will have to go through wineserver.
So from my reading, my suggestion above probably makes sense, to keep the current pair of methods I added for DI (wine_directinput_AcquireMouse and wine_dinput_MouseUnacquire), make it non-optional for a graphics driver to provide such methods and a system mouse, rename them without directinput, and then add RawInput to user32 such that it also takes an acquire on mouse and keyboard if those're what's asked for by the client software.
That's what I was thinking too. Only they would need to be more sophisticated to handle multiple "users". Some games using multiple keyboard & mouse DInput devices. Also don't forget additional software, like ventrilo, running in parallel with the game.
How do RawInput and DI interact? Is that known at this point?
Don't know, and MSDN doesn't say anything about it. Can't really test it either - don't have anything newer then win2k.
Like directinput, things that aren't keyboard, mouse or similar are of no interest to the graphics driver. I assume RawInput can handle graphics tablets, although from the look of it it really distinguishes Mouse, Keyboard and HID devices, so it might make sense to do all HID devices via libusb or equivalent libraries, if such provide useful APIs.
No, all those should come through X - nothing should really be talking directly to hardware devices. Otherwise we already would have had the evdev mouse implementation.
Then again, I haven't looked hard at exclusive-mode grabbing, so there may be some need. I'd hoped we could just tell winex11 to ignore MotionNotify, ButtonPress and ButtonRelease when the mouse is taken in exclusive mode, and grab it so it effectively stays exactly where it is, modulo the window moving around beneath it shouldn't lose the grab.
That would have to be done somewhere - either x11drv or wineserver. With current code path for LL hooks it's in x11drv.
I haven't read Vitaly's old patches for moving mouse warping to X11drv recently, but I did read them a while ago. The problem with moving the warping to X11drv is that then every graphics driver _must_ implement the hooks I've added in my patches, where as right now we have a fallback mouse support mode which will work with any graphics driver, and in fact would also work on Windows (I believe) because it simply hooks WndProc, and does not need "real hardware" access, and has well-documented and under-documented limitations because of it.
You'll always have current option of receiving standard pointer events. This doesn't go away.
I don't understand that in context of this paragraph.
Read what I said about type of hooks current DInput using. Then it will be more clear. Hooks are not going away, some programs would still use them. Which means we can't just use XI2 for dinput. It would need to be used for anything requiring raw input events (RawInput, LL hooks, DInput, HotKeys, etc).
Vitaliy.
On Sun, Apr 19, 2009 at 02:39:43PM -0600, Vitaliy Margolen wrote:
Paul TBBle Hampson wrote:
On Sun, Apr 19, 2009 at 10:48:11AM -0600, Vitaliy Margolen wrote:
Paul TBBle Hampson wrote:
On Sun, Apr 19, 2009 at 12:46:20PM +0200, Stefan Dösinger wrote:
Am Sonntag, 19. April 2009 10:41:34 schrieb Paul TBBle Hampson:
I've thrown together a rather-rough-but-working-in-a-limited-sense implementation of XInput2-based DirectInput.
- Doesn't check for XInput2.h, so it won't build without it. (Laziness) It will _run_ without XInput2, falling back to the current dinput WndProc hooks even if compiled with XInput2 support.
I'm not that much into all the input code, but I always understood it the way that dinput should always use WndProc hooks, and winex11.drv implements the relative movement part either with XI2 or warping if XI2 is not available. Ie, there should be no difference between XI2 and legacy operation in dinput.dll. That would, I think, make native dinput work as well as the builtin one, and help apps that rely on hooks the same way native dinput does(if there are any).
The problem is that this means the warping has to be moved to winex11, which is something Vitaliy tried before and failed
I could be entirely wrong with that though. And I have no idea how that would affect mouse grabbing, or window focus issues etc.
A WndProc hook can only work for Foreground-mode DI. In background mode, you still expect to get movement messages without being in a position to receive WM_MOUSEMOVE or WM_KEYPRESS.
Not necessarily. Hook is for raw mouse & keyboard events, and they are being generated by the devices themselves. On native this works regardless of where the pointer is.
OK, I'm a little confused. What message is sent on native to all windows (or at least all windows with a DI Background Acquire on the mouse?) for a WndProc hook on the Acquiring process to handle?
WndProc hook is strictly to detect focus losses. The actual input comes from LL_HOOKs: WH_KEYBOARD_LL & WH_MOUSE_LL.
I think I understand now.
So we really don't want to touch dinput at all, but instead just use XI2 to feed the WH_*_LL hooks and let the existing DI code turn those hook inputs into event queue entries as it does now.
My understanding of Wine's current method is that a background process only gets events when they happen over its window, not when they happen over other Wine windows.
Not exactly correct. ATM Wine gets only those mouse & keyboard events that happen over _any_ Wine window (for mouse) and when Wine has focus (for keyboard).
Which explains why Ventrilo in DI mode can't get keyboard input even when different Wine applications are in the foreground.
This is not true. You probably running then from different prefixes.
Nope, they were the same prefix. The exact same command with my Wine build produced the correct behaviour.
Actually, I just checked, and it's only movement that's being lost. Scroll wheels and button presses appear on both, and every once in a while, I'll see a movement entry on the client that is not the foreground.
It could very well be a bug in my test program, although I can't see what it would be, I basically assembled it out of MSDN and some other quick samples.
I'm probably wrong about Ventrilo. I had this vague recollection that it only worked with other Wine programs in non-DI mode...
Either way, that doesn't work for Wine because not every window on screen has a WndProc for us to hook. Unless I've missed something, that's the basis of my position that you cannot do correct background DI using only a WndProc hook, because you miss all the events that do not get fed to _any_ WndProc hook.
You missing something (see above). This doesn't work because lots of games buggy and think they acquire mouse in exclusive mode, while in fact they end-up using non-exclusive foreground mode.
Buggy in that they pass in the wrong flags, or buggy in that they don't check the result? I know there's some discussion regarding Quake and Quake 2 in the bug report, but it doesn't specify if it's a game bug or not. It _seems_ to indicate it's a program bug that is hidden because the game is running full-screen so is always the window under the cursor, but I think that problem needs to be addressed separately. We can't exactly misimplement the API to benefit games that are using it wrong, if it involves breaking things that are using it right.
I'll review your earlier patches for this change as well at that time, and make sure I understand how to go about this correctly.
That might be waste of time. I was trying to make x11org do all the magic (warping & grabbing pointer). This won't be aplicable as much with XI2.
Actually, I still think it has to do that. To my mind, we only want dinput telling the graphics driver when it has acquired a device (so the graphics driver can start pumping the WH_*_LL hooks) and when it has acquired a device exclusively so the graphics driver can prevent events propagating to the normal windows event loop.
Whether this involves warping the mouse every 10ms, using XI2 to perform a grab on the pointer, or some mysterious quartz driver voodoo, shouldn't be visible to dinput, or rawinput, or
So from my reading, my suggestion above probably makes sense, to keep the current pair of methods I added for DI (wine_directinput_AcquireMouse and wine_dinput_MouseUnacquire), make it non-optional for a graphics driver to provide such methods and a system mouse, rename them without directinput, and then add RawInput to user32 such that it also takes an acquire on mouse and keyboard if those're what's asked for by the client software.
That's what I was thinking too. Only they would need to be more sophisticated to handle multiple "users". Some games using multiple keyboard & mouse DInput devices. Also don't forget additional software, like ventrilo, running in parallel with the game.
Can games use multiple mouse and keyboard devices? MSDN states that Windows XP's DI only enumerates one mouse and one keyboard, so I assumed people program with that assumption. Not that this is a hard assumption to manage.
Then again, I haven't looked hard at exclusive-mode grabbing, so there may be some need. I'd hoped we could just tell winex11 to ignore MotionNotify, ButtonPress and ButtonRelease when the mouse is taken in exclusive mode, and grab it so it effectively stays exactly where it is, modulo the window moving around beneath it shouldn't lose the grab.
That would have to be done somewhere - either x11drv or wineserver. With current code path for LL hooks it's in x11drv.
[trim]
I don't understand that in context of this paragraph.
Read what I said about type of hooks current DInput using. Then it will be more clear. Hooks are not going away, some programs would still use them. Which means we can't just use XI2 for dinput. It would need to be used for anything requiring raw input events (RawInput, LL hooks, DInput, HotKeys, etc).
OK, I'm clearer on all that now, thankyou.
So I guess the way to implement the XI2 support from the above is to restart this patch series again, as follows:
Move mouse warping into winex11.drv, and add a MouseAcquire/MouseDeacquire interface pair to winex11.drv.
That pair of functions will enable mouse warping if exclusive acquisition occurs. They probably need to keep a reference count, and ensure that we only stop doing what we've been asked if everything that acquired us has deacquired us. Only one thing at a time can have an exclusive acquisition (the foreground window) but this interface needs to be able to be used by RawInput too, so it might need to protect against multiple exclusive efforts by the foreground window. (Pathological case of program using both DI and RawInput!)
Add an XI2 variation of the MouseAcquire/MouseDeacquire functions that use a grab instead of mouse warping, and feed raw events into queue_raw_mouse_message if no Wine window has X focus.
However, there's at least one issue here:
Feeding LL_HOOKS from XI2 which then feeds DirectInput means we're going from relative to absolute values and back to relative (and then back to absolute if DI has the mouse axes in absolute mode).
The middle part of this will see co-ordinates that aren't sensible (ie the hook will see absolute co-ordinates that are outside its virtual desktop if running in a virtual desktop smaller than the screen)
The larger problem is that certain mouse movements can't work with an absolute value in the middle, namely those that happen when the cursor is already on the edge of the screen. If we support those by using the absolute position in the WH_MOUSE_LL data structure as accumulated relative position (as DirectInput does when providing absolute mouse axis data) then when we get a real cursor position later, the mouse is going to appear to jump quite sharply by however much movement was applied relatively without affecting the absolute pointer position on screen.
This also means we replicate part of the mouse-warping problem, because for foreground exclusive apps, the cursor isn't moving when we receive relative motion, so either we send the real cursor position in the WH_MOUSE_LL data, in which case no movement is visible, or we send real cursor position + relative movement, and therefore accumulate error over the life of the exclusive acquisition. I'm pretty sure this is what causes the Warhammer Online cusor-controlled camera to go completely wild when used with targeted seige weapons.
I think my solution to that while keeping the same structure is to add a WH_WINEMOUSE_REL hook message that carries relative mouse movement data, and let DirectInput and RawInput hook that. This also means that applications that wish to hook WH_MOUSE_LL while using DirectInput and RawInput are free to do so. (This last point may not be interesting, I don't know if they are currently interfered with by DirectInput taking a WH_MOUSE_LL hook on their behalf, and again it's probably pathological)
This would make the prototype for MouseAcquire be something like MouseAcquire( BOOL foreground, BOOL exclusive, BOOL relative ) * foreground true disables use of XI2, since by definition data will come through the normal X channel * exclusive enables pointer grab or warping and killing of normal Mouse handling. * relative enables sending of WH_WINEMOUSE_REL hook messages.
Again, it'd have to be a reference counted system, so any outstanding acquisitions would ensure messages of the type they acquire are being resent.
It's late, and although I've been stewing this over for the last few hours, it still may not make a lot of sense or contain large oversights on my part.
On Tue, Apr 21, 2009 at 01:09:47AM +1000, Paul TBBle Hampson wrote:
I think my solution to that while keeping the same structure is to add a WH_WINEMOUSE_REL hook message that carries relative mouse movement data, and let DirectInput and RawInput hook that. This also means that applications that wish to hook WH_MOUSE_LL while using DirectInput and RawInput are free to do so. (This last point may not be interesting, I don't know if they are currently interfered with by DirectInput taking a WH_MOUSE_LL hook on their behalf, and again it's probably pathological)
It's late, and although I've been stewing this over for the last few hours, it still may not make a lot of sense or contain large oversights on my part.
Two things I overlooked last night:
WH_MOUSE_LL only supports 5 buttons, DI supports 8. (kinda trivial, I don't know if things would break if we invented XMOUSE3 through XMOUSE5...)
Responsibility for generating hook messages when no Wine window is receiving X events (ie. XI2 is the only thing generating messages). Only one X connection should be receiving XI2, presumably the first one to want to do so, but if it exits, another window should take over assuming other windows still want to know about background mouse movement.
There's the possibility of lost input events during this changeover -- specifically, those events there were queued for the old window, or would have been queued except the old window went away, and aren't requeued to the new window.
Paul TBBle Hampson wrote:
On Sun, Apr 19, 2009 at 02:39:43PM -0600, Vitaliy Margolen wrote:
Paul TBBle Hampson wrote:
On Sun, Apr 19, 2009 at 10:48:11AM -0600, Vitaliy Margolen wrote:
Paul TBBle Hampson wrote:
On Sun, Apr 19, 2009 at 12:46:20PM +0200, Stefan Dösinger wrote:
Am Sonntag, 19. April 2009 10:41:34 schrieb Paul TBBle Hampson: > I've thrown together a rather-rough-but-working-in-a-limited-sense > implementation of XInput2-based DirectInput. > * Doesn't check for XInput2.h, so it won't build without it. (Laziness) > It will _run_ without XInput2, falling back to the current dinput > WndProc hooks even if compiled with XInput2 support. I'm not that much into all the input code, but I always understood it the way that dinput should always use WndProc hooks, and winex11.drv implements the relative movement part either with XI2 or warping if XI2 is not available. Ie, there should be no difference between XI2 and legacy operation in dinput.dll. That would, I think, make native dinput work as well as the builtin one, and help apps that rely on hooks the same way native dinput does(if there are any). The problem is that this means the warping has to be moved to winex11, which is something Vitaliy tried before and failed I could be entirely wrong with that though. And I have no idea how that would affect mouse grabbing, or window focus issues etc.
A WndProc hook can only work for Foreground-mode DI. In background mode, you still expect to get movement messages without being in a position to receive WM_MOUSEMOVE or WM_KEYPRESS.
Not necessarily. Hook is for raw mouse & keyboard events, and they are being generated by the devices themselves. On native this works regardless of where the pointer is.
OK, I'm a little confused. What message is sent on native to all windows (or at least all windows with a DI Background Acquire on the mouse?) for a WndProc hook on the Acquiring process to handle?
WndProc hook is strictly to detect focus losses. The actual input comes from LL_HOOKs: WH_KEYBOARD_LL & WH_MOUSE_LL.
I think I understand now.
So we really don't want to touch dinput at all, but instead just use XI2 to feed the WH_*_LL hooks and let the existing DI code turn those hook inputs into event queue entries as it does now.
That's the goal. But it won't be an easy thing to do. For now (testing XI2) we might make a special interface between dinput and x11drv.
Which explains why Ventrilo in DI mode can't get keyboard input even when different Wine applications are in the foreground.
This is not true. You probably running then from different prefixes.
Nope, they were the same prefix. The exact same command with my Wine build produced the correct behaviour.
I'm talking about WINEPREFIX (default ~/.wine).
Actually, I just checked, and it's only movement that's being lost.
That sounds about right. Move notify aren't delivered to windows that's not under the pointer.
I'm probably wrong about Ventrilo. I had this vague recollection that it only worked with other Wine programs in non-DI mode... From what I recall it can use HotKeys or DirectInput for push-to-talk. Of
course neither one of them work on Wine ATM.
Either way, that doesn't work for Wine because not every window on screen has a WndProc for us to hook. Unless I've missed something, that's the basis of my position that you cannot do correct background DI using only a WndProc hook, because you miss all the events that do not get fed to _any_ WndProc hook.
You missing something (see above). This doesn't work because lots of games buggy and think they acquire mouse in exclusive mode, while in fact they end-up using non-exclusive foreground mode.
Buggy in that they pass in the wrong flags, or buggy in that they don't check the result?
Both. They call SetCooperativeLevel(did, NULL, DISCL_EXCLUSIVE | DISCL_FOREGROUND) which is wrong - they have to specify the window, it can't be null. And they don't check for return, assuming call was successful. And ending up with default (non-exclusive, background).
It _seems_ to indicate it's a program bug that is hidden because the game is running full-screen so is always the window under the cursor, but I think that problem needs to be addressed separately.
Well, Wine have to do what native does - at least make these games work in full screen.
We can't exactly misimplement the API to benefit games that are using it wrong, if it involves breaking things that are using it right.
Eventually we might have to - native has all sorts of "shims" to fix broken programs. But this is a topic for another big and long discussion.
I'll review your earlier patches for this change as well at that time, and make sure I understand how to go about this correctly.
That might be waste of time. I was trying to make x11org do all the magic (warping & grabbing pointer). This won't be aplicable as much with XI2.
Actually, I still think it has to do that. To my mind, we only want dinput telling the graphics driver when it has acquired a device (so the graphics driver can start pumping the WH_*_LL hooks) and when it has acquired a device exclusively so the graphics driver can prevent events propagating to the normal windows event loop.
Most likely - yes. Or at least for the time being to test new XI2 to make things easier.
Whether this involves warping the mouse every 10ms, using XI2 to perform
Now this is something we can not do. Wine can not warp mouse - some games break because of that.
a grab on the pointer, or some mysterious quartz driver voodoo, shouldn't be visible to dinput, or rawinput, or
This might be necessary in virtual-desktop mode. Full screen is kind of easy way to solve this problem for most game developers. So they don't envision their games running in a windowed mode (I'm looking at you Ubi).
So from my reading, my suggestion above probably makes sense, to keep the current pair of methods I added for DI (wine_directinput_AcquireMouse and wine_dinput_MouseUnacquire), make it non-optional for a graphics driver to provide such methods and a system mouse, rename them without directinput, and then add RawInput to user32 such that it also takes an acquire on mouse and keyboard if those're what's asked for by the client software.
That's what I was thinking too. Only they would need to be more sophisticated to handle multiple "users". Some games using multiple keyboard & mouse DInput devices. Also don't forget additional software, like ventrilo, running in parallel with the game.
Can games use multiple mouse and keyboard devices? MSDN states that Windows XP's DI only enumerates one mouse and one keyboard, so I assumed people program with that assumption. Not that this is a hard assumption to manage.
That's not what I meant. Some games create more then one keyboard/mouse devices (IDirectInput_CreateDevice). And expect them all to work.
So I guess the way to implement the XI2 support from the above is to restart this patch series again, as follows:
Move mouse warping into winex11.drv, and add a MouseAcquire/MouseDeacquire interface pair to winex11.drv.
Not move warping, remove it (it shouldn't be done at all).
That pair of functions will enable mouse warping if exclusive acquisition occurs. They probably need to keep a reference count, and ensure that we only stop doing what we've been asked if everything that acquired us has deacquired us. Only one thing at a time can have an exclusive acquisition (the foreground window) but this interface needs to be able to be used by RawInput too, so it might need to protect against multiple exclusive efforts by the foreground window. (Pathological case of program using both DI and RawInput!)
Correct. DI does something like that currently - it has a dedicated thread that receives all the events. Then it dispatches them to each acquired device. X11drv will have to do something similar - it needs a dedicated thread with a dedicated X11 connection - we can't relay on the owner of the foreground window to pump events, as some don't.
Add an XI2 variation of the MouseAcquire/MouseDeacquire functions that use a grab instead of mouse warping, and feed raw events into queue_raw_mouse_message if no Wine window has X focus.
Correct. It might be a complete replacement for the current raw event generator (regular X events).
However, there's at least one issue here:
Feeding LL_HOOKS from XI2 which then feeds DirectInput means we're going from relative to absolute values and back to relative (and then back to absolute if DI has the mouse axes in absolute mode).
We can always change DInput to talk to X11 directly. Or use ... RawInput events. It sure would be cool to make it in a native compatible way (using driver interface) but it would be too much work. No something we'd like to spend our time on ATM.
The middle part of this will see co-ordinates that aren't sensible (ie the hook will see absolute co-ordinates that are outside its virtual desktop if running in a virtual desktop smaller than the screen)
The larger problem is that certain mouse movements can't work with an absolute value in the middle, namely those that happen when the cursor is already on the edge of the screen. If we support those by using the absolute position in the WH_MOUSE_LL data structure as accumulated relative position (as DirectInput does when providing absolute mouse axis data) then when we get a real cursor position later, the mouse is going to appear to jump quite sharply by however much movement was applied relatively without affecting the absolute pointer position on screen.
In theory LL hook events should contain raw mouse events regardless of the pointer. In practice - I don't remember what native does. I think if the cursor "stuck" on the border it just (dec|inc)rements it's position by the relative move amount and send these "fake" coords to the hook. Of course the cursor position doesn't change, so (hook_coords - GetCursorPos() = relative coords) still works.
This would make the prototype for MouseAcquire be something like MouseAcquire( BOOL foreground, BOOL exclusive, BOOL relative )
- foreground true disables use of XI2, since by definition data will come through the normal X channel
- exclusive enables pointer grab or warping and killing of normal Mouse handling.
- relative enables sending of WH_WINEMOUSE_REL hook messages.
Again, it'd have to be a reference counted system, so any outstanding acquisitions would ensure messages of the type they acquire are being resent.
Looks good. Might even add a callback instead of piping messages through the whole Wine.
Vitaliy.
On Tue, Apr 21, 2009 at 08:16:14AM -0600, Vitaliy Margolen wrote:
Paul TBBle Hampson wrote:
On Sun, Apr 19, 2009 at 02:39:43PM -0600, Vitaliy Margolen wrote:
Paul TBBle Hampson wrote:
I think I understand now.
So we really don't want to touch dinput at all, but instead just use XI2 to feed the WH_*_LL hooks and let the existing DI code turn those hook inputs into event queue entries as it does now.
That's the goal. But it won't be an easy thing to do. For now (testing XI2) we might make a special interface between dinput and x11drv.
I'm probably wrong about Ventrilo. I had this vague recollection that it only worked with other Wine programs in non-DI mode...
From what I recall it can use HotKeys or DirectInput for push-to-talk. Of course neither one of them work on Wine ATM.
I'm sure one of them used to work, because I used to use it with WoW.
Either way, that doesn't work for Wine because not every window on screen has a WndProc for us to hook. Unless I've missed something, that's the basis of my position that you cannot do correct background DI using only a WndProc hook, because you miss all the events that do not get fed to _any_ WndProc hook.
You missing something (see above). This doesn't work because lots of games buggy and think they acquire mouse in exclusive mode, while in fact they end-up using non-exclusive foreground mode.
Buggy in that they pass in the wrong flags, or buggy in that they don't check the result?
Both. They call SetCooperativeLevel(did, NULL, DISCL_EXCLUSIVE | DISCL_FOREGROUND) which is wrong - they have to specify the window, it can't be null. And they don't check for return, assuming call was successful. And ending up with default (non-exclusive, background).
It _seems_ to indicate it's a program bug that is hidden because the game is running full-screen so is always the window under the cursor, but I think that problem needs to be addressed separately.
Well, Wine have to do what native does - at least make these games work in full screen.
We can't exactly misimplement the API to benefit games that are using it wrong, if it involves breaking things that are using it right.
Eventually we might have to - native has all sorts of "shims" to fix broken programs. But this is a topic for another big and long discussion.
Oh, indeed. If we can spot the mistakes (as described above) we can fix them. I meant that we cannot for example turn a foreground non-exclusive acquire into a foreground exclusive acquire, as that will break things that really do want it non-exclusive.
I'll review your earlier patches for this change as well at that time, and make sure I understand how to go about this correctly.
That might be waste of time. I was trying to make x11org do all the magic (warping & grabbing pointer). This won't be aplicable as much with XI2.
Actually, I still think it has to do that. To my mind, we only want dinput telling the graphics driver when it has acquired a device (so the graphics driver can start pumping the WH_*_LL hooks) and when it has acquired a device exclusively so the graphics driver can prevent events propagating to the normal windows event loop.
Most likely - yes. Or at least for the time being to test new XI2 to make things easier.
Whether this involves warping the mouse every 10ms, using XI2 to perform
Now this is something we can not do. Wine can not warp mouse - some games break because of that.
So how do we handle systems that don't support XI2? If we remove the mouse warping entirely, do we just reject attempts to acquire the mouse exclusively on those systems?
I assume those same games will break if we cannot acquire the mouse exclusively, although I'd be thrilled to be wrong.
I haven't looked at the other alternatives, but maybe once we get relative motion using XI2, we can simulate exclusive mode by simply discarding all mouse events in the x11drv event loop, and use a normal X cursor grab to tie the mouse inside our window?
(My knowledge on grabs is shakey at best, which is the other reason I addresses the background DI case before the exclusive DI case)
a grab on the pointer, or some mysterious quartz driver voodoo, shouldn't be visible to dinput, or rawinput, or
This might be necessary in virtual-desktop mode. Full screen is kind of easy way to solve this problem for most game developers. So they don't envision their games running in a windowed mode (I'm looking at you Ubi).
We still need to hold the mouse for full-screen games, or we get the problem that a full-screen game is generally only full-screen on one monitor, and the mouse isn't otherwise constrained to that monitor, and hence the mouse can stray out of the game's window. Happens on Windows too, to some non-DI games, although click-to-focus means that if you don't click, it doesn't break.
So from my reading, my suggestion above probably makes sense, to keep the current pair of methods I added for DI (wine_directinput_AcquireMouse and wine_dinput_MouseUnacquire), make it non-optional for a graphics driver to provide such methods and a system mouse, rename them without directinput, and then add RawInput to user32 such that it also takes an acquire on mouse and keyboard if those're what's asked for by the client software.
That's what I was thinking too. Only they would need to be more sophisticated to handle multiple "users". Some games using multiple keyboard & mouse DInput devices. Also don't forget additional software, like ventrilo, running in parallel with the game.
Can games use multiple mouse and keyboard devices? MSDN states that Windows XP's DI only enumerates one mouse and one keyboard, so I assumed people program with that assumption. Not that this is a hard assumption to manage.
That's not what I meant. Some games create more then one keyboard/mouse devices (IDirectInput_CreateDevice). And expect them all to work.
That'd work now, though, right? Each device object you create using CreateDevice gets its own event queue which the queue_event call populates, so draining the buffer on one doesn't affect the others.
Or do they expect to work by sharing a buffer (ie being actually multiple references to one instance)?
So I guess the way to implement the XI2 support from the above is to restart this patch series again, as follows:
Move mouse warping into winex11.drv, and add a MouseAcquire/MouseDeacquire interface pair to winex11.drv.
Not move warping, remove it (it shouldn't be done at all).
This is the incremental changes approach... It seems to me the first step is to move around the existing functionality, before we start ripping it out wholesale. If the first step can be ripping out warping, I'm all in favour of it.
That pair of functions will enable mouse warping if exclusive acquisition occurs. They probably need to keep a reference count, and ensure that we only stop doing what we've been asked if everything that acquired us has deacquired us. Only one thing at a time can have an exclusive acquisition (the foreground window) but this interface needs to be able to be used by RawInput too, so it might need to protect against multiple exclusive efforts by the foreground window. (Pathological case of program using both DI and RawInput!)
Correct. DI does something like that currently - it has a dedicated thread that receives all the events. Then it dispatches them to each acquired device. X11drv will have to do something similar - it needs a dedicated thread with a dedicated X11 connection - we can't relay on the owner of the foreground window to pump events, as some don't.
Add an XI2 variation of the MouseAcquire/MouseDeacquire functions that use a grab instead of mouse warping, and feed raw events into queue_raw_mouse_message if no Wine window has X focus.
Correct. It might be a complete replacement for the current raw event generator (regular X events).
So every process that uses DI or similar causes x11drv to spawn a thread that talks to the XServer, doing only XI2 raw event processing and presumably grabs? It would feed the hooks, and/or call the callback into DI or RawInput or whatever. And the current hook feeding functions in mouse.c and keyboard.c go away.
However, there's at least one issue here:
Feeding LL_HOOKS from XI2 which then feeds DirectInput means we're going from relative to absolute values and back to relative (and then back to absolute if DI has the mouse axes in absolute mode).
We can always change DInput to talk to X11 directly. Or use ... RawInput events. It sure would be cool to make it in a native compatible way (using driver interface) but it would be too much work. No something we'd like to spend our time on ATM.
I was actually thinking it might be interesting to consider RawInput implemented on DI, but hadn't thought the semantics through.
I actually went looking, but didn't find any documentation in WDK online or MSDN about how DI would talk directly to mouse or keyboard hardware under Windows.
The middle part of this will see co-ordinates that aren't sensible (ie the hook will see absolute co-ordinates that are outside its virtual desktop if running in a virtual desktop smaller than the screen)
The larger problem is that certain mouse movements can't work with an absolute value in the middle, namely those that happen when the cursor is already on the edge of the screen. If we support those by using the absolute position in the WH_MOUSE_LL data structure as accumulated relative position (as DirectInput does when providing absolute mouse axis data) then when we get a real cursor position later, the mouse is going to appear to jump quite sharply by however much movement was applied relatively without affecting the absolute pointer position on screen.
In theory LL hook events should contain raw mouse events regardless of the pointer. In practice - I don't remember what native does. I think if the cursor "stuck" on the border it just (dec|inc)rements it's position by the relative move amount and send these "fake" coords to the hook. Of course the cursor position doesn't change, so (hook_coords - GetCursorPos() = relative coords) still works.
I'll expand my test program to use native hooks (and maybe RawInput if necessary) before I do any more work on implementing these behaviours.
That comparison doesn't work if the mouse is not against the edge of the screen, I assume. (ie the hook is not processed before cursor position is updated)
This would make the prototype for MouseAcquire be something like MouseAcquire( BOOL foreground, BOOL exclusive, BOOL relative )
- foreground true disables use of XI2, since by definition data will come through the normal X channel
- exclusive enables pointer grab or warping and killing of normal Mouse handling.
- relative enables sending of WH_WINEMOUSE_REL hook messages.
Again, it'd have to be a reference counted system, so any outstanding acquisitions would ensure messages of the type they acquire are being resent.
Looks good. Might even add a callback instead of piping messages through the whole Wine.
This is actually roughly what my patch currently prototypes, a direct callback from x11drv to DirectInput. It relies on the existing message pump though, and assumes only one callback at a time will be in existence, for speed of prototyping.
Along with the notes in my other message, I think letting code that wants relative data register a callback with x11drv is the right thing to do.
Paul TBBle Hampson wrote:
Current limitations:
- Doesn't check for XInput2.h, so it won't build without it. (Laziness) It will _run_ without XInput2, falling back to the current dinput WndProc hooks even if compiled with XInput2 support.
I don't think you need the entire separate list of mouse and keyboard devices. That makes code extra complicated. You can always have a flag to check if you enumerated mouse/keyboard already or not.
- Doesn't send button-ups; XI2 can't distinguish button up from down
Is this XI2's limitation? Programs won't work without key up events.
- Doesn't send events after button-down until after button-up on a window. I'm pretty sure this is an XI2 bug, but it might be a design feature.
Kind of strange. The code seems to be straight forward. Probably something in XI2.
- Doesn't support exclusive mode. XI2 bug (grabs not yet implemented) Hopefully this can be implemented entirely within the dinput code in winex11drv (ie disabling and hiding the mouse on acquire. dinput already takes care of unacquiring when we are no longer the foreground app)
That won't be as easy to implement in x11drv. However, considering some buggy games (ex: Quake based) that fail to acquire mouse properly in exclusive mode, this might be the only option.
- Mouse buttons aren't remapped nicely downwards. Need to look harder at this, my mouse reports buttons 1, 2, 3, 4, 5, 8, 9, 10, 11 and 12 under X. 4 and 5 are scroll, 6 and 7 might be horizontal scroll in which case if this is always the case we can just remap downwards. Might need to implement device querying to confirm mouse button mapping...
Most likely just need to hard-code mapping. DInput supports up to 8 buttons and 3 axes. That's it.
- Only supports the Mouse. Adding keyboard support should be really trivial compared to actually getting the framework right.
Agreed.
- Doesn't detect capabilities... A mouse with a horizontal scroll wheel'd have four axes. I haven't looked to see if DirectInput can support that, or if our dinput code can easily accomodate more axes or buttons than the current 3/8 setup. This the point we'd need another callthrough from gdimouse to the graphics driver.
AFAIK native dinput doesn't support horizontal scrolling. You can ignore that.
- Assumes a process will only try and acquire the mouse once. I'm not sure that this is a bad assumption, and it might be that dinput makes this a valid assumption for us.
I've seen programs that call acquire every time the read data. For an acquired device it's a no-op. You should manager that in dinput - it has "acquired" flag in the base class.
- gdimouse uses Wine Mouse GUID value. I'm not sure where these come from, if anywhere. Trivial to fix before submission.
Doesn't really matter ATM.
If this format is fine, then the first patch is basically ready to go, the latter two patches may need to be re-split or merged more sensibly.
Like I mentioned above, just keep the same list of devices and add 1 flag (you don't implement keyboard atm) to iterate only one mouse.
The thing I'm still concerned about - we still rely on application having event loop in the tread owning the main window - the one that will receive all X11 events. Some programs/games (see bug http://bugs.winehq.org/show_bug.cgi?id=8854) don't have that loop. Or don't process events for some other reason - like some never get focus. I was hoping to have totally separate X11 connection with attached thread to pull/process/dispatch events.
For now it seems there few bugs in XI2 implementation that needs to be addressed first - or the whole exercise will be for nothing.
Vitaliy.
I thought I saw a reply regarding these points on the mailing list archive, but I don't see it in my inbox.
Conveniently, I got an email from whot (XI2 developer) addressing these points, but I haven't pulled from the updated XI2 repositories. On the plus side the patches to XI2 that I included in my tarball should no longer be necessary.
On Sun, Apr 19, 2009 at 06:41:34PM +1000, Paul TBBle Hampson wrote:
It's got a fair few problems, I'm mainly interested in feedback on the approach, although obviously any code or style criticisms are welcome.
Current limitations:
- Doesn't send button-ups; XI2 can't distinguish button up from down
I should have been clearer. This is a bug in the libXi library, which whot has now fixed.
- Doesn't send events after button-down until after button-up on a window. I'm pretty sure this is an XI2 bug, but it might be a design feature.
Whot said this was because clients that accept button presses cause an implicit grab until the button is released, and this was unintentionally blocking raw events. He'll either fix it, or already has.
- Doesn't support exclusive mode. XI2 bug (grabs not yet implemented) Hopefully this can be implemented entirely within the dinput code in winex11drv (ie disabling and hiding the mouse on acquire. dinput already takes care of unacquiring when we are no longer the foreground app)
Whot has now implemented active grabs, but not passive grabs yet. I don't know the difference yet, so I don't know if this is actually sufficient for us.
- Mouse buttons aren't remapped nicely downwards. Need to look harder at this, my mouse reports buttons 1, 2, 3, 4, 5, 8, 9, 10, 11 and 12 under X. 4 and 5 are scroll, 6 and 7 might be horizontal scroll in which case if this is always the case we can just remap downwards. Might need to implement device querying to confirm mouse button mapping...
Whot confirmed that this is indeed current behaviour, and will probably remain so for legacy application support. However, XI2 supports button label checking, so we can actually find out what each button number does rather than hardcoding them based on these numbers.
However, the button labels themselves are not yet implemented, so for now I won't bother querying, I'll just trust the numbers stay as they are above.
It'll be handy for this project that my main mouse is 3-axis and has 8 buttons. Right now only the first five buttons work in Wine's DI, according to my test program.
I've tried XI2 Direct Input realisation with last xorg versions. It need some function name fixes to build. Here is a fixed file. As soon, as my wine will be build, i'll test the changes.
-
Fenixk19 -
Paul TBBle Hampson -
Stefan Dösinger -
Vitaliy Margolen