Adding RID_TYPEHID RawInput support to user32

Nathan Schulte nmschulte at
Fri Jul 3 18:47:44 CDT 2015

On 07/03/2015 04:19 PM, Nikolay Sivov wrote:
> I don't know if it will work at all, but Aric already started to work on
> this area, see
> I think
> the idea is to unify hid device access logic, and move it to a single
> place that could contain plarform-specific bits still offering same
> interface to clients.

I started looking at these changes, thanks for the heads up (very recent 
too; what timing).  I think I grasp them: the HidD* (HID Driver) 
routines are user-space, and we are making the respective IOCTL calls 
and translating as necessary (so these support user-mode drivers, and 
some are purely out of convenience so they don't map 1:1 with the 
IOCTLS?).  I'm not sure why kernel-mode drivers are only allowed to call 
HidP* (HID Parser) routines, but application-mode drivers can without 
being "kernel-mode."  Kernel-mode code isn't allowed to use IOCTL, maybe?

Anyway, it looks like work to user32 (RawInput for RID_TYPEHID) will 
still be required in order for my software to work.  As I understand it, 
the software I'm trying to support will use the RawInput API to get the 
PreparsedData blob, and then use the HIDClass support routines (HidD*, 
HidP*; and I'm guessing only the latter) to extract the important 
information.  Perhaps there's another piece in the loop I'm missing 
(like a miniport driver/equiv), but I'm not sure.

On a related note, I see that the game is calling out to XInput as well 
(as the WineHQ App page notes):

He says this is only used for the L/R triggers, but it seems odd that a 
game would split input across two libs like that.  Anyway, perhaps 
there's a limitation and it's necessary, in which case I'll need to get 
XInput working as well (which I think Wine already does via evdev/input 
devices? I may need to deal with button mapping, but xboxdrv may make 
this simple; is that correct?).


More information about the wine-devel mailing list