XI2 DirectInput mouse implementation RFC (Tarballed)

[Vitaliy Margolen]

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.