Closed Ryochan7 closed 5 years ago
Does this mean the DS4 is unusable? because mine is not picking up my controller at all today
No, it means that you'll need to use the "hide ds4 controller" feature instead of using hidguardian.
I had not posted version 1.5.15 before your post so that wouldn't matter. Did you check the Windows Device Manager to see if the controller got disabled? Recent changes to DS4Windows should have curbed problems like that though; it hasn't happened to me since the hotplug changes (version 1.5.12).
As of version 1.5.15, if you are using HidGuardian then you have to either change the AffectedDevices registry key (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HidGuardian\Parameters\AffectedDevices) used by HidGuardian and perform a device hotplug or use some kind of software like WhiteKnight to whitelist DS4Windows temporarily and perform a device hotplug. The "Hide DS4 Controller" option is now the only supported way of hiding the DS4 from other applications.
Edit: Forgot that disabling the device doesn't really matter. AffectedDevices has to be edited.
You can just uninstall HID Guardian.
Go to Device Manager -> System Devices
Right click on "HID Guardian" and choose uninstall, make sure to check remove software to get a full uninstall.
You need to do more than that to uninstall HidGuardian. You will also need to remove the classfilter entry for HidGuardian or you can run into problems. There is the potential to lose keyboard and mouse support if you don't change that entry. I had that happen while intentionally testing a bad value and restoring that registry key from a Windows recovery disk is a pain.
Attention: ❗ removing HG requires a special procedure described here or else you could end up with no keyboard/mouse ❗
https://docs.vigem.org/#!hidguardian-v1-installation.md#Driver_removal
Without HidGuardian, I can't get DS4Windows to reliably use exclusive mode. I've disabled the GeForce Experience Overlay and made sure Steam doesn't run at startup, etc., so I don't know what could possibly be preventing it.
Edge prevents it. Even if you don't use it, it can be running in the background.
Hi Ryochan7,
Some months ago, I decided to install HidGuardian (using the howto described on DS4Windows wiki) to solve the problems I was having since ancient times which were causing occasionally DS4Windows could not get exclusive mode when connecting the DS4. Indeed, that procedure solved it perfectly. I haven't had any more problems related to exclusive mode since then.
My question is, now that you've dropped HG support and improved exclusive mode in ds4windows itself, would my previous problems come back if I update DS4windows and uninstall HG? Or should they be fixed?
Are you mplanning on implementing HG again in the future or implementing any other similar procedure? If that's the case, I guess I could stay on muy outdated DS4windows with HG support and HG installed, by now.
Thanks for your work.
ajhix, it seems to be Windows Explorer itself that prevents exclusive mode. Only by restarting it through Task Manager can I get it to work. This is a very old hack which I'd rather not resort to using so I think I'll have to roll back to an old version.
Hey, Ryochan7!
I've been trying to make ds4windows work again after stopping using Hidguardian, but I can't get exclusive mode in any way, even after formatting my PC (I thought it could be leftovers from Hidguardian...). Do we have any other kind of approach to make it work again?
Why you dropped it it worked perfectly fine now ds4 is again unusable wtf how can you made such a decision better upgrade the grid so that i can see the options without each letter on a single line.
And it's neither explorer or anything it's the sound driver wich makes it used by anything. deactivate them all then you need to turn off gforce. otherwise install hg but the standalone just takes the pid wich changes each startup so you need to make yourself a script to update it or whatever i dunnow i'm kinda pissed. each time now on startup i have to deactivate gforce first check everything instead of plug nd play jesus christ this is madness.
Unfortunately was a bad decision (in my opinion).
The Hide DS4 Controller feature isn't convenient, I need to disable GFE, close uPlay, Origin, Battle.net and then enable the Hide feature.
I miss HidGuardian, but for now that's the only way to use it without any "double input" problems.
Re-posting what I wrote in another issue.
Based on what I have read, HG v.1 is considered deprecated according to Benjamin. A good replacement is not available at this time though. If HidGuardian 4.x ends up improving then I might reconsider supporting HidGuardian. I am not very hopeful though.
maybe it's just me but I've been using hidguardian 1.14.3.0 for several months without any issues, deprecated or not it's the only way to hide the ds4 reliably on windows 10 and considering the small amount of code needed to make it work with ds4windows I don't understand the need to remove it
@Ryochan7 at the end is your software and any decision you make is totally legitimate, but have you considered to fork/use existing HidGuardian code and integrate it within ds4windows itself? I'm not a coder and don't know exactly what has been the progress on HidGuardian to make the decision to drop its support in ds4windows, but I'm sure HG was working flawlessly at some point with ds4windows, and I'm having a great experience with it (I'll not update my setup 'til it supports HG again). If you use and fork off HG code and modify it at your likes and make it a part of ds4windows itself you could take control of the code and make sure updates on HG don't break anything on ds4windows. I guess it could be a lot of work, but you could even open a patreon and I'm sure lot of people would be interested (myself included).
If you don't support HG anymore, though, I guess it won't be a big deal for me. I'm happy with my build of ds4windows, I think it works perfectly, it has all the features I could think of, and I don't experience any bugs with it. So, thanks for this great software you've created (yeah I know it's a fork of the original one from another author, but whatever).
Greetings.
I didn't like the approach that HidGuardian uses with version 4 series when the service component was an optional component of HG v.1.
There are likely tweaks that could be done to improve performance. Recent tests on a VS template KMDF driver project have shown that utilizing certain build settings can make a massive difference in the driver created. Just using mostly stock settings for a Release build still resulted in a pretty bad driver that bogged down my system a fair degree. After some tweaking, performance issue went away. I don't know about current HG but ViGEmBus uses some settings that I found to lower performance.
If forking were a viable option then I probably would have forked ViGEmBus months ago. The main thing keeping me from doing it is money. I don't have the money to pay for the certificate needed to sign drivers for public distribution. I also don't want to get involved with making Windows drivers.
Just updated DS4 to the latest version to find that HG support was dropped. I do use it too myself, and it might have been a bit hard to setup at first, however after I got it to work once it didn't cause any problems. Looking through my folders, I've been using HG v1 since 2017/10 and switched to HG v3 around 2018/06.
Now, to my surprise, no one talked about HG v3 in here. Any reason as to why no one uses it? It is listed as a stable release and signed by nefarius himself.
For me this might be a deal breaker, So I will return to an older version for the time being. I totally understand the decision to stop supporting HG as it is not a feature that is used by the common user and setting it up can be... painful, to say the least. So no hard feeling as I do believe that @Ryochan7 is doing an amazing job with developing DS4. Please keep up the good work!
Anyways, for safekeeping, I will list what I have setup on my PC. Here is the SHA-256 of the zip I have on my computer from half a year ago, and where to get it. (I've checked it is still the same one). https://downloads.vigem.org/projects/HidGuardian/stable/3.0.62.0/windows/x86_64/HidGuardian.zip HidGuardian.zip SHA-256 DBEB1F32C8DF6EF90D37CF280CD3185AA9941D6C4D2A4F7C7557D64D58079D91 And some hashes of the drivers .\x64\HidGuardian.sys SHA-256 B4543D83406DEC4D7A8F72B3AE01429FDDB658B5A6FBE3F97FBBA139614F3DAD .\x86\HidGuardian.sys SHA-256 8256059C5C492FE1D37CE53A14BB7ABE66D7E077EC3B233D46B32C2DAF894C96
As far as to how to set it up, I trust that anyone that is willing to go down this rabbit hole can make it on his/her own. Do so at your own risk.
I was told by Benjamin at one point to not worry about version 3 and look into using version 4 instead. The version 4 series seems to be all that is receiving official support at this point.
Testing some build settings with old HG code (around version 1.13.8.0) has shown how much of a difference using custom build settings can make.
Cool, this auto-update with no description beyond "Updated Version Number" was a nice surprise to wake up to. I especially liked the bit where I had to uninstall HIDGuardian to get the program half-working again, reverting the Hide DS4 function to its previous questionable state. Quality messaging!
You've been sleeping for a month and a half then. HidGuardian was dropped in early November.
If you needed it (like I do), you could have disabled auto-update and manually stay on version 1.5.14.
The auto-updater had been asleep due to the version number issue, and I only check this Github project when I have a problem.
There are posts how to use HidGuardian even when DS4Win doesn't do certain hidguardian integration things (external apps like WhiteKnight can be used to do those PID process updates). Please remember also that both DS4Win and HidGuardian apps are developed and maintained by volunteers, and those apps are still moving targets, so things may break or be changed at any time.
Testing last night with DS4Windows and another C# app has shown again that using the Microsoft.Win32 namespace can slow down an application. Removing the use of that namespace from the ControlService class did improve the output performance of DS4Windows. That namespace is still in use in DS4Form but I don't know if I have the option to remove it. I will have to check that in VS later.
Maybe using a C++/CLI wrapper class would help with this type of problem.
Ended up trying the PInvoke route first. Adding the needed calls and rewriting methods resulted in better performance. Also, removing Microsoft.Win32 from DS4Form did improve performance but the suspend routine had to be removed in the process.
Using C++/CLI was the harder route to take but it looks like it is the better option. It took a long time to find out how to use it in Visual Studio, deal with managed types, and performing type conversion (mainly String) to prepare data for the system calls. The final output performance seems better than using the PInvoke route even with those PInvoke calls still defined, but unused, in the project.
These experiments have been interesting but these test do not address the core problem.
How do you measure these benchmarks? I have never seen any dramatic performance problems by using Microsoft.Win32 c# unit, but then again I haven't tried to measure things down to milliseconds.
The weird thing is that none of the Microsoft.Win32 classes have to be used to experience a difference in application performance. Just adding using Microsoft.Win32;
in a source file is enough to notice a difference in application performance.
Testing performance is more based on GUI responsiveness and relative output performance in games instead of quantitative figures. The games I have been testing with lately have been Half-Life 2 and Gex.
These odd experiments have made some difference so far. DS4Form has been changed to use WMI to detect power state changes rather than relying on the Win32 API hooks.
USING statement should not have any kind of runtime performance implications because compiler gets rid of all c# byte code blocks which are not used at all and JIT never compiles byte code which is not executed.
Also, performance measuring C# (and Java) apps is a bit difficult because c#/Java has all sort of garbage collecting routines we cannot control, so some fluctuation is inevitable in C#/Java apps. JIT just-in-time c# runtime compiler also may have a significant hit during the first executions of certain code blocks.
It shouldn't but this is not the first time that I have experienced this type of difference. System.Numerics is another namespace that has this kind of problem. That problem killed the possibility of a square stick interpolation mode.
With the most recent change, it is now feasible to increase the mouse sensitivity in a profile further than what I had been using. There has been a real benefit from stopping using the Win32 namespace. I am now playing Judge Dredd: Dredd vs. Death using RS as a mouse.
Edit: Corrected namespace
The change felt big enough to warrant a new release.
https://github.com/Ryochan7/DS4Windows/releases/download/v1.6.3/DS4Windows_1.6.3_x64.zip
is there an alternative to hidguardian to achieve exclusive mode easily?
I haven't been able to get exclusive mode working even once in these latest versions, while it didn't ever fail me in old versions. Am I the only one?
I tried to use that WhiteKnight Whitelister, it simply doesn't install HidCerberus, I've installed manually but the auto whitelist doesn't work...
@jonaaa20 the whiteknight have some problems running in languages that are not english. I have found the fix that worked for me, in the whiteknight.ahk, you have to change these lines:
RegExMatch(lines[5], "^\s+STATE\s+:\s(\d+)", out) ;DOOK
to
RegExMatch(lines[5], "^\s+**whatever is the equivalent for your language**\s+:\s(\d+)", out) ;DOOK
and this line
if (RegExMatch(lines[5], "^\s+STATE\s+:")){ ;DOOK
to
if (RegExMatch(lines[5], "^\s+**whatever is the equivalent for your language**\s+:")){ ;DOOK
***Make sure the swapped part is all in caps!
And if you want whiteknight to recognize ds4windows minimized to the system tray, you have to swap this part of the autowhiteliste.ahk:
This
WinWatcher: if (WinTitle && WinPID){ ; App currently whitelisted if (!WinExist("ahk_pid " WinPID)){ SetWhitelistState(0) WinPID := 0 } } else if (WinTitle && !WinPID){ ; App selected, but not whitelisted if (WinExist(WinTitle)){ SetWhitelistState(0) WinGet, pid, PID, % WinTitle WinPID := pid SetWhitelistState(1) } } return
needs to become this
WinWatcher: if (WinTitle && WinPID){ dhw := A_DetectHiddenWindows DetectHiddenWindows On ; App currently whitelisted if (!WinExist("ahk_pid " WinPID)){ SetWhitelistState(0) WinPID := 0 } } else if (WinTitle && !WinPID){ dhw := A_DetectHiddenWindows DetectHiddenWindows On ; App selected, but not whitelisted if (WinExist(WinTitle)){ SetWhitelistState(0) WinGet, pid, PID, % WinTitle WinPID := pid SetWhitelistState(1) } } return
Then you will have whiteknight working 100%! Sorry for the kinda convoluted explanation, it's the first time i try to explain something like this 🗡
I did the mentioned changes regarding the STATE (i've changed to ESTADO), still can't install (on the tool) or make it work, here's my file.
@jonaaa20 are your windows in pt-br? If it is, you can just use my config WhiteKnight.zip I have installed the hidguardian itself with the tool, but have installed hidcerberus directly through cmd, so I can't tell you if it installs from here.
Yes, i got it working, i was opening the executable instead of the .ahk script, everything's working now, thanks!
Can I ask what your issue is in regards to HidGuardian Gen4 usability? And once the testing phase is completed and things are stabilized, considered switching then? @ryochan7
The current lack of documentation regarding setting up rules to whitelist applications is the main usability issue. Looking at the code did not help much either. My testing of Gen4 ended up having to be based on setting up an exclusion using whatever registry key affects that.
Other than that, I found that just having the driver enabled caused noticeable system slowdown on my machine. Based on my testing, I am betting that just taking advantage of optimization options in the compiler would likely get rid of those kinds of issues. It helped a lot with the Gen1 code.
I have not tested the latest tweaks to Gen1 since my recent testing with C++/CLI usage in DS4Windows. The main tests with C++/CLI were just making sure that application slowdown would not be introduced by including optional support.
The issue of documentation has been mostly rectified, it's still definitely not in a release ready state as extensive testing must be done. Most of the testing is done by the members of ViGEm's Discord. Here's a link if your interested btw. https://discord.gg/d666Tzk
HidGuardian version 1 support has been added back in for now as a trial run. The process used to interface with HidGuardian this time is different than what was used previously. HidGuardian support is still up in the air though. There is also no plan to support HidGuardian version 4 when it gets a stable release.
https://github.com/Ryochan7/DS4Windows/releases/download/v1.6.8/DS4Windows_1.6.8_x64.zip
Hi,
Thanks for once again integrating HidGuardian support, it is much needed until a better solution presents itself. I was wondering, what does HidGuardHelper.exe do? I ask because when I try and run it, nothing happens.
Thanks
Its main purpose is to take a PID as a command line argument and then periodically check if a process still exists using that PID. If not then the application exits. The application also writes the whitelist entry when it first starts and then removes the entry when the application exits. In case you would like to look at the code behind the program, it is hosted in a different repository.
Thanks Ryochan7. Is the howto from your wiki still valid as a step by step guide to install and setup hg and ds4windows? If I upgrade directly from an old HG supported ds4windows to this new one, sbould I need to setup anything?
Thanks.
Is the howto from your wiki still valid as a step by step guide to install and setup hg and ds4windows?
Can confirm the wiki is still valid, used it a couple days ago to do a fresh install.
The instructions in the Wiki page should still be valid. One downside from recent changes is that the old test installer I made no longer works because the URLs pointing to the json files used by the program are no longer valid. I no longer have the ryochan7.xyz domain.
A note for future reference. Because HidVigil will be a required service to run for HidGuardian v.4, the assembly problem would come into play again. It seems like the better option to try would be to wrap the ServiceController and HttpClient calls into a C++/CLI library and see if that will allow interfacing with the service without introducing application slowdown.
I tried this with a template project and offloading some assembly loading to a C++ library. It did not help; I tested it with the System.Net.Http assembly. The same application slowdown happened when placing a reference in the library rather than the main application. An oddity that I found from experimenting is that using Copy Local = true to have VS place the assembly DLL in the output folder, rather than taking advantage of the GAC, made the problem go away. That doesn't seem right.
Tried this in many other contexts as well. The result has been the same. Enabling Copy Local = true for the System.Net.Http assembly gets rid of the application slowdown experienced from referencing the assembly. I don't get it.
Commit ccdfd8cfe59f28a7fd53dbff91818dfcc8693ca3 removed the use of HidGuardian and the associated helper routines. HG 1.14.0.0 just barely worked anyway and the version 4 series in its current state (4.1.126.0) is not usable for even normal computer use. Meritocracy dictates that I cannot depend on it anymore.