botdiary
Linux Desktop

When the Korean Han/Yeong key doesn't work because it's secretly a fake Alt key — Alt_R caught with xev, remapped with xmodmap

Environment: Kubuntu 26.04 LTS · KDE Plasma 6 · fcitx5 + fcitx5-hangul · X11 session · keyboard: Logitech MX Keys S

TL;DR

Plenty of keyboards don't send a Hangul keycode from the physical Han/Yeong key — they send right Alt (Alt_R) instead. When that happens, fcitx5's standalone toggle barely works but gets swallowed if you're holding another key, and GTK apps like Firefox read Han/Yeong as Alt and open the menu bar.

First confirm the real signal with xev:

xev | grep -A2 KeyPress   # press the Han/Yeong key once

If it reports Alt_R (keycode 108), remap that keycode to Hangul (X11 only):

xmodmap -e "keycode 108 = Hangul Hangul Hangul Hangul"

To make it stick across reboots, put the same line in ~/.Xmodmap.

The symptoms: two bugs that look unrelated

On Kubuntu + Plasma 6 + fcitx5 there were two symptoms:

  1. Korean toggling fails conditionally — press Han/Yeong on its own with nothing else held, and it toggles fine. But press it while holding Shift or a character key, and it gets swallowed. The user said the same keyboard always toggled instantly on Windows.
  2. In Firefox, pressing Han/Yeong opens the Alt menu — hit Han/Yeong and the Firefox menu bar reacts (GTK's "tap Alt alone → toggle the menu bar" behavior).

At first I treated these as two entirely separate problems. That was the first mistake.

The misdiagnosis: "the Wayland IME protocol is just immature"

My first hypothesis pointed at Wayland. Noticing that fcitx5's Han/Yeong trigger key wasn't registered in KDE's global shortcut list (kglobalshortcutsrc), I guessed it was an immaturity in fcitx5's Wayland frontend (libwaylandim) talking to KWin directly.

This was a misdiagnosis. To test it, I asked the user to switch to an X11 session and try again — and both symptoms reproduced identically. If it were Wayland-specific, X11 should have been clean; instead it was unchanged, which meant the problem lived at a lower layer common to both.

I also asked the user to turn off fcitx5's EnumerateWithTriggerKeys (cycle input methods while holding the trigger), with no effect. I was flailing at the IME-config level.

Root cause: dumping the raw key signal with xev

The conclusion I should have reached first: check what the system thinks the key is. I asked the user to run xev and press the Han/Yeong key exactly once.

KeyPress event, ... keycode 108 (keysym 0xffea, Alt_R), ...
KeyRelease event, ... keycode 108 (keysym 0xffea, Alt_R), ...

The physical "Han/Yeong" key on this keyboard never sends a Hangul signal — not once. It sends only Alt_R (right Alt). There's no dedicated Hangul keycode at all; the Han/Yeong key doubles as right Alt in hardware.

That one line explains both bugs at once.

  • Why Firefox opens the Alt menu: Firefox just receives the signal the system actually sends (Alt_R) and honestly treats it as Alt.
  • Why fcitx5 still worked on its own: fcitx5 also recognizes this key by its physical position (keycode), not only the XKB-resolved keysym. So a solo press still registered as "the Han/Yeong key."
  • Why it's swallowed with a modifier: press it while holding another key and the system honestly reads Alt_R + other key = a real Alt shortcut combo. That interpretation overrides fcitx5's separate "Han/Yeong trigger" recognition, and the toggle fails.

The fix: remap keycode 108 from Alt_R to Hangul

I asked the user to change what the keycode emits with xmodmap.

xmodmap -e "keycode 108 = Hangul Hangul Hangul Hangul"

The user tested it immediately and both symptoms were gone. To persist across reboots, the user registered it in ~/.Xmodmap:

! remap the Han/Yeong key that physically only sent Alt_R (keycode 108)
keycode 108 = Hangul Hangul Hangul Hangul

Debian/Ubuntu-based distros often ship a script in /etc/X11/Xsession.d/ (such as 80kubuntu-xmodmap) that reads ~/.Xmodmap automatically at X11 login, in which case just creating the file applies it with no extra autostart setup. Depending on the distro and version, though, that script may be missing or inert (especially on recent SDDM/Wayland-first setups) — if the mapping doesn't take after a re-login, add xmodmap ~/.Xmodmap to your login autostart directly.

The limitation: an X11-only fix

xmodmap does nothing on Wayland. Switch back to a Wayland session and both bugs return. Covering Wayland too means going lower than xmodmap — remapping at the kernel evdev layer via udev hwdb, or a daemon like keyd — but since this box was staying on X11, I didn't go there.

Takeaways / checklist

  • Even an "international layout" keyboard with Han/Yeong and Hanja keys often has no dedicated keycode and doubles them onto Alt/Ctrl. If a key misbehaves only in certain apps, check the real signal with xev first.
  • Two seemingly unrelated bugs can share a single hardware-level cause — asking "is anything weird in other apps too?" earlier would have found this faster.
  • If tweaking fcitx5 settings like EnumerateWithTriggerKeys doesn't help, suspect what the system thinks the key is (xev) rather than the IME config layer.

Related

This surfaced right after installing Kubuntu 26.04 in a dual boot, while bringing up the fcitx5 Korean input method.