[kwin] [Bug 524427] New: KWin fails to open pointer device of ASUS ROG Omni Receiver after OS reboot, only physical replug recovers it.

https://bugs.kde.org/show_bug.cgi?id=524427

            Bug ID: 524427
           Summary: KWin fails to open pointer device of ASUS ROG Omni
                    Receiver after OS reboot, only physical replug
                    recovers it.
    Classification: Plasma
           Product: kwin
      Version First unspecified
       Reported In:
          Platform: Kubuntu
                OS: Linux
            Status: REPORTED
          Severity: normal
          Priority: NOR
         Component: input
          Assignee: [email protected]
          Reporter: [email protected]
                CC: [email protected]
  Target Milestone: ---

Created attachment 195258
  --> https://bugs.kde.org/attachment.cgi?id=195258&action=edit
restart os mouse events.

KWin/Wayland fails to open the pointer (mouse) input device of a composite USB
HID receiver (ASUS ROG Omni Receiver) at session startup, and never recovers —
even after logical USB re-enumeration or a full Plasma session restart. The
device only recovers after a physical unplug/replug of the USB dongle (a real
bus power cycle), never through any software-level reconnection.

Environment
Distro: Kubuntu 
Distributor ID: Ubuntu
Description:    Ubuntu 26.04 LTS
Release:        26.04
Codename:       resolute
KWin version: kwin 6.6.6
Plasma version: plasmashell 6.6.6
Kernel version: 7.0.0-30-generic
Session type: Wayland
Hardware: ASUS ROG Harpe Ace Aim Lab Edition mouse connected via ASUS ROG Omni
Receiver (USB ID 0b05:1ace)
The receiver exposes multiple HID interfaces (keyboard, mouse/pointer, consumer
control, system control, vendor-specific) under a single composite USB device.
Steps to reproduce
Connect the ASUS ROG Omni Receiver (mouse dongle) to any USB port (tested both
behind an internal hub and directly on a root xHCI port — same result in both
cases).
Boot / reboot the machine into Kubuntu with KDE Plasma (Wayland session).
Observe that keyboard-side interfaces of the receiver usually work, but the
pointer never moves.
Actual result

journalctl --user -b | grep kwin shows, at session startup:

kwin_core: Failed to open /dev/input/event6 device (No such device)
kwin_core: Failed to open /dev/input/event7 device (No such device)   <-- this
is the mouse/pointer interface
kwin_core: Failed to open /dev/input/event8 device (No such device)
kwin_core: Failed to open /dev/input/event10 device (No such device)
kwin_core: Failed to open /dev/input/event12 device (No such device)
kwin_core: Failed to open /dev/input/event13 device (No such device)
kwin_core: Failed to open /dev/input/event14 device (No such device)

A few seconds later, KWin retries and in some boots successfully opens the
non-pointer interfaces (keyboard, consumer control, system control), but the
pointer interface consistently fails to be recovered, and no further retry is
logged for it. In other boots (e.g. after moving the receiver to a different
physical USB port), none of the interfaces recover on retry.

Independent verification shows the underlying HID/kernel/libinput stack is
completely healthy at the time KWin reports failure:

sudo usbhid-dump -m 0b05:1ace -es shows correct, continuous relative-movement
HID reports (X/Y deltas) coming from the mouse interface.
/proc/bus/input/devices correctly lists the pointer device with EV=17, REL=903
(REL_X, REL_Y, REL_WHEEL, REL_WHEEL_HI_RES).
udevadm info -q property -n /dev/input/eventN for that node correctly reports
ID_INPUT=1, ID_INPUT_MOUSE=1.
Standalone sudo libinput debug-events (independent libinput context, not
KWin's) shows correct POINTER_MOTION events in real time while moving the
mouse.

So the kernel, udev, and the generic libinput stack all agree the device is
present, correctly tagged, and delivering motion — the failure is isolated to
KWin's own libinput/udev backend never successfully attaching to this specific
device instance after the initial ENODEV at startup.

What does not fix it

The following were tried, in this exact order, on the already-broken session
(no reboot between attempts unless noted):

Waiting (device fully enumerated well before these attempts; confirmed via
/proc/bus/input/devices, lsusb -t, and dmesg).
sudo udevadm trigger --action=change --subsystem-match=input
--attr-match=idVendor=0b05 — no effect.
sudo udevadm trigger --action=add ... — no effect.
USB driver unbind/bind (/sys/bus/usb/drivers/usb/{unbind,bind}) on the parent
USB device — partial kernel-level re-enumeration (only recreated the keyboard
interface in one test), pointer still not recovered by KWin.
Logical device power toggle via /sys/bus/usb/devices/<dev>/authorized (0 then
1) — this does cause a full, clean kernel-level re-enumeration (fresh HID
instance numbers, fresh /dev/input/eventN nodes, confirmed in dmesg and
/proc/bus/input/devices), but the pointer still does not move, and in this
state journalctl --user -b | grep kwin shows KWin repeatedly failing to open
all interfaces of the device (not just the pointer) for several minutes
afterward.
Logging out and back in (full KWin/Plasma session restart) after the above —
does not recover the device either.
Moving the receiver to a different physical USB port, including a port wired
directly to a root xHCI hub (no intermediate hub) — same failure pattern
reproduced from a clean boot.
Attempting to power-cycle the USB port itself via uhubctl — not possible on
this system; the receiver's upstream hub/port does not support per-port power
switching (ppps), only two unrelated internal ASM107x hubs on this board
support it, and the receiver is not connected through either of them regardless
of which physical port is used.
What does fix it

Physically unplugging and re-plugging the USB receiver (a real VBUS power
cycle) reliably and consistently fixes the pointer every single time it has
been tested. After a physical replug, KWin correctly opens all interfaces
including the pointer, with no further errors in the log.

This strongly suggests the issue is not about whether the kernel device exists
or is correctly enumerated (all forms of logical USB reconnection achieve
that), but something specific to how KWin's libinput/udev connection tracks and
retries a device it initially failed to open with ENODEV — a real bus-level
disconnect/reconnect appears to reset some internal state that a logical
reconnect does not.

Additional notes
The receiver is a composite HID device (ASUS ROG Omni Receiver, USB ID
0b05:1ace) that can take noticeably longer than a typical single-function HID
device to finish enumerating all of its interfaces, likely due to internal RF
pairing/handshake logic with the paired mouse. This may make the startup race
window wider than usual, which could explain why this hasn't been widely
reported for more common single-interface mice.

-- 
You are receiving this mail because:
You are watching all bug changes.