protonscr

Flydigi Vader 4 Pro not correctly recognized after reconnect

steamopen Distro Family: FedoraGeneral controller / Steam Input
ValveSoftware/steam-for-linux#13358 · opened 2026-06-29 by TacticalBill · updated 2026-08-08 · 3 comments · github
TTacticalBill 2026-06-29 github

Your system information

Please describe your issue in as much detail as possible:

Steam fails to correctly initialize a Flydigi Vader 4 Pro controller when using the official USB dongle unless the controller is already connected before Steam starts.

Once the controller disconnects or is powered off, Steam never properly reinitializes it until Steam is restarted.

This seems to have started at the beginning of June '26. It had been working fine until the recent updates to accommodate the Steam Controller Puck.

Steps for reproducing this issue:

  1. Exit Steam fully
  2. Wirelessly connect controller using the dongle
  3. Start Steam
  4. Verify everything works.
  5. Turn the controller off
  6. Turn the controller back on.
  7. Verify that its recognized as a generic controller

Expected

Steam reconnects to the controller with full Vader 4 Pro functionality every time

Actual

Steam detects the controller but it no longer functions correctly until Steam is completely restarted.

I observed that Steam finds the controller on hidraw16 when it is working, but does not use hidraw16 at all upon reconnects.

Working:
troy@bazzite:/var/home/troy$ sudo lsof -p $(pidof steam) | grep hidraw
[sudo] password for troy:
lsof: WARNING: can't stat() fuse.portal file system /run/user/1000/doc
Output information may be incomplete.
steam 53008 troy 90u CHR 241,16 0t0 2972 /dev/hidraw16
steam 53008 troy 99u CHR 241,0 0t0 218 /dev/hidraw0
steam 53008 troy 101u CHR 241,1 0t0 223 /dev/hidraw1
steam 53008 troy 102u CHR 241,2 0t0 228 /dev/hidraw2
steam 53008 troy 103u CHR 241,3 0t0 234 /dev/hidraw3
steam 53008 troy 104u CHR 241,4 0t0 236 /dev/hidraw4

Not Working, upon reconnect:
troy@bazzite:/var/home/troy$ sudo lsof -p $(pidof steam) | grep hidraw
lsof: WARNING: can't stat() fuse.portal file system /run/user/1000/doc
Output information may be incomplete.
steam 53008 troy 99u CHR 241,0 0t0 218 /dev/hidraw0
steam 53008 troy 101u CHR 241,1 0t0 223 /dev/hidraw1
steam 53008 troy 102u CHR 241,2 0t0 228 /dev/hidraw2
steam 53008 troy 103u CHR 241,3 0t0 234 /dev/hidraw3
steam 53008 troy 104u CHR 241,4 0t0 236 /dev/hidraw4

I do have the latest udev rules in place from the Steam Device github.

TTacticalBill 2026-06-30 github

I just tested on the Beta branch, same issue.
Steam Beta Branch: Steam Deck Beta
Steam Version: 1782779912

TTacticalBill 2026-07-09 github

I found that I can unbind and rebind the controller's interface 2, while it's still connected, to restore the correct functionality and remove the incorrect generic controller. This removes the need to restart Steam.


#!/bin/bash

echo "3-1:1.2" > /sys/bus/usb/drivers/usbhid/unbind


sleep 1

echo "3-1:1.2" > /sys/bus/usb/drivers/usbhid/bind

echo "3-1:1.0" > /sys/bus/usb/drivers/usbhid/unbind
PPbryanw 2026-08-08 github

@TaticalBill - Hi, I'm not sure if this is related, but I recently started having issues with my Vadar 4 Pro joypad on Fedora 44. In my case, an extra controller was being created each time the Vadar 4 Pro was connected to Steam.

This extra controller had an /dev/input/event* address, and was being displayed as a mouse in KDE's "Mouse & Touchpad" settings. Despite disabling it in "Mouse & Touchpad", it was still picked up by Steam. What fixed it for me was creating a file in /etc/udev/rules.d (I called mine 99-vadar4pro-evdev-disable.rules), with this content:

# /etc/udev/rules.d/99-vadar4pro-evdev-disable.rules
KERNEL=="event[0-9]*", ATTRS{id/vendor}=="04b4", ATTRS{id/product}=="2412", RUN+="/bin/rm -f /dev/input/%k"

Then sudo udevadm control --reload-rules afterwards to reload the udev configuration. I actually got this from the unix.stackexchange.com website. So far, it's working for me, but I'm aware this could be a different issue to the one you're experiencing on Bazzite?

Nothing extracted yet.