Le débat X11 contre Wayland pollue les forums gaming Linux depuis des années, nourri par des impressions subjectives et très peu de mesures concrètes. Marco Nett a décidé de construire son propre dispositif de mesure pour mettre fin aux conjectures. Les résultats publiés en juillet 2026 sont clairs, chiffrés, et contredisent plusieurs idées reçues.
Mesurer la latence d’entrée Linux : la méthode
Plutôt que de se fier au ressenti, Marco Nett a conçu un dispositif matériel maison. Un microcontrôleur Adafruit QT Py RP2040 simule des clics de souris à 1000 Hz et un photodiode BPW34 détecte le changement de luminosité à l’écran. Le tout est relié en USB au PC pour calculer la latence de bout en bout, du clic jusqu’au photon.
Le jeu de test est Diabotical, un titre DirectX 11 lancé via Heroic avec Proton. La configuration matérielle est précise : AMD Ryzen 7 5800X3D, RTX 4070 SUPER, écran QD-OLED 500 Hz. Le logiciel tourne sous CachyOS avec le pilote NVIDIA 610 et KDE Plasma 6.7.
Chaque scénario accumule 300 clics pour obtenir des distributions statistiquement solides. La méthodologie est reproductible et documentée.
X11 vs Wayland natif : une différence quasi imperceptible
La latence d’entrée Linux en mode natif donne des chiffres très proches entre les deux serveurs d’affichage.
| Configuration | X11 | Wayland | Différence |
|---|---|---|---|
| Plain | 4,79 ms | 4,93 ms | +0,14 ms |
| VRR | 4,45 ms | 4,67 ms | +0,22 ms |
| Low-latency | 4,64 ms | 4,83 ms | +0,19 ms |
| VRR + low-latency | 4,21 ms | 4,38 ms | +0,17 ms |
X11 gagne dans chaque scénario, mais l’écart ne dépasse jamais 0,22 ms. Ces résultats rejoignent ceux de David Ramiro, qui avec son projet m2p-latency aboutit à la même conclusion : X11 natif et Wayland natif sont pratiquement à égalité autour de 7 ms dans ses tests.
La perception que Wayland est beaucoup plus lent que X11 ne repose donc pas sur des données mesurables en mode natif.
XWayland, le vrai coupable
La situation change radicalement quand une application X11 tourne via XWayland sous Wayland. Sans dxvk-low-latency, XWayland ajoute 3,13 ms de latence par rapport à Wayland natif (8,06 ms contre 4,93 ms). C’est plus que tous les autres effets mesurés combinés.
La distribution entière se décale, ce ne sont pas quelques frames aberrants qui tirent la moyenne vers le haut. Quand XWayland est inévitable, activer dxvk-low-latency récupère 2,11 ms, ce qui est le gain le plus important observé dans toute l’étude.
La conclusion est nette : éviter XWayland est la priorité absolue pour quiconque se soucie de la latence sous Linux.
VRR : le levier le plus impactant
Le VRR (Variable Refresh Rate, G-Sync, FreeSync) dépasse en impact le choix entre X11 et Wayland natif. L’activer apporte un gain de 0,26 à 0,45 ms selon les configurations, soit plus du double de l’écart X11 / Wayland natif.
En plus de réduire la latence médiane, le VRR aplatit la distribution : l’écart entre le 5e et le 95e percentile passe de 2,6 à 3,0 ms sans VRR à seulement 2,1 à 2,2 ms avec VRR. Moins de jitter, des frames plus prévisibles. C’est cohérent avec le fonctionnement du VRR : les frames partent à l’écran dès qu’elles sont prêtes.
DXVK low-latency : petit gain en mode capé, gros gain en mode non capé
Le fork dxvk-low-latency, maintenu par netborg et intégré à proton-cachyos, montre des résultats intéressants.
En mode capé (FPS limité au taux de rafraîchissement), le gain est modeste mais cohérent :
- Entre 0,10 et 0,29 ms selon la configuration
- Comparable en magnitude à l’écart X11 / Wayland natif
En mode non capé, le pacer révèle sa vraie force. Sans dxvk-low-latency, la latence monte à 5,27 ms. Avec, elle descend à 4,43 ms. Soit un gain de 0,84 ms. En contrepartie, les FPS baissent de 715 à 670, le pacer maintient le GPU à 95 à 97 % d’utilisation pour éviter la saturation de la file de rendu.
Les bénéfices principaux du pacer s’expriment dans les scénarios réels où les temps de frame fluctuent, pas dans une scène statique sans bots.
Une approche complémentaire : VK_EXT_present_timing
Themaister a publié le 2 juillet 2026 une approche différente pour mesurer la latence sans hardware externe. En injectant des inputs via /dev/uinput et en détectant le changement d’image directement sur le GPU via l’extension Vulkan VK_EXT_present_timing, il isole la latence PC en excluant USB et affichage. C’est une méthode programmatique utile pour comparer des configurations logicielles de manière automatisée.
Ce qu’il faut retenir
- XWayland est le vrai problème : +3,13 ms par rapport à Wayland natif, plus que tous les autres facteurs réunis. Activer le mode Wayland natif dans Heroic ou Proton est la priorité.
- X11 et Wayland natif sont presque identiques : l’écart de 0,14 à 0,22 ms ne justifie pas de rester sur X11 pour des raisons de latence.
- Le VRR apporte le gain le plus important : 0,26 à 0,45 ms de réduction, plus un jitter réduit. Sur un moniteur compatible, l’activer est plus efficace que le choix du serveur d’affichage.
- dxvk-low-latency vaut le coup : gain modeste en mode capé, mais significatif en usage réel non capé et très utile quand XWayland est inévitable.
- Ces résultats sont spécifiques à ce matériel : les chiffres absolus changeront selon le setup, mais les tendances relatives devraient se transférer.
Si ces mesures t’intéressent pour optimiser ton setup gaming Linux ou que tu travailles sur des environnements à faible latence, n’hésite pas à en discuter. Abonne-toi au blog pour ne pas manquer les prochaines analyses.
Sources
- Marco Nett, « Measuring input latency on Linux: X11 vs Wayland, VRR, and DXVK » (13 juillet 2026) : https://marco-nett.de/blog/measuring-input-latency-on-linux-x11-vs-wayland-vrr-dxvk/
- Themaister, « My side quest measuring input latency with VK_EXT_present_timing » (2 juillet 2026) : https://themaister.net/blog/2026/07/02/my-side-quest-measuring-input-latency-with-vk_ext_present_timing/
- Projet DXVK (doitsujin/dxvk) : https://github.com/doitsujin/dxvk
- David Ramiro, projet m2p-latency : référencé dans l’article de Marco Nett