AltGr als „Deutsch-Turbo“: Wenn Wayland jahrzehntealte Tastatur-Workflows bricht (und wie man sie sauber repariert)

Wer viel programmiert, optimiert nicht nur Editor, Shell und Toolchain, sondern auch die kleineren Dinge, die sich über den Tag hinweg zu echten Produktivitätshebeln aufsummieren: Tastaturbelegung, Modifikatortasten, Muscle Memory. Der Klassiker: US-Layout fürs Programmieren, weil Klammern, Semikolons und Co. dort liegen, wo man sie erwartet – und Umlaute nur gelegentlich, aber dann bitte ohne „Layout wechseln → tippen → zurück wechseln“.

Das war bei mir über viele Jahre „einfach gelöst“: Unter X11 habe ich in GNOME Tweaks die Option „Taste zum Wechseln in die dritte Tastaturebene“ auf Right Alt gelegt. Ergebnis: US-Layout als Basis, und wenn ich Umlaute brauche, halte ich AltGr (Right Alt) gedrückt und tippe auf den „deutschen“ Tasten äöüß. Seit (gefühlt) 30 Jahren läuft das so. Dann kam der Umstieg auf Wayland – und die Lösung war plötzlich weg.

Aktuelle Situation

• Manjaro + GNOME
• Wechsel von X11 auf Wayland
• Gewohnter Workflow: US-Layout + „Right Alt aktiviert die dritte Ebene“ → Umlaute ohne Layoutwechsel

Nach dem Wechsel: „Es fühlt sich an, als würde AltGr manchmal funktionieren, manchmal nicht“. Und genau dieses „manchmal“ ist das Perfide.

Symptome (aka: Warum xev mich erstmal in die Irre geführt hat)

Der erste Reflex ist unter X11 jahrzehntelang konditioniert: xev starten, Taste drücken, schauen was ankommt.

