Ds4windows: [Notice] ViGEmBus Support Updates. Deprecation of ScpVBus Is Official.

Created on 4 Oct 2018  路  55Comments  路  Source: Ryochan7/DS4Windows

After all the waiting and how unstable the most recent beta release of ViGEmBus is, I am done waiting for ViGEmBus to be ready so I will no longer build a version of DS4Windows that uses it. I was hoping for the best and older versions that I helped with worked fairly well. The newest release keeps temporarily freezeing my PC while running games (Lego Star Wars The Complete Saga and .hack//G.U.) and stops generating XInput events randomly although Windows still detects the virtual Xbox 360 controller. An unplug and plugin cycle for the virtual controller is required for events to get generated again. The problem is not with DS4Windows itself.

For reference, I was using commit (5b861c9287dcebaf710232562911713b0ba7f3be) previously on my machine and that was committed on 2018/07/02. That version works just fine on my system.

https://github.com/ViGEm/ViGEmBus/tree/5b861c9287dcebaf710232562911713b0ba7f3be

Most helpful comment

DS4Windows 1.7.0 is now out.

All 55 comments

I tried building from the latest source code. I don't experience any freezing problems when using the latest code. Response time is still pretty slow though. Definitely a downgrade.

I mainly solved the problem that I had with ViGEm last night. It required another change to the build settings for the project that the compiler actually recommended. It looks like it will be time to submit another pull request.

Oh noooooooo!
And for those who uses vigem? How to update?

The apache server stats seem to show that more people use the ViGEm build than I realized. Personally, even the signed stable ViGEm driver does not meet my standards and it runs worse on my system than ScpVBus. That is the main reason I had been building the driver from source and running my computer in Test Mode all the time.

I have been experimenting with ViGEm since around November 2017. None of the changes that I have contributed to the project are included in the stable driver. I was hoping that the beta release of the driver would have allowed DS4Windows to finally make the switch to using ViGEm by default but the release was far worse than the stable driver. ViGEm has been a moving target that I had to adjust DS4Windows on a few occasions in order to support it. Having that period of massive breakage was very discouraging.

I believe I have the most recent ViGEm build code in the DS4Windows repository (vigem-udpserver branch) so it wouldn't be much work to make a new build. I still don't really want to try to provide active support for ViGEm especially if performance degrades that badly again and I have to attempt to tweak the source code to make it work for me.

In fact, i switch from SCP to ViGem because folks said its far more better and compatible with latest Windows 10 builds.

In fact my current version (1.5.8 w/ UDP) is running fine, except two issues: The "Minimize to Taskbar + Close minimizes" combo isnt working propely (in fact closing the app only minimize - normally - the app instead of exit the program OR closing it to taskbar).

The other is i got heavy lag connecting the controller using an USB cable. I got a charger/data cable combo from my smartphone, it worked to transfer files between my phone to PC.

Personally I do not care which build I use, as long as it works like it should. But the SCP build has one glaring problem for me: Sometimes when I disconnect the DS4 the next time it shows up as player 2 and I have to reconnect 3 times in quick succession to cycle through player 3 and 4 back to player 1. This is a nuisance that I have yet to experience on the ViGem build, which is why I switched to that now. If I experience input lag with that one I will switch back though, since that is worse than the player problem xD

The issue with ScpVBus not releasing ports has been a problem since the beginning. Luckily I have hardly experienced it and I have implemented workarounds for the scenarios that people have presented. I have never had a problem with ViGEm not releasing ports after unplugging a virtual controller.

For me, the latency issue has been a bigger concern and I have seen that ViGEm can outperform ScpVBus. My arbitrary rule regarding latency is still being applied in this case so ScpVBus has continued to be the main driver being used although some other projects have moved to using ViGEm. I would like to be able to start actively using and promoting ViGEm usage.

As for the minimizing options, the Close Minimizes option behavior can change depending if Minimize to Taskbar is enabled. Minimize to Taskbar only takes a window's state into account and not if the Close Minimizes option is enabled. I don't think I have a problem with the current behavior though. The code could be changed so that Close Minimizes would minimize to the system tray no matter which setting is used for Minimize to Taskbar.

I don't know why you would experience a huge input lag difference when using a USB connection instead of Bluetooth. There is a difference with Bluetooth edging out as being faster even when using a 4 ms poll rate. When the DS4 v.2 came out and using the DS4 on the PS4 wired became an option, people found out that using a Bluetooth connection was, on average, actually faster than a wired connection for some odd reason; the info might have been from a NeoGAF thread but I don't remember the source. I do not own a PS4 so I could not perform a similar test myself; the DS4 has always been a PC controller for me. The only thing that I could suggest is to check your power profile options in Windows and make sure your USB ports are getting full power at all times.

I usually use the two wireless options available rather than using a USB connection.

Thanks a lot @Ryochan7 !!

Testing it reveals the "Minimize to Taskbar" option alone isnt working. When i try to minimize the window stays minimized.

I don't have that problem with Minimize to Taskbar on my end. I can restore the window fine. I'll take a look into the Form_Resize routine where the main logic resides.

Also, I did a little test out of curiosity. Even though the Sony Wireless Adapter is locked at a 8 ms poll rate, the connection is still slightly more responsive than using a USB connection. The Sony Wireless Adapter connection and USB connection go through the same code path so nothing in DS4Windows should be impacting the result. It does seem like the DS4 handles wireless better. BT > Sony WA > USB

I don't have that problem with Minimize to Taskbar on my end. I can restore the window fine. I'll take a look into the Form_Resize routine where the main logic resides.

I have the issue as well on Win7 x64 with 1.5.8 & 1.5.9 SCP.

New build for those who want use it. I should update the title of this issue to better reflect the current standing of ViGEm support now.

http://ryochan7.xyz/ds4windows/test/DS4Windows_1.5.11_ViGEm_UdpServer_x64.zip

New build

http://ryochan7.xyz/ds4windows/test/DS4Windows_1.5.14_ViGEm_UdpServer_x64.zip

Thank you again, @Ryochan7 !

Can i ask you something extra, please? Can you share your latest compiled ViGEmBus.sys (64 bits), with the proposed patches for Nefarious? I want to upgrade ViGEm up to 1.16, but your discovered latency issue holds me to do it. Also, I would like to have the same as you in my OS.

Again, thank you very much!

It might be easier to compile the driver from source.

https://github.com/Ryochan7/ViGEmBus

It might be easier to compile the driver from source.

https://github.com/Ryochan7/ViGEmBus

Okay! Compiled. :-)
Thanks again!

