Describe the bug With a virtual Xbox 360 controller enabled, programs that poll controller input will be unable to launch. They deadlock attempting to open a handle to the device. This happens with feeder applications as well.

It also prevents any real devices from connecting to or disconnecting from my system.

To Reproduce I've been unable to consistently reproduce it. It happens fairly frequently, but with no specific steps that I could identify. If applications begin failing to launch with a feeder and Xbox 360 endpoint, however:

1. Launch an application that polls for controller input (a game, Uplay, Steam, Battle.net).
2. The application will stall or fail to launch.
3. Attempt to disable the device with Device Manager/etc, and it will also stall.
4. When the feeder is killed, the Xbox 360 endpoint device will enter an error state, displayed in Device Manager.

Expected behavior Some kind of error handling or error logging. ViGEmClient has error logging, but it doesn't appear to encounter any errors when this deadlock occurs.

Screenshots

I attempted to disable the device, Device Manager stalled, and both the Game Controllers dialog and Battle.net immediately launched. Opening another instance of Device Manager reveals that the device is still enabled:

System details (please complete the following information):

• OS: Windows 10 Pro 1903
• Feeder software: ds4wizard
• Driver Version: 1.14.3.0

Additional context It very well could be something I'm doing with my feeder, but I've been unable to figure it out.

Hello! I ran into a problem while installing ViGEmBusSetup. Installation fails with an error "Nefarius Virtual Gamepad Emulation Bus Driver Setup Wizard ended prematurely" =(

OS: Windows 10 pro 19042.685

ViGEmBus: 1.17.333 FireShock: 3.0.0.0 Shibari: 1.4.106 BthPS3: 1.2.4

I use ViGEm for using a tablet with game controls for remote play, which is better than Vita except clicking the touchscreen doesn't send touchpad events to the PS4. Could you please add this?

Describe the bug I downloaded the latest installer (ViGEmBus_Setup_1.16.115.exe) and tried to run it. Absolutely nothing happens. I already tried as admin and through powershell, nothing is printed either. I found out that GloSC wasn't working because the driver wasn't installed, so I tried to install it manually.

To Reproduce

1. Download the setup file
2. Try to run it (double-click)
3. Nothing opens

Expected behavior The driver to be installed.

System details (please complete the following information):

• OS: Windows 10 Pro 1909 x64
• Feeder software: GloSC
• Driver Version: 1.16.115

Are there any flags I can pass to the installer to make it verbose and give me any clues on what is happening?

Describe the bug Two subsequent calls to XInputSetState with different values break the state of the motors (vibration persists after being reset to 0 on both motors). It can easily be tested with this configuration on Dolphin: This happens on a DS4 with DS4Windows, though looking at DS4Windows, no XInput code seems to be there so I thought it was probably ViGEmBus? Sorry if I'm wrong. The bug does not happen on a real Xbox controller. I've also wrote some code that triggers the bug and pasted the pseudo code for you to reproduce it below. When setting "should_sleep" to true, the state won't break.

To Reproduce Steps to reproduce the behavior (example):

static bool should_sleep = false;
static int sleep_time = 100;
state_out.wLeftMotorSpeed = 0;
state_out.wRightMotorSpeed= 65535;
XInputSetState(i, &state_out););
state_out.wLeftMotorSpeed = 65535;
XInputSetState(i, &state_out););
if (should_sleep)
  Sleep(sleep_time);
state_out.wRightMotorSpeed= 0;
XInputSetState(i, &state_out);
state_out.wLeftMotorSpeed = 0;
XInputSetState(i, &state_out);

Expected behavior Vibration goes back to resting state.

System details (please complete the following information):

• OS: [e.g. Windows 10 19042]
• Feeder software: [e.g. DS4Windows 2.2.1]
• Driver Version: [e.g. 1.16.112.0]

Additional context Add any other context about the problem here.

Describe the bug Calling vigem_target_add with x360 target hangs (freezes) Windows 7. There is no BSOD nor error message, system simply stops.

To Reproduce Consider following sample code:

#include "utils/assert.h"
#include "windows.h"
#include "ViGEm/Client.h"
// g++ -Iinclude -Ivigemclient/include/ ViGEmClient.cpp c-sample.c -lsetupapi -lhid

static PVIGEM_CLIENT vigem;
static PVIGEM_TARGET target;
static XUSB_REPORT report;

int main(int argc, char** argv) {
	vigem = vigem_alloc();
	ASSERT(vigem != NULL);
	ASSERT(vigem_connect(vigem) == VIGEM_ERROR_NONE);
	XUSB_REPORT_INIT(&report);
	target = vigem_target_x360_alloc();
	ASSERT(vigem_target_add(vigem, target) == VIGEM_ERROR_NONE);
	
	while (1) {
		report.sThumbLX ++;
		ASSERT(vigem_target_x360_update(vigem, target, report) == VIGEM_ERROR_NONE);
		Sleep(10);
	}
}

