Adding RID_TYPEHID RawInput support to user32

[Nathan Schulte]

(Apologies if double posting; I wasn't sub'd the first time and it
wasn't in the archives.)

I'm working to extend Wine's RawInput implementation to support
gamepads/controllers (and possibly joysticks, or any non-keyboard/mouse
HID device).

I found this on the wine-patches list:

Vincas Miliūnas wrote:
> A comment about going beyond mouse/keyboard for raw input:Other
> devices then mouse&keyboard produce undocumented blobs of bytes;to
> interpret them, functions from the hid.dll are used. Currently
> theyare unimplemented stubs in WINE as well as not the problem I am
> solving.There is a recent article about this subject - Using the Raw
> Input APIto Process Joystick Input
> -http://www.codeproject.com/KB/game/RawInputJoystick.aspx

Does this imply then, that if one was to add support for "raw" rawinput
(RIM_TYPEHID device type) it could be used in conjunction with a native
hid.dll and software that required RIM_TYPEHID input (for e.g. game
controllers in games) would start working?

Nathan Schulte (me; original post) wrote:
> Also, could one create an adaptation from some joystick input libraries
> (evdev/x11,rawhid) and make it conform to the API in the CodeProject
> example, making modifications similar to Henri Verbeet's for mouse and
> keyboard and have built-in support for this?
>
> (Henri Verbeet's rawinput contributions:
> http://source.winehq.org/git/wine.git/?a=search&st=commit&s=rawinput)
 >
> I see that Wine already has support for joysticks in some other
> fashion (the gamepad I'm working with shows up in the `wine control`
>  Game Controller testing interface), and I bet it's a good idea to
> leverage that adaptation (those adaptations...) than to start adding
> my own.
>
> Any direction here would be appreciated. I think I understand the
> separation between the wineserver (mainly server/queue.c) and the
> dlls (dlls/user32/*), but I see that there are other "dlls" that
> don't use (or don't appear to use, given my probably incorrect
> understanding) wineserver for their adaptation, and instead talk
> directly with the Linux libs to do their work (I'm assuming).

It looks like what I was was seeing was "Wine drivers,"
(winejoystick.drv, for winmm's joystick bits, and DirectInput's joystick
bits).  Should I follow that route, or should I plumb this through
wineserver, like the rawinput keyboard and mouse?  Why are those plumbed
through wineserver?  Are they shared resources, and if so, why doesn't
that matter for winmm and DirectInput?

I'm thinking this should be fairly easy to get working, by enumerating 
the rawhid devices and just piping the data through.  I'm not sure how 
well the native hid.dll will work though; can anyone comment?

Any help is welcome, as it means my patches are more likely to make it
upstream and benefit others.  I'm wondering if there's an architecture
diagram/doc somewhere to help me understand how the system works.

Thanks,

--
Nate