Sorry you had to wait and it would be a shame if you'd abandon that road. IDK what specific problems and ViGEm betas you're talking about. The last "official" release is old, I agree but the upstream repository had received quite a fair bit of critical fixes the community reported. And releasing a properly signed driver isn't something you do in an afternoon. I'm always open for discussion and have multiple open channels for communication so if there's anything that needs to be answered: be my guest.

And @Ryochan7 in case you or your contributions are feeling ignored; let me assure you if I've failed to respond to one of your recent inquiries either vial mail or Github or any other media rest assured that this then was an unintentional slip up and not malicious in any way.

The decision and much of this discussion originated from frustration with the beta driver that came out around late August(?) after I posted on the old forums; I must have deleted my copy. The freezing problems with the beta driver that I mentioned really made things seem hopeless. Only later did I try to tinker with the latest source code.

ViGEm support in DS4Windows has been a moving target since around November 2017. As it stands, I have continued to use ScpVBus in the main build of DS4Windows despite the problems with ScpVBus because it performs better on my system than stable ViGEmBus.

I had no problem with the response time with the latest pull request. You have had other tasks to take care of on your various projects.

I'm confused; beta driver? I never released ViGEm betas in 2018.

I unfortunately had to nuke the old forum because the engine behind it didn't get enough development to become stable. 99% of the communication happens on our Discord anyway; I know you are not a fan of it but all the helping hands around these topics are gathered there and eager to help.

I recently got ViGEm WHQL certified and could drop you the latest copy for testing if you like. I can't publish it yet because of some non-technical details I don't wanna bore you with.

Or even me @Ryochan7 if @nefarius is not responding fast enough to your liking, you already have my email (which I watch more than anything else).

It is too bad that the minor conversation has gone into the ether. All I can remember is that whatever I downloaded was not available in the downloads section before the conversation. I found an old reference to my experience that was posted in this issue tracker on September 15th.

