· Bug: RAATServer USB device scan detaches kernel HID drivers from non-audio devices (mouse, LED controller)
Roon Core Machine RoonBridge 1.8 (build 1125) stable, running on Arch Linux (kernel 6.18.9-zen1-2-zen), AMD Ryzen CPU, 64GB RAM, AMD RX 7900 XTX. This is a desktop machine also used as a daily driver.
Networking Gear & Setup Details Gigabit Ethernet, direct connection to router.
Connected Audio Devices AudioQuest DragonFly Cobalt v1.0 USB DAC (usb-0000:08:00.3-4)
Number of Tracks in Library N/A — this is a RoonBridge endpoint, not the core.
Description of Issue On every boot, RAATServer's USB device scan causes my USB mouse (Logitech G502) and ASUS AURA LED controller to stop working. The mouse cursor disappears and the device becomes non-functional until the HID driver is manually rebound.
Root cause analysis:
RAATServer scans for USB audio devices using libusb. During this scan, it opens USB HID interfaces and calls USBDEVFS_DISCONNECT (equivalent to libusb_detach_kernel_driver()), which detaches the kernel usbhid driver from every HID interface it probes — not just audio devices. When RAATServer finishes probing, it does not call USBDEVFS_CONNECT / libusb_attach_kernel_driver() to reattach the kernel drivers, leaving non-audio HID devices dead.
Devices affected simultaneously at ~20s after boot: - Logitech G502 mouse (046d:c332) — interfaces 1.0 and 1.1 — mouse stops working - AudioQuest DragonFly Cobalt (21b4:0085) — interface 1.2 (HID control) - ASUS AURA LED Controller (0b05:18f3) — interface 1.2 (HID control)
Devices NOT affected: - Das Keyboard (24f0:0140) — on the same USB hub, but its HID interfaces are not claimed
How this was diagnosed:
Step 1: Identify that the USB device is present but the kernel driver is unbound
The mouse lights stay on (USB powered) and lsusb still shows the device, but the HID driver has detached from both interfaces — no driver symlink, no input devices created:
$ ls -la /sys/bus/usb/devices/5-2.1:1.0/driver ls: cannot access '/sys/bus/usb/devices/5-2.1:1.0/driver': No such file or directory
$ ls -la /sys/bus/usb/devices/5-2.1:1.1/driver ls: cannot access '/sys/bus/usb/devices/5-2.1:1.1/driver': No such file or directory
$ ls /dev/input/by-id/ | grep -i logi (no output — input device gone)
$ lsusb | grep Logitech Bus 005 Device 003: ID 046d:c332 Logitech, Inc. G502 Proteus Spectrum Optical Mouse
Step 2: Confirm no USB resets or disconnects in dmesg
The mouse binds successfully at boot (1.9s), then the driver silently disappears with no USB-level event:
$ dmesg | grep -iE '(5-2\.1|046d|G502|usbhid)' [ 1.076605] usbcore: registered new interface driver usbhid [ 1.076606] usbhid: USB HID core driver [ 1.706260] usb 5-2.1: new full-speed USB device number 3 using xhci_hcd [ 1.819615] usb 5-2.1: New USB device found, idVendor=046d, idProduct=c332, bcdDevice= 3.02 [ 1.910726] input: Logitech Gaming Mouse G502 as /devices/.../input/input2 [ 1.910798] hid-generic 0003:046D:C332.0002: input,hidraw1: USB HID v1.11 Mouse [Logitech Gaming Mouse G502] [ 1.917795] input: Logitech Gaming Mouse G502 Keyboard as /devices/.../input/input3 [ 1.968351] hid-generic 0003:046D:C332.0003: input,hiddev97,hidraw2: USB HID v1.11 Keyboard [Logitech Gaming Mouse G502]
$ dmesg | grep -iE '(reset|disconnect)' | grep '5-2' (no output — no USB resets or disconnects)
Step 3: udevadm monitor captures the unbind with DRIVER=usbfs
udevadm monitor shows all three devices unbound at the same instant (~20.2s) by a userspace program via usbfs, not by a kernel event:
Workaround: A systemd service that polls and rebinds the usbhid driver after RAATServer finishes its scan:
[Unit] Description=Rebind HID drivers after RoonBridge USB scan After=roonbridge.service
[Service] Type=oneshot ExecStart=/bin/sh -c 'for attempt in 1 2 3 4 5 6 7 8 9 10; do sleep 3; for iface in /sys/bus/usb/devices/5-2.1:*; do [ -e "$iface/driver" ] || echo "$(basename $iface)" > /sys/bus/usb/drivers/usbhid/bind 2>/dev/null; done; done' RemainAfterExit=yes
[Install] WantedBy=multi-user.target
Suggested fix: RAATServer should either: 1. Call libusb_attach_kernel_driver() after probing each interface it doesn't intend to use 2. Filter by USB audio class (bInterfaceClass=0x01) before claiming interfaces, skipping HID-only devices 3. Use the HIDAPI hidraw backend instead of raw libusb for any HID access, which doesn't detach kernel drivers
**Reference:** The libusb API documentation for [libusb_set_auto_detach_kernel_driver()](https://libusb.sourceforge.io/api-1.0/group__libusb__dev.html) states: "When this is enabled libusb will automatically detach the kernel driver on an interface when claiming the interface, and attach it when releasing the interface." This is disabled by default on new device handles, and RAATServer does not appear to enable it.
Tell us about your home network
· Gigabit Ethernet, direct connection to router.
mjw
(And I'm standing in your doorway And I'm mumbling and I can't remember the last thing that ran through my head)
2
I assume you mean RoonServer since this is your “core”.
This version is no longer maintained, and consequently, will not receive any updates. Therefore, you are advised to switch to the current stable release.
The current version of Roon uses up-to-date .NET Core instead of older Mono binaries.
Have now updated roonbridge (I was stupidly relying on the aur to keep things up to date!) but am still seeing the same issue:-
RoonBridge 2.60 (build 1501) still has the same bug. The evidence:
1. HID device numbers jumped from .0002/.0003 to .0007/.0008 — driver was unbound and rebound by our service at ~21s
2. RAATServer (PID 1274) still links libusb-1.0.so.0.5.0 — same library, same scan behavior
3. RAATServerhas/proc/asound/card0/usbid open — actively using the USB audio device
4. NoUSBdisconnectindmesg — same silent usbfs detach pattern as before
The Roon update changed the version from 1.8 (build 1125) to 2.60 (build 1501) but did not fix the libusb_detach_kernel_driver() / missing libusb_attach_kernel_driver() issue.
=== RoonBridge version ===
206001501
2.60 (build 1501) production
production
=== RoonBridge process tree ===
root 982 1 0 08:36 ? 00:00:00 /bin/sh /opt/RoonBridge/start.sh
root 999 982 0 08:36 ? 00:00:00 RoonBridge --debug --gc=sgen --server RoonBridge.exe
root 1155 999 0 08:36 ? 00:00:00 RoonBridgeHelper --debug --gc=sgen --server RoonBridgeHelper.exe
root 1166 999 0 08:36 ? 00:00:00 /opt/RoonBridge/Bridge/processreaper 1155
root 1274 999 0 08:37 ? 00:00:00 RAATServer --debug --gc=sgen --server RAATServer.exe
=== HID timeline (shows bind/unbind/rebind sequence) ===
\[ 0.768704\] usbcore: registered new interface driver usbfs
\[ 1.075467\] usbcore: registered new interface driver usbhid
\[ 1.075468\] usbhid: USB HID core driver
\[ 1.708282\] usb 5-2.1: new full-speed USB device number 3 using xhci_hcd
\[ 1.822885\] usb 5-2.1: New USB device found, idVendor=046d, idProduct=c332, bcdDevice= 3.02
\[ 1.822888\] usb 5-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
\[ 1.822890\] usb 5-2.1: Product: Gaming Mouse G502
\[ 1.822891\] usb 5-2.1: Manufacturer: Logitech
\[ 1.822893\] usb 5-2.1: SerialNumber: 1360385F3038
\[ 1.908996\] input: Logitech Gaming Mouse G502 as /devices/pci0000:00/0000:00:08.1/0000:0f:00.3/usb5/5-2/5-2.1/5-2.1:1.0/0003:046D:C332.0002/input/input2
\[ 1.909058\] hid-generic 0003:046D:C332.0002: input,hidraw1: USB HID v1.11 Mouse \[Logitech Gaming Mouse G502\] on usb-0000:0f:00.3-2.1/input0
\[ 1.916167\] input: Logitech Gaming Mouse G502 Keyboard as /devices/pci0000:00/0000:00:08.1/0000:0f:00.3/usb5/5-2/5-2.1/5-2.1:1.1/0003:046D:C332.0003/input/input3
\[ 1.966363\] hid-generic 0003:046D:C332.0003: input,hiddev97,hidraw2: USB HID v1.11 Keyboard \[Logitech Gaming Mouse G502\] on usb-0000:0f:00.3-2.1/input1
\[ 20.999048\] input: Logitech Gaming Mouse G502 as /devices/pci0000:00/0000:00:08.1/0000:0f:00.3/usb5/5-2/5-2.1/5-2.1:1.0/0003:046D:C332.0007/input/input22
\[ 20.999168\] hid-generic 0003:046D:C332.0007: input,hidraw0: USB HID v1.11 Mouse \[Logitech Gaming Mouse G502\] on usb-0000:0f:00.3-2.1/input0
\[ 21.006093\] input: Logitech Gaming Mouse G502 Keyboard as /devices/pci0000:00/0000:00:08.1/0000:0f:00.3/usb5/5-2/5-2.1/5-2.1:1.1/0003:046D:C332.0008/input/input23
\[ 21.057459\] hid-generic 0003:046D:C332.0008: input,hiddev96,hidraw1: USB HID v1.11 Keyboard \[Logitech Gaming Mouse G502\] on usb-0000:0f:00.3-2.1/input1
=== g502-hid-bind service status ===
● g502-hid-bind.service - Rebind HID drivers after RoonBridge USB scan
Loaded: loaded (/etc/systemd/system/g502-hid-bind.service; enabled; preset: disabled)
Active: active (exited) since Mon 2026-02-16 08:37:30 CET; 3min 46s ago
Invocation: f192fc4ebec24fd3983f874ef2d138f5
Process: 983 ExecStart=/bin/sh -c for attempt in 1 2 3 4 5 6 7 8 9 10; do sleep 3; for iface in /sys/bus/usb/devices/5-2.1:\*; do \[ -e "$iface/driver" \] || echo "$(basename $iface)" > /sys/bus/usb/drivers/usbhid/bind 2>/dev/null; don
e; done (code=exited, status=0/SUCCESS)
Main PID: 983 (code=exited, status=0/SUCCESS)
Mem peak: 1.7M
CPU: 18ms
Feb 16 08:37:00 solitair-linux systemd\[1\]: Starting Rebind HID drivers after RoonBridge USB scan...
Feb 16 08:37:30 solitair-linux systemd\[1\]: Finished Rebind HID drivers after RoonBridge USB scan.
=== Current driver state ===
/sys/bus/usb/devices/5-2.1:1.0: ../../../../../../../../bus/usb/drivers/usbhid
/sys/bus/usb/devices/5-2.1:1.1: ../../../../../../../../bus/usb/drivers/usbhid
=== Does RAATServer still link libusb? ===
RAATServer PID: 1274
lr-------- 1 root root 64 Feb 16 08:41 7fb426003000-7fb426007000 -> /usr/lib/libusb-1.0.so.0.5.0
lr-------- 1 root root 64 Feb 16 08:41 7fb426007000-7fb426017000 -> /usr/lib/libusb-1.0.so.0.5.0
lr-------- 1 root root 64 Feb 16 08:41 7fb426017000-7fb42601f000 -> /usr/lib/libusb-1.0.so.0.5.0
lr-------- 1 root root 64 Feb 16 08:41 7fb42601f000-7fb426020000 -> /usr/lib/libusb-1.0.so.0.5.0
lr-------- 1 root root 64 Feb 16 08:41 7fb426020000-7fb426021000 -> /usr/lib/libusb-1.0.so.0.5.0
7fb426003000-7fb426007000 r--p 00000000 00:21 13776959 /usr/lib/libusb-1.0.so.0.5.0
7fb426007000-7fb426017000 r-xp 00004000 00:21 13776959 /usr/lib/libusb-1.0.so.0.5.0
7fb426017000-7fb42601f000 r--p 00014000 00:21 13776959 /usr/lib/libusb-1.0.so.0.5.0
7fb42601f000-7fb426020000 r--p 0001c000 00:21 13776959 /usr/lib/libusb-1.0.so.0.5.0
7fb426020000-7fb426021000 rw-p 0001d000 00:21 13776959 /usr/lib/libusb-1.0.so.0.5.0
=== Does RAATServer have any USB device files open? ===
/proc/asound/card0/usbid
mjw
(And I'm standing in your doorway And I'm mumbling and I can't remember the last thing that ran through my head)
6
I can’t reproduce this since I don’t run Arch. However, I do run Ropieee, whixh is Arxh-based, and this doesn’t happen.
Indeed, I can’t imagine Roon Bridge detaching kernel drivers.
Let’s see want Roon has to say. You could also post in Tinkering as some Arch users hand out there.
Thanks for that @Andrew_Prevett! No updates yet - your ticket is still in the queue.
If your thread closes before our team has a chance to review your case, please know we’ll immediately re-open it and ping you directly when there is new information or updates to share.
Thanks for the detailed report and the thorough investigation.
Here’s where we stand: our findings are technically consistent for this setup, but we’re considering this an edge case at this time due in the absence of broader user reports.
USB interface claiming and kernel driver binding behavior can vary significantly across kernels, libusb versions, and udev configurations. The system you described here is a desktop installation running a non-LTS, performance-tuned (zen) kernel,with composite HID devices. This stands out from the majority of Roon users who rely on a minimal, endpoint-style RoonBridge setup without any non-audio devices.
We’re by no means closing this report, but our QA team has an open investigation and we will share updates here.
No problem, I thought that would probably be the case. I have a usable workaround so it doesn’t impact me much anymore.
Mostly thought it could be useful for you in case there were other usb problems reported. it was mainly just an annoyance having to unplug and reconnect my mouse every time I logged in and I had some time to kill while stuff was building so investigated with the above results!
