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
{{ message }}
This repository was archived by the owner on Mar 5, 2026. It is now read-only.
Currently it's too much work to test if third-party controllers are supported by DS4Windows.
Basically we always have to compile new versions, which have the following cons:
only people who know their way around compiling DS4Windows can do so
make it so users who have new, unsupported controllers dependent on devs helping them test
lock new controllers out of support if DS4Windows goes unmaintained again
My idea would be the following:
On start-up make DS4Windows read from disk a .json file with a list of custom supported controllers, making it easy for anyone to test new controllers by just filling the name/vid/pid/flags themselves
Keep the hard-coded supported devices list in DS4Windows
Have a property called "EnableDetection" for each device on the list of custom supported devices. If it's false then support is disabled even if it's on the list
The intention of this is to have a way to disable support for a given hard-coded device by adding it to the list of custom devices but with the "EnableDetection" property set to false
Add a GUI for easy adding/removing support for devices so they don't need to mess with manually editing the .Json file
I'm interested in implementing this, but I'd like to hear your thoughts on if the way I envision seems ok
Currently it's too much work to test if third-party controllers are supported by DS4Windows.
Basically we always have to compile new versions, which have the following cons:
My idea would be the following:
I'm interested in implementing this, but I'd like to hear your thoughts on if the way I envision seems ok