X Window

1. X Window System

1. Conditions générales et Wayland

Depuis l’apparition de Xorg, la configuration de X Window est réduite au minimum : elle ne concerne généralement que les cas où la modification d’un comportement par défaut est nécessaire. Pour preuve, en l’espace de dix ans, l’auteur n’a eu besoin de modifier la configuration qu’à deux reprises, pour activer des options expérimentales de sa carte graphique.

Wayland est, tout comme Xorg, un protocole de communication entre un serveur d’affichage et ses clients. Un ensemble de bibliothèques est fourni afin de permettre son utilisation native par des applications. Wayland a été développé dans le but de remplacer Xorg, devenu lourd, moins sûr (les communications entre le client et le serveur transitent en clair), et peu performant. L’implémentation de Wayland sous Linux se nomme Weston. La différence la plus visible avec Xorg est l’utilisation obligatoire d’un compositeur graphique pour gérer l’affichage, ce qui implique l’utilisation des fonctions avancées de bibliothèques ou pilotes graphiques, et du matériel associé : par exemple openGL avec l’accélération matérielle 3D.

L’arrivée de Wayland ne rend pas caduque l’utilisation de X Window : certains environnements et applications en ont encore besoin. Le composant XWayland permet une compatibilité des applications X avec Wayland. C’est un Xorg patché qui fonctionne en surcouche à Wayland.

En février 2020, les distributions Ubuntu 19.10 (et la future LTS 20.04), SLES, openSUSE 15.1, Red Hat Linux 7 et CentOS 7 utilisent encore Xorg nativement par défaut. Dans la plupart des cas, les éditeurs ne considèrent pas Wayland comme assez stable pour remplacer Xorg, mais permettent de l’activer à des fins de tests, sans support.

Xorg a donc encore devant lui quelques années de cohabitation avec Wayland.

Pour savoir si vous utilisez Wayland, vérifiez la présence de la variable d’environnement WAYLAND_DISPLAY :

$ echo $WAYLAND_DISPLAY  
wayland-0 

Si vous souhaitez connaître les applications qui utilisent XWayland, utilisez la commande xlsclients. Cette commande liste les clients...

1. Principe

Le Display Manager, ou gestionnaire d’affichage, est un élément de X Window qui se charge de la connexion des utilisateurs, locaux ou distants, de leur authentification, puis qui charge leur environnement de travail en leur ouvrant une session. Il gère un ensemble d’affichages X, qui peuvent être locaux ou distants.

Pour les connexions distantes, le Display Manager s’appuie sur le protocole standard XDMCP (X Display Manager Control Protocol).

Le Display Manager est en gros l’équivalent graphique des services proposés par init, getty et login : il demande des identifiants et mots de passe, authentifie les personnes et ouvre une session.

Le gestionnaire par défaut se nomme XDM : X Display Manager. Son style graphique n’est pas très attrayant mais il est léger et fonctionne avec tous les serveurs X.

Une session X peut être vue comme une session de console : c’est la durée de vie du processus d’un utilisateur après la connexion. Sous une console c’est le shell, sous X c’est un « session manager », généralement le gestionnaire de fenêtre (ou un processus de l’environnement bureautique) ou un terminal graphique. Quand ce processus est fermé (déconnexion du terminal, sortie de l’environnement bureautique, etc.) la session se termine et la boîte de connexion de XDM (ou tout autre Display Manager) est réaffichée.

Il est possible d’ouvrir plusieurs sessions X depuis un seul Display Manager, y compris sur une même machine.

Linux dispose de plusieurs Display Manager mais quatre sont principalement utilisés :

Les versions GDM, KDM et lightDM sont évoluées : elles proposent la même chose que XDM avec des fonctionnalités supplémentaires :

1. Via le Display Manager

Vous déterminez généralement le type d’environnement graphique chargé par la session X depuis gdm ou kdm (il est rare d’utiliser xdm) et le menu associé. Ceux-ci se rappellent de la session précédente comme session par défaut grâce à la présence du fichier .dmrc dans votre répertoire personnel :

seb@ubuntu:~$ pwd 
/home/seb 
seb@ubuntu:~$ cat .dmrc 
[Desktop] 
Session=ubuntu 

