Le problème
On a lsusb, lspci, lscpu… mais rien pour les écrans ou les GPUs.
Pour savoir quel écran est branché sur quelle sortie, c'est la danse du
xrandr | grep connected, cat /sys/class/drm/card*/edid | edid-decode,
nvidia-smi…
J'ai écrit deux outils pour régler ça.
lsdisplay
Liste les écrans connectés avec fabricant, modèle, numéro de série,
résolution, fréquence, diagonale, et dessine un schéma ASCII du layout :
$ lsdisplay
CONNECTED DISPLAYS
==================
DP-4 1440x2560+0+0 27" 75Hz Iiyama PL2792Q DisplayPort S/N:1152031921274 rot=left [PRIMARY]
HDMI-A-2 1440x2560+1441+0 27" 75Hz Iiyama PL2792Q HDMI S/N:1152032422031 rot=left
HDMI-A-5 5376x3024+0+2561 65" 60Hz Samsung QN800D HDMI S/N:94:e6:ba:dd:9a:7a
Total: 3 display(s) connected
LAYOUT
======
+--------------+ +--------------+
| | | |
| DP-4* | | HDMI-A-2 |
| | | |
+--------------+ +--------------+
+------------------------------+
| |
| HDMI-A-5 |
| |
+------------------------------+Fonctionnalités :
- Parse les EDID directement depuis
/sys/class/drm(pas de dépendance externe) - Fonctionne sur X11 et Wayland (KDE, Sway, wlroots)
- Mode
--jsonpour le scripting - Mode
--scanpour découvrir les Smart TV Samsung sur le réseau - Fichier d'overrides pour corriger les EDID buggés (Samsung, je te regarde…)
- Python 3.6+, zéro dépendance
lsgpu
Liste les GPUs avec stats NVIDIA, mapping écran par sortie :
$ lsgpu
GRAPHICS CARDS
==============
card0: NVIDIA GA107 [GeForce RTX 3050 6GB]
Driver: nvidia | VRAM: 6 GB | GPU:0% MEM:2077/6144MB 37°C 16.7W
├─ DP-4: connected ← Iiyama PL2792Q 27"
├─ HDMI-A-2: connected ← Iiyama PL2792Q 27"
card1: Intel Arrow Lake-S [Intel Graphics]
Driver: i915
├─ HDMI-A-5: connected ← Samsung TQ65QN800DTXXC 65"
Total: 2 GPU(s), 3 output(s) connectedFonctionnalités :
- Stats NVIDIA (utilisation, température, puissance, mémoire)
- Stats AMD via sysfs
- Mode
--watchavec sparklines en temps réel - Liste des processus utilisant le GPU
- Python 3.6+, zéro dépendance Python
Installation
sudo cp lsdisplay.py /usr/local/bin/lsdisplay
sudo chmod +x /usr/local/bin/lsdisplayPaquet .deb disponible aussi. Un seul fichier Python, pas de pip, pas de venv.
Appel à testeurs
C'est une v0.1.0 — testé sur ma config (GPU NVIDIA + Intel, KDE Wayland,
3 écrans dont 2 Samsung TV). J'aimerais des retours sur :
- Configs AMD (j'ai le code mais pas le matos pour tester)
- Wayland hors KDE (Sway, GNOME, Hyprland)
- Écrans avec EDID exotiques
- Suggestions d'affichage ou de fonctionnalités
Liens
Licence : GPL-2.0
# $ lsdisplay --list-priority
Posté par géhème . Évalué à 2 (+2/-0). Dernière modification le 04 mai 2026 à 13:18.
# Test config AMD
Posté par gUI (Mastodon) . Évalué à 3 (+0/-0). Dernière modification le 04 mai 2026 à 08:17.
Ça m'a tout l'air d'être OK:
Pour info je suis également sous Wayland/KDE.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# ne reconnais pas mon environnement
Posté par Matthieu Duchemin (site web personnel) . Évalué à 1 (+1/-0).
Je suis sous mageia 9 et j'utilise sway, lsdisplay considère que je suis sous xwayland et n'arrive pas à détecter les modèles de mes écrans.
[^] # Re: ne reconnais pas mon environnement
Posté par géhème . Évalué à 2 (+2/-0).
Salut Matthieu, pourrais-tu retester ?
C'est corrigé dans le dernier commit — tu dois juste re-télécharger lsdisplay.py et vérifier que wlr-randr est installé (c'est lui qui donne les vraies infos sous Sway, au lieu de xrandr qui ne voit que les sorties XWAYLAND).
[^] # Re: ne reconnais pas mon environnement
Posté par Matthieu Duchemin (site web personnel) . Évalué à 2 (+2/-0).
ça me semble bon. Voici le résultat après avoir téléchargé la dernière version:
[^] # Re: ne reconnais pas mon environnement: le reconnais maintenant! merci pour le feedback.
Posté par géhème . Évalué à 1 (+1/-0).
Merci!!!
# Liste des fabriquants
Posté par Dring . Évalué à 4 (+2/-0).
Super script !
Dans ton code, je vois ça :
Tu les as trouvé où ces codes ? Quelqu'un connaît l'histoire derrière ces codes ?
[^] # Re: Liste des fabriquants
Posté par géhème . Évalué à 3 (+3/-0).
https://github.com/onkoe/pnpid/blob/main/list.csv
La liste datée
[^] # Re: Liste des fabriquants
Posté par Dring . Évalué à 5 (+3/-0).
En cherchant un peu, il semblerait qu'en standard, tout bon système linux ait le fichier
/usr/share/hwdata/pnp.idsavec les données souhaitées. Si ça peut être utile…[^] # Re: Liste des fabriquants
Posté par yabb85 . Évalué à 3 (+3/-0).
Sur Debian ça demande d'avoir le paquet pnp.ids qui n'est pas installé par défaut ou alors ajouter une dépendance.
https://packages.debian.org/trixie/all/pnp.ids/filelist
# Source des PNP_MANUFACTURERS
Posté par géhème . Évalué à 5 (+5/-0).
La source officielle est le PNP ID Registry maintenu par Microsoft (en tant qu'administrateur du standard VESA/UEFI): https://uefi.org/PNP_ID_List
C'est la base de référence. Chaque fabricant enregistre son code 3 lettres auprès de l'UEFI Forum (anciennement via Microsoft).
Il existe aussi :
- https://github.com/vcrhonek/hwdata — le paquet hwdata de Linux, fichier pnp.ids (utilisé par edid-decode, lshw, etc.)
- /usr/share/hwdata/pnp.ids — sur la plupart des distributions Linux
$ cat /usr/share/hwdata/pnp.ids| nl | head
1 AAA Avolites Ltd
2 AAE Anatek Electronics Inc.
3 AAM Aava Mobile Oy
4 AAN AAEON Technology Inc.
5 AAT Ann Arbor Technologies
6 ABA ABBAHOME INC.
7 ABC AboCom System Inc.
8 ABD Allen Bradley Company
9 ABE Alcatel Bell
10 ABO D-Link Systems Inc
$ cat /usr/share/hwdata/pnp.ids| nl | tail
2548 ZTE ZTE Corporation
2549 ZTI Zoom Telephonics Inc
2550 ZTM ZT Group Int'l Inc.
2551 ZTT Z3 Technology
2552 ZWE Shenzhen Zowee Technology Co., LTD
2553 ZYD Zydacron Inc
2554 ZYP Zypcom Inc
2555 ZYT Zytex Computers
2556 ZYX Zyxel
2557 ZZZ Boca Research Inc
# Test config WSL2
Posté par Toto . Évalué à 1 (+0/-0).
Pour le fun, ca marche aussi sur WSL (Debian sur Windows).
La partie GPU ne renvoi rien (logique dans mon cas, je tenterais une WSL avec gpu amd dans la soirée par soucis de complétude)
./lsgpu.py
No GPUs found.
# marche pas
Posté par jtremesay (site web personnel) . Évalué à 2 (+0/-0).
[^] # Re: marche pas
Posté par géhème . Évalué à 1 (+1/-0). Dernière modification le 05 mai 2026 à 08:12.
Merci pour le test !
Python 3.6 n'a pas dataclasses dans la stdlib (ajouté en 3.7). C'est corrigé dans le dernier commit — le requis est maintenant Python 3.7+ et le message d'erreur est explicite.
Sur AlmaLinux 8 :
puis
# Test sous Kubuntu 26.04 (Wayland)
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 3 (+1/-0).
lsdisplayrécupéré depuis Git (commitae71bc5bb0d630dab9d0ad4355aea02bfab7bb66) fonctionne parfaitement. Il ne comprends pas que mon 3ème écran est inutilisable parce qu’une autre source est sélectionnée, mais Wayland ne le comprends pas non plus, et X11 ne le comprenait pas non plus avant, donc c’est normal – mais c’est une limitation qu’il pourrait être intéressant de documenter.lsgpurécupéré depuis Git (commit3ecbd96f7a0c8e7c25ef8ec0e876e6969a104cd4) fonctionne parfaitement lui aussi, y compris les infos des senseurs :Dans les deux cas j’ai un doute sur la numérotation des ports DisplayPort (je pensais avor le BenQ sur le DP-2, au milieu sur la carte), mais comme ils sont particulièrement inaccessibles sur mon setup actuel, je ne peux pas vérifier.
La connaissance libre : https://zestedesavoir.com
# Résultats
Posté par Benoît Sibaud (site web personnel) . Évalué à 6 (+3/-0). Dernière modification le 05 mai 2026 à 09:32.
Le lsgpy donne plus d'infos sur le nom des écrans que le lsdisplay.
Les affichages du type « display(s) » ça me semble toujours bizarre : la programmation a décidé de laisser le calcul du singulier/pluriel à l'exercice du lectorat. D'ailleurs « DISPLAYS » et « CARDS » sont bien au pluriel.
[^] # Re: Résultats
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 3 (+1/-0). Dernière modification le 06 mai 2026 à 09:42.
Idem j’ai le nom des écran dans
lsgpumais pas danslsdisplay. C’est pas un bug, mais ce serait bien de les avoir danslsdisplayégalement.En regardant les sorties json, je pense que je comprends pourquoi on l’a pas pour
lsdisplay, le manufacturer et le model sont ceux de la classe du port, et sont probablement vides. Alors que ceux affichés danslsgpudoivent être dans un autre device de/sysqui contient bien le manufacturer. Faudrait probablement lier les deux. Si j’ai le temps aujourd’hui, je tente une contribution…En tout cas sous Xfce/X11/Manjaro ça marche très bien :
[^] # Re: Résultats
Posté par Vincent Danjean . Évalué à 2 (+1/-0).
Regarde mon commentaire en dessous. lsdisplay cherche un edid dans
/sys/class/drm/avec comme heuristique de retrouver le nom de la sortie (par exempleDP-1-1) dans le nom des devices (DP-5pour toi apparemment). Ça ne marche pas. La bonne chose à faire serait de passer par le CONNECTOR_ID dans les propriété dexrandr(à rechercher dans/sys/class/drm/*/connector_id)# Cohérence des informations
Posté par Vincent Danjean . Évalué à 4 (+3/-0). Dernière modification le 05 mai 2026 à 14:24.
Je me reconnais parfaitement :-)
Plusieurs remarques après un test rapide :
1) c'est super !
2) quand on regarde les sorties (json pour scripter) des deux outils, c'est difficile de faire le lien entre eux. Chez moi, j'ai par exemple :
Faire le lien entre
DP-1-3delsdisplayetDP-5delsgpune me semble pas évident.3) la représentation graphique des écrans les mets côte à côte quand ils sont en mirroir (total). Je n'ai pas encore testé avec mirroir partiel (un écran plus grand que l'autre)
4) si tu as besoin d'un sponsor ou d'un maintainer pour mettre ces logiciels officiellement dans Debian (et donc à terme toutes les distrib dérivées), n'hésite pas à me contacter.
[^] # Re: Cohérence des informations
Posté par Vincent Danjean . Évalué à 1 (+0/-0).
Une autre chose à laquelle je pense. Cela faisait plusieurs semaines/mois qu'
evinceme mettait systématiquement un message de warning à chaque démarrage comme quoi je n'avais pas d'accélération matérielle pour OpenGL, que je n'avais que l'émulation logicielle (mesa).J'ai mis du temps à trouver la raison :
- j'avais une (très) vieille config dans
/etc/xorg/xorg.confqui forçait le chargement du driverintel- le driver
intelde xorg ne charge(ait) plus le driver 3D correct (il a récemment changé de nom, https://askubuntu.com/questions/1544601/libgl-error-unable-to-load-driver-i965-dri-so m'avait mis sur la piste)J'ai donc complètement viré
/etc/xorg/xorg.conf, et maintenant ce sont les modulesmodesetting+vesa+glamoreglqui sont chargés et utilisés par xorg (et je n'ai plus le warning avecevince).Au passage, j'ai découvert la commande
env MESA_VK_DEVICE_SELECT=list vulkaninfopermettant de voir les gpu (réels ou virtuels dans le cas de llvm/mesa) permettant de faire de l'accélération 3D.J'en arrive à mes questions en rapport avec ce sujet :
- est-il possible de remonter les drivers xorg utilisés sur la machine pour gérer les CPU (ça ferait aussi apparaître nouveau/NVidia, …)
- est-il possible/pertinent de montrer les GPU pour 3D (dans lsgpu ? avec une option ?)
[^] # Re: Cohérence des informations
Posté par Vincent Danjean . Évalué à 1 (+0/-0). Dernière modification le 05 mai 2026 à 13:06.
En fait, c'est vraiment un problème :
lsdisplayne trouve pas les infos edid de mes écrans.=> la fonction
read_edid_for_outputdelsdisplaytrouve les infos poureDP-1mais pas pourDP-1-3Dans mes scripts, j'avais utilisé les infos EDID de
xrandr --verbosecar je n'avais pas trouvé comment faire le lien avec le bon répertoire dans/sys/class/drmIl semblerait que la propriété
CONNECTOR_IDdansxrandrquand elle existe puisse servir à faire le lien (https://forums.developer.nvidia.com/t/feature-request-xrandr-connector-id-property/240578)[^] # Re: Cohérence des informations
Posté par Vincent Danjean . Évalué à 2 (+1/-0).
Et je viens de découvrir l'outil
jcqui permet de parser les sorties de commandes (dontxrandr) et d'avoir le résultat en json.[^] # Re: Cohérence des informations
Posté par géhème . Évalué à 2 (+2/-0).
Merci Vincent, retour précieux !
DP-1-3 vs DP-5 : c'est le cas MST (hub/dock DisplayPort) que je n'avais pas anticipé. Bonne piste avec CONNECTOR_ID — je vais implémenter le mapping via xrandr --properties.
En fallback, parser l'EDID directement depuis xrandr --verbose est aussi une option.
Miroir : à corriger, je n'ai pas ce cas chez moi.
Debian : oui avec plaisir ! Je t'envoie un mail ? du coup il faudra passer en v1.0 ou je peux rester en v0.x ?
jc : je ne connaissais pas, merci pour la découverte.
[^] # Re: Cohérence des informations
Posté par Vincent Danjean . Évalué à 3 (+2/-0).
Pour le numéro de version dans Debian, on fait vraiment comme on veut.
Tu peux me contacter sur mon adresse vdanjean@debian.org si besoin.
J'ai aussi découvert à cette occasion
jcquand j'ai voulu regarder s'il n'y avait pas un moyen facile/déjà écrit de récupérer l'info de xrandr.# Test sous Ubuntu 22.04.5 LTS
Posté par Stephane COLIN (site web personnel) . Évalué à 1 (+1/-0).
Fonctionne parfaitement.
# config Gnome + AMD + wayland
Posté par yabb85 . Évalué à 1 (+1/-0).
ça a l'air ok de mon coté
# un écran 8" affiché à 59"
Posté par Blaise (Mastodon) . Évalué à 1 (+0/-0).
GPU NVIDIA + Intel, KDE Wayland également, donc pas de surprise, ça fonctionne,
Mais un écran un peu exotique : écran 8" intégré dans le boitier PC (Jonsbo D31),
qui se retrouve affiché à 59"
# Ok sur ArchLinux/KDE
Posté par seraf1 (site web personnel) . Évalué à 1 (+0/-0).
Bonjour,
Tout fonctionne sur ArchLinux/KDE :
Je peux essayer d'en faire des paquets AUR si tu le souhaites (il faudra trouver un moyen que je sois notifié lors de nouvelles versions).
[^] # Re: Ok sur ArchLinux/KDE
Posté par seraf1 (site web personnel) . Évalué à 1 (+0/-0).
J'ai créer les paquets dans AUR ! Donc ils sont disponibles dans ArchLinux et dérivées.
[^] # Re: Ok sur ArchLinux/KDE
Posté par géhème . Évalué à 0 (+0/-0). Dernière modification le 16 mai 2026 à 11:42.
Bien vu — c'est un bug de layout réel. D'après les coords :
Donc physiquement eDP-1 est collé à droite de DP-2, légèrement décalé en bas (508 px d'offset). Le rendu correct serait quelque chose comme :
C'est bien cela? Or les 2 écrans sont séparés verticalement avec un grand vide → l'algo de layout les met sur 2 lignes distinctes au lieu de les superposer.. Tu confirmes?
bug -> https://github.com/AGuyMarc/lsdisplay/issues
Pour archlinux,
Je vais mettre à jour demain.
[^] # Re: Ok sur ArchLinux/KDE
Posté par seraf1 (site web personnel) . Évalué à 1 (+0/-0). Dernière modification le 18 mai 2026 à 08:48.
C'est bien cela, la config vu depuis la configuration systèmes de KDE ressemble à ça :
[^] # Re: Ok sur ArchLinux/KDE
Posté par seraf1 (site web personnel) . Évalué à 1 (+0/-0).
Pour les paquets ArchLinux, je vais mettre à jour dès que possible. Par contre, j'ai un soucis avec le nom de l’exécutable lsgpu, le nom rentre en conflit avec celui du paquet "intel-gpu-tools", pour le moment, je me suis permit de renommer les exécutable "lsdisplays" et "lsgpus", si tu as un meilleure proposition, je suis preneur.
# lsgpu → lsgpus
Posté par géhème . Évalué à 0 (+0/-0).
Merci pour le retour, et désolé pour ce conflit que je n'avais pas anticipé.
▎
▎ J'ai vérifié : le conflit existe aussi sur Debian/Ubuntu (apt-file show igt-gpu-tools montre /usr/bin/lsgpu et lsgpu.1.gz), donc pas seulement sur Arch. En lisant le man page d'igt-gpu-tools, leur lsgpu n'est pas Intel-only contrairement à ce que
▎ le nom du paquet laisse penser — c'est un outil d'énumération bas niveau pour le framework de tests IGT, pour un public différent du nôtre.
▎
▎ Je suis ta proposition pour lsgpu → lsgpus. En revanche, lsdisplay n'est en conflit nulle part à ma connaissance (rien dans apt-file search lsdisplay, un conflit existerait-il sur Arch?). En l'absence de conflit, je préfèrerais le laisser tel quel.
▎
▎ Je prépare une v0.2.0 dès que disponible avec :
▎ - binaire /usr/bin/lsgpus (au lieu de lsgpu)
▎ - man page lsgpus.1
▎ - paquet Debian renommé en lsgpus pour la cohérence
▎
▎ Le repo GitHub reste AGuyMarc/lsgpu (pour ne pas casser les liens). Je te ping ici dès que la v0.2.0 est taguée pour que tu puisses mettre à jour l'AUR sans avoir à patcher localement.
▎
▎ Merci pour la patience et la vigilance sur le packaging !
python3 lsgpu.py --version
lsgpu 0.1.5 (2026-05-18 lun 23h28m33s)
python3 lsdisplay.py --version
lsdisplay 0.2.1 (2026-05-18 lun 23h27m25s)
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.