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

Dug through xev, evtest, setxkbmap, xmodmap, libinput debug-events
Discovered that this key:
- Without Fn: emits Super_L
- With Fn: emits ISO_Next_Group
- Sometimes: emits nothing
Checked BIOS: no useful Fn key control (just Fn Lock Option, irrelevant)
Disabled fcitx5, tried .xprofile, systemd hooks, layout toggles
Tested grp:menu_toggle, grp:rctrl_toggle, grp:win_toggle
Sometimes it worked, then stopped, then resumed after suspend
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.

Originally published: Dear ASUS: Why Did You Turn My Right Ctrl into a Puzzle? — Alex Rezvov's Blog

推荐订阅源