When Keybindings Fight Each Other: A GNOME “Hyper” Gotcha

If you heavily customize your keyboard shortcuts, you’ll eventually hit this: one mapping silently breaks another.

It took me years to get my setup where I wanted it. My daily stack looks like this:

• GNOME
• Terminal (urxvt)
• tmux
• vim

That’s multiple layers, each with its own shortcuts, buffers, and behaviors — all stacked on top of each other. Copy/paste alone can come from different sources (vim, tmux, system clipboard, browser), and you need to stay in control of which layer you’re interacting with.

Everything works — until it doesn’t.

The Problem

At some point, I mapped my Super (Win) key to Hyper.

In GNOME, this lives here:

/org/gnome/desktop/input-sources/xkb-options

My setting looked like this:

['ctrl:nocaps', 'altwin:hyper_win']

This used to work fine. GNOME even allowed shortcuts like:

Hyper + S

But in newer GNOME versions (around 48), this breaks.

Symptom:

• Pressing shortcuts involving that key → nothing happens
• GNOME simply ignores the Hyper modifier

The Cause

GNOME no longer properly recognizes Hyper as a usable modifier for shortcuts.

So if you remap your Super key to Hyper, you effectively lose it as a shortcut key in GNOME.

The Fix

Remove the Hyper mapping and go back to default Super behavior:

gsettings set org.gnome.desktop.input-sources xkb-options "['ctrl:nocaps']"

The Fallout

This is the annoying part:

• All shortcuts previously defined as Hyper+... are now broken
• GNOME will recreate them as Super+... instead
• You have to remap them manually

Takeaway

Hyper might look like a clean “extra modifier” on paper — but in modern GNOME, it’s effectively dead.

If you rely on GNOME-level shortcuts:

• Stick with Super
• Avoid Hyper unless you fully control the entire input stack

Otherwise, you’ll end up debugging “why nothing happens” again in a few years.