varlog/_cache/articles/586c5ab7-e960-465b-b499-83e0209890fe.json

{"uuid":"586c5ab7-e960-465b-b499-83e0209890fe","slug":"quand-alt-ne-repond-plus-anatomie-d-un-bug-clavier-sous-gnome-wayland","title":"Quand Alt ne répond plus : anatomie d'un bug clavier sous GNOME/Wayland","author":"cedric@abonnel.fr","published":true,"published_at":"2026-05-25 07:27","created_at":"2026-05-12 13:35:47","updated_at":"2026-05-12 13:40:34","revisions":[],"cover":"cover.png","files_meta":{"cover.png":{"author":"","source_url":"https://img1.teletype.in/files/87/6b/876beab9-74d8-4c14-bb47-d600639b629f.png"},"af37382560286fe2-6958.svg":{"author":"","source_url":""}},"external_links":[],"seo_title":"","seo_description":"Alt+Tab et Alt+F4 ne répondent plus sous GNOME/Wayland ? Une option xkb peut détourner Alt gauche en AltGr. Diagnostic et correction expliqués.","og_image":"https://varlog.a5l.fr/file?uuid=586c5ab7-e960-465b-b499-83e0209890fe&name=cover.png","category":"informatique","content":"# Quand Alt ne répond plus : anatomie d'un bug clavier sous GNOME/Wayland\n\n*Comment une option de clavier a priori anodine peut désactiver Alt+Tab, Alt+F4 et tous les raccourcis Alt — et comment diagnostiquer ce genre de problème de façon méthodique.*\n\n## Le symptôme\n\nUn beau matin, les raccourcis clavier ne répondent plus. Pas tous : seulement ceux qui utilisent la touche **Alt gauche**.\n\n- `Alt+Tab` ne change plus de fenêtre\n- `Alt+F4` ne ferme plus l'application active\n- Dans un terminal, les raccourcis `Alt+quelque chose` (édition de ligne readline, raccourcis dans une applicaiton, navigation tmux…) restent sans effet\n- La touche **AltGr** (Alt droite), elle, fonctionne toujours : on peut taper `@`, `#`, `~`, les caractères normalement obtenus via Alt droite sur un clavier français azerty\n\nPremier réflexe naturel : « Le clavier est cassé ». Sauf que la touche physique répond bien — elle ne déclenche simplement plus ce qu'on attend d'elle.\n\n## Comprendre ce qui se passe (sans connaître Linux par cœur)\n\nPour saisir le bug, il faut comprendre un détail qu'on ignore généralement : **une touche physique du clavier et la fonction qu'elle déclenche sont deux choses différentes**.\n\nQuand on appuie sur la touche marquée « Alt » à gauche du clavier, le système reçoit d'abord un signal matériel — un code brut, `KEY_LEFTALT` sous Linux. Ce signal est ensuite **traduit** en une fonction logique par une couche logicielle appelée **xkb** (X Keyboard Extension). C'est xkb qui décide que `KEY_LEFTALT` signifie « modificateur Alt gauche » (le fameux `Alt_L`).\n\nMais xkb peut être configuré pour faire autre chose de ce même signal. Et c'est exactement ce qui s'était passé ici. Une option xkb nommée `lv3:lalt_switch` indiquait à la couche de traduction :\n\n> « Quand tu reçois `KEY_LEFTALT`, ne génère pas `Alt_L`. Génère `ISO_Level3_Shift` à la place. »\n\n`ISO_Level3_Shift`, c'est le nom technique de **AltGr** : la touche modificatrice qui permet d'accéder au « troisième niveau » d'une touche (le `@` au-dessus du `à`, le `#` au-dessus du `\"`, etc.). En clair, l'option transformait Alt gauche en un deuxième AltGr.\n\nConséquence : du point de vue des applications, **personne n'appuie jamais sur Alt**. Le gestionnaire de fenêtres (mutter, dans GNOME) attend un événement `Alt_L` qui ne vient jamais ; le terminal attend un préfixe Alt qui ne vient jamais non plus ; AltGr fonctionne toujours parce que c'est lui le « vrai » Level 3 Shift sur azerty, par défaut.\n\nC'est l'analogie d'un interrupteur dont on aurait inversé deux fils dans le mur : l'interrupteur marche, mais il commande une autre lampe.\n\n## La cause exacte\n\nSous GNOME, les options xkb sont stockées dans la base de configuration **dconf**, accessible via la commande `gsettings`. La clé concernée :\n\n```bash\ngsettings get org.gnome.desktop.input-sources xkb-options\n```\n\nSur le système concerné, la commande retournait :\n\n```\n['lv3:lalt_switch']\n```\n\nD'où venait cette option ? Plusieurs hypothèses plausibles :\n\n- Sélectionnée par erreur dans Paramètres → Clavier → Options de disposition lors d'une configuration ancienne\n- Importée depuis une ancienne machine via la synchronisation du profil\n- Activée par un script ou un outil de personnalisation (GNOME Tweaks, dconf-editor)\n- Héritée d'une habitude QWERTY où certains préfèrent un second AltGr à gauche\n\nSur un clavier français azerty, cette option n'a aucun intérêt pratique : AltGr est déjà sur la touche Alt droite, là où l'index droit peut l'atteindre naturellement. Ajouter un second AltGr sur la touche Alt gauche revient à perdre Alt sans gagner quoi que ce soit.\n\n## Le diagnostic, étape par étape\n\nVoici la séquence de commandes pour confirmer le problème — utile à mémoriser parce qu'elle s'applique à tout symptôme similaire sur GNOME/Wayland.\n\n**1. Confirmer l'environnement de session.** Les commandes qui suivent supposent GNOME sous Wayland ; sous X11 ou KDE, le diagnostic diffère.\n\n```bash\necho $XDG_SESSION_TYPE     # attendu : wayland\necho $XDG_CURRENT_DESKTOP  # attendu : GNOME\n```\n\n**2. Inspecter les options xkb.** C'est le test diagnostic principal pour ce genre de panne.\n\n```bash\ngsettings get org.gnome.desktop.input-sources xkb-options\n```\n\nSi la sortie n'est pas `@as []` (liste vide) ou une option clairement intentionnelle, on tient probablement le coupable. Les options les plus susceptibles de casser des raccourcis :\n\n- `lv3:lalt_switch` — transforme Alt gauche en AltGr (le cas présent)\n- `altwin:swap_alt_win` — échange Alt et Super (la touche Windows)\n- `caps:swapescape` — échange Caps Lock et Échap (anodin pour Alt, mais peut surprendre)\n- `ctrl:nocaps`, `ctrl:swapcaps` — transforment Caps Lock en Ctrl\n\n**3. Vérifier que les raccourcis WM sont bien définis.** Cela permet d'éliminer une mauvaise piste : si `Alt+Tab` ne marchait pas parce que le raccourci avait été effacé, ce serait visible ici.\n\n```bash\ngsettings get org.gnome.desktop.wm.keybindings switch-applications\n```\n\nLa sortie attendue est `['<Super>Tab', '<Alt>Tab']` ou équivalent. Si `<Alt>Tab` y figure, le gestionnaire de fenêtres est correctement configuré — la panne est ailleurs.\n\n**4. Vérifier les options d'accessibilité.** Les touches rémanentes (StickyKeys), touches lentes (SlowKeys) ou touches rebonds (BounceKeys) peuvent provoquer des comportements clavier surprenants quand elles sont activées par erreur.\n\n```bash\ngsettings get org.gnome.desktop.a11y.keyboard stickykeys-enable\ngsettings get org.gnome.desktop.a11y.keyboard slowkeys-enable\ngsettings get org.gnome.desktop.a11y.keyboard bouncekeys-enable\n```\n\nToutes les trois doivent normalement renvoyer `false` sauf besoin spécifique.\n\n**5. Tester au niveau matériel si rien d'autre n'explique.** Si toutes les vérifications logicielles sont propres, on vérifie que la touche envoie bien un signal au noyau :\n\n```bash\nsudo evtest\n```\n\nL'outil demande de choisir un périphérique (le clavier), puis affiche en direct chaque événement reçu. En appuyant sur Alt gauche, une ligne contenant `KEY_LEFTALT` doit apparaître. Si rien ne s'affiche, le problème est matériel ou dans le pilote — ce qui sort du cadre de cette fiche.\n\n## La correction\n\nUne seule commande suffit dans le cas présent :\n\n```bash\ngsettings set org.gnome.desktop.input-sources xkb-options \"[]\"\n```\n\nL'effet est **immédiat** : mutter recharge la configuration clavier à la volée, sans qu'on ait besoin de fermer sa session. Si pour une raison ou une autre l'effet ne se voit pas (vieux processus qui a mis en cache la configuration, terminal récalcitrant…), une déconnexion/reconnexion de la session GNOME suffit à tout réinitialiser.\n\nPour vérifier que la valeur est bien revenue à vide :\n\n```bash\ngsettings get org.gnome.desktop.input-sources xkb-options\n# attendu : @as []\n```\n\n## Et si on voulait vraiment garder l'option ?\n\nPour information, la commande inverse est :\n\n```bash\ngsettings set org.gnome.desktop.input-sources xkb-options \"['lv3:lalt_switch']\"\n```\n\nÀ réserver aux cas où l'on tape énormément de caractères de troisième niveau de la main gauche et où on accepte de perdre Alt+Tab.\n\n## La méthode à retenir, au-delà de ce bug précis\n\nL'intérêt de cette fiche n'est pas tant la solution — une ligne de commande — que la **logique de diagnostic**. Quand une touche cesse de fonctionner sous Linux, on remonte la chaîne des responsabilités, du plus haut niveau au plus bas :\n\n1. **Le gestionnaire de fenêtres a-t-il bien le raccourci ?** (`gsettings ... wm.keybindings`)\n2. **Les options d'accessibilité ne brouillent-elles pas la frappe ?** (`gsettings ... a11y.keyboard`)\n3. **La couche xkb traduit-elle correctement la touche en modificateur ?** (`gsettings ... xkb-options`)\n4. **Le noyau reçoit-il un signal matériel quand on appuie ?** (`evtest`)\n\nÀ chaque étage, une commande, une sortie attendue, et un verdict clair. La grande force de Linux dans ce genre de situation, c'est que chaque couche est inspectable séparément. Le réflexe à acquérir n'est pas « ça ne marche pas, je redémarre » mais « ça ne marche pas, je trouve quelle couche ment ».\n\n## Checklist mémo\n\nModificateur (Alt / Super / Ctrl) qui ne répond plus sous GNOME/Wayland :\n\n1. `gsettings get org.gnome.desktop.input-sources xkb-options` — surveiller `lv3:lalt_switch`, `altwin:swap_alt_win`, `caps:*`, `ctrl:*`\n2. `gsettings list-recursively org.gnome.desktop.wm.keybindings | grep -i alt` — confirmer que le raccourci existe\n3. `gsettings get org.gnome.desktop.a11y.keyboard stickykeys-enable` (puis `slowkeys-enable`, `bouncekeys-enable`)\n4. `sudo evtest` → choisir le clavier → presser la touche → doit afficher le bon code (`KEY_LEFTALT`, `KEY_LEFTMETA`, etc.)\n\nQuatre commandes, quatre couches, et 95 % des bugs clavier de session graphique sont localisés.","featured":false,"tags":[]}