XI2 DirectInput mouse implementation RFC (Tarballed)

[Vitaliy Margolen]

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.