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"?

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.

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)

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)

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

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)

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

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

1 entered:

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

 
2 rechecked that current user is related with input group:

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

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/'

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)

* 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.

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

Last edited by IUser (2026-05-31 20:54:13)

systemd v261 should include this fix.

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

Last edited by IUser (2026-05-31 20:54:22)

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 (2026-06-01 11:02:28)