Hello everyone,
I would like to share a problem I encountered on Bazzite KDE/Wayland involving a Logitech G502 HERO, along with the workaround that solved it for me.
Summary
The problem happened when switching users. My system is configured to automatically log into one user after boot. When I selected “Switch User” and tried to log into my own user, the keyboard would sometimes stop accepting normal text input on the Plasma login screen.
The mouse continued working normally, and the Enter key sometimes still worked, but letters and numbers could not be entered into the password field. The password field also appeared to lose or fail to retain keyboard focus.
The problem was intermittent, but it happened much more frequently when the Logitech G502 was connected.
Interestingly, I had experienced a very similar problem previously when I was using Fedora KDE, although it happened much less frequently there.
Environment
- Bazzite KDE
- KDE Plasma
- Wayland
- Plasma Login Manager (
plasmalogin) - Logitech G502 HERO
- Logitech MX Keys keyboard
Reproduction
My setup has automatic login enabled for one user.
The problem can occur with the following sequence:
- Boot or reboot the system.
- Bazzite automatically logs into the default user.
- Select “Switch User”.
- Select the second user.
- The Plasma login screen appears.
- Click the password field.
- The keyboard may not accept normal alphanumeric input.
Symptoms:
- Mouse works normally.
- Enter may still work.
- Letters and numbers cannot be entered.
- The password field does not seem to retain keyboard focus correctly.
- The problem is intermittent, but occurs much more frequently with the G502 connected.
If I disconnect the G502 and repeat the exact same procedure, the problem disappears.
Investigation
The first important clue was that the G502 is exposed by Linux as two separate input devices.
libinput list-devices showed:
Device: Logitech G502 HERO Gaming Mouse
Capabilities: pointer
and also:
Device: Logitech G502 HERO Gaming Mouse Keyboard
Capabilities: keyboard pointer
The G502 keyboard interface was available through:
/dev/input/by-id/usb-Logitech_G502_HERO_Gaming_Mouse_058331673537-if01-event-kbd
Running:
udevadm info -q property -n /dev/input/by-id/usb-Logitech_G502_HERO_Gaming_Mouse_058331673537-if01-event-kbd
showed:
ID_VENDOR=Logitech
ID_VENDOR_ID=046d
ID_MODEL=G502_HERO_Gaming_Mouse
ID_MODEL_ID=c08b
ID_INPUT=1
ID_INPUT_KEY=1
ID_INPUT_KEYBOARD=1
ID_USB_INTERFACE_NUM=01
ID_USB_DRIVER=usbhid
So the G502 was exposing an additional USB HID interface that Linux was treating as a keyboard.
evtest findings
Running:
sudo evtest /dev/input/by-id/usb-Logitech_G502_HERO_Gaming_Mouse_058331673537-if01-event-kbd
showed that the G502 keyboard interface exposes a very large keyboard keymap.
Among the supported keys were:
KEY_A ... KEY_Z
KEY_0 ... KEY_9
KEY_F1 ... KEY_F24
KEY_F23
KEY_F24
as well as many multimedia and other special keys.
This was particularly interesting because the KWin/Wayland logs contained XKB warnings involving F23/F24.
Relevant journal messages
The Wayland/KWin logs contained warnings such as:
The XKEYBOARD keymap compiler (xkbcomp) reports:
Warning: Multiple symbols for level 1/group 1 on key <FK23>
Using F23, ignoring XF86TouchpadOff
Warning: Symbol map for key <FK23> redefined
Warning: Symbol map for key <FK24> redefined
There was also a message from plasma-keyboard:
qtvirtualkeyboard currently is not supported at client-side,
use QT_IM_MODULES=qtvirtualkeyboard at compositor-side.
The Plasma Login Manager also reported:
Auth: plasmalogin-helper exited with 255
However, the 255 occurred after the user authentication/session transition and did not appear to be the direct cause of the keyboard problem.
Important diagnostic test
The most important test was very simple.
I completely disconnected the Logitech G502 and repeated the exact same user-switching procedure.
The problem disappeared completely.
With the G502 disconnected:
- User switching worked normally.
- The password field accepted keyboard input.
- The keyboard did not stop working.
- I could no longer reproduce the problem.
This strongly suggested that the additional HID keyboard interface exposed by the G502 was involved.
Workaround
Instead of disabling the G502 completely, I decided to make libinput ignore only the keyboard interface of the G502 while keeping the actual mouse interface active.
I created:
sudo nano /etc/udev/rules.d/99-g502-ignore-keyboard.rules
with the following rule:
ACTION=="add|change", SUBSYSTEM=="input", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c08b", ENV{ID_INPUT_KEYBOARD}=="1", ENV{LIBINPUT_IGNORE_DEVICE}="1"
Then I reloaded the udev rules:
sudo udevadm control --reload-rules
and triggered them:
sudo udevadm trigger
Then I rebooted:
systemctl reboot
Result
After reboot, I checked the G502 again with:
sudo libinput list-devices | grep -A20 -B3 "G502"
The result showed only:
Device: Logitech G502 HERO Gaming Mouse
Capabilities: pointer
The following device was no longer presented to libinput:
Logitech G502 HERO Gaming Mouse Keyboard
The G502 mouse itself continued to work normally.
Most importantly, the original problem disappeared.
I can now:
- Reboot the computer.
- Allow the automatic login to occur.
- Select Switch User.
- Select my user.
- Enter the password normally.
The keyboard no longer becomes unusable at the Plasma login screen.
The workaround has been reliable on my system so far.
Why I think this is happening
My current theory is that the additional HID keyboard interface of the Logitech G502 is contributing to an XKB/input conflict during the Wayland Plasma login/session transition.
The evidence supporting this theory is:
- The G502 exposes a separate keyboard HID interface.
- That interface exposes F23/F24.
- KWin reports F23/F24 XKB conflicts.
- Disconnecting the G502 eliminates the problem.
- Ignoring only the G502 keyboard interface fixes the problem.
- The actual G502 mouse continues to work normally after the workaround.
I cannot say with certainty whether the root cause is in Bazzite, KDE Plasma, Plasma Login Manager, KWin, XKB, libinput, or the interaction between these components.
However, the workaround consistently solved the problem on my system.
I also experienced the same problem previously on Fedora KDE, although it was much less frequent. This makes me suspect that the issue may not be specific to Bazzite and could potentially affect other Fedora-based distributions using Plasma, Wayland and libinput.
Reverting the workaround
If the workaround needs to be removed, the rule can be deleted with:
sudo rm /etc/udev/rules.d/99-g502-ignore-keyboard.rules
sudo udevadm control --reload-rules
sudo udevadm trigger
systemctl reboot
How to check if you are affected
If you have a Logitech G502 and experience similar symptoms:
- Keyboard input fails on the Plasma login screen.
- Mouse continues working normally.
- The problem happens after switching users.
- The password field appears to lose keyboard focus.
- The problem is intermittent under Wayland.
Check the input devices with:
sudo libinput list-devices
and look for:
Logitech G502 HERO Gaming Mouse
and:
Logitech G502 HERO Gaming Mouse Keyboard
If the second device is present, it may be worth investigating whether it is responsible for the problem.
Conclusion
I wanted to document the complete troubleshooting process because simply replacing or reconnecting the keyboard would not have addressed the actual cause in my case.
The solution was not to disable the Logitech G502 itself, but to prevent its additional HID keyboard interface from being handled by libinput.
The G502 continues to work normally as a mouse, while the Plasma login keyboard problem has been eliminated.
Hopefully this helps anyone else running into the same issue, and perhaps provides useful information for identifying the underlying issue upstream.