URL: https://linuxfr.org/users/brainois/journaux/hidpi-retour-aux-fondamentaux-xorg Title: HiDPI - retour aux fondamentaux Xorg Authors: brainois Date: 2026-08-27T11:43:18+02:00 License: CC By-SA Tags: hidpi, windowmaker, icewm et xorg Score: -11 # Configurer un écran HiDPI sous Debian 13 & Window Maker : retour aux fondamentaux de Xorg L'utilisation d'un gestionnaire de fenêtres classique comme **WindowMaker** ou **IceWM** sur un ordinateur portable doté d'une dalle HiDPI soulève souvent la question du support des hautes résolutions. --- ## Genèse de cet article : Quand l'expérience UNIX recadre l'IA Cet article est le fruit d'une longue session d'itération et de diagnostic avec une intelligence artificielle. Il illustre de façon frappante les limites du « consensus du Web » actuel. Au départ, l'IA s'est orientée vers les solutions massivement documentées sur Internet : * L'utilisation de commandes `xrandr` dynamiques (avec `--scale` ou `--scale-from`), * Le bricolage des variables d'environnement applicatives (`GDK_SCALE`, `GDK_DPI_SCALE`, `QT_SCALE_FACTOR`), * L'ajustement du scaling au niveau du Display Manager ou de l'environnement de bureau. Toutes ces approches ont produit le même résultat décevant : une interface lisible mais **floue, baveuse et instable**, où les applications continuaient de calculer leur zone de rendu sur la grille 2.8K native avant de subir une interpolation logicielle. **La clé du problème n'est pas venue des données du Web, mais de la mémoire technique.** En me remémorant la manière dont nous configurions les serveurs X11 à la main à la fin des années 90 — directement dans les fichiers de configuration Xorg —, j'ai réorienté l'IA vers une résolution à la source. C'est cette intuition qui a permis d'aboutir à la seule solution qui, selon moi, soit véritablement propre. --- ## Le biais du Web : l'oubli progressif du fonctionnement de Xorg Si le Web est inondé de réponses bancales, c'est le résultat d'un phénomène de fond : **l'oubli progressif de la configuration bas niveau de X11**. Depuis l'avènement de l'auto-détection du matériel au milieu des années 2000 (disparition du fichier `xorg.conf` monolithique au profit de KMS et `udev`), la connaissance de la configuration déclarative du serveur X s'est érodée. Parallèlement, l'arrivée des dalles Retina/HiDPI a poussé les environnements modernes (GNOME, KDE) à intégrer la mise à l'échelle au niveau des *toolkits* (GTK, Qt) ou de Wayland. Le Web en a déduit deux fausses vérités : 1. Le *scaling* applicatif logiciel serait la **seule** façon moderne de gérer un écran haute densité. 2. Tout environnement dépourvu d'un curseur « Scaling 150 % » dans ses menus serait de facto **périmé ou inapte au HiDPI**. --- ## Le mythe du gestionnaire de fenêtres « non-HiDPI ready » On lit fréquemment que les anciens *Window Managers* comme WindowMaker seraient « obsolètes » ou « inadaptés au HiDPI ». Il s'agit d'une mépréhension de l'architecture X11 : * **Le rôle du Window Manager :** Window Maker est un *reparenting window manager*. Il gère la décoration, le placement et la géométrie des fenêtres, mais n'a pas à traiter le rendu raster global ni la densité de pixels. * **Le rôle de X11 :** C'est le serveur X11 qui définit la géométrie et la grille de restitution du système. * **La réalité :** Tout *window manager* — quelle que soit son année de création — devient intrinsèquement *HiDPI ready* dès lors que le serveur X11 est configuré correctement à la racine. Le scaling « intégré » de certains bureaux modernes (comme XFCE) n'est souvent qu'une facilité d'interface qui masque une interpolation logicielle baveuse. --- ## Pourquoi l'interpolation logicielle rend l'image baveuse ? Lorsque le redimensionnement est appliqué après le démarrage du serveur X11 (via `xrandr` ou des variables GDK/Qt) : 1. Le serveur X11 et les toolkits calculent leurs éléments pour la résolution native (ex. 2880x1620). 2. Le système applique une interpolation/extrapolation pour tout compresser dans un espace 1080p. 3. **Résultat :** Les pixels applicatifs ne correspondent plus aux pixels physiques de la dalle. L'alignement subpixel des polices et la netteté des icônes sont détruits. Pour obtenir une netteté absolue (**1 pixel applicatif = 1 pixel affiché**), Xorg doit être configuré directement à la racine. --- ## Cas pratique 1 : Dalle 16:9 standard (ex. Asus Vivobook en 1920x1080) Pour un écran 16:9 récent, il suffit de contraindre la section `Screen` de Xorg dans `/etc/X11/xorg.conf.d/10-monitor.conf` : ```xorg Section "Screen" Identifier "Screen0" Device "Card0" SubSection "Display" Modes "1920x1080" Virtual 1920 1080 EndSubSection EndSection ``` Dès le démarrage de Xorg, le serveur initialise la grille de manière stricte en 1080p, garantissant un ratio **1 pixel applicatif = 1 pixel affiché**. --- ## Cas pratique 2 : Dalle 3:2 sur-mesure (ex. Surface Laptop) Sur des machines comme la Microsoft Surface Laptop, l'écran adopte un ratio **3:2** avec une résolution native très dense (ex. 2256x1504). Forcer une résolution 16:9 (comme 1080p) déformerait l'image. Pour créer une résolution intermédiaire parfaitement adaptée à sa vue tout en conservant strictement le ratio 3:2 (par exemple 1500x1000 ou 1680x1120) : ### 1. Générer la ligne GTF Dans un terminal, on utilise l'outil `gtf` pour calculer la ligne de rafraîchissement exacte (*Modeline*) : ```bash gtf 1500 1000 60 ``` L'outil retourne une définition de mode vidéo sous cette forme : ```text # 1500x1000 @ 60.00 Hz (GTF) hsync: 62.10 kHz; pclk: 122.21 MHz Modeline "1500x1000_60.00" 122.21 1500 1592 1752 2000 1000 1001 1004 1035 -HSync +VSync ``` ### 2. Injecter le Mode customisé dans Xorg On reporte ce `Modeline` dans la section `Monitor`, puis on l'appelle dans la section `Screen` du fichier `/etc/X11/xorg.conf.d/10-monitor.conf` : ```xorg Section "Monitor" Identifier "Monitor0" # Modeline générée par gtf pour le ratio 3:2 Modeline "1500x1000_60.00" 122.21 1500 1592 1752 2000 1000 1001 1004 1035 -HSync +VSync EndSection Section "Screen" Identifier "Screen0" Device "Card0" Monitor "Monitor0" SubSection "Display" Modes "1500x1000_60.00" Virtual 1500 1000 EndSubSection EndSection ``` **Résultat :** L'écran conserve ses proportions 3:2 sans aucune déformation, les polices restent d'une netteté cristalline et la taille de l'interface est calibrée exactement selon le confort visuel souhaité. --- ## Vérification sous Window Maker Une fois la session ouverte, une simple commande permet de confirmer le résultat : ```bash xrandr ``` ### Éléments à vérifier : * **Résolution active :** La ligne correspondant au mode choisi (`1920x1080` ou `1500x1000_60.00`) est bien marquée d'un astérisque (`*`). * **Fréquence :** La fréquence de rafraîchissement optimale de la dalle est conservée (ex. `60.00*` ou `120.00*`). --- ## Conclusion Il est temps d'arrêter les solutions de bricolage logiciel à la chaîne — qu'il s'agisse de scripts `xrandr` bancals, de surcouches d'environnements lourds ou de variables d'environnement éparpillées. Dans l'architecture UNIX, **à chacun son rôle** : ne déportons pas la responsabilité de la définition d'affichage sur le gestionnaire de fenêtres alors qu'elle incombe au serveur d'affichage sous-jacent. En revenant aux fondamentaux de X11 et en configurant le serveur Xorg directement à la source, n'importe quel gestionnaire de fenêtres — que ce soit Window Maker, IceWM, FVWM ou Fluxbox — devient instantanément *HiDPI ready*, sans le moindre effort applicatif ni aucun compromis sur la netteté.