J'ai besoin de pouvoir désactiver complètement le clavier par programmation
(shell zsh), afin que quelque-soit les (combinaisons de) touches tapées il
n'y ait aucune influence.
Le but avoué de cela est qu'une personne vienne brancher un clavier sur un
module préinstallé Linux, qu'il tape une clé WEP, et ceci fait qu'il ne
puisse plus du tout manipuler ce module.
Comment dois-je m'y prendre ?
P.S. : je ne pense pas que cela soit important, mais je suis sous Mandrake
10.
On Fri, 25 Feb 2005 00:11:32 +0100 Jerome Lambert wrote:
Ceux qui continuent à implémenter ça sur des cartes mères sont *aussi* des charlots...
Sauf que je n'ai pas les moyens que 20% de mon temps CPU soient consacrés à la communication avec clavier et souris USB.
-- Jérémy JUST
l'indien
On Sat, 26 Feb 2005 13:36:20 +0100, Jérémy JUST wrote:
On Fri, 25 Feb 2005 00:11:32 +0100 Jerome Lambert wrote:
Ceux qui continuent à implémenter ça sur des cartes mères sont *aussi* des charlots...
Sauf que je n'ai pas les moyens que 20% de mon temps CPU soient consacrés à la communication avec clavier et souris USB.
20% du temps CPU pour communiquer en USB 1.0 ? Tu as un gros problème, là... Pour info, 20% du temps CPU, c'est ce que je consome pour transférer 600 ko/s sur un PPC à 200 Mhz en utilisant un chip USB avec lequel il faut tout faire à la main (le sl811 de scanlogic, pour ceux qui connaissent). Un clavier ou une souris, qui typiquement vont utiliser un paquet de 8 ou 16 octets max par frame USB, ça fait du 16 ko/s max si tu as des évènements tous le temps ! Un calcul simpliste me fait estimer que tu consomerais 20 % du CPU pour faire celà, disons avec un 486 à 25 ou 33 Mhz...
On Sat, 26 Feb 2005 13:36:20 +0100, Jérémy JUST wrote:
On Fri, 25 Feb 2005 00:11:32 +0100
Jerome Lambert <jerome.lambert@swing.be> wrote:
Ceux qui continuent à implémenter ça sur des cartes mères sont *aussi*
des charlots...
Sauf que je n'ai pas les moyens que 20% de mon temps CPU soient
consacrés à la communication avec clavier et souris USB.
20% du temps CPU pour communiquer en USB 1.0 ?
Tu as un gros problème, là...
Pour info, 20% du temps CPU, c'est ce que je consome pour transférer 600
ko/s sur un PPC à 200 Mhz en utilisant un chip USB avec lequel il faut
tout faire à la main (le sl811 de scanlogic, pour ceux qui connaissent).
Un clavier ou une souris, qui typiquement vont utiliser un paquet de 8
ou 16 octets max par frame USB, ça fait du 16 ko/s max si tu as des
évènements tous le temps !
Un calcul simpliste me fait estimer que tu consomerais 20 % du CPU pour
faire celà, disons avec un 486 à 25 ou 33 Mhz...
On Sat, 26 Feb 2005 13:36:20 +0100, Jérémy JUST wrote:
On Fri, 25 Feb 2005 00:11:32 +0100 Jerome Lambert wrote:
Ceux qui continuent à implémenter ça sur des cartes mères sont *aussi* des charlots...
Sauf que je n'ai pas les moyens que 20% de mon temps CPU soient consacrés à la communication avec clavier et souris USB.
20% du temps CPU pour communiquer en USB 1.0 ? Tu as un gros problème, là... Pour info, 20% du temps CPU, c'est ce que je consome pour transférer 600 ko/s sur un PPC à 200 Mhz en utilisant un chip USB avec lequel il faut tout faire à la main (le sl811 de scanlogic, pour ceux qui connaissent). Un clavier ou une souris, qui typiquement vont utiliser un paquet de 8 ou 16 octets max par frame USB, ça fait du 16 ko/s max si tu as des évènements tous le temps ! Un calcul simpliste me fait estimer que tu consomerais 20 % du CPU pour faire celà, disons avec un 486 à 25 ou 33 Mhz...
Jérémy JUST
On Sat, 26 Feb 2005 15:41:37 +0100 l'indien wrote:
20% du temps CPU pour communiquer en USB 1.0 ?
Avec 20%, j'exagère un peu, mais mon expérience est que:
- un graveur de CD USB en 4X (ça ressemble à ce que tu décris) prend presque toutes les ressources d'un AMD K6 à 380 MHz sous Windows 98, alors que le disque dur n'est pas à fond (je peux transférer par SSH à une débit équivalent sans problème) et qu'il y suffisamment de RAM (192 Mo).
- une souris USB sur un Pentium IIIm à 900 MHz sous Linux fait augmenter la charge de façon visible quand on la bouge rapidement pendant quelques secondes (le « load » augmente de 0.1-0.2 unités).
Tout ça est très intuitif, mais ça me laisse penser que l'USB est *très* gourmand en CPU.
-- Jérémy JUST
On Sat, 26 Feb 2005 15:41:37 +0100
l'indien <l_indien_no_more_spams@magic.fr> wrote:
20% du temps CPU pour communiquer en USB 1.0 ?
Avec 20%, j'exagère un peu, mais mon expérience est que:
- un graveur de CD USB en 4X (ça ressemble à ce que tu décris) prend
presque toutes les ressources d'un AMD K6 à 380 MHz sous Windows 98,
alors que le disque dur n'est pas à fond (je peux transférer par SSH à
une débit équivalent sans problème) et qu'il y suffisamment de RAM
(192 Mo).
- une souris USB sur un Pentium IIIm à 900 MHz sous Linux fait
augmenter la charge de façon visible quand on la bouge rapidement
pendant quelques secondes (le « load » augmente de 0.1-0.2 unités).
Tout ça est très intuitif, mais ça me laisse penser que l'USB est
*très* gourmand en CPU.
On Sat, 26 Feb 2005 15:41:37 +0100 l'indien wrote:
20% du temps CPU pour communiquer en USB 1.0 ?
Avec 20%, j'exagère un peu, mais mon expérience est que:
- un graveur de CD USB en 4X (ça ressemble à ce que tu décris) prend presque toutes les ressources d'un AMD K6 à 380 MHz sous Windows 98, alors que le disque dur n'est pas à fond (je peux transférer par SSH à une débit équivalent sans problème) et qu'il y suffisamment de RAM (192 Mo).
- une souris USB sur un Pentium IIIm à 900 MHz sous Linux fait augmenter la charge de façon visible quand on la bouge rapidement pendant quelques secondes (le « load » augmente de 0.1-0.2 unités).
Tout ça est très intuitif, mais ça me laisse penser que l'USB est *très* gourmand en CPU.
-- Jérémy JUST
l'indien
On Sun, 27 Feb 2005 17:39:06 +0100, Jérémy JUST wrote:
On Sat, 26 Feb 2005 15:41:37 +0100 l'indien wrote:
20% du temps CPU pour communiquer en USB 1.0 ?
Avec 20%, j'exagère un peu, mais mon expérience est que:
- un graveur de CD USB en 4X (ça ressemble à ce que tu décris) prend presque toutes les ressources d'un AMD K6 à 380 MHz sous Windows 98, alors que le disque dur n'est pas à fond (je peux transférer par SSH à une débit équivalent sans problème) et qu'il y suffisamment de RAM (192 Mo).
- une souris USB sur un Pentium IIIm à 900 MHz sous Linux fait augmenter la charge de façon visible quand on la bouge rapidement pendant quelques secondes (le « load » augmente de 0.1-0.2 unités).
Je ne sais pas comment ça marche sous Windows mais le temps CPU utilisé par l'USB dépend en grande partie de la façon dont est codée le driver. En fait, l'USB consome du temps CPU en permanence, même quand on ne s'en sert pas, si le driver n'est pas rusé: le comportement par défaut des chips USB est généralement de générer une interruption par trame USB, c'est à dire à chaque milli-seconde. Si le handler d'interruption est complexe (ce qui est le cas dans les drivers USB Linux pour l'OHCI et l'UHCI), le temps consomé n'est pas négligeable. Par contre, le fait d'avoir du trafic ne change rien, si le chip sait faire de la DMA: dans le cas d'une souris, à chaque trame USB l'OS doit demander un paquet à la souris. Si celle-ci a quelque chose à dire, elle remplit ce paquet, sinon, elle renvoie un paquet vide. Ce qui fait que quand la souris n'a rien à dire, elle génère pratiquement autant de trafic que quand elle ne fait rien. La gestion de l'USB est pleine d'absurdité de ce genre... Dans le cas d'un disque dur, le temps consomé est effectivement plutôt proportionnel au trafic. Une webcam, mais c'est déjà plus logique, consome une grosse bande passante USB mais comme son protocole peut utiliser de gros paquets, elle doit consomer assez peu de CPU.
Tout ça est très intuitif, mais ça me laisse penser que l'USB est *très* gourmand en CPU.
L'USB est en effet assez inefficace: le ratio CPU consomé / travail fournit est très défavorable. C'est apparement du au fait que ça a été assez mal designé et que comme c'était au départ destiné uniquement à des périphériques avec des bandes passantes très faibles (clavier/souris), le problème de la lourdeur de la gestion n'a pas été pris en compte. Les mauvaises langues (moi, donc) disent que ,pour un protocole designé par Intel et Microsoft, le résultat aurait pu être bien pire, même si il est loin d'avoir les qualités habituellement requises pour une norme industrielle.
On Sun, 27 Feb 2005 17:39:06 +0100, Jérémy JUST wrote:
On Sat, 26 Feb 2005 15:41:37 +0100
l'indien <l_indien_no_more_spams@magic.fr> wrote:
20% du temps CPU pour communiquer en USB 1.0 ?
Avec 20%, j'exagère un peu, mais mon expérience est que:
- un graveur de CD USB en 4X (ça ressemble à ce que tu décris) prend
presque toutes les ressources d'un AMD K6 à 380 MHz sous Windows 98,
alors que le disque dur n'est pas à fond (je peux transférer par SSH à
une débit équivalent sans problème) et qu'il y suffisamment de RAM
(192 Mo).
- une souris USB sur un Pentium IIIm à 900 MHz sous Linux fait
augmenter la charge de façon visible quand on la bouge rapidement
pendant quelques secondes (le « load » augmente de 0.1-0.2 unités).
Je ne sais pas comment ça marche sous Windows mais le temps CPU utilisé
par l'USB dépend en grande partie de la façon dont est codée le driver.
En fait, l'USB consome du temps CPU en permanence, même quand on ne
s'en sert pas, si le driver n'est pas rusé:
le comportement par défaut des chips USB est généralement de générer
une interruption par trame USB, c'est à dire à chaque milli-seconde.
Si le handler d'interruption est complexe (ce qui est le cas dans les
drivers USB Linux pour l'OHCI et l'UHCI), le temps consomé n'est pas
négligeable.
Par contre, le fait d'avoir du trafic ne change rien, si le chip sait
faire de la DMA: dans le cas d'une souris, à chaque trame USB l'OS doit
demander un paquet à la souris. Si celle-ci a quelque chose à dire, elle
remplit ce paquet, sinon, elle renvoie un paquet vide. Ce qui fait que
quand la souris n'a rien à dire, elle génère pratiquement autant de
trafic que quand elle ne fait rien. La gestion de l'USB est pleine
d'absurdité de ce genre...
Dans le cas d'un disque dur, le temps consomé est effectivement plutôt
proportionnel au trafic.
Une webcam, mais c'est déjà plus logique, consome une grosse bande
passante USB mais comme son protocole peut utiliser de gros paquets, elle
doit consomer assez peu de CPU.
Tout ça est très intuitif, mais ça me laisse penser que l'USB est
*très* gourmand en CPU.
L'USB est en effet assez inefficace: le ratio CPU consomé / travail
fournit est très défavorable. C'est apparement du au fait que ça a
été assez mal designé et que comme c'était au départ destiné
uniquement à des périphériques avec des bandes passantes très faibles
(clavier/souris), le problème de la lourdeur de la gestion n'a pas été
pris en compte.
Les mauvaises langues (moi, donc) disent que ,pour un protocole designé
par Intel et Microsoft, le résultat aurait pu être bien pire, même si
il est loin d'avoir les qualités habituellement requises pour une norme
industrielle.
On Sun, 27 Feb 2005 17:39:06 +0100, Jérémy JUST wrote:
On Sat, 26 Feb 2005 15:41:37 +0100 l'indien wrote:
20% du temps CPU pour communiquer en USB 1.0 ?
Avec 20%, j'exagère un peu, mais mon expérience est que:
- un graveur de CD USB en 4X (ça ressemble à ce que tu décris) prend presque toutes les ressources d'un AMD K6 à 380 MHz sous Windows 98, alors que le disque dur n'est pas à fond (je peux transférer par SSH à une débit équivalent sans problème) et qu'il y suffisamment de RAM (192 Mo).
- une souris USB sur un Pentium IIIm à 900 MHz sous Linux fait augmenter la charge de façon visible quand on la bouge rapidement pendant quelques secondes (le « load » augmente de 0.1-0.2 unités).
Je ne sais pas comment ça marche sous Windows mais le temps CPU utilisé par l'USB dépend en grande partie de la façon dont est codée le driver. En fait, l'USB consome du temps CPU en permanence, même quand on ne s'en sert pas, si le driver n'est pas rusé: le comportement par défaut des chips USB est généralement de générer une interruption par trame USB, c'est à dire à chaque milli-seconde. Si le handler d'interruption est complexe (ce qui est le cas dans les drivers USB Linux pour l'OHCI et l'UHCI), le temps consomé n'est pas négligeable. Par contre, le fait d'avoir du trafic ne change rien, si le chip sait faire de la DMA: dans le cas d'une souris, à chaque trame USB l'OS doit demander un paquet à la souris. Si celle-ci a quelque chose à dire, elle remplit ce paquet, sinon, elle renvoie un paquet vide. Ce qui fait que quand la souris n'a rien à dire, elle génère pratiquement autant de trafic que quand elle ne fait rien. La gestion de l'USB est pleine d'absurdité de ce genre... Dans le cas d'un disque dur, le temps consomé est effectivement plutôt proportionnel au trafic. Une webcam, mais c'est déjà plus logique, consome une grosse bande passante USB mais comme son protocole peut utiliser de gros paquets, elle doit consomer assez peu de CPU.
Tout ça est très intuitif, mais ça me laisse penser que l'USB est *très* gourmand en CPU.
L'USB est en effet assez inefficace: le ratio CPU consomé / travail fournit est très défavorable. C'est apparement du au fait que ça a été assez mal designé et que comme c'était au départ destiné uniquement à des périphériques avec des bandes passantes très faibles (clavier/souris), le problème de la lourdeur de la gestion n'a pas été pris en compte. Les mauvaises langues (moi, donc) disent que ,pour un protocole designé par Intel et Microsoft, le résultat aurait pu être bien pire, même si il est loin d'avoir les qualités habituellement requises pour une norme industrielle.
Nicolas George
Jérémy JUST wrote in message :
- une souris USB sur un Pentium IIIm à 900 MHz sous Linux fait augmenter la charge de façon visible quand on la bouge rapidement pendant quelques secondes (le « load » augmente de 0.1-0.2 unités).
Refais l'expérience en quittant toutes les applications qui écoutent potentiellement la souris (en particulier X11, et gpm). Là, je soupçonne que tout ce que ça montre, c'est que quand tu secoues la souris, ça réveille Gnome.
Jérémy JUST wrote in message
<20050227173906.5902252a@norbert.inapg.inra.fr>:
- une souris USB sur un Pentium IIIm à 900 MHz sous Linux fait
augmenter la charge de façon visible quand on la bouge rapidement
pendant quelques secondes (le « load » augmente de 0.1-0.2 unités).
Refais l'expérience en quittant toutes les applications qui écoutent
potentiellement la souris (en particulier X11, et gpm). Là, je soupçonne que
tout ce que ça montre, c'est que quand tu secoues la souris, ça réveille
Gnome.
- une souris USB sur un Pentium IIIm à 900 MHz sous Linux fait augmenter la charge de façon visible quand on la bouge rapidement pendant quelques secondes (le « load » augmente de 0.1-0.2 unités).
Refais l'expérience en quittant toutes les applications qui écoutent potentiellement la souris (en particulier X11, et gpm). Là, je soupçonne que tout ce que ça montre, c'est que quand tu secoues la souris, ça réveille Gnome.
Jérémy JUST
On Sun, 27 Feb 2005 18:33:04 +0000 (UTC) Nicolas George <nicolas$ wrote:
- une souris USB sur un Pentium IIIm à 900 MHz sous Linux fait augmenter la charge de façon visible quand on la bouge rapidement pendant quelques secondes (le « load » augmente de 0.1-0.2 unités).
Refais l'expérience en quittant toutes les applications qui écoutent potentiellement la souris (en particulier X11, et gpm). Là, je soupçonne que tout ce que ça montre, c'est que quand tu secoues la souris, ça réveille Gnome.
J'étais sous Fvwm2, sur un bureau vide (donc pas de changement de forme du pointeur de la souris). Ensuite, effectivement, je veux bien que X11 travaille, mais j'ai eu l'impression de constater une différence entre le touchpad et la souris USB (encore une fois, je ne donne là qu'une impression; je n'ai pas cherché à mesurer rigoureusement).
Je testerai à l'occasion.
-- Jérémy JUST
On Sun, 27 Feb 2005 18:33:04 +0000 (UTC)
Nicolas George <nicolas$george@salle-s.org> wrote:
- une souris USB sur un Pentium IIIm à 900 MHz sous Linux fait
augmenter la charge de façon visible quand on la bouge rapidement
pendant quelques secondes (le « load » augmente de 0.1-0.2 unités).
Refais l'expérience en quittant toutes les applications qui écoutent
potentiellement la souris (en particulier X11, et gpm). Là, je
soupçonne que tout ce que ça montre, c'est que quand tu secoues la
souris, ça réveille Gnome.
J'étais sous Fvwm2, sur un bureau vide (donc pas de changement de
forme du pointeur de la souris).
Ensuite, effectivement, je veux bien que X11 travaille, mais j'ai eu
l'impression de constater une différence entre le touchpad et la souris
USB (encore une fois, je ne donne là qu'une impression; je n'ai pas
cherché à mesurer rigoureusement).
On Sun, 27 Feb 2005 18:33:04 +0000 (UTC) Nicolas George <nicolas$ wrote:
- une souris USB sur un Pentium IIIm à 900 MHz sous Linux fait augmenter la charge de façon visible quand on la bouge rapidement pendant quelques secondes (le « load » augmente de 0.1-0.2 unités).
Refais l'expérience en quittant toutes les applications qui écoutent potentiellement la souris (en particulier X11, et gpm). Là, je soupçonne que tout ce que ça montre, c'est que quand tu secoues la souris, ça réveille Gnome.
J'étais sous Fvwm2, sur un bureau vide (donc pas de changement de forme du pointeur de la souris). Ensuite, effectivement, je veux bien que X11 travaille, mais j'ai eu l'impression de constater une différence entre le touchpad et la souris USB (encore une fois, je ne donne là qu'une impression; je n'ai pas cherché à mesurer rigoureusement).
Je testerai à l'occasion.
-- Jérémy JUST
l'indien
On Mon, 28 Feb 2005 00:42:45 +0100, Jérémy JUST wrote:
On Sun, 27 Feb 2005 18:33:04 +0000 (UTC) Nicolas George <nicolas$ wrote:
- une souris USB sur un Pentium IIIm à 900 MHz sous Linux fait augmenter la charge de façon visible quand on la bouge rapidement pendant quelques secondes (le « load » augmente de 0.1-0.2 unités).
Refais l'expérience en quittant toutes les applications qui écoutent potentiellement la souris (en particulier X11, et gpm). Là, je soupçonne que tout ce que ça montre, c'est que quand tu secoues la souris, ça réveille Gnome.
J'étais sous Fvwm2, sur un bureau vide (donc pas de changement de forme du pointeur de la souris). Ensuite, effectivement, je veux bien que X11 travaille, mais j'ai eu l'impression de constater une différence entre le touchpad et la souris USB (encore une fois, je ne donne là qu'une impression; je n'ai pas cherché à mesurer rigoureusement).
Comme je l'ai dit, une souris USB (comme un clavier) consome autant de temps CPU quand elle ne fait rien que quand elle bouge (ça marche uniquement par polling). Comme il y a très peu de traitement fait par le noyau si le paquet retourné n'est pas vide, je pense que le CPU consomé pour celà est négligeable.
Par contre, un évènement de souris débloque les applications qui attendent ces évènements, d'ou une augmentation du load. Si ta souris et ton touchpad sont gérés de la même façon (en utilisant /dev/input/mice ou /dev/input/mouse<x> pour les deux), il n'y a pas de raison que tu constates une différence. Si tu utilise /dev/psaux pour ton périphérique en PS/2, il est probable que la différence vienne de traitements différents dans les application pour les 2 protocoles.
On Mon, 28 Feb 2005 00:42:45 +0100, Jérémy JUST wrote:
On Sun, 27 Feb 2005 18:33:04 +0000 (UTC)
Nicolas George <nicolas$george@salle-s.org> wrote:
- une souris USB sur un Pentium IIIm à 900 MHz sous Linux fait
augmenter la charge de façon visible quand on la bouge rapidement
pendant quelques secondes (le « load » augmente de 0.1-0.2 unités).
Refais l'expérience en quittant toutes les applications qui écoutent
potentiellement la souris (en particulier X11, et gpm). Là, je
soupçonne que tout ce que ça montre, c'est que quand tu secoues la
souris, ça réveille Gnome.
J'étais sous Fvwm2, sur un bureau vide (donc pas de changement de
forme du pointeur de la souris).
Ensuite, effectivement, je veux bien que X11 travaille, mais j'ai eu
l'impression de constater une différence entre le touchpad et la souris
USB (encore une fois, je ne donne là qu'une impression; je n'ai pas
cherché à mesurer rigoureusement).
Comme je l'ai dit, une souris USB (comme un clavier) consome autant de
temps CPU quand elle ne fait rien que quand elle bouge (ça marche
uniquement par polling). Comme il y a très peu de traitement fait par le
noyau si le paquet retourné n'est pas vide, je pense que le CPU consomé
pour celà est négligeable.
Par contre, un évènement de souris débloque les applications qui
attendent ces évènements, d'ou une augmentation du load.
Si ta souris et ton touchpad sont gérés de la même façon (en utilisant
/dev/input/mice ou /dev/input/mouse<x> pour les deux), il n'y a pas de
raison que tu constates une différence. Si tu utilise /dev/psaux pour ton
périphérique en PS/2, il est probable que la différence vienne de
traitements différents dans les application pour les 2 protocoles.
On Mon, 28 Feb 2005 00:42:45 +0100, Jérémy JUST wrote:
On Sun, 27 Feb 2005 18:33:04 +0000 (UTC) Nicolas George <nicolas$ wrote:
- une souris USB sur un Pentium IIIm à 900 MHz sous Linux fait augmenter la charge de façon visible quand on la bouge rapidement pendant quelques secondes (le « load » augmente de 0.1-0.2 unités).
Refais l'expérience en quittant toutes les applications qui écoutent potentiellement la souris (en particulier X11, et gpm). Là, je soupçonne que tout ce que ça montre, c'est que quand tu secoues la souris, ça réveille Gnome.
J'étais sous Fvwm2, sur un bureau vide (donc pas de changement de forme du pointeur de la souris). Ensuite, effectivement, je veux bien que X11 travaille, mais j'ai eu l'impression de constater une différence entre le touchpad et la souris USB (encore une fois, je ne donne là qu'une impression; je n'ai pas cherché à mesurer rigoureusement).
Comme je l'ai dit, une souris USB (comme un clavier) consome autant de temps CPU quand elle ne fait rien que quand elle bouge (ça marche uniquement par polling). Comme il y a très peu de traitement fait par le noyau si le paquet retourné n'est pas vide, je pense que le CPU consomé pour celà est négligeable.
Par contre, un évènement de souris débloque les applications qui attendent ces évènements, d'ou une augmentation du load. Si ta souris et ton touchpad sont gérés de la même façon (en utilisant /dev/input/mice ou /dev/input/mouse<x> pour les deux), il n'y a pas de raison que tu constates une différence. Si tu utilise /dev/psaux pour ton périphérique en PS/2, il est probable que la différence vienne de traitements différents dans les application pour les 2 protocoles.
