Wayland n'est plus expérimental : selon les données opt-in de KDE, 79% des utilisateurs de Plasma 6 utilisent déjà Wayland. Plus de 60% des bureaux Linux utilisent Wayland par défaut.

Pour KDE, le choix est pragmatique : "Le modèle dual-stack X11+Wayland a ralenti le progrès". Concentrer les efforts sur Wayland permet d'accélérer l'innovation.

Si Xwayland est un pont utile, il a ses limitations :

X11 excellait pour ssh -X. Wayland n'a pas cela par défaut, mais des solutions existent :

• Waypipe : Proxy Wayland qui s'utilise comme waypipe ssh user@host gedit. Équivalent moderne de ssh -X.
• GNOME Remote Desktop + RDP : Pour les sessions complètes headless
• KDE KRdp : Support RDP natif dans KDE Plasma (disponible dans les paramètres Système → Réseau → Bureau à distance)

Ces outils utilisent des portails XDG pour négocier les permissions, ce qui est plus sûr qu'une transparence réseau sans restrictions.

Bien que Wayland soit mature, il reste des points de friction, surtout pour les power users. Bonne nouvelle : Plasma 6.6 (février 2026) résout ou améliore plusieurs problèmes historiques.

Statut général : >80% des fonctionnalités critiques fonctionnent parfaitement. Les 20% restants nécessitent des workarounds ou sont en cours de résolution.

Symptôme : OBS, Ksnip, ou autres outils de capture ne fonctionnent pas ou plantent sous Wayland

Cause : X11 permettait libre accès au framebuffer ; Wayland exige une permission via le portail

Solution :

• S'assurer que xdg-desktop-portal et le backend approprié (xdg-desktop-portal-kde pour KDE) sont installés
• Autoriser la permission quand le portail demande
• Pour OBS : utiliser une version récente (OBS 30+) avec support natif PipeWire/Wayland activé

# Diagnostiquer l'état des portails
systemctl --user status xdg-desktop-portal
systemctl --user status xdg-desktop-portal-kde

# Réactiver si nécessaire
systemctl --user restart xdg-desktop-portal
systemctl --user restart xdg-desktop-portal-kde

Symptôme : Une application X11 (via Xwayland) est pixelisée sur écran haute résolution ou multi-écran

Cause : Xwayland n'hérite pas toujours du scaling du compositeur

Solution :

# Forcer le scaling pour Xwayland
QT_SCALE_FACTOR=1.5 app-name

# Ou pour les applis GTK :
GDK_SCALE=2 GDK_DPI_SCALE=0.5 app-name

# Solution permanente : créer un wrapper script
#!/bin/bash
export QT_SCALE_FACTOR=1.5
exec /usr/bin/app-real "$@"

Situation : Les technologies d'accessibilité sont dans une transition. Orca (lecteur d'écran GNOME) fonctionne correctement sur GNOME Wayland. KDE rattrape son retard avec des avancées significatives dans Plasma 6.6.

État actuel (février 2026) :

• ✅ GNOME Wayland : support d'accessibilité stable pour lecteurs d'écran
• ✅ KDE Wayland : support en amélioration rapide :
  • Slow Keys (touches lentes) disponible dans Plasma 6.6 pour la session Wayland — aide les utilisateurs avec limitations motrices à éviter les frappes involontaires
  • Zoom amélioré : mode où le pointeur reste au centre physique de l'écran, améliorant la lisibilité pour les utilisateurs en zoom permanent
• ⚠️ Outils de mobilité : certains outils exotiques (eye trackers, dwell clickers spécialisés) nécessitent encore des implémentations spécifiques par compositeur

Solution à court terme : Si vous dépendez d'accessibilité très spécialisée, testez Wayland avant de migrer vos systèmes de production.

Les outils comme xdotool, xbindkeys ou xinput interagissent directement avec le serveur X11 pour simuler des frappes, des clics ou gérer les raccourcis globaux. Sous Wayland, cette architecture n'existe plus : chaque application est isolée et le compositeur (KWin, Mutter, Sway) contrôle strictement les entrées. Pour des raisons de sécurité, il n'est pas possible pour un programme tiers de "forcer" des événements vers une autre fenêtre sans autorisation explicite.

Heureusement, des alternatives adaptées à Wayland ont émergé. Elles fonctionnent soit au niveau du compositeur (via des protocoles dédiés), soit en émulant des événements au niveau du noyau (ce qui nécessite parfois des droits élevés). Voici les principales solutions en février 2026.

Pour les actions liées aux fenêtres (changer de bureau, déplacer une fenêtre, lister les applications…), chaque environnement propose ses propres solutions :

• KDE Plasma : kdotool (fork de ydotool adapté à KWin) – permet de lister les fenêtres, les activer, les déplacer. Exemple :

  # Activer une fenêtre par son titre
  kdotool search "Firefox" | xargs kdotool windowactivate

• GNOME : gdbus ou wmctrl (limité) ; l'extension Focus my window peut être contrôlée via D‑Bus.
• Sway/Hyprland (compositeurs Wayland i3-like) : swaymsg ou hyprctl permettent de tout contrôler par ligne de commande.

Pour un contrôle unifié, le projet wlr-foreign-toplevel-management (protocole standard) est supporté par la plupart des compositeurs. Des outils comme toplevel ou swayr l'exploitent.

Si vous aviez l'habitude d'utiliser xdotool pour automatiser des tâches ou des raccourcis, voici la marche à suivre :

1. Pour la simulation de frappes simples : wtype est le plus simple et le plus compatible.
2. Pour des actions plus complexes (souris + clavier) : ydotool est l'alternative la plus complète.
3. Pour contrôler les fenêtres : utilisez l'outil natif de votre compositeur (kdotool pour KDE, swaymsg pour Sway, hyprctl pour Hyprland).

Avec ces outils, vous retrouverez toute la puissance de vos scripts d’automatisation, dans le respect de la philosophie de sécurité de Wayland.