New: ASUSTeK ROG OMNI RECEIVER (0b05:1ace) handshake timeout and power management failure on AMD B850 / Ryzen 9000

https://bugzilla.kernel.org/show_bug.cgi?id=221954

            Bug ID: 221954
           Summary: ASUSTeK ROG OMNI RECEIVER (0b05:1ace) handshake
                    timeout and power management failure on AMD B850 /
                    Ryzen 9000
           Product: Drivers
           Version: 2.5
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P3
         Component: USB
          Assignee: [email protected]
          Reporter: [email protected]
        Regression: No

Hello,

I am reporting a persistent hardware initialization issue with the ASUS ROG Keris Wireless Aimpoint gaming mouse, utilizing the ASUSTeK ROG OMNI RECEIVER (USB ID 0b05:1ace) on a modern AMD AM5 platform under Arch Linux (Kernel 6.x, KDE Plasma 6).

[Problem Description]
When booting the system from a cold start, the wireless receiver is detected by the kernel during the early boot phase but fails to process any pointer movements or clicks once the desktop environment loads. The mouse remains completely unresponsive until a physical hotplug is performed (unplugging and replugging the USB dongle forces the port to wake up).

There are two distinct trigger scenarios for this platform:

1. CPU-bound USB 3.2 Ports (Ryzen 9700X):
The kernel initializes the USB stack too aggressively. The internal ARM controller inside the ROG Omni Receiver requires a few hundred milliseconds to perform its internal self-test and establish a radio sync with the mouse. Because it doesn't respond instantly to the initial host handshake, the kernel cuts power to the port/hub via aggressive runtime autosuspend.

2. Chipset-bound USB 2.0 Ports (B850) and MediaTek MT7927 Conflict:
Initially, when using USB 2.0 ports, the mouse initialization collided with the onboarding of the MediaTek MT7927 (Wi-Fi 7 / Bluetooth 5.4) module. The Bluetooth firmware loading routine threw 'Failed to load firmware file (-2)' errors and triggered a 'A stop job is running for Rule-based Manager' systemd hang, during which the shared internal USB hub was hard-reset, dropping the mouse HID handshake entirely.

Even after completely disabling the Bluetooth Controller in UEFI (which resolved the systemd hang), the mouse still fails to wake up on boot in any port due to the aggressive runtime power management of the USB stack.

[Workaround]
The issue is currently resolved locally by implementing a custom udev rule that forces the port to stay powered and listen for wakeup events:
ACTION=="add|change", SUBSYSTEM=="usb", ATTRS{idVendor}=="0b05", ATTRS{idProduct}=="1ace", ATTR{power/control}="on", ATTR{power/wakeup}="enabled"

[Requested Action]
Please consider adding the ASUSTeK ROG OMNI RECEIVER (0b05:1ace) to the global USB quirks list (drivers/usb/core/quirks.c) to prevent runtime autosuspend during early boot stages and ensure backward compatibility on newer AMD platforms out-of-the-box.

Hardware Environment:
- CPU: AMD Ryzen 7 9700X
- Motherboard: ASUS ROG STRIX B850-E GAMING WIFI (Chipset B850, Bluetooth disabled in UEFI)
- OS: Arch Linux (Rolling, up-to-date)

[Technical Logs and Device Dumps]

1. lsusb output:
Bus 008 Device 006: ID 0b05:1ace ASUSTek Computer, Inc. ROG OMNI RECEIVER

2. Boot journal logs (journalctl -b 0):
kernel: usb 8-12: New USB device found, idVendor=0b05, idProduct=1ace,
bcdDevice= 6.25
kernel: input: ASUSTeK ROG OMNI RECEIVER Keyboard as /devices/pci0000:00/0000:00:02.1/0000:04:00.0/0000:05:0c.0/0000:0c:00.0/usb8/8-12/8-12:1.0/0003:0B05:1ACE.0006/input/input9
kernel: hid-generic 0003:0B05:1ACE.0006: input,hidraw5: USB HID v1.11 Keyboard
[ASUSTeK ROG OMNI RECEIVER] on usb-0000:0c:00.0-12/input0
kernel: input: ASUSTeK ROG OMNI RECEIVER as /devices/pci0000:00/0000:00:02.1/0000:04:00.0/0000:05:0c.0/0000:0c:00.0/usb8/8-12/8-12:1.1/0003:0B05:1ACE.0007/input/input10
kernel: hid-generic 0003:0B05:1ACE.0007: input,hidraw6: USB HID v1.11 Mouse
[ASUSTeK ROG OMNI RECEIVER] on usb-0000:0c:00.0-12/input1

3. udevadm info -a -p /sys/bus/usb/devices/8-12:
looking at device
'/devices/pci0000:00/0000:00:02.1/0000:04:00.0/0000:05:0c.0/0000:0c:00.0/usb8/8-12':

    KERNEL=="8-12"
    SUBSYSTEM=="usb"
    DRIVER=="usb"
    ATTR{authorized}=="1"
    ATTR{avoid_reset_quirk}=="0"
    ATTR{bConfigurationValue}=="1"
    ATTR{bDeviceClass}=="00"
    ATTR{bDeviceProtocol}=="00"
    ATTR{bDeviceSubClass}=="00"
    ATTR{bMaxPacketSize0}=="64"
    ATTR{bMaxPower}=="500mA"
    ATTR{bNumConfigurations}=="1"
    ATTR{bNumInterfaces}==" 4"
    ATTR{bcdDevice}=="0625"
    ATTR{bmAttributes}=="e0"
    ATTR{busnum}=="8"
    ATTR{configuration}=="Default configuration"
    ATTR{devnum}=="6"
    ATTR{devpath}=="12"
    ATTR{idProduct}=="1ace"
    ATTR{idVendor}=="0b05"
    ATTR{manufacturer}=="ASUSTeK"
    ATTR{power/autosuspend}=="2"
    ATTR{power/control}=="on"
    ATTR{power/runtime_status}=="active"
    ATTR{power/wakeup}=="enabled"

4. /sys/bus/usb/devices/8-12/uevent:
MAJOR=189
MINOR=901
DEVNAME=bus/usb/008/006
DEVTYPE=usb_device
DRIVER=usb
PRODUCT=b05/1ace/625
TYPE=0/0/0
BUSNUM=008
DEVNUM=006

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=221954

Lovekesh Solanki ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #1 from Lovekesh Solanki ([email protected]) --- I think the this isn't a kernel bug but a systemd regression,
https://github.com/systemd/systemd/issues/41296, which seems to have been fixed. Could you see if their fix resolves or issue.

many reports seems to have been made on this bug on different places.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.