XI2 DirectInput mouse implementation RFC (Tarballed)

Sun Apr 19 14:33:51 CDT 2009

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, B.Sc, LPI, MCSE
Very-later-year Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
Paul.Hampson at Pobox.com

Of course Pacman didn't influence us as kids. If it did,
we'd be running around in darkened rooms, popping pills and
listening to repetitive music.
 -- Kristian Wilson, Nintendo, Inc, 1989

License: http://creativecommons.org/licenses/by/2.5/au/
-----------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20090420/27fbd285/attachment.pgp>