D

Le
St
Bonjour,

J'ai un portable et je me suis associé des raccourcis claviers pour
décider de la configuration des mes écrans : interne et externe sur VGA.
Je peux décider si je branche un projecteur de conserver l'écran interne
comme étant l'écran principal positionné à gauche du projecteur, si je
branche mon écran 23 pouces de le transformer en écran principal à gauche
du portable, de forcer à n'afficher que sur l'écran du portable ou de
l'écran externe.

Je cherche maintenant à détecter le (dé)branchement de l'écran externe
afin de déclencher automatiquement les actions ou tout au moins me
proposer un choix. Par contre, je ne trouve pas comment faire ; que faut-
il « surveiller », quel événement ? Je n'ai pas d'idée.

Merci d'avance

--
Stéphan Peccini
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 3
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Nicolas George
Le #24997312
Stéphan Peccini , dans le message écrit :
Je cherche maintenant à détecter le (dé)branchement de l'écran externe
afin de déclencher automatiquement les actions ou tout au moins me
proposer un choix. Par contre, je ne trouve pas comment faire ; que faut-
il « surveiller », quel événement ? Je n'ai pas d'idée.



À ma connaissance, il n'y a aucun événement actif pour ce genre de choses,
même au niveau matériel. Je me base pour dire ça sur le fait que xrandr met
un temps court mais sensible à réagir : si X.org était au courant des
branchements, ce serait instantané.
marc
Le #24997432
Stéphan Peccini wrote:

Bonjour,

J'ai un portable et je me suis associé des raccourcis claviers pour
décider de la configuration des mes écrans : interne et externe sur VGA.
Je peux décider si je branche un projecteur de conserver l'écran interne
comme étant l'écran principal positionné à gauche du projecteur, si je
branche mon écran 23 pouces de le transformer en écran principal à gauche
du portable, de forcer à n'afficher que sur l'écran du portable ou de
l'écran externe.

Je cherche maintenant à détecter le (dé)branchement de l'écran externe
afin de déclencher automatiquement les actions ou tout au moins me
proposer un choix. Par contre, je ne trouve pas comment faire ; que faut-
il « surveiller », quel événement ? Je n'ai pas d'idée.

Merci d'avance





http://www.iloveubuntu.net/meet-vga-switch-first-open-hardware-project-
released-ubuntu

?


--
--
What's on Shortwave guide: choose an hour, go!
http://shortwave.tk
700+ Radio Stations on SW http://swstations.tk
300+ languages on SW http://radiolanguages.tk
marc
Le #24997482

http://www.iloveubuntu.net/meet-vga-switch-first-open-hardware-project-
released-ubuntu

?




relatée pour hdmi:
http://thecodecentral.com/2011/03/01/switch-to-external-monitor-connected-
via-hdmivga-port-in-ubuntu





--
--
What's on Shortwave guide: choose an hour, go!
http://shortwave.tk
700+ Radio Stations on SW http://swstations.tk
300+ languages on SW http://radiolanguages.tk
Nicolas George
Le #24997472
marc , dans le message
http://www.iloveubuntu.net/meet-vga-switch-first-open-hardware-project-
released-ubuntu



C'est quoi le rapport avec la question ?
Stéphane Le Men
Le #24997642
Le 27/11/2012 20:59, Nicolas George a écrit :
proposer un choix. Par contre, je ne trouve pas comment faire ; que faut-
>il « surveiller », quel événement ? Je n'ai pas d'idée.



À ma connaissance, il n'y a aucun événement actif pour ce genre de choses,
même au niveau matériel. Je me base pour dire ça sur le fait que xrandr met
un temps court mais sensible à réagir : si X.org était au courant des
branchements, ce serait instantané.



Non non, ça marche chez moi, c'est bien la commande xrandr

while [ 1 ] ; do xrandr --prop ; sleep 10; done

Si tu (dé)branches pendant la boucle, les informations EDID (dis)paraissent.

http://pinouts.ru/Video/VGA15_pinout.shtml

Avec la 11, la 12 ou la 15 doivent servir à rentrer de l'info.

Ici, il y a une présentation du truc

http://www.x.org/wiki/XDC2007Notes?action=AttachFile&do=get&target=Xorg_2007-EDID-JMiseli.pdf
Nicolas George
Le #24997722
Stéphane Le Men , dans le message écrit :
Non non, ça marche chez moi, c'est bien la commande xrandr

while [ 1 ] ; do xrandr --prop ; sleep 10; done

Si tu (dé)branches pendant la boucle, les informations EDID (dis)paraissent.



Je n'ai pas dit le contraire, tu n'as pas bien compris mon message. Je
reformule : la détection des informations sur une prise du contrôleur réseau
est une opération active, effectuée en réaction à une décision logicielle
(ici, ton xrandr lancé en boucle toutes les dix secondes) et pas une
opération passive, initée par le matériel lui-même.
Stéphane Le Men
Le #24997812
Le 27/11/2012 23:08, Nicolas George a écrit :
tu n'as pas bien compris mon message.



Oui, je suis fatigué le soir ! désolé

reformule : la détection des informations sur une prise du contrôleur réseau
est une opération active, effectuée en réaction à une décision logicielle
(ici, ton xrandr lancé en boucle toutes les dix secondes) et pas une
opération passive, initée par le matériel lui-même.



