XI2 DirectInput mouse implementation RFC (Tarballed)

[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.

* 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.

-- 
Paul "TBBle" Hampson, Paul.Hampson at Pobox.com

Shorter .sig for a more eco-friendly paperless office.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xi2-rfc1.tar.bz2
Type: application/octet-stream
Size: 12262 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20090419/504414a9/attachment-0001.obj>
-------------- 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/20090419/504414a9/attachment-0001.pgp>