https://github.com/Ryochan7/DS4Windows/issues/428#issuecomment-421609732

I could probably record a video to definitely prove that my other claim is valid regarding the vanilla version of ViGEmBus from early October running slower on my machine than with the other two commits. I would expect that you could probably duplicate the same result on your end as well.

Apart from that, I had checked out the ViGEm Discord before; caved in for HidGuardian version 4 info about two weeks ago. The recent email notifications have been interesting; I ended up checking out the chat for context. Didn't expect a slander charge to get thrown around. I might be in trouble for some minor posts that I have made about ScpToolkit and HidGuardian version 4 as well.

I have ps4pro controllers now. They don't work with scpdrivers at all. They only work with Vigem drivers :(

So the latest link of vigem works for me but the main branch, controller just has a white light and nothing happens.

Neither driver interacts with the DS4. DS4Windows acts as the reader and formats an output report for the output driver. This sounds more like HidGuardian is installed so a controller might not be exposed to DS4Windows automatically anymore. The last ViGEm build still had HidGuardian v.1 support.

I uninstalled it via tutorial b4 I went to the main branch. I don't even see hidguardian in the device manager anymore.

The device is more useful for applications to probe and determine if the driver is installed. As long as the actual driver file still exists and the UpperFilters registry entry still references HidGuardian then the driver will still do its job. Following the tutorial should have taken care of the problem as long as you rebooted your machine afterwards.

As a follow up, I got around to testing it again and what I downloaded thinking that it was a newer driver was actually an old version. I did not see it in the downloads archive before the conversation and the file timestamp is misleading; server refactor issue I guess. That version showed up in the recent driver list in the Add Hardware wizard with recent tests. Tested with it and ran into the freezing problems mentioned before.

https://downloads.vigem.org/archive/ViGEm_x64_Win10_Signed_1152921504626464733.zip

i'm a bit confused on what you would like me to do for you to determine the solution to the issue.

nvrmnd, figured it out. the .sys file was still in windows32>driver folder so I deleted and restarted. Now the original drivers work again so now I can go back to the default branch.

That's good you were able to get the issue resolved. The default routine for devcon.exe does not remove the actual .sys file from the driver store. There is an option to remove the driver file when removing the device using the Device Manager. Another option would have been to use the program DriverStore Explorer. The second devcon.exe command in the uninstall instructions should have been enough to stop the driver from being used though.

I guess we'll see what happens.

https://forums.vigem.org/topic/252/here-is-the-news

Great news!

DS4Wndows version 1.7 will use ViGEmBus as the controller emulation driver. Support has been added to the main branch and ScpVBus utilities have been removed from the code. I originally just wanted to switch to access some bug fixes that ViGEmBus provides but some extra tweaks made last night for the ViGEm .NET libraries actually allowed better performance for ViGEmBus, even when using driver version 1.14.3.0, than ScpVBus was providing. Some of the recent compiler tweaks made in DS4Windows were carried over to the libraries so this change could not have happened earlier. It will be nice to finally dump ScpVBus.

I tested the new version using the 360deg steering wheel emulation in various racing games and it seems to be working. The new version of DS4Win prompts to install VigemBus driver and installation went through OK.

That is good to hear. I have not tested the 360 steering wheel code yet. I have been testing the driver install routine and overall input performance so far. Testing the 360 steering wheel code in ATS will happen a little bit later.

Edit: It was hard to test play ATS, given my situation, but 360 steering wheel mode works on my end. HTML5 Gamepad Tester also confirms that the full range is mapped as expected.

DS4Windows 1.7.0 is now out.

Glad i needed to format my PC, so i didnt get any scp traces anymore to reinstall DS4W!

@vpontin no need to format the PC to get rid of SCP, there's a comprehensive removal guide available.

Cheers

Besides the method linked by nefarius, there is another way to get rid of ScpVBus from your system. DS4Windows keeps the original ScpVBus installer in the DS4Windows program folder under Virtual Bus Driver. You can run the ScpDriver.exe program in that folder and click the uninstall button to delete the exposed ScpVBus device and delete the driver from the driver store.

scpvbus_folder

