Hello everyone,
So with this the last few commits I can officially say that WINE now has a fully functioning HID stack for Linux hidraw devices. Thanks to Sebastian Lackner and Alexandre for all the help, reviews and attention paid. It is working and in the state it is now because of their assistance.
This means that applications that use hid.dll or direct device access to HID devices will start seeing and being able to interact with devices. This is very exciting but is just the very first step. Of course any application trying to do HID directly would be a wonderful test case, I am sure there are many many things that will need to be refined and added before a real application starts being happy.
I do have a very rough, quick, poorly coded test case for HID controllers available to the curious.
https://www.codeweavers.com/xfer/aric/HID/hid.exe
There are still manual steps required before things will start working.
1) By default no hidraw devices on Linux are given any access to users. So you will need to had rw permission to the /dev/hidraw<X> device that you want to have accessible in Wine. Or if you want to be wild and crazy you can add a new udev rule to add permission to all the devices as they are added. 2) The winebus service is not started by default yet. so you will need to start winebus. (wine net start winebus) This makes things a little complicated. I would recommend testing with a process like this: wine cmd net start winebus <test application> Or you an change the service start for winebus in the registry [System\CurrentControlSet\Services\WineBus] "Start"=dword:00000002
I would love comment, reports, anything as people test various devices and programs.
As for more platforms, patches for OS/X have just been submitted so that IOHID devices will work on Mac. Then I have a set of patches adding linux event devices as well.
Looking forward, the hope is that then we will be able to build RawInput support on top of HID, and also dinput and xinput support as well. As a fun challenge I have been working to get native dinput from DirectX 9 to work on Wine on top of HID and it is moving forward much better than I expect, with a lot of hacks at present. (native Dinput sees the gamepads and even start trying to read them, but current is not getting reports properly)
So tell me how things work! thanks, -aric
Hi,
On 11/03/2016 04:15 PM, Aric Stewart wrote:
Looking forward, the hope is that then we will be able to build RawInput support on top of HID, and also dinput and xinput support as well. As a fun challenge I have been working to get native dinput from DirectX 9 to work on Wine on top of HID and it is moving forward much better than I expect, with a lot of hacks at present. (native Dinput sees the gamepads and even start trying to read them, but current is not getting reports properly)
I'm glad to see so much progress on the HID functionality. As for Dinput and Xinput, last time I was active in the mailing list there was a discussion about how to correctly identify Xinput devices in programs that can enumerate both Xinput and Dinput controllers.
Have you thought about how to allow software to differentiate between Dinput-only and Xinput+Dinput devices? Roderick Colenbrander wrote that many old games that support Xinput+Dinput use WMI to identify Xinput devices. Apparently it's what the article on MSDN I found last time proposes too, I just didn't see the bit about it being WMI before: https://msdn.microsoft.com/en-us/library/windows/desktop/ee417014(v=vs.85).a...
I feel like there needs to be a layer between HID and Dinput/Xinput that checks whether a certain HID device is an XInput controller and fills in the correct info before passing it to DInput and XInput. Since we're just mapping HID devices, that "check" must know all possible mappings for XInput devices, so basically it must contain most of the functionality that several of us have implemented directly in xinput.dll in one way or another.
So tell me how things work! thanks, -aric
Best regards, Juan
Hi Juan!
Great to hear from you!
On 11/10/16 3:20 PM, Juan Jose Gonzalez wrote:
Hi,
On 11/03/2016 04:15 PM, Aric Stewart wrote:
Looking forward, the hope is that then we will be able to build RawInput support on top of HID, and also dinput and xinput support as well. As a fun challenge I have been working to get native dinput from DirectX 9 to work on Wine on top of HID and it is moving forward much better than I expect, with a lot of hacks at present. (native Dinput sees the gamepads and even start trying to read them, but current is not getting reports properly)
I'm glad to see so much progress on the HID functionality. As for Dinput and Xinput, last time I was active in the mailing list there was a discussion about how to correctly identify Xinput devices in programs that can enumerate both Xinput and Dinput controllers.
Have you thought about how to allow software to differentiate between Dinput-only and Xinput+Dinput devices? Roderick Colenbrander wrote that many old games that support Xinput+Dinput use WMI to identify Xinput devices. Apparently it's what the article on MSDN I found last time proposes too, I just didn't see the bit about it being WMI before: https://msdn.microsoft.com/en-us/library/windows/desktop/ee417014(v=vs.85).a...
So the key thing is if the device has an IG_ string in the device Identifier. I intend to investigate more closely where that is done. I feel like it is likely on the bus level there is some logic that determines if the device is and XInput device and if so uses IG_<#> to list the device, Normal devices use IM_<#> in that place in the identity.
Right now, with my HID stuff, all gamepads/joysticks are identified with IG_ I know that is wrong long term but can be corrected as we need to properly identify XInput compatible devices.
I feel like there needs to be a layer between HID and Dinput/Xinput that checks whether a certain HID device is an XInput controller and fills in the correct info before passing it to DInput and XInput. Since we're just mapping HID devices, that "check" must know all possible mappings for XInput devices, so basically it must contain most of the functionality that several of us have implemented directly in xinput.dll in one way or another.
I don't know if that needs to be between HID and XInput. I think it can be part of the device bus logic. I am going to investigate with this Logitech F310 gamepad that identifies as an XInput device when the little switch is switched over. That will give me an idea of where and at what level the IG_ identifier is added.
-aric
So tell me how things work! thanks, -aric
Best regards, Juan
-
Aric Stewart -
Juan Jose Gonzalez