Avec udev cela doit se faire.

Pas testé, mais en googlant tu trouves cela

http://stackoverflow.com/questions/5469828/how-to-create-a-callback-for-monitor-plugged-on-an-intel-graphics
Nicolas George
Le #24998162
Stéphane Le Men , dans le message écrit :
Avec udev cela doit se faire.



udev n'est pas magique, si le matériel n'envoie pas de signal, il ne peut
rien y faire.

Pas testé, mais en googlant tu trouves cela
http://stackoverflow.com/questions/5469828/how-to-create-a-callback-for-monitor-plugged-on-an-intel-graphics



Qui conseille de consulter /sys/class/drm/card$n-$out/status ; la lecture du
code du noyau montre que le contenu de ce fichier est calculé en
interrogeant activement le contrôleur graphique :

status = connector->funcs->detect(connector, true);
Stéphane Le Men
Le #24998672
Le 28/11/2012 09:44, Nicolas George a écrit :

udev n'est pas magique, si le matériel n'envoie pas de signal, il ne peut
rien y faire.



C'est clair, la télépathie ne fonctionne que sur Windows

Qui conseille de consulter /sys/class/drm/card$n-$out/status ; la lecture du
code du noyau montre que le contenu de ce fichier est calculé en
interrogeant activement le contrôleur graphique :

status = connector->funcs->detect(connector, true);



Je ne vais pas aussi loin, je lis juste le man udev:

The udev daemon, udevd(8), receives device uevents directly from the
kernel whenever a device is added or removed from the system, or it
changes its state.

Que le kernel soit obligé de faire une attente active parce qu'il a un
hard à "2 balles", il y a 3 lignes sur le port de base VGA en entrée, si
la carte n'est pas capable remonter un signal au kernel, ben on y peut
rien, faudra faire avec, mieux une attente active que rien du tout.

Après si udev ou le kernel bouffe x% du CPU pour voir si le port a
changé d'état, ce sera le cout qu'aura en exploit ce hard, exactement
comme les WinModem bouffaient du CPU pour faire le job d'un composant.

Maintenant, sur la page russe du port VGA, il y a deux fils qui sont
marqués i2c. J'y connais rien en i2c, tout ce que je sais c'est que i2c
c'est un protocole de hard, et cela doit causer aussi au kernel.

C'est bien possible qu'il y ait des fabricants carte video qui
s'assoient sur l'utilité de ces lignes de données, mais pour ceux qui
les utilisent, c'est bien possible que par le biais du bus i2c la carte
video dise au kernel "il s'est passé qqchose sur mon port VGA là, tu
veux pas aller voire ce qui s'est passé ?" et donc la ligne de code que
tu montres qui a tout l'air d'être une attente active, n'en est pas une
parce que cette ligne de code est sollicitée par une interruption
arrivée sur le driver du bus i2c de la carte vidéo.

Je ne mettrai pas ma main au feu que c'est fait comme cela, mais j'ai du
mal à croire que la détection d'un changement d'état sur le port video
nécessite une attente active en kernel.

Sur mon 3.6.7, il y a une dépendance de module kernel entre i2c et drm

rmmod i2c_core

Error: Module i2c_core is in use by: drm i2c_piix4 drm_kms_helper
i2c_algo_bit radeon videodev

Franchement, si en 2012, les specs du PC nécessitent encore une attente
active en kernel pour détecter un changement d'état du port VGA, c'est
vraiment "ze big shame" pour le PC.
Nicolas George
Le #24998892
Stéphane Le Men , dans le message écrit :
mieux une attente active que rien du tout.



C'est une position extrêmement contestable.

Après si udev ou le kernel bouffe x% du CPU pour voir si le port a
changé d'état, ce sera le cout qu'aura en exploit ce hard



Non, absolument pas. Le noyau ou le serveur X11 n'ont absolument pas
_besoin_ d'être notifiés du branchement d'un moniteur, et pour l'immense
majorité des utilisateurs cette consommation CPU, et donc électrique, serait
en pure perte.

C'est bien possible qu'il y ait des fabricants carte video qui
s'assoient sur l'utilité de ces lignes de données, mais pour ceux qui
les utilisent, c'est bien possible que par le biais du bus i2c la carte
video dise au kernel "il s'est passé qqchose sur mon port VGA là, tu
veux pas aller voire ce qui s'est passé ?" et donc la ligne de code que
tu montres qui a tout l'air d'être une attente active, n'en est pas une
parce que cette ligne de code est sollicitée par une interruption
arrivée sur le driver du bus i2c de la carte vidéo.



Tu spécules.

Je ne mettrai pas ma main au feu que c'est fait comme cela, mais j'ai du
mal à croire que la détection d'un changement d'état sur le port video
nécessite une attente active en kernel.



Ah, manifestement tu es encore très naïf.

Sur mon 3.6.7, il y a une dépendance de module kernel entre i2c et drm



Ça ne prouve rien quant à la notification.

Franchement, si en 2012, les specs du PC nécessitent encore une attente
active en kernel pour détecter un changement d'état du port VGA, c'est
vraiment "ze big shame" pour le PC.



L'architecture PC est pourrie, elle l'était il y a trente ans, ça n'a pas
changé.
Publicité
Poster une réponse
Anonyme