· 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.
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
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!
· I’m having the same issue as this support request:
I can’t see how to contact you other than this the general contact form (I didn’t want to open another support request). I do however want to point out that it wasn’t just that user with the issue. I also have a different mouse, the bequiet! sym. I’m using opensuse tumbleweed with the stock kernel. It’s the same issue otherwise. It took weeks to figure out for me, but once the roonserver.service starts, it detaches my mouse and doesn’t reattach it. I edited the service file to add the following command to fix it for now;
ExecStartPost=/usr/bin/bash -c '/usr/bin/sleep 15; for d in /sys/bus/usb/devices/*/; do if [ -f "$${d}idVendor" ] && [ "$(/usr/bin/cat $${d}idVendor)" = "373f" ]; then for i in $${d}*:*; do if [ -d "$$i" ]; then echo -n "$(/usr/bin/basename $$i)" > /sys/bus/usb/drivers/usbhid/bind 2>/dev/null; fi; done; fi; done'
I’m sorry if this ends up adding a new topic, as I just wanted to add that I’m experiencing the same issue on a different setup, but that topic is locked, otherwise I would have replied there. My solution does the same thing as the other user, but with a one line addition to the service file.
I never would have considered using the flag for anything other than reporting malicious content, so that is good to know.
I looked at the docker recommendation. When I used the configuration tool to generate paths, passing through usb audio seems like it will cause the exact same problem, no? I see these device mappings on the config:
devices:
16
- /dev/snd:/dev/snd
17
- /dev/bus/usb:/dev/bus/usb
It looks like Roon will still scan the host usb devices, just with extra steps.
RoonBridge 2.60.1501 on Linux detaches kernel drivers from non-audio USB devices, breaking my Logitech G203 Prodigy Gaming Mouse (046d:c084).
RoonBridge’s USB device enumeration code uses raw usbfs access to probe USB devices. When run as root (as the AUR package defaults to), it detaches the usbhid kernel driver from non-audio USB devices such as mice, probes them, then releases the interface without reattaching the kernel driver. This causes the affected devices to stop functioning entirely until physically unplugged and replugged.
Steps to Reproduce
Have a USB mouse and one or more USB audio devices connected
Mouse does not recover when RoonBridge is stopped; a physical unplug/replug is required
Root Cause
I traced RoonBridge via strace -fe ioctl and udevadm monitor --kernel --property. During startup, RoonBridge’s native code (libraatmanager.so) performs raw USB device enumeration via usbfs (/dev/bus/usb/). For each USB device it encounters — including non-audio HID devices — it performs the following sequence:
USBDEVFS_GET_CAPABILITIES → query device
USBDEVFS_SUBMITURB / REAPURBNDELAY → send control transfers to probe the device
USBDEVFS_GETDRIVER → check which kernel driver is bound (returns "usbhid")
USBDEVFS_IOCTL → detach the kernel driver
USBDEVFS_CLAIMINTERFACE → claim the USB interface for userspace
USBDEVFS_SUBMITURB → probe further
USBDEVFS_RELEASEINTERFACE → release the interface
→ (no USBDEVFS_CONNECT to reattach the kernel driver)
The udevadm monitor output confirms the unbind, showing DRIVER=usbfs as the driver at the point of removal — meaning RoonBridge had already replaced usbhid with its own usbfs claim before releasing the interface.
The issue: after USBDEVFS_RELEASEINTERFACE, no USBDEVFS_CONNECT ioctl is issued to reattach the original kernel driver. If this code were using libusb with LIBUSB_AUTO_DETACH_KERNEL_DRIVER (or libusb_set_auto_detach_kernel_driver()), the driver would be automatically reattached on release. Instead, the USBDEVFS_IOCTL disconnect is never reversed.
Workaround
The workaround I’ve found is to run RoonBridge as a dedicated non-root user with audio group membership. This prevents the usbfs driver-detach ioctl from succeeding while preserving full ALSA access.
