Mouse not correctly recognized during boot

seth · 2026-05-23 12:30:57

https://github.com/openrazer/openrazer/issues/2049 doesn't sound wayland specific?
On wayland, does the mouse produce input events in "sudo evtest" or "sudo libinput debug-events"?

IUser · 2026-05-23 14:30:56

https://github.com/openrazer/openrazer/issues/2049 doesn't sound wayland specific?

It's unclear what login manager they used. Maybe they used Plasma login that used Wayland underneath and mouse was bugged in this step so after logging into Plasma (x11) session mouse was already bugged and didn't recover there. Maybe I'm missing something.

[On wayland, does the mouse produce input events in "sudo evtest" or "sudo libinput debug-events"?

1 Logged into Plasma Wayland session
2 Mouse is not responsive
3 Entered "sudo evtest" that showed a couple of mouse related results:

...
/dev/input/event19: ASUSTeK ROG HARPE ACE AIM LAB EDITION
/dev/input/event20: ASUSTeK ROG HARPE ACE AIM LAB EDITION Consumer Control
/dev/input/event21: ASUSTeK ROG HARPE ACE AIM LAB EDITION System Control
/dev/input/event22: ASUSTeK ROG HARPE ACE AIM LAB EDITION
/dev/input/event23: ASUSTeK ROG HARPE ACE AIM LAB EDITION Keyboard
...

This mouse has a few additional configurable buttons. It could be normal that it for example detects mouse "Keyboard" because these buttons can be configured to simulate keybaord.

4 after trying different events I found that when event "19" is selected, console reacts (prints) to mouse moves, scroll and clicks (only console reacts, mouse wasn't replugged and cursor doesn't move and in bugged state).

So it seems WiFi dongle and mouse is recognized, communicate and work correctly underneath after boot but something on top that should read mouse events is bugged and only starts to work when mouse is replugged after boot.

Last edited by IUser (2026-05-23 19:21:47)

seth · 2026-05-23 21:03:54

The next layer would be libinput - if that also records the events, the wayland compositor is dropping the ball.
Maybe it's purely visual?
Does exporting KWIN_FORCE_SW_CURSOR=1 (to kwin_wayland) help anything?

IUser · 2026-05-24 10:10:09

Plasma (Wayland) session.
After entering "sudo libinput debug-events" console reacts to mouse moves, scrolls and clicks while cursor is bugged and stays in place (similar situation as with "sudo evtest").

KWIN_FORCE_SW_CURSOR=1 didn't help.

KDE https://userbase.kde.org/System_Settings "System Settings" -> "Mouse & Touchpad" -> "Mouse" -> "Device" lists this mouse name only after mouse is replugged

Also noticed:
1 Log into GNOME session
2 Replug the mosue to make it work
3 Log out to SDDM (x11) login
4 Login into Plasma (Wayland)
5 Mouse works without replug here

So replugging mouse in one Wayland based session makes it work in another session if PC is not rebooted.
If mouse is bugged in Plasma (Wayland) it will be bugged in GNOME after switching session without reboot. And if mouse works correctly in Plasma (Wayland) this state is also transferred to another session if PC not rebooted. Mouse state is transferred between Wayland based sessions or something like that.

Last edited by IUser (2026-05-24 10:31:44)

seth · 2026-05-24 13:33:32

After entering "sudo libinput debug-events" console reacts to mouse moves, scrolls and clicks while cursor is bugged and stays in place (similar situation as with "sudo evtest").

Are there any errors in the journal eg. about pointer jumps being ignored etc?

IUser · 2026-05-24 17:23:50

Still investigating journal more closely. Don't want to post the whole journal here. There could be something that shouldn't be public.

Earlier I posted partial result of "sudo evtest" that mentioned 5 mouse related events like "/dev/input/event19: ..."
now I recognized those 5 devices/events in journal and spotted a few related warnings after boot:

.. kwin_wayland[1214]: Failed to open /dev/input/event19 device (No such device)
.. kwin_wayland[1214]: Failed to open /dev/input/event20 device (No such device)
.. kwin_wayland[1214]: Failed to open /dev/input/event21 device (No such device)
.. kwin_wayland[1214]: Failed to open /dev/input/event22 device (No such device)
.. kwin_wayland[1214]: Failed to open /dev/input/event23 device (No such device)

why there "No such device" when evtest and libinput debug-events can read mouse events like moves and clicks and print them to console?

Also there is something strange with mouse serial number.

Mouse connected using cable:
1 mouse works properly and doesn't require replug after login
2 Journal shows mouse serial number
3 dmesg shows mouse serial number
4 replugging the mouse (just to see new log)
5 Journal shows mouse serial number
6 dmesg shows mouse serial number
// nothing strange here

Mouse connected using bluetooth:
// steps and result similar to above..no issues

Mouse connected using WiFi dongle:
1 mouse doesn't work properly after login and requires replug
2 journal doesn't contain an entry with mouse serial number, but all remaining mouse related entries seems to be there.
3 dmesg shows mouse serial number entry but serial number is longer and has some additional symbols after serial number that weren't present when mouse was connected with cable or bluetooth. To make it more strange these appended additional symbols aren't stable and can be different after reboot. This boot one of the appended symbols looks like "\" and "-" combined into one symbol. I tried to copy this symbol here but after copying it just looks like "\" without "-". This symbol is not something mouse vendor will use in serial number. Or maybe it's 2 symbols printed in the same place?
// to see how mouse serial number looks after boot and how it looks (with appended symbols) after mouse replug see first post where another user had similar issue and provided dmesg output.
4 repluging the mouse to make it work
5 journal shows proper (not extended) serial number
6 dmesg shows proper (not extended) serial number
// why entry with mouse serial number is not present after boot in journal and only after replug? why dmesg shows serial number after boot but it's longer? Was there silent crash/abort when trying to read serial number or trying to log it in journal? Or maybe there is code duplication where different but similar code is run in similar situations and no issues here (except changing appended simbols)...

Last edited by IUser (2026-05-24 17:37:18)

seth · 2026-05-24 19:00:45

There could be something that shouldn't be public.

The journal should™ not contain sensitive information - sometimes publically routable IPv6 show up and sudo gets audited, ie. every sudo command is logged.

why there "No such device" when evtest and libinput debug-events can read mouse events

getfacl /dev/input/event19

IUser · 2026-05-24 21:17:33

getfacl /dev/input/event19

# file: dev/input/event19
# owner: root
# group: input
user::rw-
group::rw-
other::---

GNOME shows similar errors as Plasma (Wayland):

... gnome-shell[1274]: Could not open device /dev/input/event19: GDBus.Error:System.Error.ENODEV: No such device
... gnome-shell[1274]: Could not open device /dev/input/event20: GDBus.Error:System.Error.ENODEV: No such device
... gnome-shell[1274]: Could not open device /dev/input/event21: GDBus.Error:System.Error.ENODEV: No such device
... gnome-shell[1274]: Could not open device /dev/input/event22: GDBus.Error:System.Error.ENODEV: No such device
... gnome-shell[1274]: Could not open device /dev/input/event23: GDBus.Error:System.Error.ENODEV: No such device

IUser · 2026-05-24 21:32:05

Under Plasma (X11) session where mouse works properly journal doesn't contain something like " ... kwin_x11 Failed to open /dev/input/event..." errors.

seth · 2026-05-25 06:39:21

The access permissions are "normal" but does it help to add yourself to the input group?

IUser · 2026-05-25 11:55:36

The access permissions are "normal" but does it help to add yourself to the input group?

1 entered:

sudo usermod -a -G input username           // instead of "username"  specified current username

2 rechecked that current user is related with input group:

id username

3 rebooted
4 still issues with the mouse and kwin_wayland /dev/input/event errors are still there

seth · 2026-05-25 12:06:03

Please post your complete system journal for the boot:

sudo journalctl -b | curl -s -H "Accept: application/json, */*" --upload-file - 'https://paste.c-net.org/'

IUser · 2026-05-25 16:22:01

Please post your complete system journal for the boot:

I switched to KDE unstable channel a while ago to see if it helps with some issues including mouse issue and installed excessive amount of packages. Journal contains more info than it should. I'll do a clean install with GNOME as default to see if it helps and to determine if it's Plasma Wayland issue (that somehow transferred to GNOME installed on top of it)
And I still unsure about posting full journal log. It contains IP, MAC, specter vulnerability info, WiFi info, serial numbers and probably more arguably sensitive info.
I appreciate your attempts to help. After OS reinstall I'll return with the result.

Last edited by IUser (2026-05-25 16:26:49)

seth · 2026-05-25 20:33:15

It contains IP, MAC, specter vulnerability info, WiFi info, serial numbers and probably more arguably sensitive info.

* https://en.wikipedia.org/wiki/Private_network
* MACs are trackable (it you post them in various places one can link those posts) but radio devices yell them into the environment and they're otherwise worthless out of geographic range
* Most modern CPUs are vulnerable to spectre - what do you expect anyone to do with this information when not running local code where they can query that information from the cpu anyway?
* radio devices yell them into the environment and they're otherwise worthless out of geographic range
* Partition UUIDs are locally generated for collision prevention, they hold no further information

You can essentially not prevent fingerprinting from the journal (the combination of hard and software will largely do that, no special number required) and you don't have to post the journal but I can't tell what's going on based upon vague descriptions and I cannot ask you for direct information w/o any idea what's going on with the system.

IUser · Yesterday 20:32:01

It seems it's systemd and serial number related issue and the fix is coming https://github.com/systemd/systemd/issues/41296

After upgrading to systemd v259.4 (v258.7 on Fedora), the keyboard is non-functional at boot. KWin fails to open all input event nodes (event2–event7) with ENODEV. Replugging the USB dongle usually restores functionality. Downgrading to systemd v259.3 / v258.0 fixes the issue without any replug.
Root cause probably identified by source comparison between v259.3 and v259.4: property_is_valid() was added to device_add_property_aux() in src/libsystemd/sd-device/sd-device.c.
It returns -EINVAL for property values containing non-UTF8 or control characters. The ROG Azoth dongle reports a garbage/non-UTF8 serial string in its USB descriptor at initial 2.4 GHz wireless boot enumeration. This causes the sd_device object to be left in an incomplete state, which propagates to logind's TakeDevice failing with ENODEV for the associated input event nodes.
After a replug the dongle reports a clean ASCII serial (N9MPGDD12884) — all properties pass validation and the device works correctly.

Last edited by IUser (Yesterday 20:54:13)

IUser · Yesterday 20:43:45

systemd v261 should include this fix.

// OS reinstall with GNOME as default didn't solve the issue

Last edited by IUser (Yesterday 20:54:22)

seth · Yesterday 21:19:26

- SDDM login + GNOME sesion + mutter // mouse works only in SDDM login

seth wrote:

You can essentially not prevent fingerprinting from the journal (the combination of hard and software will largely do that, no special number required) and you don't have to post the journal but I can't tell what's going on based upon vague descriptions and I cannot ask you for direct information w/o any idea what's going on with the system.

IUser · Today 10:58:48

According to the bug report mentioned above, the issue appeared in systemd v259.4

After downgrading systemd packages to older version the mouse started to work after boot without replug in Plasma (Wayland).
If they implemented the fix properly the issue should be resolved in v261.

Thanks for the help and sorry for not providing the full log.
This report probably can be marked as resolved or maybe it's better to wait 261 release.

Last edited by IUser (Today 11:02:28)

Arch Linux

#26 2026-05-23 12:30:57

Re: Mouse not correctly recognized during boot

#27 2026-05-23 14:30:56

Re: Mouse not correctly recognized during boot

#28 2026-05-23 21:03:54

Re: Mouse not correctly recognized during boot

#29 2026-05-24 10:10:09

Re: Mouse not correctly recognized during boot

#30 2026-05-24 13:33:32

Re: Mouse not correctly recognized during boot

#31 2026-05-24 17:23:50

Re: Mouse not correctly recognized during boot

#32 2026-05-24 19:00:45

Re: Mouse not correctly recognized during boot

#33 2026-05-24 21:17:33

Re: Mouse not correctly recognized during boot

#34 2026-05-24 21:32:05

Re: Mouse not correctly recognized during boot

#35 2026-05-25 06:39:21

Re: Mouse not correctly recognized during boot

#36 2026-05-25 11:55:36

Re: Mouse not correctly recognized during boot

#37 2026-05-25 12:06:03

Re: Mouse not correctly recognized during boot

#38 2026-05-25 16:22:01

Re: Mouse not correctly recognized during boot

#39 2026-05-25 20:33:15

Re: Mouse not correctly recognized during boot

#40 Yesterday 20:32:01

Re: Mouse not correctly recognized during boot

#41 Yesterday 20:43:45

Re: Mouse not correctly recognized during boot

#42 Yesterday 21:19:26

Re: Mouse not correctly recognized during boot

#43 Today 10:58:48

Re: Mouse not correctly recognized during boot

Board footer