(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
On 04.07.2015 0:12, Nathan Schulte wrote:
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?
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.
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.
CC'ing Aric, to make sure he doesn't miss this.
Thanks,
-- Nate
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
On 7/3/15 6:47 PM, Nathan Schulte wrote:
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?
Hello there, Sorry for the delay I was away on vacation until today.
Yes, RawInput support should go through hid.dll. That is actually part of the reason I am doing the hid work the ways I am doing it. I want to be able to fully and correctly support RawInput as well as dinput, xinput and winmm joysticks.
For wine work, you can have all the user32 stuff using the hid.dll HidD_ and HidP_ functions as they can be considered user land work. If you find there are HidD_ or HidP_ function you need that are not implemented, then that can be done.
Right now the hid.dll work has gotten in but I am just starting to get the underlying hid minidriver work in place. Without the minidriver work hid.dll will not do much.
Native hid.dll will not do much of anything either.
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.
Yes all the user32 work will need to be done.
I am working on the minidriver part right now, thought my work is mostly structural and Mac related. Someone will have to work on the Linux minidriver as well.
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?).
Xinput is on my goal list also. Xinput should also be a client of hid.dll
-aric
-
Aric Stewart -
Nathan Schulte -
Nikolay Sivov