Steam and Chromium rumble gaps for PlayStation and Switch Pro virtual gamepads

[ReenigneArcher]

Environment

• Host OS: Windows and Linux
• Virtual controller provider: libvirtualhid through Sunshine
• Affected profiles: DualShock 4, DualSense, Nintendo Switch Pro
• Consumers: Steam controller tester and Chromium Gamepad API
• Comparison consumer: SDL/HIDAPI

Observed behavior

• Steam identifies the affected virtual controllers through HIDAPI, but its controller tester does not produce a libvirtualhid output callback for DualShock 4, DualSense, or Switch Pro.
• Chrome can rumble the virtual DualShock 4 and Switch Pro on Windows.
• Chromium does not expose a vibration actuator for DualSense on Windows.
• Switch Pro is not recognized by the Chromium Gamepad API on the tested Linux system.

libvirtualhid validation

The native libvirtualhid output path is working for the affected profiles:

• On Windows, SDL3's native HIDAPI drivers can open virtual DualShock 4, DualSense, and Switch Pro controllers through the installed VHF driver. SDL rumble reaches the public GamepadOutput callback for all three profiles.
• Native Windows tests verify the PlayStation feature-report handshake and output-report routing.
• Linux consumer tests cover SDL and direct HID output for the native PlayStation profiles.

This exercises real consumer and installed-driver/kernel paths rather than only calling the report parser with synthetic packets. No missing libvirtualhid descriptor, feature reply, output route, or accepted rumble packet shape has been demonstrated.

Steam investigation

Steam recognizes and opens the controllers, but the tested controller-rumble action does not send an output report for libvirtualhid to parse. A similar current report exists for a physical DualSense on Linux, where Steam does not dispatch a write or force-feedback operation:

• [Steam Input][Linux] DualSense rumble is never dispatched by Steam, while kernel fftest works ValveSoftware/steam-for-linux#13435

This is separate from Chromium's DualSense behavior.

Chromium DualSense investigation

On Windows, Chromium currently enables IgnorePS5GamepadsInWgi by default and excludes DualSense and DualSense Edge from its Windows Gaming Input fetcher:

• https://chromium.googlesource.com/chromium/src/+/main/device/gamepad/public/cpp/gamepad_features.cc
• https://chromium.googlesource.com/chromium/src/+/HEAD/device/gamepad/wgi_data_fetcher_win.cc

The controller then uses Chromium's Raw Input path. That path exposes vibration only for its dedicated DualShock 4 handler and a small HID-haptics allowlist; it has no DualSense haptic handler:

• https://chromium.googlesource.com/chromium/src/+/HEAD/device/gamepad/raw_input_gamepad_device_win.cc
• https://chromium.googlesource.com/chromium/src.git/+/refs/heads/main/device/gamepad/hid_haptic_gamepad.cc

Therefore Chromium reports no Gamepad API vibration actuator before it can send an output report to libvirtualhid. This selection is based on the real Sony VID/PID and affects physical DualSense controllers as well as faithful virtual ones. Chromium documents --disable-features=IgnorePS5GamepadsInWgi as a diagnostic override:

• https://chromium.googlesource.com/chromium/src/+/a4054d433c09517226f790d62590ab7f402c08fc

Changing libvirtualhid's VID/PID to evade Chromium's filter would stop the profile from faithfully identifying as a DualSense and is not an appropriate workaround.

Remaining work

• Track the Steam behavior upstream and retest when Steam begins dispatching an output operation for these controllers.
• Track or report Chromium's missing Raw Input DualSense haptics/fetcher-selection behavior upstream.
• If a consumer produces an output report that reaches libvirtualhid but is not normalized, capture that exact report and add parser/backend regression coverage.

Based on the current evidence, the remaining failures are consumer-side compatibility gaps rather than a demonstrated libvirtualhid output-path defect.