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.
Stéphan Peccini , dans le message <k937kf$n7o$, a é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é.
Stéphan Peccini , dans le message <k937kf$n7o$1@eweb.domicile>, a
é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é.
Stéphan Peccini , dans le message <k937kf$n7o$, a é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
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.
-- -- 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
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.
--
--
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
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.
-- -- 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
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
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
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
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.
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.
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.
Stéphane Le Men , dans le message <k93d30$d71$, a é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 , dans le message <k93d30$d71$1@speranza.aioe.org>, a
é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 , dans le message <k93d30$d71$, a é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 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.
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.
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 , dans le message <k93f4j$i3c$, a é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 , dans le message <k93f4j$i3c$1@speranza.aioe.org>, a
é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 , dans le message <k93f4j$i3c$, a é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 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.
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.
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
Stéphane Le Men , dans le message <k94q1d$9a8$, a é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é.
Stéphane Le Men , dans le message <k94q1d$9a8$1@speranza.aioe.org>, a
é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é.
Stéphane Le Men , dans le message <k94q1d$9a8$, a é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é.
