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 http://source.winehq.org/git/wine.git/history/HEAD:/dlls/hid. 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):
https://appdb.winehq.org/objectManager.php?sClass=version&iId=31866
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?).
-- Nate