Game: Tainted Grail: The Fall of Avalon (AppID 1466060) Proton version: Proton Experimental (build 1783957914, experimental-11.0-20260713) Controller: Sony DualSense Edge Wireless Controller (VID 054c, PID 0df2)
Symptom:
When the DualSense Edge is connected over USB, neither rumble nor adaptive
triggers work in-game. When the exact same controller is connected over Bluetooth instead (same Proton version, same game, same session), both
work correctly.
This doesn't seem to be game-specific, but I'm unsure.
What I ruled out before concluding this is a Proton/USB-path issue:
Hardware/kernel: confirmed fully functional independent of Steam - both dualsensectl trigger right feedback 0 8 (adaptive trigger resistance) and
a raw python-evdevFF_RUMBLE effect sent directly to /dev/input/eventX produced physical feedback over USB
USB autosuspend: disabled (power/control = on, runtime_suspended_time = 0).
udev rules: standard steam-devices package rules, hidraw permissions
correct (uaccess tag present, device readable/writable by the user).
Reboot + full Steam restart: no change.
Wine registry Enable SDL / DisableHidraw toggles: no change either way.
windows.gaming.input DLL override (to force the game off that backend):
no change.
Fresh Wine prefix (deleted and let Steam recreate it from scratch): no
change.
Over USB, the device enumerates cleanly and is treated as a plain hidraw
gamepad with no special handling:
00b0:trace:hid:hidraw_device_create dev ..., node "/dev/hidraw12", desc {vid 054c, pid 0df2, version 0100, input 3, uid 00000000, is_gamepad 0, is_hidraw 1, bus_type 1}.
00ac:trace:plugplay:get_device_instance_id Returning ID L"USB\\VID_054C&PID_0DF2&MI_03\\256&44:46:48:47:ff:8b&0&0&0".
00c4:trace:hid:sdl_add_device controller id 0, axis_offset 0, desc {vid 054c, pid 0df2, version 0100, input -1, uid 00000000, is_gamepad 1, is_hidraw 0, bus_type 0}.
Over Bluetooth (working), Wine additionally applies and later clears a
report-format quirk specific to Bluetooth DualSense (see dlls/winebus.sys/bus_udev.c, QUIRK_DUALSENSE_BT):
00b0:trace:hid:bus_create_hid_device Enabling report fixup for Bluetooth DualSense device 0000000000EC1390
...
00a8:trace:hid:hidraw_disable_report_fixups Disabling report fixup for Bluetooth DualSense device 0000000000EC1390
No equivalent quirk/negotiation path exists for USB, which is expected -
but whatever makes the Bluetooth path reach full working state clearly
isn't happening for USB, despite USB otherwise being the better-supported,
lower-latency transport for this exact family of controller.
Full raw logs available (WINEDEBUG=+hid,+plugplay, one full session each):
Game: Tainted Grail: The Fall of Avalon (AppID 1466060)
Proton version: Proton Experimental (build 1783957914,
experimental-11.0-20260713)Controller: Sony DualSense Edge Wireless Controller (VID
054c, PID0df2)Symptom:
When the DualSense Edge is connected over USB, neither rumble nor adaptive
triggers work in-game. When the exact same controller is connected over
Bluetooth instead (same Proton version, same game, same session), both
work correctly.
This doesn't seem to be game-specific, but I'm unsure.
What I ruled out before concluding this is a Proton/USB-path issue:
dualsensectl trigger right feedback 0 8(adaptive trigger resistance) anda raw
python-evdevFF_RUMBLEeffect sent directly to/dev/input/eventXproduced physical feedback over USBpower/control=on,runtime_suspended_time= 0).steam-devicespackage rules, hidraw permissionscorrect (
uaccesstag present, device readable/writable by the user).Enable SDL/DisableHidrawtoggles: no change either way.windows.gaming.inputDLL override (to force the game off that backend):no change.
change.
Log evidence (
WINEDEBUG=+hid,+plugplay PROTON_LOG=1):Over USB, the device enumerates cleanly and is treated as a plain hidraw
gamepad with no special handling:
Over Bluetooth (working), Wine additionally applies and later clears a
report-format quirk specific to Bluetooth DualSense (see
dlls/winebus.sys/bus_udev.c,QUIRK_DUALSENSE_BT):No equivalent quirk/negotiation path exists for USB, which is expected -
but whatever makes the Bluetooth path reach full working state clearly
isn't happening for USB, despite USB otherwise being the better-supported,
lower-latency transport for this exact family of controller.
Full raw logs available (
WINEDEBUG=+hid,+plugplay, one full session each):runA_bluetooth_stock-proton.logrunC_usb_stock-proton.logHappy to gather more targeted output (e.g. tracing the actual output/feature
report writes for rumble/trigger commands specifically) if useful.
runA_bluetooth_stock-proton.filtered.log
runA_bluetooth_stock-proton.log
runC_usb_stock-proton.filtered.log
(raw runC logs are too big to attach)