• In xev sah alles gut aus: Alt + Umlauttaste lieferte äöüß.
• In „echten Programmen“ (Terminal, Editor, Browser, …) kamen aber die US-Zeichen an, z.B. statt äöüß eher sowas wie ‚ ‚; [ –.

Der entscheidende Punkt: xev ist ein X11-Debug-Tool. Es zeigt, was ein X-Server an Events liefert. (manpages.debian.org)
Unter GNOME/Wayland bedeutet das praktisch: xev läuft (typischerweise) als X11-Client via XWayland – und XWayland ist ein eigener X-Server, der als Proxy auf Wayland sitzt. (wiki.gnome.org)

Kurz: xev kann dir unter Wayland eine Realität zeigen, die für native Wayland/GTK-Anwendungen nicht maßgeblich ist.

Takeaway: Unter Wayland ist xev nicht „falsch“, aber es misst unter Umständen den falschen Stack.

Was sich unter Wayland ändert (ohne Religionskrieg)

Unter X11 war die Welt oft: X-Server + XKB-Konfiguration → alle Clients sehen dasselbe.

Unter Wayland ist es eher: Compositor (Mutter) + libxkbcommon/XKB → native Clients bekommen Keymap direkt; X11-Clients hängen an XWayland als zusätzlicher Ebene. (wiki.gnome.org)

Das erklärt die Beobachtung „xev zeigt Umlaute, aber Apps nicht“: Du hast zwei Schichten, die zwar ähnlich klingen, aber nicht zwingend identisch konfiguriert sind.

Wenn man wirklich sehen will, was Wayland-native Programme bekommen, ist ein Wayland-Eventviewer sinnvoller (statt xev). Für Wayland gibt es mit wev ein Pendant zu xev. (phoronix.com)

Ziel

Ich wollte wieder exakt das Nutzererlebnis von X11:

• US fürs Programmieren (Default)
• Umlaute/ß ohne Layoutwechsel, idealerweise „AltGr halten → Taste drücken“
• Stabil in allen Anwendungen (Wayland-native und XWayland)

Und dann sind wir – Schritt für Schritt – durch die Optionen gelaufen.

Der Lösungsweg (so wie wir ihn gemeinsam gegangen sind)

Schritt 1: „US (intl., with AltGr dead keys)“ – dritter Level ist da, aber es ist nicht „Deutsch“

Der erste pragmatische Versuch war: Statt plain us das Layout

English (intl., with AltGr dead keys)

Das ist us+altgr-intl. Damit kommt man sauber in die 3. Ebene (AltGr/Level3). Ergebnis: Ja, die dritte Ebene existiert wieder zuverlässig.

Aber: Das ist eben immer noch US international, nicht „deutsche Buchstaben per AltGr auf den gewohnten Tasten“. Dead Keys sind nett, aber nicht der Workflow, den ich seit Jahrzehnten nutze.

Schritt 2: „Dann schalte ich doch mit Right Alt einfach kurz aufs deutsche Layout“ (theoretisch hübsch, praktisch tricky)

Die Idee war sauber: Nicht „3. Ebene“, sondern Layout-Gruppe wechseln, solange Right Alt gedrückt ist.

In XKB sind das zwei unterschiedliche Konzepte:

• 3rd level chooser (lv3:…) = zusätzliche Ebene innerhalb eines Layouts
• Group switching (grp:…) = Umschalten zwischen Layouts/Gruppen

Die Optionen dafür sind in xkeyboard-config dokumentiert, u.a. explizit:

• grp:switch = Right Alt (while pressed)
• lv3:menu_switch etc. (man.freebsd.org)

Also haben wir in GNOME per gsettings geschaut, was gesetzt ist. GNOME verwaltet XKB-Optionen zentral über org.gnome.desktop.input-sources.xkb-options. (help.gnome.org)

Bei dir sah das so aus (gekürzt auf das Wesentliche):

gsettings get org.gnome.desktop.input-sources xkb-options
# ['grp_led:scroll', 'compose:caps', 'grp:switch', 'lv3:menu_switch']

gsettings get org.gnome.desktop.input-sources sources
# [('xkb', 'us+altgr-intl'), ('xkb', 'de')]

Das liest sich erstmal plausibel: Default us+altgr-intl, zweite Quelle de, Right Alt hält kurz die zweite Gruppe (grp:switch).

Warum kam trotzdem kein Umlaut?

Weil du damit Right Alt doppelt belegst:

• In us+altgr-intl ist Right Alt funktional bereits AltGr/Level3.
• Gleichzeitig willst du Right Alt als Group Switch benutzen.

Damit konkurrieren zwei Bedeutungen derselben Taste. Auf dem Papier „geht irgendwie beides“, in der Praxis ist es häufig ein Garant für uneinheitliches Verhalten – insbesondere, wenn ein Teil der Anwendungen über XWayland läuft und ein Teil nativ über Wayland/GTK.

Das war der Punkt, an dem die Lösung „schön gedacht“ war, aber nicht robust.

Schritt 3: Die eigentliche Lösung – „Deutsch (US)“ statt „US + Tricks“

Der Durchbruch war, nicht länger zu versuchen, zwei Welten (US-Layout + deutsches Layout + temporärer Wechsel) über Modifikatorkunst zusammenzubinden, sondern eine XKB-Variante zu nehmen, die genau dafür gebaut ist:

German (US, with German letters)
aka: Deutsch (US)
XKB: de(us)

Das ist konzeptionell elegant: Es ist im Kern das US-Layout und ergänzt gezielt deutsche Zeichen. In der XKB-Definition ist das sogar explizit als „US include + Name German (US, with German letters)“ nachvollziehbar. (Unix & Linux Stack Exchange)

Praktischer Effekt:

• Du bleibst im US-Layout (Programmieren ohne Schmerz)
• Du bekommst Umlaute/ß über AltGr-Kombinationen (ohne Layoutwechsel)
• Und: Du vermeidest die fragile „Right Alt ist gleichzeitig AltGr und Group-Switch“-Kollision.

In GNOME taucht das Layout je nach Distribution nicht unter „German“ auf, sondern manchmal unter „German, Swedish and Finnish (US)“ oder ähnlich – je nachdem, wie die Eingabequellen gruppiert sind. (Der entscheidende Marker ist „German (US, with German letters)“ bzw. „Deutsch (US)“.)

Damit war das Problem erledigt – und zwar so, dass es auch unter Wayland stabil bleibt.

Verifikation (damit man nicht wieder auf xev reinfällt)

Wenn du unter Wayland testen willst, ob die Belegung wirklich in nativen Clients ankommt, nutze lieber einen Wayland-Eventviewer wie wev. (phoronix.com)

xev bleibt nützlich – aber eben als Diagnose für XWayland/X11-Clients. (manpages.debian.org)

Lessons Learned

1. Wayland ist nicht „X11 mit anderem Namen“ – Eingabe läuft über andere Schichten, und XWayland ist eine zusätzliche Abstraktionsebene. (wiki.gnome.org)
2. xev misst X11-Events. Unter Wayland misst du damit oft XWayland – nicht zwingend das, was native Apps sehen. (manpages.debian.org)
3. XKB-Optionen sind präzise, aber gnadenlos: lv3:* (3rd level) ist etwas anderes als grp:* (Gruppenwechsel). (man.freebsd.org)
4. Für den konkreten Use Case „US + schnell Umlaute“ ist de(us) / „Deutsch (US)“ in GNOME meist die robusteste Lösung, weil sie ohne „temporäres Layoutdrücken“ auskommt. (Unix & Linux Stack Exchange)

Und ganz am Ende ist das wie bei Pfadabhängigkeiten in der Ökonomie: Wenn ein Workflow 30 Jahre Rendite liefert, dann sind die Umstellungskosten real – und man sollte die neue Technologie so konfigurieren, dass sie den Workflow stützt, nicht umgekehrt.