You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since in DS4Windows Mode the controller is supposed to be remapped into a virtual controller by DS4Windows, to prevent the famous double-input issue the controller's HID descriptor was changed so Windows stopped recognizing it as a gamepad.
Some users are reporting that in the latest stable driver Windows still recognizes the controller in DS4Windows Mode as an actual gamepad.
Details
From the image below, Windows is ignoring the X, Y, Z, RZ axes and the T-Hat, though RX and RY as well as the other buttons are recognized as normal :
Looking at the HID descriptor, it seems as windows is ignoring everything before the usage page is refreshed:
Test
I wanted to confirm if the issue was being caused by windows recognizing the axes/buttons after the usage page was "refreshed" in the HID descriptor, so I replaced all gamepad related sections of the HID descriptor (all axes, buttons, t-hat) with vendor-defined padding:
And the result was that Windows still recognizes the controller as a gamepad, but now without any buttons/axes:
Final thoughts on the issue
I can only think that Windows got stuck identifying the controller as a gamepad, regardless to what the initial usage and usage page is defined on the HID Descriptor. I don't know how to further troubleshoot this, since I can't replicate this on my system.
The text was updated successfully, but these errors were encountered:
Kanuan
changed the title
Windows (sometimes) recognizing the controller in DS4Windows mode as an gamepad
Windows (sometimes) recognizing the controller in DS4Windows mode as a gamepad
May 19, 2021
Since DS4Windows has its own byte-based parser anyway I think the whole Report Descriptor could be further simplified by not exposing any "well-known" usages all together, just make sure the report sizes still match, nothing else so the hidclass parser has nothing to expose to the system.
@Kanuan could you test my change please? I basically ripped out all known usages and just fixed the overall padding of the input report, at least on my end DS4Windows (3.0.11) seems to be happy with the change and still functions while the original devices remains fully hidden:
Summary
Since in DS4Windows Mode the controller is supposed to be remapped into a virtual controller by DS4Windows, to prevent the famous double-input issue the controller's HID descriptor was changed so Windows stopped recognizing it as a gamepad.
Some users are reporting that in the latest stable driver Windows still recognizes the controller in DS4Windows Mode as an actual gamepad.
Details
From the image below, Windows is ignoring the X, Y, Z, RZ axes and the T-Hat, though RX and RY as well as the other buttons are recognized as normal :
Looking at the HID descriptor, it seems as windows is ignoring everything before the usage page is refreshed:
Test
I wanted to confirm if the issue was being caused by windows recognizing the axes/buttons after the usage page was "refreshed" in the HID descriptor, so I replaced all gamepad related sections of the HID descriptor (all axes, buttons, t-hat) with vendor-defined padding:
And the result was that Windows still recognizes the controller as a gamepad, but now without any buttons/axes:
Final thoughts on the issue
I can only think that Windows got stuck identifying the controller as a gamepad, regardless to what the initial usage and usage page is defined on the HID Descriptor. I don't know how to further troubleshoot this, since I can't replicate this on my system.
The text was updated successfully, but these errors were encountered: