*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.