Journal HiDPI - retour aux fondamentaux Xorg

Sommaire

• Configurer un écran HiDPI sous Debian 13 & Window Maker : retour aux fondamentaux de Xorg
  • Genèse de cet article : Quand l'expérience UNIX recadre l'IA
  • Le biais du Web : l'oubli progressif du fonctionnement de Xorg
  • Le mythe du gestionnaire de fenêtres « non-HiDPI ready »
  • Pourquoi l'interpolation logicielle rend l'image baveuse ?
  • Cas pratique 1 : Dalle 16:9 standard (ex. Asus Vivobook en 1920x1080)
  • Cas pratique 2 : Dalle 3:2 sur-mesure (ex. Surface Laptop)
    • 1. Générer la ligne GTF
    • 2. Injecter le Mode customisé dans Xorg
  • Vérification sous Window Maker
    • Éléments à vérifier :
  • Conclusion

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 :

Section "Screen"
    Identifier "Screen0"
    Device     "Card0"
    SubSectionSub "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) :

gtf 1500 1000 60

L'outil retourne une définition de mode vidéo sous cette forme :

# 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 :

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"
    SubSectionSub "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 :

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