Skip to content

Instantly share code, notes, and snippets.

@danielrosehill
Created November 27, 2025 13:28
Show Gist options
  • Select an option

  • Save danielrosehill/c2968c31f04c0019de923edc3d9e63a9 to your computer and use it in GitHub Desktop.

Select an option

Save danielrosehill/c2968c31f04c0019de923edc3d9e63a9 to your computer and use it in GitHub Desktop.
F13 Key Not Recognized on KDE Wayland - Troubleshooting and Fix Attempt

F13 Key Not Recognized on KDE Plasma (Wayland) - Troubleshooting Notes

Problem

F13 key (sent via input-remapper from a macropad) was not being recognized by KDE for keyboard shortcuts, while F14-F18 worked fine.

Environment

  • OS: Ubuntu 25.04
  • Desktop: KDE Plasma on Wayland
  • Input Device: CH57x-based 6-button macropad (VID:1189 PID:8890)
  • Remapping Tool: input-remapper

Diagnosis

Layer 1: Kernel/evdev

The key was correctly being sent as KEY_F13 (keycode 183) at the evdev level. Verified with evtest.

Layer 2: XKB Symbols

The issue was in /usr/share/X11/xkb/symbols/inet where extended F-keys are remapped:

key <FK13>   {      [ XF86Tools         ]       };   # F13 → XF86Tools (PROBLEM)
key <FK14>   {      [ XF86Launch5       ]       };   # F14 → XF86Launch5 (works)
key <FK15>   {      [ XF86Launch6       ]       };   # F15 → XF86Launch6 (works)
key <FK16>   {      [ XF86Launch7       ]       };   # F16 → XF86Launch7 (works)
key <FK17>   {      [ XF86Launch8       ]       };   # F17 → XF86Launch8 (works)
key <FK18>   {      [ XF86Launch9       ]       };   # F18 → XF86Launch9 (works)

Root Cause: F13 was mapped to XF86Tools, which KDE either doesn't recognize as a bindable shortcut key or is consumed elsewhere. F14-F18 map to XF86Launch* keys which KDE handles as generic bindable keys.

Attempted Fix

1. Cleaned up legacy udev rules (not the cause)

Removed old macropad udev rules that weren't affecting key mapping:

sudo rm /etc/udev/rules.d/99-macropad.rules
sudo rm /etc/udev/rules.d/99-ch57x-macropad.rules
sudo udevadm control --reload-rules && sudo udevadm trigger

2. Attempted user-level XKB override (didn't work on Wayland)

Created ~/.config/xkb/symbols/custom:

partial alphanumeric_keys
xkb_symbols "fkeys" {
    key <FK13> { [ F13 ] };
    // ... F14-F24
};

And ~/.config/xkb/rules/evdev:

! option = symbols
  custom:fkeys = +custom(fkeys)

! include %S/evdev

Added to ~/.config/kxkbrc:

Options=grp:alt_shift_toggle,custom:fkeys

This approach did not work - the custom XKB option wasn't being loaded by KDE Wayland.

3. Direct system XKB modification (pending session restart)

Modified /usr/share/X11/xkb/symbols/inet line 193:

Before:

key <FK13>   {      [ XF86Tools         ]       };

After:

key <FK13>   {      [ F13               ]       };

Backup created at /usr/share/X11/xkb/symbols/inet.backup

Next Steps

  1. Log out and back in to fully reload XKB symbols (KWin reconfigure alone may not be sufficient)
  2. Test if F13 is now recognized in KDE shortcut settings
  3. If it works, consider whether to also remap F14-F18 to actual F-keys instead of XF86Launch*

Notes

  • The system XKB modification will be overwritten on xkb-data package updates
  • A more permanent solution would be to get the user-level XKB config working, or create a system-level override in /etc/xkb/
  • Alternatively, input-remapper could be configured to send XF86Launch5 instead of KEY_F13 as a workaround

Generated by Claude Code. Please verify this information against your specific system configuration.

Comments are disabled for this gist.