Welcome to the DS4Windows documentation! Please select the section you want to see.
Please note that most of the guides and images are taken from the original website.
This is the multi-page printable view of this section. Click here to print.
Welcome to the DS4Windows documentation! Please select the section you want to see.
Please note that most of the guides and images are taken from the original website.
DS4Windows.exe
After installation you will have install some drivers, some of which are optional:
Driver | Required? | Description |
---|---|---|
ViGEmBUS | Yes | Allows DS4Windows to create virtual controllers. |
HidHide | No, but recommended | “Hides” your real controller in order to prevent games from simultaneously recognising both your real and virtual controller, which can lead to the infamous double controller issue.. |
FakerInput | No | Useful for users who want to use their controllers as keyboard and mouse. Though DS4Windows can do so by itself, FakerInput has better performance and can work in more games and situations where Windows might prevent the usage of DS4Windows KBM handler. |
Connect your controller. If everything went well, it should appear in the main window, in the Controllers
tab.
To pair the controller, you first have to set it in pairing mode.
Hold PS and Share buttons at the same time until the lightbar starts flashing in a heartbeat pattern.
Hold down the Sync button until the controller LEDs enter a back n’ forth pattern.
Probably the same as for the original controllers. Refer to specific device’s manual.
The official adapter from Sony supports only 1 controller, but allows the headphone jack to be used wireless for both audio and mic.
To pair a DualShock 4 to it, both must be set to pairing mode. For the Wireless Adapter, its main body must be slightly pressed towards the USB port (until a “click” is felt) then hold it down in this position for 3 seconds, with its LED flashing in a heartbeat pattern indicating that it’s in pairing mode. Set then DualShock 4 into pairing mode (check the previous section) and it it should connect to the adapter.
To prevent or fix the issue of double input it’s necessary to hide the real controller in order to make only DS4Windows’ virtual controller visible to games. This can be done in two ways:
HidHide is a driver that acts as a barrier between Windows and game controllers connected to the system. It allows the user to selectively hide gamepads and only allow specific software to still detect them.
It is the recommended method because once it has been properly setup the double input issue is solved for good for the hidden controller.
In DS4Windows case, the user needs to set HidHide to:
Configuration:
Alternativaly, you can follow the official HidHide guide.
If you have HidHide installed and correctly setup then this option is redudant and should be left disabled to prevent issues or confusion.
This option exists on DS4Windows’ Settings tab. When enabled, DS4Windows will kindly ask Windows for exclusive access to detected devices, meaning the later would only allow DS4Windows to detect the gamepads and preventing the double input issue.
The problem with this method is that Windows can deny the exclusive access request when another process already has a open connection to the gamepad. Common reasons for this request to fail are:
Even if it works initially, if your gamepad disconnects in the middle of a game chances are that you’ll lose exclusive access upon reconnection, requiring you to close the game to try again.
For the reasons explained above, the Hide DS4 Controllers option is NOT RECOMMENDED, though it remains available to users that need to use it for whatever reason. HidHide is the better option all around for those who can use it.
There are some aplications and games that behave differently when they detect DS4Windows is running on the users system. The known ones are:
This guide will make DS4Windows run under a new process name instead of the standard DS4Windows.exe in order to make it run undetectable.
The name DS4Win will be used as an example for this guide, but any other name can be used:
Step 1
Step 2
Fully close DS4Windows, make sure it’s not running on the background or in the system tray.
Step 3 In DS4Windows’ folder, locate the new TheNameYouChose.exe (DS4Win.exe) file and run it
Step 4 Check if the program is running under the new name in the task manager.
DS4Windows.exe
fileRun at Startup
option is enabled then disable it for nowCustom Exe name
boxCurrently supported controllers:
If a gamepad is made to be a complete replica of a official one, meaning that they act exactly as the original controller and appear to Windows as such, then chances are DS4Windows will just detect it as being the official controller and it may just work. For example, 8bitdo controllers that are compatible with Nitendo’s Switch usually present themselves as a replica of the Pro Controller and can be used as normal with DS4Windows.
For cases where the gamepad presents itself differently than the official one to the system (most DS4 replicas) then DS4Windows will not recognize them. DS4W detects controller by their Vendor and Product Identification (VID/PID), meaning that if a controller’s VID/PID is not already on DS4W code then it will just be ignored.
Adding support to new copy-cats may be as easy as just adding their VID/PID to the code or as hard as making major changes to the internal structures of DS4Windows. If you have a unsupported copy-cat feel free to reach us and kindly ask for it to be added to DS4Windows code while providing the maximum amount of information on it.
Moonlight virtual controller is supported from version 3.7.0 up.
You can enable it in Settings -> Device Options -> Moonlight Support
.
Not selecting Advanced Support
means you’re using the simple implementation of the support,
which should be sufficient for most users.
When a new controller is detected, its checked for being virtual. Normally, if it’s detected that it’s a virtual device, it simply wouldn’t be added to the controllers list. However, this behaviour makes the detection of the Moonlight virtual controller impossible. To counteract this, this support mode makes all devices with a matching Vendor and Product ID skip the check.
If you can connect both physical and virtual controllers and all the behaviour is as usual.
This option is meant to counteract what is described in this issue. This behaviour doesn’t appear to be consistent across all machines. Most users should never have to use this option. It does its work to counteract that issue, but it’s got its tradeoffs.
Namely, you cannot connect 2 devices one right after another, you have to wait for 5 seconds after connecting one. Additionally, sometimes you will have to disconnect a device that’s already connected for the program to detect more controllers.
To counteract the issue, a timeout on device detection is used. For 5 seconds after connecting a controller, any further detections are skipped.
If when using simple support you connect a single controller and the program starts adding multiple devices to the list.
Without all required software, the app will not start.
DS4Windows’ Log can give important warnings when issues occur. It may be found in 2 different places and, if it exists on both, the most recent one should be inspected:
DS4Windows may be inside a folder that is write-protected, therefore requiring it to be executed with higher privileges to be able to save and edit data. Such folders can be the “Windows” folder, “Program Files” and sometimes even the user Desktop (unlikely, but possible).
It’s recommended to have DS4Windows inside a folder that is known to not require higher-privileges to prevent this issue, like the user’s “Documents” or “Downloads” folder.
The easy way to check this is making sure DS4Windows is not running and then backing up and erasing all of its User Data. If erasing the User Data fix the issue but the user wishes to keep some of its old data, it’s possible to restore each User Data related file and folder individually until the corrupted file is found, then removing it only.
Either ViGEmBus is not installed or DS4Windows is failing to detect it. The ViGEmBus’s guides on how to install, verify if its working correctly, uninstall or perform a full clean of everything vigem related can be found on ViGEmBus’ How to Install/Remove page.
If these messages appear on DS4Windows’ Log or in Windows’ Event View then try to do the “repair Windows installation” fix using a Microsoft Windows installation media. There has been reports that this fixed a problem of DS4Windows app silently doing nothing when launched -issue. Or run WinOS “WMI repository repair” commands. Repair WinOS WMI repository.
Some users have reported that certain versions of MSI Afterburner and MSI RTSS RivaTuner apps are not compatible with WPF version of DS4Windows (every version since v2.0).
RTSS prevents DS4Windows app to startup. Try adding DS4Windows.exe file to RTSS application list and set app option as “Application Detection Level=NONE” in RTSS (search issue tickets with these keywords for more information on DS4Windows’ Issue Tracker).
The Scp Virtual Bus Driver (ScpVBus) is a legacy driver that was used to spawn virtual Xbox controllers. It has been succeeded by the ViGEmBus.
Though DS4Windows should just ignore the ScpVBus, there is a small chance that having it installed along-side the ViGEmBus can lead to issues.
When everything else fails, update Windows.
If you just search “DS4Windows” on google, chances are that the first result is the obsolete version from jays2kings, which has not been updated since 2016 and should not be used anymore.
The currently maintained version you should be using is schmaldeo’s DS4Windows. If in trouble, check out the installation guide.
DS4 needs to actually be running for things to work. If it is stopped then you can press the Start button on the bottom-right to make things roll again.
You have connected your controller to the PC but it does not appear on Windows’ Devices and Printers? No, that should not be possible under normal circumstances. Your controller MUST appear there in some shape or form, even if it does not looks like a controller.
When connected via USB a new entry should appear, so keep an eye for it. Test on other USB ports to be sure. If literally nothing happens then maybe:
When a controller has been paired to Windows via Bluetooth then its entry will exist there regardless if the controller is currently connected or not. Also…
Add a device
notification will keep on appearingThere is a correct and a incorrect method of pairing a controller to the PC via Bluetooth. Both will result in the controller appearing to be connected, but on the incorrect method the controller won’t remain connected for more than a few seconds and Windows will sometimes show a Add a device notification.
Sometimes this happen when a user had previously connected the controller to the PC, removed the device and is trying to simply turn on the controller in the hopes that it will reconnect. If in doubt, fully remove the controller from Windows’ Device list and re-pair it via the proper way.
User manually makes Windows look out for a device that is in pairing mode
User simply turns on the controller and tries to accept the Add a device
notification
There is a chance that DS4W has permanently disabled your controller in a previous attempt of gaining Exclusive Access when using the Hide DS4 controllers option.
Though this can happen via any connection method, on Bluetooth removing and re-pairing the controller will fix the issue.
On USB, the easiest way to verify this is by checking if the controller works properly in other USB ports, though another indication for DS4 or DualSense users is that the lightbar will keep flashing yellow, indicating that the controller is only at a charging state (likewise, it will flash yellow only once then turn off if fully charged).
To check if your controller is disabled:
If it was disabled then re-enabling should fix the issue.
If you found out that:
Then it may be hidden. The following tools could be the culprit:
HidGuardian is a driver that can prevent Windows from recognizing a connected controller as an actual game controller. It was used by DS4Windows to prevent the double-input issue, but support for it was removed in v3.0.8 for 2 reasons:
As such, the latest versions of DS4Windows won’t request HidGuardian for hidden controller’s access and if a controller is hidden by it then it won’t be detected anymore.
Users who still have HidGuardian installed must:
You can check if you have HidHide installed by opening Windows’ Apps and Features and searching for it, though if it do is installed then it’s probably just not properly configured to grant DS4Windows access to hidden controllers.
For these type of controllers to be detected by DS4Windows, they need to either:
The Gamepad Tester should work in most modern browsers and will show detected controllers along with some additional info such as their vendor and hardware identification (VID/PID).
Connected controllers should appear on Windows Game controllers list, also called joy.cpl. To open it:
Windows’ Devices and Printers should offer a simple view of connected devices. You can use it to confirm a device has been detected by:
To open the Devices and Printers menu:
This menu will show connected/paired Bluetooth controllers and other devices, though it does not go much beyond that. Paired controllers can be removed here.
To reach it, open Windows’ Settings on the Start Menu and select it there.
The Device Manager is the one source of truth to everything that makes part of your PC. If it has been detected then it will appear there, but because it is very techinical on how it presents devices to the users it may be a little hard for the average user to find their way around it.
Regardless, to open it, press Win+X in your keyboard (or right click the Start Menu) then select Device Manager in the appearing menu.
There are 2 ways a controller can be paired to Windows:
If the controller has been connected in the wrong method it will 100% not work even though it appears on Windows as if it has been properly added. If in doubt, make Windows remove the controller from its Device list and re-pair it again using the correct method. Check the following section on how to propperly connect a controller to the PC.
For more information, click here
Open Windows’ Bluetooth Devices list on its Settings
Locate your controller on the list, click on it then select Remove device
Sometimes this can be used when Windows’ fail to remove a device through the usual Devices Settings menu
Remove device
The integrated BT adapter must be disabled in Windows’ Device Manager:
Both PCs’ Bluetooth adapters probably have the exact same MAC Address, so the controller can’t differentiate between them and tries to connect to the first one that responds.
A connection latency is how much time it takes for one system to communicate to another. In DS4Windows case, we refer to the time it takes for the system/DS4Windows to communicate with the controller. A high latency means a high input delay in games, meaning the time it takes for your character to respond to the controller commands.
A high but stable input delay will make the users’ character feel slow to respond, while a low input delay with high delay spikes may make the user prone to errors because of unexpected slow respond times.
It’s often considered that a really bad high latency is one where the input delay is above 20ms, though the ideal is to keep it bellow 10ms.
The following table can be used as reference for comparison on what input delay to expect with a supported controller and a good Bluetooth adapter:
Controller | Usual input delay | Minimum input delay | Notes |
---|---|---|---|
DualShock 3 | 5ms | 5ms | Connected through BthPS3 + DsHidMini (DS4Windows Mode) |
DualShock 4 | 4ms = DS4W default settings | 1,5ms - polling rate set to maximum | v1 and v2 don’t have major latency differences |
DualSense | 3ms | 1ms | |
Switch Pro Controller | 16ms | 16ms | 16ms is the lowest latency the official controller can achieve |
Joy-Cons | 16ms | 16ms |
For the DualShock 3 you need to have DsHidMini’s Lightbar to LED translation enabled, then latency spikes will cause all 4 LEDs to quickly flash.
In case you are having issues with input delay, keep something in mind: DS4Windows itself is probably not the cause of whatever high input latency/latency spikes that you may have! 98% chance of the issue being elsewhere.
Controllers do not communicate directly with DS4Windows via some driver, they connect to the default Windows’ Bluetooth Stack and DS4Windows just receives and sends data to it through the channels given by Windows.
If you are having latency issues then installing/uninstalling drivers won’t fix them unless they are directly related to your dongle’s driver. For this reason, messing with DS4Windows’ related drivers will probably be a waste of time.
Latency issues always boils down to:
Keep in mind that when the term “bad” is used it does not necessarily mean “cheap”. Multiple users have confirmed they have no latency issues even with 4 controllers connected with cheap, generic $5 adapters from Aliexpress.
Both use the same frequency. Although they should auto adjust to prevent interference, sometimes it just happens. Check if your area isn’t overloaded with different 2.4Ghz WiFi networks and Bluetooth devices. Also, if one of the signals is too weak then it’s quite easy for the other to heavily interfere.
It’s quite common for integrated BT adapters to suck for one of the following reasons:
Though the minimum BT specification required for most modern controllers is the 2.1 specs, more modern adapters should have better signal stability.
Each connected controller means more data that is being transferred through the Bluetooth adapter. If you have a bad adapter or high radio interference near it it may not be able to maintain the required data rate between the system and controllers, causing high latency or even connection loss. Not much can be done besides trying to lower the interference or replacing the adater with a better one.
A good quality adapter can easily maintain a stable, low latency connection with 4 controllers or even more.
THIS ONLY APPLIES TO DUALSHOCK 4 AND DUALSENSE DS4 and DualSense controllers can communicate in 2 different modes:
When first connected to Windows, these controllers communicate in PC friendly mode and their data transfer rate is low. When picked by DS4Windows (or Steam for that matter), a request is sent for them to change into Native PS mode, which increases the volume and the frequency of data being sent.
Not only that, DS4Windows also sends data back to the controller related to the rumble, lightbar, triggers (DualSense only) etc.
When these changes occur, if the Bluetooth adapter can’t keep up with the required data rate then the user may suffer with high input delay or even connection loss. So if your never had latency problems when using your DS4/DualSense in games as a generic controller but then start having issues when trying to use DS4Windows or Steam this may be the cause.
This test is recommended for those with integrated cards that work as both BT and WiFi adapters
By disabling the WiFi signal you have one less source of radio interference so you can then verify your BT adapter performance in a environment with less signal noise. Keep wifi enabled devices far from the PC too.
A dedicated, good quality BT USB Adapter should offer better performance than an integrated one. Because its antenna is located outside of the laptop/desktop’s shell, it also suffers less from signal loss caused by physical obstacles.
When using a USB adapter in a PC that also has a integrated one the latter must be disabled in Windows’ Device Manager in order for the USB BT adapter one to be used, since Windows can only keep one dongle active.
Moving the dongle to a better located USB port may offer a better quality signal. Also, USB ports (specially 3.0 and above) can be a source of radio noise. Test the dongle in different ports to verify which offer you a better signal.
A laptop/desktop’s shell is a source of radio noise, specially if it’s ungrounded or near high powered, high data transfer ports like USB 3.0 and above. This noise may worsen your BT’s adapter performance.
Connecting your BT adapter through an active cable extension, so it stays located at some distance from the computers shell (not necessarily nearer to the controller), is known to be useful in these cases.
Only works with DS4 and DualSense gamepads. The BT polling rates of other types cannot be controlled
In Profile Editor -> Other
tab it’s possible to set the BT Poll Rate used for DS4 and DualSense controllers on Bluetooth. If you are having latency issues, specially with multiple controllers connected, try setting this value to 10ms or more. For most games, a controller input delay is only noticeable above 16ms.
Your adapter may not be up to the task to both receive and send data to the controller. In this case, you can set a profile with the Enable output data to DS4
option disabled. Keep in mind that disabling this option will also disable Rumble and Lightbar control.
DS4Windows cannot magically change your real controller to one for another type, so what it actually does is create a virtual Xbox or DS4 controller that is then associated to your real one. If the virtual controller creation fails then one of DS4Windows main features is not working.
ViGEm spawned the device but it’s in a error state. Verify on Device Manager - Check ViGEm log - Virtual controller has been hidden by HidHide/HidGuardian? - HidHide HidGuardian issue that can happen when the user has both installed at the same time.
It’s possible that the user has disabled virtual controller creating/association in the currently active profile. To verify:
Controllers
tabProfile editor -> Other
tab if the Disable virtual controller
checkbox is ticked. Untick it if applicableIf there is an X on the “Ex” column then it’s possible for the double input issue to occur
It’s possible for the double input issue to actually make your controller NOT be detected by games, as such it should be the user’s number one priority to prevent it before anything else.
This happens because the game may detect the wrong controller (your physical one) first and then keep waiting for its commands while ignoring DS4Windows’ virtual one. Depending on how the game “reads” the physical controller inputs it may get stuck in a “nothing happens” situation.
Check the page about what causes the double controller (double input) issue and how to prevent it.
This may be related to a somewhat known Windows issue where it has, hidden from view, associated the connected Xbox controller to a incorrect / not-expected “XInput Slot”.
Most games support only Xbox controllers because of how easy it is to add complete support to them. Even games that were released for Playstation consoles sometimes don’t have native DS4 support on the PC, and there is nothing that can be done besides switching to Xbox controller emulation.
A good (but not 100% reliable) way to confirm if a game has native DS4 support is by locating it on the PC Gaming Wiki and looking for the “Input settings” section. Look carefully, sometimes it is quite hidden, so make sure to expand menus when applicable. Still, most games that have support for DS4 controllers don’t actually have rumble support, so be warned.
Some games also can be modded to include PS button icons while using Xbox controllers, though it’s not possible to cover this here and so you’ll have to google it yourself.
Though it’s quite uncommon, some games absolutely require using your DS4 through Steam Input by enabling the Playstation Configuration Support option and launching the game through Steam to have working DS4 support or to support rumble/lightbar features.
Keep in mind that for using your virtual DS4 controller through Steam Input you’ll have to run DS4Windows under a custom name for Steam to not ignore it (thanks for not giving us the option on this and making our lives harder, Steam).
No known cases. Most users who claimed some game had this behavior were actually having other unrelated issue. Example: Shovel Knight ignores DS4 controllers if it detects DS4Windows is running, but it shouldn’t matter if the user is using a Xbox controller or if running disguised to not be detected.
Not saying it’s not possible, just that it’s not known.
It’s essentially the major reason for users having problems playing games with DS4Windows. To not keep repeating information all over the site, check the double input page for more information on that.
Make sure your real controller is 100% hidden before playing games, otherwise you might start having double input/controller issues and mistake them for something else.
If there is an X on the “Ex” column then it’s possible for the double input issue to occur
It’s possible that the currently active profile is misconfigured, either by incorrectly tweaking settings or by having it broken after a DS4Windows update (really rare to happen, but possible).
To not go into a wild goose-chase, the very first thing that should be done is creating a new, sure-to-be-working profile:
This should result in a good profile for troubleshooting most issues.
This is usually caused by the “stick drifting” issue, which happens when the controller stick position is not perfectly centered when at rest and can be possibly caused by 2 different hardware issues:
To counteract this, you can use the Stick calibration
tool that was added in version 3.6.0.
To correctly use it:
Edit
button in that controller’s row in the main menu
Stick calibration
and set the offset manually or use the automatic tool. Please note that there’s a separate section for each stick
Alternatively, you can use deadzone, but with stick calibration you preserve the linearity of raw input.
Random inputs are 99.9% of the time caused by the controller itself being faulty, not by DS4Windows or other drivers.
If the issue is in the triggers, it’s possible to try increasing its/their dead-zone to require pressing them further before being registered.
One way to test if you are having random buttom presses is by creating a profile that has a Special action enabled that causes a profile switch to another profile when a specific button is pressed, then just leave your controller turned on and wait, or maybe try slightly touching the buttons without fully pressing them to see if its a sensibility issue.
Other than that, the only thing left to do is taking the controller to the assistance.
Unless DS4Windows is out-right crashing or appearing to be frozen (Windows says that it is not responding) then it is probably an issue with your controllers cable, its own USB port, the PC’s USB port or if connected via Bluetooth then a latency issue.
For wired users, try using other PC USB ports, replacing the cable or testing if the problem does not occur when connected over Bluetooth.
Besides that, check if there isn’t any error message in DS4Windows’ Log that could give some direction on this.
This was an issue with HidHide that was fixed on v1.1.50. Make sure to update to the latest available HidHide version.
Because of an issue with the ViGEmBus, DS4Windows has disabled support for rumble and the Lightbar passthru mode when using virtual DS4 controllers
The issue causes the controller to occasionally not stop rumbling or to set wrong lightbar colors
The last version to have these features enabled was v3.0.10. Keep in mind that these features may or may not work well with games in this version and support will not be given to users that aren’t to the latest version
Are you reeeeeally sure it actually has support for those features? One good way of knowing, though not 100% reliable, is by looking in your games’ page on the PC Gaming Wiki and checking in the controller section if it has 1) DS4 Controller support and 2) if it’s specifically stated that those functions are supported
Make sure you are using a emulated DS4 controller and that you’ve enabled the corresponding passthru options that you intend to use on the active profile
Sometimes, for a game to have support for these features (or to even detect DS4 controllers) the following conditions are required: 1) launching the game through Steam and 2) Using the DS4 controller through Steam’s Playstation Configuration Support. For more info on that, please check the Steam related info page
Rumble and lightbar passthrough are currently disabled when DS4 emulation is active
Because of an issue with the ViGEmBus, DS4Windows has disabled support for rumble and the Lightbar passthru mode when using virtual DS4 controllers
The issue causes the controller to occasionally not stop rumbling or to set wrong lightbar colors
The last version to have these features enabled was v3.0.10. Keep in mind that these features may or may not work well with games in this version and support will not be given to users that aren’t to the latest version
Check on your profile settings’ Other tab if the rumble is not at 0%
Still on the Other tab test there if both your motors are working. If they don’t work there then it’s a hardware issue with your controller or you have a third-party / copy-cat controller that doesn’t have rumble or does not work with DS4Windows
Most games only have working rumble when using Xbox controllers even if the game supports both Xbox and DualShock 4 controllers
Some games only support DS4 controllers or DS4 controller rumble when using Steam’s Playstation Configuration Support. Read the previous topic for more info on that
The KB+M handlers are the means by which DS4Windows sends keyboard and mouse actions. Currently the 2 handlers used are the SendInput and the FakerInput handler.
The SendInput handler requires no driver and it’s used by default when the FakerInput driver is not installed.
Unfortunaly, some games and Windows’ events may end-up ignoring commands coming from SendInput for a variety of reasons, with a few examples being:
The FakerInput handler does not suffer from the limitations of the SendInput handler, but it’s usage requires its driver installation. It’s also currently in beta and the user may suffer from unknown issues.
When it’s active, DS4Windows’ KB+M commands are sent via the FakerInput and received by the system as non-different than a real keyboard and mouse, meaning Windows and games will accept its commands even in situations that virtual KB+M usage are blocked.
You can check on DS4Windows’ Log tab which handler is being used.
DS4Windows always uses the FakerInput handler if its driver is installer, so to switch between handlers it’s a matter of installing or uninstalling the FakerInput driver and then restarting DS4Windows.
Restart DS4Windows after the installation
Make sure DS4Windows is not running when uninstalling the FakerInput driver
This usually happens when the KB & M are mapped to the controller’s sticks but these are suffering from stick drift, which happens when the controller’s sticks are not correctly centered when at a resting position.
To fix this, please refer to this page.
Some situations, mainly in User Account Control (UAC) warnings/prompts, will make Windows ignore DS4W’s commands if the SendInput handler is being used. This happens as a Windows’ protection against malicious software that try to abuse the SendInput function to take control of the user’s system.
The possible fixes for this are:
This usually happens if the SendInput handler is being used in a manner similar to the topic above (have a read on it), though the difference is that some games do this as an anti-cheat counter-measure.
The only real fix for this is switching to the FakerInput handler, which the game usually can’t differentiate between it and real KB & M devices being used by the user.
Some games have really strong anti-cheat protection that both:
Usually, this “main device” verification is done the moment the game is being launched by detecting which KB/M is the first to send commands. These first devices will be recognized as the “main” user devices and every other one will then be ignored.
The workaround to this is to either:
If keyboard events are sent too fast Windows may not register that they happened. It is advised that the user:
If the game detects both the real and the virtual gamepad at the same time then it will receive commands from 2 different devices at every button press and stick movement, which can lead to the infamous double-input issue that can make games unplayable.
Double Input issue may:
To prevent or fix this issue it’s necessary to hide the real controller in order to make only DS4Windows’ virtual controller visible to games.
For a guide on how to do this, click here.
Some official and third-party DualShock 4 and DualSense gamepads support audio input/output when connected to the PC via specific connection methods (mostly USB only). This page is dedicated on instructing users on how to fix some “issues” that might happen when connecting their gamepads to the PC and leave some comments
Or quick switch by right-clicking:
Because some gamepads expose their headphone and mic jack when connected (check the list above on this page) Windows may be auto-switching to them as the new computer’s default.
The “fix” is instructing Windows or the application being used (Discord, Skype, some games that support audio communication) to switch back specifically to the desired headphone/mic. Have a look at the “switching between audio devices” section on this page.
Things to check:
If everything looks OK but the headphone/mic still isn’t working then… Don’t know, sorry. Maybe the headphone jack port is broken or you are suffering from some poor contact?
No, this feature is not implemented. Is it possible to implement this? Apparently yes. WILL it be implemented? The answer is probably no unless some new developer steps in to specifically focus on this.
What most users don’t understand is that:
My fork contains a new post-build script. It’s located in /utils
and it’s a complete rewrite of the original batch post-build script that was included in Ryochan7’s fork. It updates the newest.txt
file that contains the latest version. It’s used for checking if you’re running the latest version of the application (it checks it against the file in my repo). It also moves the relevant localisation assemblies to a separate directory, runs Ryochan7’s script that injects relevant code into that build’s .deps.json
file, renames the target folder from net8.0-windows
to DS4Windows
and zips the folder, completely automating the deployment process (from there all you have to do is release it on GitHub).
It is important that you do not have the script execute when you just want to debug/run it quickly from the IDE. It won’t let you do that anyway, because it tries to run an exe thats in a directory called net8.0-windows
that doesn’t exist anymore. I’m trying to keep it commented out in the .csproj
file when I push new commits, however sometimes I might forget to do it and you might come accross an issue where you can’t run the code in the IDE, because it tells you that the file does not exist.
In that case, you need to comment the line that runs the script out in the /DS4Windows/DS4WinWPF.csproj
file by putting REM in front of it (it needs to look like this: REM python $(SolutionDir)utils\post-build.py $(TargetDir) $(ProjectDir) $(Version)
).
For deployment, remember to uncomment the post-build script. You also need to remember that a version check is ran against this file so you need to disable version check (like in case of beta versions) or update the code that checks if the app is up to date to fetch this info from your repo.
If you want to release a version from a different branch than master
, it’s important that you define a BETA_VERSION
constant before build. Otherwise you end up getting the outdated version warning. To do it, simply add BETA_VERSION
in <DefineConstants>
in a relevant Release
PropertyGroup
in the /DS4Windows/DS4WinWPF.csproj
file. Example of how it should look:
...
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'">
<AllowUnsafeBlocks>true</AllowUnsafeBlocks>
<DefineConstants>WIN64;BETA_VERSION</DefineConstants>
<ErrorReport>none</ErrorReport>
<DebugType>none</DebugType>
<DebugSymbols>false</DebugSymbols>
<GenerateSerializationAssemblies>Auto</GenerateSerializationAssemblies>
<PlatformTarget>x64</PlatformTarget>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|x86'">
<AllowUnsafeBlocks>true</AllowUnsafeBlocks>
<DefineConstants>BETA_VERSION</DefineConstants>
<ErrorReport>none</ErrorReport>
<DebugType>none</DebugType>
<DebugSymbols>false</DebugSymbols>
<GenerateSerializationAssemblies>Auto</GenerateSerializationAssemblies>
<PlatformTarget>x86</PlatformTarget>
</PropertyGroup>
...