Détecter moniteur à distance en Live session Debian par CLI
Bonjour à tous :),
J'ai un système Debian en Live session (Clonezilla personnalisé avec entre autres des paquets intégrés utiles à l'administration système et réseau), que j'accède à distance par SSH (pas de GUI, juste en CLI). Depuis lui, je veux tester différents moniteurs VGA (débrancher, rebrancher) sur ports VGA et Display Port et voir qu'ils fonctionnent. Problème dès que j'ai débranché le premier moniteur, quand je rebranche le suivant (fonctionnel je précise), l'affichage reste noir, il n'est pas détecté.
Dans ce cas de figure, que feriez vous pour re-détecter les moniteurs sans avoir à rebooter et recharger la session Live (actuellement elle réalise une tâche délicate à interrompre) ?
L'idée derrière ça c'est de pouvoir utiliser une "Live session" pour tout un tas d'opérations sans avoir à la redémarrer, dont celle du test de matériels non plug and play.
Je ne sais pas si ma demande est claire, je peux préciser ...
Note : pour être sûr qu'on parle bien des mêmes choses, il n'y a pas d'environnement Xorg ou autre puisque en CLI.
Avec adelphité,
lnj
Linux / Firefox 78.0
J'ai des questions à toutes vos réponses. (Woody Allen)
6 réponses
-
Bonjour lenainjaune,
La seule commande que je connaisse pour lister les écrans (dont les "DP" dont tu parles) est la commande xrandr, qui comme son nom le suggère repose sur le serveur graphique.
A priori tu peux t'en sortir avec le contenu de /sys/class/drm qui est peuplé même si tu n'as pas de serveur graphique
(mando@silk) (~) $ ls /sys/class/drm card0 card0-eDP-1 card0-HDMI-A-1 renderD128 versionCe serait intéressant de voir ce que racontes les logs au moment où tu branches / débranches un écran :
sudo tail -f /var/log/*
Bonne chance
-
root@CZ-LIVE:~# ls /sys/class/drm version root@CZ-LIVE:~# cat /sys/class/drm/version drm 1.1.0 20060810 root@CZ-LIVE:~# ls -l /sys/class/drm* /sys/class/drm: total 0 -r--r--r-- 1 root root 4096 20 sept. 11:54 version /sys/class/drm_dp_aux_dev: total 0 root@CZ-LIVE:~# ls -al /sys/class/drm_dp_aux_dev/ total 0 drwxr-xr-x 2 root root 0 20 sept. 10:43 . drwxr-xr-x 65 root root 0 20 sept. 10:33 .. # => aucun fichierDonc les DP ne sont pas listés mais j'ai voulu creuser la piste drm :
root@CZ-LIVE:~# lsmod | sort | grep dp cec 61440 2 drm_dp_helper,i915 drm 614400 5 drm_dp_helper,drm_kms_helper,drm_buddy,i915,ttm drm_dp_helper 159744 1 i915 drm_kms_helper 192512 2 drm_dp_helper,i915=> il y aurait le pilote drm_dp_helper (dp = Display Port ?)
PS : semble corroboré par https://sources.debian.org/src/linux/5.10.140-1/include/drm/drm_dp_helper.h
Au fait merci :) pour tail -f /var/log/* qui est bien pratique pour voir l'évolution dans tous les fichiers (j'utilisais tail -f sur un fichier unique)
-
-
Tu me confirmes que xrandr n'est pas installé ? Si c'est le cas, ne peux-tu pas envisager un live plus complet (par exemple Ubuntu) pour l'avoir ?
-
Vu que c'est une session en CLI, il n'y a pas de serveur X.
Oui je pourrais prendre une autre Live Session (j'avais testé Porteus basé sur Slackware que je trouvais vraiment top en Live session graphique). Mais j'avoue avoir un faible pour Clonezilla basé sur Debian que je maîtrise bien (simple, léger, rapide, configurable à souhait car je sais ajouter dans l'image interne tous les paquets dont j'ai besoin). Aussi je ne veux pas multiplier les supports. Je préfère avoir peu et pouvoir tout faire avec (ou presque).
Rien à voir, mais je suis en train de trouver une solution pour défragmenter un système Windows ... depuis Linux (ce qui m'éviterait tous les outils Micromou et me permettrait de rester sur ma Live Session).
Mais au delà de ça, j'aimerais comprendre ... et j'imaginais que c'était plus simple (plus haut je parlais de solution pour actualiser la reconnaissance de périphériques USB, si tu suis le fil, il y a un dev qui a élaboré un tout petit programme à compiler et à exécuter qui fonctionne à merveille) !
Je laisse le fil ouvert et quand j'aurais plus d'expertise sur le sujet, je ferais un retour (j'y crois :) )
-
- Les lives Debian sont très mais ils sont prévus pour être minimaux afin d'être légers à télécharger, car il n'y a pas besoin de grand chose pour installer une debian et faire un chroot (et c'est leur rôle). Là tu t'écartes un peu de leur utilisation initiale et donc tu ne peux pas leur "reprocher" que certains outils (udev, acpi, xrandr, etc.) d'être absent. Du coup c'est peut-être le moment d'envisager ubuntu ou porteus ou n'importe quel live un peu plus complet, car je ne sais pas ce qui manque dans le cas présent.
- Concernant xrandr, la commande peut être présente malgré tout (elle l'est sur une debian installée sans interface graphique), c'est pour ça que ça mérite d'être testé. Mais il y a de forte chance qu'elle ne marche pas.
- Dans ton cas, je ne sais pas pourquoi /sys/class/drm ne contient pas grand chose, tu peux essayer de voir si c'est ailleurs (c'est comme ça que dans mon cas j'ai trouvé /sys/class/drm)
find /sys | grep DP | more
- Concernant le reste (la défragmentation, la reconnaissance USB, etc) j'avoue avoir du mal à te suivre et ça me paraît hors sujet par rapport au sujet initial, donc si tu veux en discuter, je t'invite à ouvrir un nouveau fil de discussion dans lequel tu expliqueras mieux ce que tu cherches à faire et les questions que tu te poses.
Bonne chance
-
-
Bonjour,
Il y a un truc que je ne comprends pas dans ta question : si tu as possibilité de changer l'écran sur l'ordinateur, pourquoi as-tu besoin de ssh ? Pourquoi ne pas travailler directement avec le système d'exploitation lancé sur l'ordinateur auquel tu raccordes tes écrans ?
En théorie, même en mode texte, ta carte vidéo est sensé quand tu connectes/déconnectes un écran. Est-ce que ce n'est pas simplement que ton écran a plusieurs interface d'entrée (genre VGA, DVI, display port) et ne lit pas le signal sur la bonne entrée ? Et auquel cas ce n'est pas au niveau de Linux mais bien au niveau des boutons de l'écran qu'il faut agir ?
Bonne chance
-
Bonjour mamiemando et merci de m'aider encore une fois ;)
Après avoir booté le Live USB, j'ai lancé le processus délicat alors que le moniteur était connecté au port VGA et fonctionnel. Comme j'ai voulu tester un adaptateur Display port-VGA et que je n'avais pas d'autre écran, je l'ai débranché du connecteur VGA et pour le mettre sur le DP. Comme je n'avais pas d'affichage, j'ai remis sur le VGA qui n'affiche plus rien non plus !
Je sais que dans un système classique (disons Debian), on peut brancher/débrancher sans rebooter mais là comme je suis en environnement Live, il ne doit pas y avoir les processus habituels qui rafraîchissent.
Ce que je voudrais c'est savoir comment les écrans sont détectés en coulisse pour pouvoir re-déclencher leur détection sans avoir à rebooter, etc. J'ai déjà fait ça pour de l'USB (par exemple voir ce fil), donc ça doit pouvoir se faire.
PS : hors sujet, mais j'ai toujours une réponse à te donner depuis quelques temps (voir ici) mais comme je ne suis pas revenu sur le sujet, je n'ai pas eu l'occasion de te répondre. Ça va venir sous peu, puisque je dois booster le vieux portable en question pour ma compagne.
-
Bonjour,
Il peut être nécessaire de réattacher la console avec l'affichage :
echo 1 > /sys/class/vtconsole/vtcon0/bind
(à adapter en fonction des vtconX sur ton système)
Voir ici : https://www.kernel.org/doc/html/latest/fb/fbcon.html
-
Bonjour :)
J'y ai cru ... mais ça n'a pas fonctionné, mais c'est ce genre de réponse que je recherche.
A noter :
- pour les vtconX j'ai vtcon0 et vtcon1 et l'opération n'a rien donné sur aucune des 2
- bizarrement le DP depuis cette Live Session supporte le plug and play, mais pas le VGA (?)pour
- depuis une autre live session sur un autre PC (que j'ai pu tester temporairement pendant la pause), le VGA fonctionne en PnP
Au final, je ne sais pas pourquoi je n'ai pas le même comportement sur les 2 machines.
Note : J'étudierais avec soin le lien que tu m'as proposé mais pas maintenant car j'ai des urgences et surtout je n'ai pas encore Internet chez moi après un déménagement (là je suis au boulot).
Bonjour,
Tu peux éventuellement tenter de supprimer (modprobe -r ...) puis recharger (modprobe ...) le(s) driver(s) correspondant à ton GPU, bien que cela peut conduire à des comportements instables ou des freezes.
Une autre technique peut être d'éjecter le GPU puis scanner les périphériques PCI pour le retrouver. Voir ici.
Il me semble avoir constaté ceci en session Live (je ne peux pas le confirmer en raison d'un problème matériel - voir dessous) :
- si je branche l'écran par DP avant le boot du système, le VGA sera indisponible
- si je branche l'écran sur le VGA, le DP sera indisponible
Pour couronner le tout je viens de voir que sur les 2 adaptateurs DP-VGA qu'on vient de commander le 1er n'a jamais fonctionné et le 2e fonctionnait mais maintenant a un comportement erratique (de bien belles m**des quoi !), donc en attendant les adaptateurs DP de remplacement je ne peux plus tester le DP.
Toutefois, j'ai récupéré les infos et suivi tes propositions.
Récupérer les infos :
root@cz-live:~# dmidecode -t 8 | awk -v RS="" -v ORS="\n\n" '/VGA|DISPLAY PORT/' Handle 0x001A, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: 00H Internal Connector Type: None External Reference Designator: VGA Port External Connector Type: DB-15 female Port Type: Video Port Handle 0x001B, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: 00H Internal Connector Type: None External Reference Designator: DISPLAY PORT External Connector Type: Other Port Type: Video Port root@cz-live:~# lshw -c display *-display NON-RÉCLAMÉ description: VGA compatible controller produit: 2nd Generation Core Processor Family Integrated Graphics Controller fabriquant: Intel Corporation identifiant matériel: 2 information bus: pci@0000:00:02.0 version: 09 bits: 64 bits horloge: 33MHz fonctionnalités: msi pm vga_controller bus_master cap_list configuration: latency=0 ressources: mémoire:e0c00000-e0ffffff mémoire:d0000000-dfffffff portE/S:3000(taille=64) mémoire:c0000-dffff *-graphics produit: VESA VGA identifiant matériel: 1 nom logique: /dev/fb0 fonctionnalités: fb configuration: depth=16 resolution=800,600 root@cz-live:~# lspci -vv | awk -v RS="" -v ORS="\n\n" '/ VGA /' 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller]) DeviceName: Onboard IGD Subsystem: Dell 2nd Generation Core Processor Family Integrated Graphics Controller Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 11 Region 0: Memory at e0c00000 (64-bit, non-prefetchable) [size=4M] Region 2: Memory at d0000000 (64-bit, prefetchable) [size=256M] Region 4: I/O ports at 3000 [size=64] Expansion ROM at 000c0000 [virtual] [disabled] [size=128K] Capabilities: [90] MSI: Enable- Count=1/1 Maskable- 64bit- Address: 00000000 Data: 0000 Capabilities: [d0] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [a4] PCI Advanced Features AFCap: TP+ FLR+ AFCtrl: FLR- AFStatus: TP- Kernel modules: i915Tes propositions :
root@cz-live:~# echo 1 > /sys/bus/pci/rescan => KO l'écran reste éteint root@cz-live:~# lsmod | grep i915 | sort cec 61440 2 drm_dp_helper,i915 drm 614400 5 drm_dp_helper,drm_kms_helper,drm_buddy,i915,ttm drm_buddy 20480 1 i915 drm_dp_helper 159744 1 i915 drm_kms_helper 192512 2 drm_dp_helper,i915 i2c_algo_bit 16384 1 i915 i915 3166208 0 ttm 86016 1 i915 video 57344 1 i915 root@cz-live:~# modprobe -r i915 root@cz-live:~# lsmod | grep i915 | wc -l 0 root@cz-live:~# modprobe i915 root@cz-live:~# lsmod | grep i915 | wc -l 9 => KO l'écran reste éteint root@cz-live:~# for d in $( find /sys/bus/pci/devices -maxdepth 1 -type l ) ; do echo 1 > "$d/rescan" ; done => KO l'écran reste éteintNote : je ne sais pas comment voir si le système détecte bien l'écran par le DP en Live Session en CLI donc en dehors d'une session graphique X (xrandr) ; en particulier journalctl -f n'affiche pas d'activité ...
-
-
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question -
Bonjour,
Recharger le module de la carte graphique peut effectivement débloquer la solution. Mais selon moi, il faudrait s'assurer que les paquets acpid et udev sont bien installés sur ton système live.
sudo apt update sudo apt install udev acpid acpi-support-base
Si ça ne suffit pas, as-tu regardé ce tutorial et parviens-tu à le mettre en application ?
Bonne chance
-
Dans mon cas il manquait : acpi-support-base acpid et la dépendance libudev1
J'ai tenté (voir post #7) :
root@cz-live:~# echo 1 > /sys/bus/pci/rescan root@cz-live:~# modprobe -r i915 root@cz-live:~# modprobe i915 root@cz-live:~# for d in $( find /sys/bus/pci/devices -maxdepth 1 -type l ) ; do echo 1 > "$d/rescan" ; doneet un hot-plug VGA->DP
=> KO l'écran reste toujours éteint
Je vais tester le tuto, mais j'ai l'impression qu'il nécessite un serveur X, dans mon cas je suis en CLI uniquement.
{edit]
udevadm monitor ne semble pas détecter les plugs/unplug des moniteurs
Une idée :
J'arrive à trouver le pilote du VGA (ici i915) avec lspci -vv mais comment faire pour le DP puisqu'il n'est pas listé par lspci ?
[/edit]
-
-
Bonjour,
Concernant le message #16 :
Oui, xrandr nécessite que le serveur graphique soit lancé. Attention, il ne doit pas être lancé en root (car il n'a aucune raison de l'être), au même titre que le serveur graphique. Ce n'est donc pas une bonne piste si tu ne veux pas installer et lancer un serveur graphique.
Retour à ton problème
Concernant /sys/class/drm, il est peuplé par le pilote de la carte vidéo (voir par exemple cette discussion et cette discussion), or sur un système live, il y a de fortes chances que tu charges uniquement des modules très basiques pour la prendre en charge. Cela expliquerait pourquoi dans ton cas /sys/class/drm est vide.
Dans le cas de ta carte vidéo, voir ce lien. Ça tombe bien, j'ai cette carte vidéo sur mon portable, donc voici les modules qui sont chargés en temps normaux :
(mando@silk) (~) $ lsmod | grep i915 i915 2965504 76 drm_buddy 20480 1 i915 i2c_algo_bit 16384 1 i915 drm_display_helper 180224 1 i915 cec 61440 2 drm_display_helper,i915 ttm 90112 1 i915 drm_kms_helper 192512 2 drm_display_helper,i915 drm 602112 17 drm_kms_helper,drm_display_helper,drm_buddy,i915,ttm video 57344 2 asus_wmi,i915Je pense que dans ton cas, charger le module drm devrait suffire à charger en cascade tous les modules sus-mentionnés et peupler /sys/class/drm. En root ou via sudo :
modprobe drm ls /sys/class/drm
Bonne chance
