Linux Switch Pro UHID device repeatedly dropped by Steam due to "hid_read failure" #176

Describe the Bug

When Sunshine emulates a Nintendo Switch Pro Controller via libvirtualhid on Fedora Linux, Steam and KDE repeatedly lose and rediscover the controller after a few seconds.

The virtual input device itself does not disappear from the kernel, and evdev input continues working.

Steam logs:

Controller using HIDAPI driver, vid=0x057e, pid=0x2009
Nintendo Controller subtype 3
Controller device closed after hid_read failure
Controller PollState Changed from 2 to 0

"/proc/bus/input/devices" remains unchanged during the disconnect:

N: Name="Sunshine (libvirtualhid) Nintendo Pro Controller"
P: Phys=libvirtualhid/uhid/057e:2009/7
H: Handlers=event28 js1

N: Name="Sunshine (libvirtualhid) Nintendo Pro Controller (IMU)"
P: Phys=libvirtualhid/uhid/057e:2009/7
H: Handlers=event27

"udevadm monitor --kernel --subsystem-match=input" and:

udevadm monitor --kernel --subsystem-match=hidraw

produce no add/remove events while Steam/KDE report the controller disconnecting.

Expected Behavior

The virtual Nintendo Switch Pro Controller should remain continuously available to Steam/KDE for the duration of the Moonlight session, without HIDAPI read failures or repeated disconnect/reconnect cycles.

Additional Context

"evtest /dev/input/event28" continues receiving input immediately even while Steam and KDE consider the controller disconnected.

Example:

Event: type 3 (EV_ABS), code 0 (ABS_X), value 1104
Event: type 3 (EV_ABS), code 1 (ABS_Y), value 4321
-------------- SYN_REPORT ------------

Sunshine logs creation normally:

Gamepad will be Nintendo Switch Pro controller (auto-selected by client-reported type)
Gamepad 0 will be Sunshine (libvirtualhid) Nintendo Pro Controller

Switching Sunshine's emulated controller type from Nintendo Switch Pro to Xbox 360 completely fixes the issue. Steam remains connected and input works normally.