Sur les dernières versions, c’est dans /var/lib/ServiceAccounts/users/$USER qu’il faudra chercher. Le fichier porte le nom de votre utilisateur. Cela évite à gdm ou kdm de nécessiter des droits étendus pour lire vos fichiers :

# cat seb 
[User] 
Language= 
Session= 
XSession=icewm-session 
Icon=/home/seb/.face 
SystemAccount=false 

Vous remarquerez, si vous utilisez l’un ou l’autre des deux gestionnaires d’affichage, que la liste des sessions possibles est partagée. C’est l’un des avantages de Freedesktop : les fichiers de description des sessions sont placés dans /usr/share/xsessions (la description du fichier kdmrc indique d’autres positions possibles).

$ ls -l /usr/share/xsessions/ 
total 12 
-rw-r--r-- 1 root root 207 oct.   4 13:16 gnome.desktop 
-rw-r--r-- 1 root root 2274 sept. 21 03:30 plasma.desktop 
-rw-r--r-- 1 root root 238 oct.   4 13:16 ubuntu.desktop 

Chaque fichier desktop représente une session possible. Les descriptions et les commandes de lancement sont présentes dans chacun des fichiers, et notamment via les lignes Exec et Name :

$ grep -E "Exec|Name=" /usr/share/xsessions/*.desktop 
/usr/share/xsessions/gnome.desktop:Name=GNOME 
/usr/share/xsessions/gnome.desktop:Exec=gnome-session --session=gnome 
/usr/share/xsessions/gnome.desktop:TryExec=gnome-shell 
/usr/share/xsessions/plasma.desktop:Exec=/usr/bin/startkde 
/usr/share/xsessions/plasma.desktop:TryExec=/usr/bin/startkde 
/usr/share/xsessions/plasma.desktop:Name=Plasma 
/usr/share/xsessions/ubuntu.desktop:Name=Ubuntu 
/usr/share/xsessions/ubuntu.desktop:Exec=/usr/lib/gnome-session/
run-systemd-session ubuntu-session.target 
/usr/share/xsessions/ubuntu.desktop:TryExec=unity...

1. RDP

Remote Desktop Protocol est un protocole d’accès à un bureau à distance, développé par Microsoft, pour des systèmes Windows. Des clients et même des serveurs sont disponibles pour tous les systèmes d’exploitation, notamment sous Linux. Il est possible de sécuriser le protocole à l’aide de certificats.

Le serveur s’appelle xrdp. Il est disponible pour la plupart des distributions via le package du même nom. Sur une Fedora 31 ou une CentOS 8, il s’installe comme ceci :

# yum -y install xrdp  # ou dnf install xrdp, sur Fedora, Red Hat, CentOS 
# apt-get install xrdp # Ubuntu ou Debian 
# systemctl start xrdp 
# systemctl enable xrdp # démarrage automatique 

RDP écoute sur le port 3389 en TCP. Il faudra autoriser le port d’écoute comme suit :

Sur Red Hat ou CentOS 7 ou plus, et Fedora :

# firewall-cmd --permanent --zone=public -add-port=3389/tcp 
# firewall-cmd --reload 

Sur Ubuntu, il faut ouvrir le port mais aussi modifier une règle de sécurité :

# ufw allow 3389/tcp 

Puis modifiez le fichier /etc/polkit-1/localauthority.conf.d/02-allow-colord.conf en intégrant ceci dedans :

polkit.addRule(function(action, subject) { 
if ((action.id == “org.freedesktop.color-manager.create-device” || action.id == 
“org.freedesktop.color-manager.create-profile”...

1. Assistance au clavier et à la souris

Un simple réglage du clavier peut aider une personne ayant des problèmes moteurs. Par exemple, une personne lente va chercher longtemps une touche, quitte à se tromper, puis appuiera trop longtemps sur la touche voulue, ce qui aura pour effet de répéter le caractère saisi plusieurs fois.

Le module AccessX de l’environnement graphique permet de nombreux réglages. Ceux-ci sont accessibles depuis les centres de configuration des environnements graphiques. Sous KDE par exemple, le module Accessibilité de la section Personnalisation de la configuration du système propose de modifier de nombreux réglages par défaut, dont le fonctionnement du clavier. Par exemple, dans l’onglet Filtres du clavier, cochez Utiliser les touches lentes. Si une personne veut effectuer une action, elle ne sera prise en compte qu’après...