Re: Adding RID_TYPEHID RawInput support to user32
On 7/6/15 10:53 AM, Nathan Schulte wrote:
On 07/06/2015 07:40 AM, Aric Stewart wrote:
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.
I found your recent discussion from April ("Wine Joysticks, seeking a plan"), as well as reviewed your current work to hid.dll. I've been learning about the stack as I go along, but it seems documented enough to get a grasp of. These are the minidrivers you're talking about?
https://msdn.microsoft.com/en-us/library/windows/hardware/jj131707(v=vs.85)....
You're thinking of creating one per platform/API (on the hosting side: Linux/evdev, (Unix/Linux?) X11, Unix/Mac *), or mirroring MS's setup? I'm not sure how the loading of those libraries works (I did see the HidRegisterMinidriver routine though), so maybe the question is inaccurate.
So the next round of patches have been submitted so you can see my hidclass and minidriver work. The goal is to have all the system native minidriver be in the winehidminidriver.sys so that it can be independent from the graphics driver. Wine's hidclass.sys can handle multiple minidrivers in one service, so we should not need independent minidrivers for every platform. Which should be handy.
On 07/06/2015 07:40 AM, Aric Stewart wrote:
Yes all the user32 work will need to be done.
Xinput is on my goal list also. Xinput should also be a client of hid.dll
Sounds good. I'll try to help where I can. It sounds like I need to become more familiar with the system before I'm really useful.
There are 3 places I can really use help. 1) Review patches: I always love good reviews on my patches. Leads to stronger code. 2) Above hid.dll: This is doing the development work on RawInput, Xinput, Dinput and such to become clients of the user level hid.dll functions to access joysticks and gamepads. This should mostly be learning the respective APIs and hooking them into HID. RawInput is probably the easiest as it does not do much with the HID reports other than just pass them on. 3) Linux minidrivers: I have implemented the OS/X minidriver because that is what I am most familiar with. There is work to implement the linux and linuxinput minidrivers. This is for someone familiar with or wants to become familiar with the lower level linux interfaces. -aric
On 07/07/2015 07:37 AM, Aric Stewart wrote:
Wine's hidclass.sys can handle multiple minidrivers in one service, so we should not need independent minidrivers for every platform. Which should be handy.
Excellent. On 07/07/2015 07:37 AM, Aric Stewart wrote:
There are 3 places I can really use help.
1) Review patches: I always love good reviews on my patches. Leads to stronger code.
2) Above hid.dll: This is doing the development work on RawInput, Xinput, Dinput and such to become clients of the user level hid.dll functions to access joysticks and gamepads. This should mostly be learning the respective APIs and hooking them into HID. RawInput is probably the easiest as it does not do much with the HID reports other than just pass them on.
3) Linux minidrivers: I have implemented the OS/X minidriver because that is what I am most familiar with. There is work to implement the linux and linuxinput minidrivers. This is for someone familiar with or wants to become familiar with the lower level linux interfaces.
I can definitely help with #1; it'll be a good way to become familiar with this part of the stack too. I started in on all of this with #2, so I can probably help with this as well. I just started researching #3, with trying to drive XInput by evdev; I'd like to contribute what I can here as well. Starting with the evdev minidriver seems right, and then RawInput will probably come next. I still wonder about my question earlier; about how RawInput manages shared resources in wineserver. Does the concern there play into how you design hid.dll/HIDclass? -- Nate
On 7/7/15 10:30 AM, Nathan Schulte wrote:
On 07/07/2015 07:37 AM, Aric Stewart wrote:
There are 3 places I can really use help.
1) Review patches: I always love good reviews on my patches. Leads to stronger code.
2) Above hid.dll: This is doing the development work on RawInput, Xinput, Dinput and such to become clients of the user level hid.dll functions to access joysticks and gamepads. This should mostly be learning the respective APIs and hooking them into HID. RawInput is probably the easiest as it does not do much with the HID reports other than just pass them on.
3) Linux minidrivers: I have implemented the OS/X minidriver because that is what I am most familiar with. There is work to implement the linux and linuxinput minidrivers. This is for someone familiar with or wants to become familiar with the lower level linux interfaces.
I just started researching #3, with trying to drive XInput by evdev; I'd like to contribute what I can here as well. Starting with the evdev minidriver seems right, and then RawInput will probably come next.
Here is a very nice reference and walk through for HID class minidrivers: http://flylib.com/books/en/4.168.1.84/1/ And of course the microsoft documentation: https://msdn.microsoft.com/en-us/library/jj131708%28v=vs.85%29.aspx All the bits are not implemented or needed. So you can refer to the minidriver_osx.c module (when we get that far and it is committed) to see how much of a minidriver is needed. The big question is will the underling linux parts give you access directly to the HID Report Descriptor and the HID Reports. If they do, such as the mac parts, then things are super easy. If they do NOT, then it gets much more complicated.
I still wonder about my question earlier; about how RawInput manages shared resources in wineserver. Does the concern there play into how you design hid.dll/HIDclass?
Sorry, I have totally missed that question. I am not much of a wineserver person so that is going to be tough for me. But I have found that 90% of the time I think something is going to have to be in the wineserver it ends up not being one, so there is that possibility. -aric
On Tue, Jul 7, 2015 at 9:18 PM, Aric Stewart <aric(a)codeweavers.com> wrote:
The big question is will the underling linux parts give you access directly to the HID Report Descriptor and the HID Reports. If they do, such as the mac parts, then things are super easy. If they do NOT, then it gets much more complicated.
I looked into this earlier. Devices like /dev/input/js0 and /dev/js0 are an abstraction and do not provide direct access to HID report descriptor or reports (which may not even exist, depending on the type of joystick). Devices like /dev/hidraw0 or /dev/hiddev0 do provide this access, however on a default Ubuntu setup non-root users do not have permission to access these devices.
On 7/8/15 4:20 PM, Vincent Povirk wrote:
On Tue, Jul 7, 2015 at 9:18 PM, Aric Stewart <aric(a)codeweavers.com> wrote:
The big question is will the underling linux parts give you access directly to the HID Report Descriptor and the HID Reports. If they do, such as the mac parts, then things are super easy. If they do NOT, then it gets much more complicated.
I looked into this earlier. Devices like /dev/input/js0 and /dev/js0 are an abstraction and do not provide direct access to HID report descriptor or reports (which may not even exist, depending on the type of joystick).
Devices like /dev/hidraw0 or /dev/hiddev0 do provide this access, however on a default Ubuntu setup non-root users do not have permission to access these devices.
That being the case, I have built in some shortcuts to make the process a bit easier. Of course all the hidclass.sys stuff is not committed yet so it is a bit odd to be talking about it like it is. But once it is in place.. For a normal windows minidriver you would have to build your own USB HID Report Descriptor and use it. That means hand building the Descriptor and then having hidclass parse that structure to generate the preparse data. I have added two new ioctls that are WINE specific to end run around that process. That would allow a wine specific minidriver to be able to built its own preparse data directly and pass it into hidclass. Makes things a bit easier. You would still end up building the reports by hand. But if you have a preparse data, then we can implement all the HidP_ parts around setting values into reports and you can use them to create the report and send them up. -aric
On 07/08/2015 04:20 PM, Vincent Povirk wrote:
I looked into this earlier. Devices like /dev/input/js0 and /dev/js0 are an abstraction and do not provide direct access to HID report descriptor or reports (which may not even exist, depending on the type of joystick).
I couldn't find anything about raw HID report [descriptors] in evdev either. The point you make about the reports/descriptors not existing has me confused: Which parts of the puzzle are USB HID specific, and which parts are not? It looks like HIDClass speaks in terms of USB HID, but is not necessarily USB HID specific? In the same way, one could work with any input device as though it spoke USB HID, as Aric describes in his follow-up (quoted below). Is this correct? On 07/09/2015 07:04 AM, Aric Stewart wrote:
For a normal windows minidriver you would have to build your own USB HID Report Descriptor and use it. That means hand building the Descriptor and then having hidclass parse that structure to generate the preparse data.
I have added two new ioctls that are WINE specific to end run around that process. That would allow a wine specific minidriver to be able to built its own preparse data directly and pass it into hidclass. Makes things a bit easier.
You would still end up building the reports by hand. But if you have a preparse data, then we can implement all the HidP_ parts around setting values into reports and you can use them to create the report and send them up.
Thinking about enumeration has me confused as well. I was thinking RawInput was operating "below" (or sibling to) hid.dll, meaning GetRawInputDeviceList and such needed to enumerate devices on buses (USB or otherwise) on its own. Is it in fact some other way, and RawInput uses (or could use) hid.dll to enumerate HID devices from its registered minidrivers? On 07/08/2015 04:20 PM, Vincent Povirk wrote:
Devices like /dev/hidraw0 or /dev/hiddev0 do provide this access, however on a default Ubuntu setup non-root users do not have permission to access these devices.
So we're throwing these (hiddev/hidraw) out then and instead going to prefer custom minidrivers per available input source/system? I'm wondering how many of these input sources we'd support (evdev, joydev (old and new), hiddev/hidraw, usbfs, ...), which I think would depend on how wide each source's support for real hardware is. I'm guessing some of these sources work-around buggy hardware already (e.g. reporting axes as relative when they should be absolute, etc.), and that may conflict with any work-arounds in HIDClass client code? I guess the question is... are we planning to emulate these input APIs with a fixed (or somehow dynamic) feature-set (via translation from host-attached devices), or expose them un-touched so the clients interact with "real" devices just like they would on Windows? Apologies for the verbosity of my post... I have a lot of questions. -- Nate
I looked into this earlier. Devices like /dev/input/js0 and /dev/js0 are an abstraction and do not provide direct access to HID report descriptor or reports (which may not even exist, depending on the type of joystick).
I couldn't find anything about raw HID report [descriptors] in evdev either.
The point you make about the reports/descriptors not existing has me confused: Which parts of the puzzle are USB HID specific, and which parts are not? It looks like HIDClass speaks in terms of USB HID, but is not necessarily USB HID specific? In the same way, one could work with any input device as though it spoke USB HID, as Aric describes in his follow-up (quoted below). Is this correct?
Xbox controllers, for example, are USB devices but communicate using a nonstandard protocol rather than USB HID. The Linux driver creates an evdev device for them, and this process does not involve HID at all. However, we can make up our own HID reports/descriptors based on the evdev device. I haven't tested, but I don't think xbox controllers go through HIDClass on Windows. My understanding is that not all controllers necessarily do. I think Aric has decided (and I agree) that we should use HIDClass for all controllers because it simplifies things.
Thinking about enumeration has me confused as well. I was thinking RawInput was operating "below" (or sibling to) hid.dll, meaning GetRawInputDeviceList and such needed to enumerate devices on buses (USB or otherwise) on its own. Is it in fact some other way, and RawInput uses (or could use) hid.dll to enumerate HID devices from its registered minidrivers?
At least based on the work Aric's been doing, all hid.dll does is communicate with hidclass.sys through ioctls and work with the type of data hidclass.sys uses. Maybe user32.dll on Windows communicates with hidclass.sys independently, but we don't care about this, and in order to be a truly independent implementation, we'd prefer not to know. We only care about what we need to provide to applications for compatibility with the Windows API. If we can implement RawInput API's for controllers in user32 by going through hid.dll, we should probably do that because it's a cleaner design.
Devices like /dev/hidraw0 or /dev/hiddev0 do provide this access, however on a default Ubuntu setup non-root users do not have permission to access these devices.
So we're throwing these (hiddev/hidraw) out then and instead going to prefer custom minidrivers per available input source/system? I'm wondering how many of these input sources we'd support (evdev, joydev (old and new), hiddev/hidraw, usbfs, ...), which I think would depend on how wide each source's support for real hardware is. I'm guessing some of these sources work-around buggy hardware already (e.g. reporting axes as relative when they should be absolute, etc.), and that may conflict with any work-arounds in HIDClass client code?
I suspect that we will eventually want to support hiddev at least, for specialized devices like the Oculus Rift. I don't think hiddev or hidraw will ever be useful for game controllers, though. I don't know if there's a reason to support joydev if we have evdev.
I guess the question is... are we planning to emulate these input APIs with a fixed (or somehow dynamic) feature-set (via translation from host-attached devices), or expose them un-touched so the clients interact with "real" devices just like they would on Windows?
That's still an open question, I think. On Linux, the default permissions for joystick devices force us to use evdev/joydev which prevents us from letting Windows programs see the real devices. However, HID devices that are not joysticks, mice, or keyboards will probably require direct access from Windows programs to function correctly. I'm also unsure how XInput layout remapping, if we have it, will work. That is, Xbox controllers on Windows provide a very specific button and axis configuration, which is different from what we're likely to get from controllers that we'd want to access through XInput (including, from what I've heard, what the Linux drivers give us for Xbox controllers), and we'll have to remap them. Some programs use DInput but expect the XInput layout, so we should remap things for DInput as well. I think that remapping should happen inside hidclass.sys, but I'm not sure if it can be done cleanly.
On 7/9/15 2:04 PM, Nathan Schulte wrote:
On 07/08/2015 04:20 PM, Vincent Povirk wrote:
I looked into this earlier. Devices like /dev/input/js0 and /dev/js0 are an abstraction and do not provide direct access to HID report descriptor or reports (which may not even exist, depending on the type of joystick).
I couldn't find anything about raw HID report [descriptors] in evdev either.
The point you make about the reports/descriptors not existing has me confused: Which parts of the puzzle are USB HID specific, and which parts are not? It looks like HIDClass speaks in terms of USB HID, but is not necessarily USB HID specific? In the same way, one could work with any input device as though it spoke USB HID, as Aric describes in his follow-up (quoted below). Is this correct?
So, on windows. HID is not USB specific. Any device can be a HID device. However much of the language HIDClass and HID speak are the USB standard. If you are writing a hid minidriver that is NOT a USB device on windows, then you will still need to build a USB HID Report Descriptor to report up to HIDClass, and when you generate reports those reports are in USB report standards.
On 07/09/2015 07:04 AM, Aric Stewart wrote:
For a normal windows minidriver you would have to build your own USB HID Report Descriptor and use it. That means hand building the Descriptor and then having hidclass parse that structure to generate the preparse data.
I have added two new ioctls that are WINE specific to end run around that process. That would allow a wine specific minidriver to be able to built its own preparse data directly and pass it into hidclass. Makes things a bit easier.
You would still end up building the reports by hand. But if you have a preparse data, then we can implement all the HidP_ parts around setting values into reports and you can use them to create the report and send them up.
Thinking about enumeration has me confused as well. I was thinking RawInput was operating "below" (or sibling to) hid.dll, meaning GetRawInputDeviceList and such needed to enumerate devices on buses (USB or otherwise) on its own. Is it in fact some other way, and RawInput uses (or could use) hid.dll to enumerate HID devices from its registered minidrivers?
I am pretty positive RawInput has to be a client of Hid.dll. Have not investigated but the connection between the two are too close to not be interrelated. As for enumeration. hid.dll gives you no method to enumerate. That is all done through setupapi. Here is a very rough overview: https://msdn.microsoft.com/en-us/library/windows/hardware/ff538731%28v=vs.85... I have specific code that does this that I can share later also. -aric
participants (3)
-
Aric Stewart -
Nathan Schulte -
Vincent Povirk