XI2 DirectInput mouse implementation RFC (Tarballed)
wine-devel at kievinfo.com
Sun Apr 19 12:19:19 CDT 2009
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
> * 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
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.
> * 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
For now it seems there few bugs in XI2 implementation that needs to be
addressed first - or the whole exercise will be for nothing.
More information about the wine-devel