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.
Ha bon, et pourquoi ? Si le hard ne sait pas, est-ce sale de faire par soft ?
>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.
Ce n'est pas le cas de l'OP
>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.
C'est bien possible mais en cherchant un peu on trouve ce genre de patch :
"We detect HDMI output connection status by writing to HOT Plug Interrupt Detect Enable bit in PORT_HOTPLUG_EN. The behavior will generate an specified interrupt, which is caught by audio driver, but during one detection driver set all Detect Enable bits of HDMIB, HDMIC and HDMID, which generate wrong interrupt signals for current output, according to the signals audio driver misunderstand device status. The patch intends to handle corresponding output precisely."
Alors peut être que l'interruption est le luxe de l'HDMI ! Ils ont l'air de faire un peu des spaghettis avec les interruptions, mais je ne leur jettes pas la pierre.
>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.
A Intel, ils ont l'air d'être plutôt de mon avis que du tien, sinon ils se prendraient pas la tête à gérer des interruptions dans leurs drivers pour du hotplug.
>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.
Je reconnais, le patch que j'ai trouvé concerne que le HDMI (qui a aussi un bus i2c) et que ceux qui n'ont pas la ou les bonnes cartes, font de l'attente active pour détecter le HotPlug
>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é.
Honnêtement, j'ai toujours détesté les PC, mais quand je vois le PCI-Express Gen 1,2,3, la mémoire et les CPU d’aujourd’hui, je remarque un changement, même un sacré changement. Et si on prend la peine de choisir un bon constructeur de PC, on peut avoir une machine très correct à petit prix. Fuir le PC coute cher, très cher.
Certes, j'aurais un peu peur de savoir que nos chaudrons atomiques sont gérés par des PC, mais je parie quand même qu'à Airbus, il y a quelques PC qui sortent de chez eux qui ont eu certif "aviation" et qui volent tous les jours au dessus de nos têtes.
Le 28/11/2012 12:03, Nicolas George a écrit :
> mieux une attente active que rien du tout.
C'est une position extrêmement contestable.
Ha bon, et pourquoi ?
Si le hard ne sait pas, est-ce sale de faire par soft ?
>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.
Ce n'est pas le cas de l'OP
>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.
C'est bien possible mais en cherchant un peu on trouve ce genre de patch :
"We detect HDMI output connection status by writing to HOT Plug
Interrupt Detect Enable bit in PORT_HOTPLUG_EN. The behavior will
generate an specified interrupt, which is caught by audio driver, but
during one detection driver set all Detect Enable bits of HDMIB, HDMIC
and HDMID, which generate wrong interrupt signals for current output,
according to the signals audio driver misunderstand device status. The
patch intends to handle corresponding output precisely."
Alors peut être que l'interruption est le luxe de l'HDMI ! Ils ont l'air
de faire un peu des spaghettis avec les interruptions, mais je ne leur
jettes pas la pierre.
>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.
A Intel, ils ont l'air d'être plutôt de mon avis que du tien, sinon ils
se prendraient pas la tête à gérer des interruptions dans leurs drivers
pour du hotplug.
>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.
Je reconnais, le patch que j'ai trouvé concerne que le HDMI (qui a aussi
un bus i2c) et que ceux qui n'ont pas la ou les bonnes cartes, font de
l'attente active pour détecter le HotPlug
>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é.
Honnêtement, j'ai toujours détesté les PC, mais quand je vois le
PCI-Express Gen 1,2,3, la mémoire et les CPU d’aujourd’hui, je remarque
un changement, même un sacré changement. Et si on prend la peine de
choisir un bon constructeur de PC, on peut avoir une machine très
correct à petit prix. Fuir le PC coute cher, très cher.
Certes, j'aurais un peu peur de savoir que nos chaudrons atomiques sont
gérés par des PC, mais je parie quand même qu'à Airbus, il y a quelques
PC qui sortent de chez eux qui ont eu certif "aviation" et qui volent
tous les jours au dessus de nos têtes.
Ha bon, et pourquoi ? Si le hard ne sait pas, est-ce sale de faire par soft ?
>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.
Ce n'est pas le cas de l'OP
>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.
C'est bien possible mais en cherchant un peu on trouve ce genre de patch :
"We detect HDMI output connection status by writing to HOT Plug Interrupt Detect Enable bit in PORT_HOTPLUG_EN. The behavior will generate an specified interrupt, which is caught by audio driver, but during one detection driver set all Detect Enable bits of HDMIB, HDMIC and HDMID, which generate wrong interrupt signals for current output, according to the signals audio driver misunderstand device status. The patch intends to handle corresponding output precisely."
Alors peut être que l'interruption est le luxe de l'HDMI ! Ils ont l'air de faire un peu des spaghettis avec les interruptions, mais je ne leur jettes pas la pierre.
>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.
A Intel, ils ont l'air d'être plutôt de mon avis que du tien, sinon ils se prendraient pas la tête à gérer des interruptions dans leurs drivers pour du hotplug.
>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.
Je reconnais, le patch que j'ai trouvé concerne que le HDMI (qui a aussi un bus i2c) et que ceux qui n'ont pas la ou les bonnes cartes, font de l'attente active pour détecter le HotPlug
>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é.
Honnêtement, j'ai toujours détesté les PC, mais quand je vois le PCI-Express Gen 1,2,3, la mémoire et les CPU d’aujourd’hui, je remarque un changement, même un sacré changement. Et si on prend la peine de choisir un bon constructeur de PC, on peut avoir une machine très correct à petit prix. Fuir le PC coute cher, très cher.
Certes, j'aurais un peu peur de savoir que nos chaudrons atomiques sont gérés par des PC, mais je parie quand même qu'à Airbus, il y a quelques PC qui sortent de chez eux qui ont eu certif "aviation" et qui volent tous les jours au dessus de nos têtes.
Nicolas George
Stéphane Le Men , dans le message <k95c8m$p3h$, a écrit :
> mieux une attente active que rien du tout.
C'est une position extrêmement contestable.
Ha bon, et pourquoi ?
Parce que ce n'est pas nécessaire.
Si le hard ne sait pas, est-ce sale de faire par soft ?
Si on peut s'en passer, oui.
Ce n'est pas le cas de l'OP
Oui. Son cas est très atypique.
Alors peut être que l'interruption est le luxe de l'HDMI !
Il y a de fortes chances.
Honnêtement, j'ai toujours détesté les PC, mais quand je vois le PCI-Express Gen 1,2,3, la mémoire et les CPU d’aujourd’hui, je remarque un changement, même un sacré changement. Et si on prend la peine de choisir un bon constructeur de PC, on peut avoir une machine très correct à petit prix.
Oh, tu auras une machine correcte pas chère, mais l'architecture sera pourrie, ça n'est pas une contradiction.
Stéphane Le Men , dans le message <k95c8m$p3h$1@speranza.aioe.org>, a
écrit :
> mieux une attente active que rien du tout.
C'est une position extrêmement contestable.
Ha bon, et pourquoi ?
Parce que ce n'est pas nécessaire.
Si le hard ne sait pas, est-ce sale de faire par soft ?
Si on peut s'en passer, oui.
Ce n'est pas le cas de l'OP
Oui. Son cas est très atypique.
Alors peut être que l'interruption est le luxe de l'HDMI !
Il y a de fortes chances.
Honnêtement, j'ai toujours détesté les PC, mais quand je vois le
PCI-Express Gen 1,2,3, la mémoire et les CPU d’aujourd’hui, je remarque
un changement, même un sacré changement. Et si on prend la peine de
choisir un bon constructeur de PC, on peut avoir une machine très
correct à petit prix.
Oh, tu auras une machine correcte pas chère, mais l'architecture sera
pourrie, ça n'est pas une contradiction.
Stéphane Le Men , dans le message <k95c8m$p3h$, a écrit :
> mieux une attente active que rien du tout.
C'est une position extrêmement contestable.
Ha bon, et pourquoi ?
Parce que ce n'est pas nécessaire.
Si le hard ne sait pas, est-ce sale de faire par soft ?
Si on peut s'en passer, oui.
Ce n'est pas le cas de l'OP
Oui. Son cas est très atypique.
Alors peut être que l'interruption est le luxe de l'HDMI !
Il y a de fortes chances.
Honnêtement, j'ai toujours détesté les PC, mais quand je vois le PCI-Express Gen 1,2,3, la mémoire et les CPU d’aujourd’hui, je remarque un changement, même un sacré changement. Et si on prend la peine de choisir un bon constructeur de PC, on peut avoir une machine très correct à petit prix.
Oh, tu auras une machine correcte pas chère, mais l'architecture sera pourrie, ça n'est pas une contradiction.
Nicolas George
Stéphan Peccini , dans le message <k95t19$89q$, a écrit :
[ bin]$ more /etc/udev/rules.d/99-monitor-hotplug.rules ACTION=="change", SUBSYSTEM=="drm", RUN+="/usr/local/bin/hotplug.sh"
Et ton script est effectivement exécuté à chaque fois que tu branches l'écran ?
Stéphan Peccini , dans le message <k95t19$89q$1@eweb.domicile>, a
écrit :
[stephan@ldlc bin]$ more /etc/udev/rules.d/99-monitor-hotplug.rules
ACTION=="change", SUBSYSTEM=="drm", RUN+="/usr/local/bin/hotplug.sh"
Et ton script est effectivement exécuté à chaque fois que tu branches
l'écran ?
Stéphan Peccini , dans le message <k95t19$89q$, a écrit :
[ bin]$ more /etc/udev/rules.d/99-monitor-hotplug.rules ACTION=="change", SUBSYSTEM=="drm", RUN+="/usr/local/bin/hotplug.sh"
Et ton script est effectivement exécuté à chaque fois que tu branches l'écran ?
moi-meme
Le Wed, 28 Nov 2012 16:16:36 +0000, Nicolas George a écrit :
Honnêtement, j'ai toujours détesté les PC, mais quand je vois le PCI-Express Gen 1,2,3, la mémoire et les CPU d’aujourd’hui, je remarque un changement, même un sacré changement. Et si on prend la peine de choisir un bon constructeur de PC, on peut avoir une machine très correct à petit prix.
Oh, tu auras une machine correcte pas chère, mais l'architecture sera pourrie, ça n'est pas une contradiction.
M$ se mettant aux tablettes (processeur ARM et plus X86 et dérivés) on va finir par trouver des PC sous ARM aussi avec une architecture plus correcte, consommant moins et moins cher aussi.
Le Wed, 28 Nov 2012 16:16:36 +0000, Nicolas George a écrit :
Honnêtement, j'ai toujours détesté les PC, mais quand je vois le
PCI-Express Gen 1,2,3, la mémoire et les CPU d’aujourd’hui, je remarque
un changement, même un sacré changement. Et si on prend la peine de
choisir un bon constructeur de PC, on peut avoir une machine très
correct à petit prix.
Oh, tu auras une machine correcte pas chère, mais l'architecture sera
pourrie, ça n'est pas une contradiction.
M$ se mettant aux tablettes (processeur ARM et plus X86 et dérivés) on
va finir par trouver des PC sous ARM aussi avec une architecture plus
correcte, consommant moins et moins cher aussi.
Le Wed, 28 Nov 2012 16:16:36 +0000, Nicolas George a écrit :
Honnêtement, j'ai toujours détesté les PC, mais quand je vois le PCI-Express Gen 1,2,3, la mémoire et les CPU d’aujourd’hui, je remarque un changement, même un sacré changement. Et si on prend la peine de choisir un bon constructeur de PC, on peut avoir une machine très correct à petit prix.
Oh, tu auras une machine correcte pas chère, mais l'architecture sera pourrie, ça n'est pas une contradiction.
M$ se mettant aux tablettes (processeur ARM et plus X86 et dérivés) on va finir par trouver des PC sous ARM aussi avec une architecture plus correcte, consommant moins et moins cher aussi.
St
Le Tue, 27 Nov 2012 20:25:51 +0000, Stéphan Peccini 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.
Grâce aux indications données par Stéphane, voici ce que j'ai fait.
Comme inotifywait ne marche pas sur /sys/class/drm/card0-VGA-1/status, je suis donc passé par l'écriture d'un fichier sous /var/tmp/VGA
[ bin]$ more /etc/udev/rules.d/99-monitor-hotplug.rules ACTION=="change", SUBSYSTEM=="drm", RUN+="/usr/local/bin/hotplug.sh" [ bin]$ more /usr/local/bin/hotplug.sh #!/bin/sh
Puis je surveille ce fichier pour savoir ce que je dois faire.
[ bin]$ more /usr/local/bin/surveille_VGA #!/bin/sh
inotifywait -q -m -r -e modify /var/tmp/VGA --format '%w%f|%e' | sed -- unbuffered 's/|.*//g' | while read FICHIER ; do if [ `cat /var/tmp/VGA` = "connected" ] ; then if zenity --question --text="Utiliser l'écran externe comme écran principal ?" ...
Et je lance ce script au démarrage de ma session.
Il ne me reste plus qu'à comprendre comment fonctionne EDID afin de switcher de manière plus automatique, et tout sera bien.
Je ne sais pas si c'est le plus efficace mais cela marche.
-- Stéphan Peccini
Le Tue, 27 Nov 2012 20:25:51 +0000, Stéphan Peccini 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.
Grâce aux indications données par Stéphane, voici ce que j'ai fait.
Comme inotifywait ne marche pas sur /sys/class/drm/card0-VGA-1/status, je
suis donc passé par l'écriture d'un fichier sous /var/tmp/VGA
[stephan@ldlc bin]$ more /etc/udev/rules.d/99-monitor-hotplug.rules
ACTION=="change", SUBSYSTEM=="drm", RUN+="/usr/local/bin/hotplug.sh"
[stephan@ldlc bin]$ more /usr/local/bin/hotplug.sh
#!/bin/sh
Puis je surveille ce fichier pour savoir ce que je dois faire.
[stephan@ldlc bin]$ more /usr/local/bin/surveille_VGA
#!/bin/sh
inotifywait -q -m -r -e modify /var/tmp/VGA --format '%w%f|%e' | sed --
unbuffered 's/|.*//g' |
while read FICHIER ;
do
if [ `cat /var/tmp/VGA` = "connected" ] ;
then
if zenity --question --text="Utiliser l'écran externe comme écran
principal ?"
...
Et je lance ce script au démarrage de ma session.
Il ne me reste plus qu'à comprendre comment fonctionne EDID afin de
switcher de manière plus automatique, et tout sera bien.
Je ne sais pas si c'est le plus efficace mais cela marche.
Le Tue, 27 Nov 2012 20:25:51 +0000, Stéphan Peccini 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.
Grâce aux indications données par Stéphane, voici ce que j'ai fait.
Comme inotifywait ne marche pas sur /sys/class/drm/card0-VGA-1/status, je suis donc passé par l'écriture d'un fichier sous /var/tmp/VGA
[ bin]$ more /etc/udev/rules.d/99-monitor-hotplug.rules ACTION=="change", SUBSYSTEM=="drm", RUN+="/usr/local/bin/hotplug.sh" [ bin]$ more /usr/local/bin/hotplug.sh #!/bin/sh
Puis je surveille ce fichier pour savoir ce que je dois faire.
[ bin]$ more /usr/local/bin/surveille_VGA #!/bin/sh
inotifywait -q -m -r -e modify /var/tmp/VGA --format '%w%f|%e' | sed -- unbuffered 's/|.*//g' | while read FICHIER ; do if [ `cat /var/tmp/VGA` = "connected" ] ; then if zenity --question --text="Utiliser l'écran externe comme écran principal ?" ...
Et je lance ce script au démarrage de ma session.
Il ne me reste plus qu'à comprendre comment fonctionne EDID afin de switcher de manière plus automatique, et tout sera bien.
Je ne sais pas si c'est le plus efficace mais cela marche.
-- Stéphan Peccini
St
Le Wed, 28 Nov 2012 20:28:57 +0000, Nicolas George a écrit :
Stéphan Peccini , dans le message <k95t19$89q$, a écrit :
[ bin]$ more /etc/udev/rules.d/99-monitor-hotplug.rules ACTION=="change", SUBSYSTEM=="drm", RUN+="/usr/local/bin/hotplug.sh"
Et ton script est effectivement exécuté à chaque fois que tu branches l'écran ?
Oui, à chaque fois. Je branche, j'ai un menu (avec zenity) pour choisir si je prends l'écran externe en tant que principal, je débranche, je remets l'écran du portable comme écran principal. Efficace et simple.
Le Wed, 28 Nov 2012 20:28:57 +0000, Nicolas George a écrit :
Stéphan Peccini , dans le message <k95t19$89q$1@eweb.domicile>, a
écrit :
[stephan@ldlc bin]$ more /etc/udev/rules.d/99-monitor-hotplug.rules
ACTION=="change", SUBSYSTEM=="drm", RUN+="/usr/local/bin/hotplug.sh"
Et ton script est effectivement exécuté à chaque fois que tu branches
l'écran ?
Oui, à chaque fois. Je branche, j'ai un menu (avec zenity) pour choisir
si je prends l'écran externe en tant que principal, je débranche, je
remets l'écran du portable comme écran principal. Efficace et simple.
Le Wed, 28 Nov 2012 20:28:57 +0000, Nicolas George a écrit :
Stéphan Peccini , dans le message <k95t19$89q$, a écrit :
[ bin]$ more /etc/udev/rules.d/99-monitor-hotplug.rules ACTION=="change", SUBSYSTEM=="drm", RUN+="/usr/local/bin/hotplug.sh"
Et ton script est effectivement exécuté à chaque fois que tu branches l'écran ?
Oui, à chaque fois. Je branche, j'ai un menu (avec zenity) pour choisir si je prends l'écran externe en tant que principal, je débranche, je remets l'écran du portable comme écran principal. Efficace et simple.
Tonton Th
On 11/28/2012 09:29 PM, moi-meme a dit:
[ARM] avec une architecture plus correcte,
Dictée par microsoft ? J'ai comme un doute...
--
Nous vivons dans un monde étrange/ http://foo.bar.quux.over-blog.com/
On 11/28/2012 09:29 PM, moi-meme a dit:
[ARM] avec une architecture plus
correcte,
Dictée par microsoft ? J'ai comme un doute...
--
Nous vivons dans un monde étrange/
http://foo.bar.quux.over-blog.com/
Nous vivons dans un monde étrange/ http://foo.bar.quux.over-blog.com/
Sergio
Le Wed, 28 Nov 2012 23:03:56 +0100, Tonton Th a écrit :
On 11/28/2012 09:29 PM, moi-meme a dit:
[ARM] avec une architecture plus correcte,
Dictée par microsoft ? J'ai comme un doute...
Où tu y vois du Microsoft ?
La plupart des tablettes, téléphones portables etc. sont à base d'ARM, sans que MS y mette son nez. On y trouve : - Du Linux - De l'Androïd - De l'iOS - Du Symbian - Des Playstation (quel OS ?) - Et même un peu de Windows CE / Windows Phone / Windows RT
MS a pris le train en route, c'est tout...
Le Wed, 28 Nov 2012 23:03:56 +0100, Tonton Th a écrit :
On 11/28/2012 09:29 PM, moi-meme a dit:
[ARM] avec une architecture plus correcte,
Dictée par microsoft ? J'ai comme un doute...
Où tu y vois du Microsoft ?
La plupart des tablettes, téléphones portables etc. sont à base d'ARM,
sans que MS y mette son nez. On y trouve :
- Du Linux
- De l'Androïd
- De l'iOS
- Du Symbian
- Des Playstation (quel OS ?)
- Et même un peu de Windows CE / Windows Phone / Windows RT
Le Wed, 28 Nov 2012 23:03:56 +0100, Tonton Th a écrit :
On 11/28/2012 09:29 PM, moi-meme a dit:
[ARM] avec une architecture plus correcte,
Dictée par microsoft ? J'ai comme un doute...
Où tu y vois du Microsoft ?
La plupart des tablettes, téléphones portables etc. sont à base d'ARM, sans que MS y mette son nez. On y trouve : - Du Linux - De l'Androïd - De l'iOS - Du Symbian - Des Playstation (quel OS ?) - Et même un peu de Windows CE / Windows Phone / Windows RT
MS a pris le train en route, c'est tout...
moi-meme
Le Thu, 29 Nov 2012 05:34:36 +0000, Sergio a écrit :
La plupart des tablettes, téléphones portables etc. sont à base d'ARM, sans que MS y mette son nez. On y trouve : - Du Linux - De l'Androïd - De l'iOS - Du Symbian - Des Playstation (quel OS ?) - Et même un peu de Windows CE / Windows Phone / Windows RT
MS a pris le train en route, c'est tout...
+1 Les sociétés hégémoniques sont déconnectées de la réalité : Kodak a loupé l'APN comme M$ a loupé l'internet.
Ce que je voulais dire : comme tous les PC sont livrés avec M$, si M$ se met à l'ARM les PC seront avec ARM ... on peut le souhaiter.
Le Thu, 29 Nov 2012 05:34:36 +0000, Sergio a écrit :
La plupart des tablettes, téléphones portables etc. sont à base d'ARM,
sans que MS y mette son nez. On y trouve : - Du Linux - De l'Androïd
- De l'iOS
- Du Symbian
- Des Playstation (quel OS ?)
- Et même un peu de Windows CE / Windows Phone / Windows RT
MS a pris le train en route, c'est tout...
+1
Les sociétés hégémoniques sont déconnectées de la réalité : Kodak a loupé
l'APN comme M$ a loupé l'internet.
Ce que je voulais dire : comme tous les PC sont livrés avec M$, si M$ se
met à l'ARM les PC seront avec ARM ... on peut le souhaiter.
Le Thu, 29 Nov 2012 05:34:36 +0000, Sergio a écrit :
La plupart des tablettes, téléphones portables etc. sont à base d'ARM, sans que MS y mette son nez. On y trouve : - Du Linux - De l'Androïd - De l'iOS - Du Symbian - Des Playstation (quel OS ?) - Et même un peu de Windows CE / Windows Phone / Windows RT
MS a pris le train en route, c'est tout...
+1 Les sociétés hégémoniques sont déconnectées de la réalité : Kodak a loupé l'APN comme M$ a loupé l'internet.
Ce que je voulais dire : comme tous les PC sont livrés avec M$, si M$ se met à l'ARM les PC seront avec ARM ... on peut le souhaiter.
Stéphane Le Men
Le 28/11/2012 21:43, Stéphan Peccini a écrit :
Comme inotifywait ne marche pas sur /sys/class/drm/card0-VGA-1/status, je suis donc passé par l'écriture d'un fichier sous /var/tmp/VGA
Tu peux aussi utiliser un pipe nommé, c'est plus confortable dans ce cas
Puis je surveille ce fichier pour savoir ce que je dois faire.
En utilisant un pipe, tu n'as plus besoin de surveiller, c'est le pipe qui va te réveiller
[ bin]$ more /usr/local/bin/surveille_VGA
while [ 1 ] do cat /var/tmp/VGA | fonction_de_ce_je_dois_en_faire() done
Il faut penser à protéger ton pipe en écriture _et_ lecture que pour toi, sinon d'autres utilisateurs peuvent foutre la grouille.
Et je lance ce script au démarrage de ma session.
Avec le pipe, il y a la contrainte d'être sûr que le nombre d'écriture sur le pipe est exactement égale au nombre de lecture, sinon tu vas bloquer le script sur l’écriture du pipe si personne n'est là pour le lire.
Je pense que c'est mieux que ce soit ton utilisateur "toto" qui crée le pipe, et que le script hotplug.sh lancé par udev cherche s'il n'y a pas un "toto" sur la machine qui voudrait savoir quand l'écran est (dé)branché en cherchant "cat" bloqué sur un pipe nommé user-nuprocess-vga dans la liste des process. Si pas de "cat trouvé" alors le script hotplug n’écrit pas dans le pipe pour éviter de se retrouver bloqué.
Il ne me reste plus qu'à comprendre comment fonctionne EDID afin de switcher de manière plus automatique, et tout sera bien.
xrandr peut te donner des infos, il y a aussi une commande ddccontrol pour les infos propres à chaque moniteur que tu obtiens sur le bus i2c du port vga.
Le 28/11/2012 21:43, Stéphan Peccini a écrit :
Comme inotifywait ne marche pas sur /sys/class/drm/card0-VGA-1/status, je
suis donc passé par l'écriture d'un fichier sous /var/tmp/VGA
Tu peux aussi utiliser un pipe nommé, c'est plus confortable dans ce cas
mknod /var/tmp/VGA p
[stephan@ldlc bin]$ more /usr/local/bin/hotplug.sh
#!/bin/sh
Puis je surveille ce fichier pour savoir ce que je dois faire.
En utilisant un pipe, tu n'as plus besoin de surveiller, c'est le pipe
qui va te réveiller
[stephan@ldlc bin]$ more /usr/local/bin/surveille_VGA
while [ 1 ]
do
cat /var/tmp/VGA | fonction_de_ce_je_dois_en_faire()
done
Il faut penser à protéger ton pipe en écriture _et_ lecture que pour
toi, sinon d'autres utilisateurs peuvent foutre la grouille.
Et je lance ce script au démarrage de ma session.
Avec le pipe, il y a la contrainte d'être sûr que le nombre d'écriture
sur le pipe est exactement égale au nombre de lecture, sinon tu vas
bloquer le script sur l’écriture du pipe si personne n'est là pour le lire.
Je pense que c'est mieux que ce soit ton utilisateur "toto" qui crée le
pipe, et que le script hotplug.sh lancé par udev cherche s'il n'y a pas
un "toto" sur la machine qui voudrait savoir quand l'écran est
(dé)branché en cherchant "cat" bloqué sur un pipe nommé
user-nuprocess-vga dans la liste des process. Si pas de "cat trouvé"
alors le script hotplug n’écrit pas dans le pipe pour éviter de se
retrouver bloqué.
Il ne me reste plus qu'à comprendre comment fonctionne EDID afin de
switcher de manière plus automatique, et tout sera bien.
xrandr peut te donner des infos, il y a aussi une commande ddccontrol
pour les infos propres à chaque moniteur que tu obtiens sur le bus i2c
du port vga.
Puis je surveille ce fichier pour savoir ce que je dois faire.
En utilisant un pipe, tu n'as plus besoin de surveiller, c'est le pipe qui va te réveiller
[ bin]$ more /usr/local/bin/surveille_VGA
while [ 1 ] do cat /var/tmp/VGA | fonction_de_ce_je_dois_en_faire() done
Il faut penser à protéger ton pipe en écriture _et_ lecture que pour toi, sinon d'autres utilisateurs peuvent foutre la grouille.
Et je lance ce script au démarrage de ma session.
Avec le pipe, il y a la contrainte d'être sûr que le nombre d'écriture sur le pipe est exactement égale au nombre de lecture, sinon tu vas bloquer le script sur l’écriture du pipe si personne n'est là pour le lire.
Je pense que c'est mieux que ce soit ton utilisateur "toto" qui crée le pipe, et que le script hotplug.sh lancé par udev cherche s'il n'y a pas un "toto" sur la machine qui voudrait savoir quand l'écran est (dé)branché en cherchant "cat" bloqué sur un pipe nommé user-nuprocess-vga dans la liste des process. Si pas de "cat trouvé" alors le script hotplug n’écrit pas dans le pipe pour éviter de se retrouver bloqué.
Il ne me reste plus qu'à comprendre comment fonctionne EDID afin de switcher de manière plus automatique, et tout sera bien.
xrandr peut te donner des infos, il y a aussi une commande ddccontrol pour les infos propres à chaque moniteur que tu obtiens sur le bus i2c du port vga.
