Cedric Abonnel
150 lines
8.8 KiB
Markdown
150 lines
8.8 KiB
Markdown
*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+Tab` ne change plus de fenêtre
|
|
- `Alt+F4` ne 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 pas `Alt_L`. Génère `ISO_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 :
|
|
|
|
```bash
|
|
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.
|
|
|
|
```bash
|
|
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.
|
|
|
|
```bash
|
|
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.
|
|
|
|
```bash
|
|
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.
|
|
|
|
```bash
|
|
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 :
|
|
|
|
```bash
|
|
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 :
|
|
|
|
```bash
|
|
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 :
|
|
|
|
```bash
|
|
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 :
|
|
|
|
```bash
|
|
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 :
|
|
|
|
1. **Le gestionnaire de fenêtres a-t-il bien le raccourci ?** (`gsettings ... wm.keybindings`)
|
|
2. **Les options d'accessibilité ne brouillent-elles pas la frappe ?** (`gsettings ... a11y.keyboard`)
|
|
3. **La couche xkb traduit-elle correctement la touche en modificateur ?** (`gsettings ... xkb-options`)
|
|
4. **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 :
|
|
|
|
1. `gsettings get org.gnome.desktop.input-sources xkb-options` — surveiller `lv3:lalt_switch`, `altwin:swap_alt_win`, `caps:*`, `ctrl:*`
|
|
2. `gsettings list-recursively org.gnome.desktop.wm.keybindings | grep -i alt` — confirmer que le raccourci existe
|
|
3. `gsettings get org.gnome.desktop.a11y.keyboard stickykeys-enable` (puis `slowkeys-enable`, `bouncekeys-enable`)
|
|
4. `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. |