Folio
8.7 KiB
Quand Alt ne répond plus : anatomie d'un bug clavier sous GNOME/Wayland
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.
Le symptôme
Un beau matin, les raccourcis clavier ne répondent plus. Pas tous : seulement ceux qui utilisent la touche Alt gauche.
Alt+Tabne change plus de fenêtreAlt+F4ne ferme plus l'application active- Dans un terminal, les raccourcis
Alt+quelque chose(édition de ligne readline, raccourcis dans une applicaiton, navigation tmux…) restent sans effet - 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
Premier 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.
Comprendre ce qui se passe (sans connaître Linux par cœur)
Pour 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.
Quand 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).
Mais 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 :
« Quand tu reçois
KEY_LEFTALT, ne génère pasAlt_L. GénèreISO_Level3_Shiftà la place. »
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.
Consé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.
C'est l'analogie d'un interrupteur dont on aurait inversé deux fils dans le mur : l'interrupteur marche, mais il commande une autre lampe.
La cause exacte
Sous GNOME, les options xkb sont stockées dans la base de configuration dconf, accessible via la commande gsettings. La clé concernée :
gsettings get org.gnome.desktop.input-sources xkb-options
Sur le système concerné, la commande retournait :
['lv3:lalt_switch']
D'où venait cette option ? Plusieurs hypothèses plausibles :
- Sélectionnée par erreur dans Paramètres → Clavier → Options de disposition lors d'une configuration ancienne
- Importée depuis une ancienne machine via la synchronisation du profil
- Activée par un script ou un outil de personnalisation (GNOME Tweaks, dconf-editor)
- Héritée d'une habitude QWERTY où certains préfèrent un second AltGr à gauche
Sur 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.
Le diagnostic, étape par étape
Voici 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.
1. Confirmer l'environnement de session. Les commandes qui suivent supposent GNOME sous Wayland ; sous X11 ou KDE, le diagnostic diffère.
echo $XDG_SESSION_TYPE # attendu : wayland
echo $XDG_CURRENT_DESKTOP # attendu : GNOME
2. Inspecter les options xkb. C'est le test diagnostic principal pour ce genre de panne.
gsettings get org.gnome.desktop.input-sources xkb-options
Si 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 :
lv3:lalt_switch— transforme Alt gauche en AltGr (le cas présent)altwin:swap_alt_win— échange Alt et Super (la touche Windows)caps:swapescape— échange Caps Lock et Échap (anodin pour Alt, mais peut surprendre)ctrl:nocaps,ctrl:swapcaps— transforment Caps Lock en Ctrl
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.
gsettings get org.gnome.desktop.wm.keybindings switch-applications
La 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.
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.
gsettings get org.gnome.desktop.a11y.keyboard stickykeys-enable
gsettings get org.gnome.desktop.a11y.keyboard slowkeys-enable
gsettings get org.gnome.desktop.a11y.keyboard bouncekeys-enable
Toutes les trois doivent normalement renvoyer false sauf besoin spécifique.
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 :
sudo evtest
L'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.
La correction
Une seule commande suffit dans le cas présent :
gsettings set org.gnome.desktop.input-sources xkb-options "[]"
L'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.
Pour vérifier que la valeur est bien revenue à vide :
gsettings get org.gnome.desktop.input-sources xkb-options
# attendu : @as []
Et si on voulait vraiment garder l'option ?
Pour information, la commande inverse est :
gsettings set org.gnome.desktop.input-sources xkb-options "['lv3:lalt_switch']"
À 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.
La méthode à retenir, au-delà de ce bug précis
L'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 :
- Le gestionnaire de fenêtres a-t-il bien le raccourci ? (
gsettings ... wm.keybindings) - Les options d'accessibilité ne brouillent-elles pas la frappe ? (
gsettings ... a11y.keyboard) - La couche xkb traduit-elle correctement la touche en modificateur ? (
gsettings ... xkb-options) - Le noyau reçoit-il un signal matériel quand on appuie ? (
evtest)
À 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 ».
Checklist mémo
Modificateur (Alt / Super / Ctrl) qui ne répond plus sous GNOME/Wayland :
gsettings get org.gnome.desktop.input-sources xkb-options— surveillerlv3:lalt_switch,altwin:swap_alt_win,caps:*,ctrl:*gsettings list-recursively org.gnome.desktop.wm.keybindings | grep -i alt— confirmer que le raccourci existegsettings get org.gnome.desktop.a11y.keyboard stickykeys-enable(puisslowkeys-enable,bouncekeys-enable)sudo evtest→ choisir le clavier → presser la touche → doit afficher le bon code (KEY_LEFTALT,KEY_LEFTMETA, etc.)
Quatre commandes, quatre couches, et 95 % des bugs clavier de session graphique sont localisés.