I need to reformat my PC at some point as well to get rid of some bloat.

Now when DS4Windows uses the ViGem driver then maybe some users run into an issue Nefarious found out from users of Oculus VR controllers (ie. Oculus uses or at least used to use a rip off version of ViGem driver):
https://forums.vigem.org/topic/47/psa-oculus-software-can-crash-your-machine

And if Oculus still haven't officially contacted Nefarious about the use of his driver then bad bad and shameful Oculus (or whoever nowadays owns it).

Well Facebook owns Oculus now so that type of behavior does not surprise me.

I though the problem that Nefarius documented was from a driver version before 1.14.3.0. DS4Windows users should hopefully not get a BSOD from the current ViGEmBus driver.

I though the problem that Nefarius documented was from a driver version before 1.14.3.0. DS4Windows users should hopefully not get a BSOD from the current ViGEmBus driver.

Yes, but if a PC has that Oculus stuff already installed (or it is installed later on) then this rip off driver version may conflict with the official Nefarious ViGEm driver if the rip off uses the same driver ID. This way DS4Win might end up using an older version of ViGEm driver. Well, BSOD error message would not happen here because DS4Win doesnt create virtual DS4Controller object but older driver version may have other problems.

Good point. I would have hoped that Oculus would have exposed their version of the driver differently but nope.

But if you happen to run other tools interacting with ViGEm who request a virtual DS4, they pick up the Oculus Bus (because the geniuses copying it didn鈥檛 change the interface GUID 馃槧), request it to spawn a DS4 and boom, there goes your unsaved work.

This could be a big problem for people using the Oculus Software and DS4Windows. Hopefully, there aren't many people in that situation.

I'm using both Oculus Rift and DS4Windows. I haven't played my Rift for awhile though (too busy with other PC games), so I don't know how's the compatibility with DS4W. Should I close DS4W before playing Rift or that would have no effect?

You would probably have to close DS4Windows to close the connection with ViGEmBus but that is only part of the problem. The underlying problem is due to two drivers conflicting because Oculus did not fork their version of ViGEmBus properly. A workaround section was written in the post made by Nefarius.

https://forums.vigem.org/topic/47/psa-oculus-software-can-crash-your-machine

When you want to use your Rift, you would have to disable the Virtual Gamepad Emulation Bus device in Device Manager under System devices. Then you would probably have to restart the Oculus VR Runtime Service service. When you want to use DS4Windows again, you would have to stop the Oculus VR Runtime Service and then disable the Oculus Virtual Gamepad Emulation Bus device in Device Manager. You would then be able to start DS4Windows without any conflict.

Wow, so much trouble every time I want to play one or the other. I guess I'll see if I get BSOD before trying that. And if I do, I'll send an Oculus support ticket and direct them to this thread lol.

It is a shame. Oculus should have just used upstream ViGEmBus and collaborated with Nefarius rather than forking it the way they did.

Oculus should have done a lot of things differently... primary among them, don't be sold to Facebook.

As an aside, it would be fairly simply to write batch files or a little program to toggle the states of the services and devices. I don't have an Oculus anything and don't desire one, so I can't develop and test such a thing, though.

Come to think of it, do you really even need to disable the newer ViGEmBus device and re-enable the older one in order to use the Oculus stuff? If the problem with leaving the old device active when using DS4Windows is that it'll connect to the old device, that implies that the Oculus service might similarly connect to the new device if it's the only one active...?

We've had a bit of back and forth a long time ago which basically lead to nothing. Their state is everything is fine, which clearly isn't, my state is "I won't do your job and give free support to people you screwed" so that's currently a bit of a deadlock. Could all have been prevented if they'd simply contacted me beforehand but no...

I even got in touch with John Carmack at the time. :/
John

Oh yeah, that was you mate 馃槃 Still, lead to nothing.

In all fairness I had a chat with one of their technicians but the end result was "not reproducible" on their end so that trail went cold fast.

This issue has run its course now that ViGEmBus is being used by DS4Windows. I guess the next step would be to check on the current status of HidGuardian 4 and start testing that. The last time I tested it, I couldn't get the new whitelist technique working. A new issue will be made and pinned containing notes regarding progress.

Was this page helpful?
0 / 5 - 0 ratings