Dear ASUS: Why Did You Turn My Right Ctrl into a Puzzle?

On my ASUS ExpertBook B3404CVA running Kubuntu 24.04 (KDE Plasma 5.27.11, X11, Kernel 6.8.0-52-generic), I set the usual keyboard layout switcher via:

/etc/default/keyboard:
XKBLAYOUT="us,ru"
XKBOPTIONS="grp:menu_toggle"

Normally I set up layout switching through the standard graphical interface in Kubuntu — never had to think twice. But on this machine, it simply didn’t work. I had to fall back on this method. And even then, it works only intermittently:

• sometimes with the Fn key,
• sometimes without,
• and there's no clear logic when or why.

🚨 Symptoms

• Layout switching works... sometimes
• Sometimes requires holding Fn to work
• Sometimes doesn’t work at all
• After suspend/resume — it starts working again
• After reboot — might stop again
• In short: totally inconsistent

And here's the kicker:

• If I reboot, I can switch layout with a single press of the Right Ctrl/Menu key.
• If the system was suspended and resumed, now I can only switch layouts by holding Fn + that same key.

Thanks, engineer from Masus.

🔍 My Investigation

1. Dug through xev, evtest, setxkbmap, xmodmap, libinput debug-events
2. Discovered that this key:
   • Without Fn: emits Super_L
   • With Fn: emits ISO_Next_Group
   • Sometimes: emits nothing
3. Checked BIOS: no useful Fn key control (just Fn Lock Option, irrelevant)
4. Disabled fcitx5, tried .xprofile, systemd hooks, layout toggles
5. Tested grp:menu_toggle, grp:rctrl_toggle, grp:win_toggle
6. Sometimes it worked, then stopped, then resumed after suspend
7. Eventually wrote a systemd sleep hook that reapplies layout settings post-suspend

⏳ Time Spent

~10 hours over 4 days. I’m a developer. I know what I'm doing. If I struggled this much — imagine a non-tech-savvy user.

🙏 A Message to ASUS Engineers

Dear ASUS engineers,

Thanks for the light laptop, good build quality, and battery life. But please explain:

• Why did you replace Right Ctrl with Super_L?
• Why does the key's behavior depend on Fn state?
• Why is there no BIOS/UEFI or EC override?

You spent your time, budget, and engineering effort to remove a standard key and made it inconsistent, undocumented, and non-overridable.

Please, just let users decide what the key does — especially when it's part of years of muscle memory.

📊 TL;DR

I hacked around it. I use a setxkbmap call from a systemd hook after suspend. It sort of works.

But it’s not stable. It still changes behavior after suspend. Fn sometimes required, sometimes not.

I didn’t fix it — I just learned to live with it. For now. I’ll be back to dig deeper into this absurd situation, but at the moment I simply ran out of time. The story isn’t over yet.