... compiled with g++ from MinGW package.

When code reaches vigem_target_add, it blocks briefly and I can clearly hear "ding" from new device notification. Right after it, entire system freezes, often even with last audio sample looping indefinitely.

When ran on Windows 10 (recompiled or even same executable) or when DS4 target is used, code works exactly as expected.

Expected behavior Not freezing.

Screenshots I've captured output from serial console and uploaded it to pastebin, just in case it will be somehow useful. I believe it's same message repeated.

System details (please complete the following information):

• OS: Windows 7
• Everything 32bit
• Driver Version: 01/19/2018,1.14.3.0
• Tested both with Virtualbox and real hardware

https://github.com/Ryochan7/DS4Windows/issues/1414

Any way something can be done on this end regarding this issue? Windows 7 Ultimate 64 bit here.

I do not have quickboot because it is not a feature of win7. System restore is not on, nor is hibernation mode. So nothing is being stored to memory when my cpu is shut down.

When first starting windows (after their permanent controller feature was introduced, and turning on ds4windows for the first time nomatter with autoboot or manually, virtual xbox controllers are seen in the joy.cpl when no controller is connected and when ds4windows is not on permanent mode. I have to stop and restart ds4windows (the whole program) for everything to function correctly. If I just press stop/start, the output slots are not cleared inside ds4windows.

So is there any way that something on the driver end can be adjusted to fix this issue for win7?

Using newer version of driver (1.17.333) "Tested with Cemu emulator" when a rumble event comes in, the rumble is extended too much time. For example, a rumble event that originally is only a hit or a shoot "0,25 seconds" the controller rumbles for 3-4 seconds. This is a bit annoying in games with too much rumble events.

Previously I used 1.6 version with some issues like controller disconnected problems when the rumble event come in. In this case, this is now solved, but this problem replaced the old one.

Using PS4 Dualshock V2. Windows 10 x64 H2 Build.

Is your feature request related to a problem? Please describe.

Virtual DS4 rumble and lightbar passthru support has been a problem for a while but I have not had time to really look into it beforehand; I don't use the feature myself and I had removed support for it in DS4Windows at one point before mika-n added the routine back in the code. The feedback data returned by games can really differ and causes distinguishing between the type of event that the data represents virtually impossible. My main test games that provide native DS4 controller support are The Witcher 3 and Streets of Rage 4.

Currently, DS4Windows tries to make an effort to determine whether an event should be considered a rumble event, lightbar event, or both. The workaround was mainly made using test feedback data given while playing The Witcher 3. Even before this current batch of tests, the data seemed to indicate that The Witcher 3 sent separate output reports for rumble events and lightbar events. The DS4 feedback notification delegate in DS4Windows works on that assumption so it tends to work fine for The Witcher 3; it is likely still not accurate but good enough to not cause major problems. Current tests show that the initial hypothesis is true and The Witcher 3 will change the HID output report features byte (byte 0x01) depending on whether the data represents a rumble event (set to 0x01), a lightbar event (set to 0x02), or both (set to 0x03); a value of 0x03 seems to be used most often for resetting both the rumble motors and lightbar.

However, Streets of Rage 4 seems to include both rumble and lightbar data in the same report and uses a value of 0x07 for the features byte. Flag 0x04 is used to enable flash support for the lightbar although it looks like the game does not set any flash data in the output report buffer. The current DS4 feedback workaround does not really work at all for Streets of Rage 4 and can cause infinite rumble to occur at times.

Location of the DS4 feedback delegate in the current code.

https://github.com/Ryochan7/DS4Windows/blob/57ca7fa2f61ce8447d949760a0146d45aa1aa7cb/DS4Windows/DS4Control/ControlService.cs#L648

Describe the solution you'd like

In order to be able to properly distinguish whether a feedback event should be considered a rumble event, lightbar event, or possibly both, the features byte from the main HID output report buffer (byte 0x01) needs to be provided by ViGEmBus through the ViGEmClient. As it is now, that byte is skipped by ViGEmBus and starts copying report data starting at byte 0x04 (Right Light rumble).

Describe alternatives you've considered

A workaround has been available in DS4Windows for a while. It only works relatively fine in The Witcher 3. The feedback processing workaround fails completely in Streets of Rage 4 when using its native DS4 controller support.

Additional context

I wanted to provide some test data I gathered from Trace events using TraceView Plus. Unfortunately, it looks like TraceView Plus cannot just output the filtered messages to an output file. It still includes all received messages from a session and the process of making the XML file takes several minutes and my current file is around 448 MB. Instead, I can only provide a small snippet of the last group of sample messages shown in a screenshot. The data was gathered while playing The Witcher 3 for a few minutes using its native DS4 controller support.

As you can see, the data differs depending on the flags set in the features byte.

Not sure if it will be relevant but here is the code snippet I inserted into ViGEmBus to log those messages. The code was added to the EmulationTargetDS4::UsbBulkOrInterruptTransfer method in the Ds4Pdo.cpp file.

PUCHAR rawOutputBuffer = static_cast<PUCHAR>(pTransfer->TransferBuffer);
TraceEvents(TRACE_LEVEL_INFORMATION,
  TRACE_DS4,
  "TestBytes: %02X,%02X,%02X,%02X,%02X,%02X,%02X,%02X\n",
  rawOutputBuffer[1],
  rawOutputBuffer[4],
  rawOutputBuffer[5],
  rawOutputBuffer[6],
  rawOutputBuffer[7],
  rawOutputBuffer[8],
  rawOutputBuffer[9],
  rawOutputBuffer[10]);

Some problems when the Vigem 1.16.116 are installed on the system. When a rumble event comes on some games (Using different emulators) the controller freezes and the character keeps walking/shooting/whatever. After uninstalling the Vigem, the problem was solved.

This reminds me a similar problem on another software called ScpServer:

https://github.com/nefarius/ScpToolkit/issues/39

The thing is that I need Vigem in order to use DS4Windows + Cemu emulator. In this emulator, the problem happens in every game with rumble functions.

On another emulators such as RPCS3, the problem happens also in the games. But if I uninstall Vigem (Since RPCS3 haves dualshock passthrough and it doesn't need an external software) the problem is solved again.

There are any plans for releasing a new Vigem version? The latest one was on Dec 19. Almost a year ago.

My specs:

Windows 10 x64 GTX 970 i7 4790k 16 GB DDR3

Thank you for this awesome software.

Is your feature request related to a problem? Please describe. N/A

Describe the solution you'd like With every new release of ViGEmBus, use a GitHub workflow to update manifests at https://github.com/microsoft/winget-pkgs repository.

I can create a pull request if you would like. It would help in keeping manifests up-to-date at WinGet with every new release automatically.

Same can be done for HidHide.

Describe alternatives you've considered N/A

Additional context N/A

Bumps dessant/support-requests from 2 to 3.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

I got BSOD while waking up from sleep. Bugcheck code is WDF_VIOLATION and parameter is 0x4

I'm using the latest release version 1.21.442.0

This is the stack

PSA

A successor "ViGEmBus 2" (not the official name) is in development since the beginning of 2022 and will supersede this project eventually. No new features will be added to this repository, only bug-fix updates. This issue will be updated once more information is available.

It'd be awesome to have an emulated switch pro controller, as it has motion controls that work with Steam. It'd also allow the program BetterJoyForCemu to emulate a switch pro controller using joy cons, allowing the joy con motion controls to function on steam instead of emulating a mouse.

The issue

HP's line of Omen gaming laptops come pre-installed with a modified version of the ViGEmBus driver. Apps trying to locate the latest ViGEmBus may end up detecting the modified HP driver instead, causing all sorts of issue since it is based on an older version of vigem (v1.4.3.X), but presents itself with a higher number (10.X...)

Workaround

HP's ViGEm driver must be disabled and its entry in Windows' registry deleted so only the actual Nefarius' ViGEmBus remains active on the system:

Remember that you can click on the images to expand them

• Open Device Manager by pressing the keys WIN + X and selecting it from the menu

• Click on the View tab at the top and change the view type to Devices by connection

• Look for the HP Omen Driver and expand it, then right-click on the Virtual Gamepad Emulation Bus under it and select Disable device
  

• After confirming the driver is disabled, open the Windows Run tool by pressing WIN + R and executing the regedit command. Windows' registry should then open

• Navigate, carefully, to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceClasses

• When you reach DeviceClasses, right click on it and choose Find. Copy and paste {96e42b22-f5e9-42f8-b043-ed0f932f014f} on the appearing search box and then select Find Next

• The search function should lead you to a folder. Expand it and look for a folder called: SWD\DRIVERENUM{2abac65e-84b2-4dbd-8ab1-2a2894991813}#HPIncVigemBusOmenFusionSoftware&4&14eddee5&0 (Emphazis on the HPIncVigemBUS in the middle of its name)

• Right click on the (...)HPIncVigemBUS(...) entry and then delete it. Be EXTRA CAREFUL so you don't delete the wrong entry
  

Deleting that entry should solve the problem for good, but keep in mind that HP's Virtual Gamepad Emulation Bus must remain disabled on the Device Manager, otherwise it will recreate that entry after every system reboot... like a virus...

Proper solution

Send angry e-mails to HP support to make this issue more relevant until they decide to actually fix it on their side (I'm being serious).

Hello! There are working piece of code, detail reverse engineering report with example how to implement that audio play through dual shock 4 controller

https://translate.google.ru/translate?sl=ru&tl=en&u=https%3A%2F%2Fhabr.com%2Fru%2Fpost%2F302356%2F (translated)

https://habr.com/ru/post/302356/ (original)

Can you please implement that audio device inside ViGem driver or separated driver?