Bonjour,
Lorsque je brancher mon apn sur la prise usb de mon pc, je peux voir qu'il
est reconnu grâce à la commande lsusb et que les modules adequat sont
chargés grâce au fichier /var/log/messages. Le problème c'est que je ne
sais pas à quel fichier du repertoire /dev correspond l'appareil. Comment le
savoir ?
Il peut être parfois plus utile d'utiliser le programme « gphoto2 » qui gère plus de 500 appareils photos numériques et qui possède différents programmes (gphoto2, digikam, gtkam, ...) pour les manipuler aisément. Sûrment que votre appareil est supporté. Si c'est le cas, faire attention que, s'il existe un pilote pour votre périphérique dans le noyau, il ne doit *PAS* être chargé. Cordialement,
Si le module n'est pas chargé, comment l'os peut il utiliser le périphérique? C'est gphoto2 qui gère le pilote?
Nicolas
A+ Exactement,
Et c'est pour cela que gphoto2 ne peut venir en sus du pilote du noyau. Nous avons codé différents pilotes pour communiquer à travers les BUS séries et USB ainsi que chaque pilote pour chaque appareil photo et le tour est joué. À mon humble avis, il est important de remettre à sa place le noyau : il est là pour offrir un moyen de communication entre les périphériques et les programmes, mais il ne faut pas que le noyau se mette à tout gérer. Il nous offre un moyen d'envoyer des données à nos appareils : tant mieux, arrêtons-nous là ! De plus, la librairie permet d'offrir bien plus que la simple gestion des images contenues dans un appareil (configuration à distance, vérification des paramètres, prise de photos, et n'importe quel gadget que l'on peut trouver sur nos périphs). Pour intégrer tout ceci dans le noyau, il aurait fallu passer par des subterfuges plus ou moins compliqués (passage d'infos par /proc, création de multiples entrées dans /dev, ...) Le code aurait été conséquent ce qui augmente de fait, considérablement les bugs possibles. Enfin, des appareils-photos, il en sort tous les jours ; une librairie se change en quelques secondes tandis que changer le noyau ou installer des nouveaux modules pour le noyau est un peu plus compliqué. Voili voilou, tout ça pour dire qu'il faut éviter de tout mettre dans le noyau (d'ailleurs la tendance actuelle est d'y retirer du code (cf. devfs et compagnie..))
-- Aurélien Projet AP²C - http://www.ap2c.org Clef Publique : http://www.ap2c.org/aurelien.gpg
Nicolas Pontoizeau wrote:
Il peut être parfois plus utile d'utiliser le programme « gphoto2 » qui
gère plus de 500 appareils photos numériques et qui possède différents
programmes (gphoto2, digikam, gtkam, ...) pour les manipuler aisément.
Sûrment que votre appareil est supporté. Si c'est le cas, faire attention
que, s'il existe un pilote pour votre périphérique dans le noyau, il ne
doit *PAS* être chargé.
Cordialement,
Si le module n'est pas chargé, comment l'os peut il utiliser le
périphérique? C'est gphoto2 qui gère le pilote?
Nicolas
A+
Exactement,
Et c'est pour cela que gphoto2 ne peut venir en sus du pilote du noyau. Nous
avons codé différents pilotes pour communiquer à travers les BUS séries et
USB ainsi que chaque pilote pour chaque appareil photo et le tour est joué.
À mon humble avis, il est important de remettre à sa place le noyau : il est
là pour offrir un moyen de communication entre les périphériques et les
programmes, mais il ne faut pas que le noyau se mette à tout gérer. Il nous
offre un moyen d'envoyer des données à nos appareils : tant mieux,
arrêtons-nous là ! De plus, la librairie permet d'offrir bien plus que la
simple gestion des images contenues dans un appareil (configuration à
distance, vérification des paramètres, prise de photos, et n'importe quel
gadget que l'on peut trouver sur nos périphs). Pour intégrer tout ceci dans
le noyau, il aurait fallu passer par des subterfuges plus ou moins
compliqués (passage d'infos par /proc, création de multiples entrées
dans /dev, ...) Le code aurait été conséquent ce qui augmente de fait,
considérablement les bugs possibles. Enfin, des appareils-photos, il en
sort tous les jours ; une librairie se change en quelques secondes tandis
que changer le noyau ou installer des nouveaux modules pour le noyau est un
peu plus compliqué.
Voili voilou, tout ça pour dire qu'il faut éviter de tout mettre dans le
noyau (d'ailleurs la tendance actuelle est d'y retirer du code (cf. devfs
et compagnie..))
--
Aurélien
Projet AP²C - http://www.ap2c.org
Clef Publique : http://www.ap2c.org/aurelien.gpg
Il peut être parfois plus utile d'utiliser le programme « gphoto2 » qui gère plus de 500 appareils photos numériques et qui possède différents programmes (gphoto2, digikam, gtkam, ...) pour les manipuler aisément. Sûrment que votre appareil est supporté. Si c'est le cas, faire attention que, s'il existe un pilote pour votre périphérique dans le noyau, il ne doit *PAS* être chargé. Cordialement,
Si le module n'est pas chargé, comment l'os peut il utiliser le périphérique? C'est gphoto2 qui gère le pilote?
Nicolas
A+ Exactement,
Et c'est pour cela que gphoto2 ne peut venir en sus du pilote du noyau. Nous avons codé différents pilotes pour communiquer à travers les BUS séries et USB ainsi que chaque pilote pour chaque appareil photo et le tour est joué. À mon humble avis, il est important de remettre à sa place le noyau : il est là pour offrir un moyen de communication entre les périphériques et les programmes, mais il ne faut pas que le noyau se mette à tout gérer. Il nous offre un moyen d'envoyer des données à nos appareils : tant mieux, arrêtons-nous là ! De plus, la librairie permet d'offrir bien plus que la simple gestion des images contenues dans un appareil (configuration à distance, vérification des paramètres, prise de photos, et n'importe quel gadget que l'on peut trouver sur nos périphs). Pour intégrer tout ceci dans le noyau, il aurait fallu passer par des subterfuges plus ou moins compliqués (passage d'infos par /proc, création de multiples entrées dans /dev, ...) Le code aurait été conséquent ce qui augmente de fait, considérablement les bugs possibles. Enfin, des appareils-photos, il en sort tous les jours ; une librairie se change en quelques secondes tandis que changer le noyau ou installer des nouveaux modules pour le noyau est un peu plus compliqué. Voili voilou, tout ça pour dire qu'il faut éviter de tout mettre dans le noyau (d'ailleurs la tendance actuelle est d'y retirer du code (cf. devfs et compagnie..))
-- Aurélien Projet AP²C - http://www.ap2c.org Clef Publique : http://www.ap2c.org/aurelien.gpg
Emmanuel Florac
Le Wed, 15 Dec 2004 10:31:51 +0100, Aurelien Croc a écrit :
Exactement, Et c'est pour cela que gphoto2 ne peut venir en sus du pilote du noyau.
Le gros défaut c'est qu'il est pratiquement impossible d'empécher le chargement automatique du module par hotplug à moins d'être un vrai gros geek. D'ailleurs je pense être un vrai gros geek et je n'ai pas trouvé, puis je n'ai pas que ça à foutre de lire des tonnes de scripts dans /etc/hotplug... Du coup pour utiliser gphoto, il faut brancher l'apn, ouvrir un shell, faire un rmmod, puis utiliser gphoto... Ce qui est abominablement compliqué pour le pékin moyen, non?
-- Ne pas savoir de quoi on parle est un avantage dont il ne faut pas abuser. R.Debray
Le Wed, 15 Dec 2004 10:31:51 +0100, Aurelien Croc a écrit :
Exactement,
Et c'est pour cela que gphoto2 ne peut venir en sus du pilote du noyau.
Le gros défaut c'est qu'il est pratiquement impossible d'empécher le
chargement automatique du module par hotplug à moins d'être un vrai
gros geek. D'ailleurs je pense être un vrai gros geek et je n'ai pas
trouvé, puis je n'ai pas que ça à foutre de lire des tonnes de scripts
dans /etc/hotplug...
Du coup pour utiliser gphoto, il faut brancher l'apn, ouvrir un shell,
faire un rmmod, puis utiliser gphoto... Ce qui est abominablement
compliqué pour le pékin moyen, non?
--
Ne pas savoir de quoi on parle est un avantage dont il ne faut pas
abuser.
R.Debray
Le Wed, 15 Dec 2004 10:31:51 +0100, Aurelien Croc a écrit :
Exactement, Et c'est pour cela que gphoto2 ne peut venir en sus du pilote du noyau.
Le gros défaut c'est qu'il est pratiquement impossible d'empécher le chargement automatique du module par hotplug à moins d'être un vrai gros geek. D'ailleurs je pense être un vrai gros geek et je n'ai pas trouvé, puis je n'ai pas que ça à foutre de lire des tonnes de scripts dans /etc/hotplug... Du coup pour utiliser gphoto, il faut brancher l'apn, ouvrir un shell, faire un rmmod, puis utiliser gphoto... Ce qui est abominablement compliqué pour le pékin moyen, non?
-- Ne pas savoir de quoi on parle est un avantage dont il ne faut pas abuser. R.Debray
Aurelien Croc
Emmanuel Florac wrote:
Le Wed, 15 Dec 2004 10:31:51 +0100, Aurelien Croc a écrit :
Exactement, Et c'est pour cela que gphoto2 ne peut venir en sus du pilote du noyau.
Le gros défaut c'est qu'il est pratiquement impossible d'empécher le chargement automatique du module par hotplug à moins d'être un vrai gros geek. D'ailleurs je pense être un vrai gros geek et je n'ai pas trouvé, puis je n'ai pas que ça à foutre de lire des tonnes de scripts dans /etc/hotplug... Du coup pour utiliser gphoto, il faut brancher l'apn, ouvrir un shell, faire un rmmod, puis utiliser gphoto... Ce qui est abominablement compliqué pour le pékin moyen, non?
Effectivement, ça peut devenir lourd. C'est pour ça qu'il faut espérer que
les pilotes noyau seront retirés rapidement du noyau pour que gphoto puisse faire son travail correctement (Comme l'histoire du devfs qui voit son travail effectué par un programme plutôt qu'un code du noyau). En attendant,hotplug, qui se charge de charger les pilotes, peut se charger de ne pas en charger justement. Moyennant la ligne adéquate dans /etc/hotplug/blacklist, (suffit d'y mettre le nom du module à ne _pas_ charger), le module ne sera plus chargé, donc plus de soucis de rmmod.
Je ne pense pas que cette manipulation : $ su password: # echo "nomdupilote" >> /etc/hotplug/blacklist # exit
soit hors de portée :) Cordialement,
-- Aurélien Projet AP²C - http://www.ap2c.org Clef Publique : http://www.ap2c.org/aurelien.gpg
Emmanuel Florac wrote:
Le Wed, 15 Dec 2004 10:31:51 +0100, Aurelien Croc a écrit :
Exactement,
Et c'est pour cela que gphoto2 ne peut venir en sus du pilote du noyau.
Le gros défaut c'est qu'il est pratiquement impossible d'empécher le
chargement automatique du module par hotplug à moins d'être un vrai
gros geek. D'ailleurs je pense être un vrai gros geek et je n'ai pas
trouvé, puis je n'ai pas que ça à foutre de lire des tonnes de scripts
dans /etc/hotplug...
Du coup pour utiliser gphoto, il faut brancher l'apn, ouvrir un shell,
faire un rmmod, puis utiliser gphoto... Ce qui est abominablement
compliqué pour le pékin moyen, non?
Effectivement, ça peut devenir lourd. C'est pour ça qu'il faut espérer que
les pilotes noyau seront retirés rapidement du noyau pour que gphoto puisse
faire son travail correctement (Comme l'histoire du devfs qui voit son
travail effectué par un programme plutôt qu'un code du noyau). En
attendant,hotplug, qui se charge de charger les pilotes, peut se charger de
ne pas en charger justement. Moyennant la ligne adéquate
dans /etc/hotplug/blacklist, (suffit d'y mettre le nom du module à ne _pas_
charger), le module ne sera plus chargé, donc plus de soucis de rmmod.
Je ne pense pas que cette manipulation :
$ su
password:
# echo "nomdupilote" >> /etc/hotplug/blacklist
# exit
soit hors de portée :)
Cordialement,
--
Aurélien
Projet AP²C - http://www.ap2c.org
Clef Publique : http://www.ap2c.org/aurelien.gpg
Le Wed, 15 Dec 2004 10:31:51 +0100, Aurelien Croc a écrit :
Exactement, Et c'est pour cela que gphoto2 ne peut venir en sus du pilote du noyau.
Le gros défaut c'est qu'il est pratiquement impossible d'empécher le chargement automatique du module par hotplug à moins d'être un vrai gros geek. D'ailleurs je pense être un vrai gros geek et je n'ai pas trouvé, puis je n'ai pas que ça à foutre de lire des tonnes de scripts dans /etc/hotplug... Du coup pour utiliser gphoto, il faut brancher l'apn, ouvrir un shell, faire un rmmod, puis utiliser gphoto... Ce qui est abominablement compliqué pour le pékin moyen, non?
Effectivement, ça peut devenir lourd. C'est pour ça qu'il faut espérer que
les pilotes noyau seront retirés rapidement du noyau pour que gphoto puisse faire son travail correctement (Comme l'histoire du devfs qui voit son travail effectué par un programme plutôt qu'un code du noyau). En attendant,hotplug, qui se charge de charger les pilotes, peut se charger de ne pas en charger justement. Moyennant la ligne adéquate dans /etc/hotplug/blacklist, (suffit d'y mettre le nom du module à ne _pas_ charger), le module ne sera plus chargé, donc plus de soucis de rmmod.
Je ne pense pas que cette manipulation : $ su password: # echo "nomdupilote" >> /etc/hotplug/blacklist # exit
soit hors de portée :) Cordialement,
-- Aurélien Projet AP²C - http://www.ap2c.org Clef Publique : http://www.ap2c.org/aurelien.gpg
Emmanuel Florac
Le Wed, 15 Dec 2004 15:47:27 +0100, Aurelien Croc a écrit :
Je ne pense pas que cette manipulation : $ su password: # echo "nomdupilote" >> /etc/hotplug/blacklist # exit
soit hors de portée :)
Non en effet. Sauf que parfois je voudrais utiliser mon APN comme webcam et là, j'ai besoin du module noyau... Tsss, on n'en sort pas :)
-- Dix grammes d'abstraction valent des tonnes de bricolage. Loi de Booker.
Le Wed, 15 Dec 2004 15:47:27 +0100, Aurelien Croc a écrit :
Je ne pense pas que cette manipulation : $ su
password:
# echo "nomdupilote" >> /etc/hotplug/blacklist # exit
soit hors de portée :)
Non en effet. Sauf que parfois je voudrais utiliser mon APN comme webcam
et là, j'ai besoin du module noyau... Tsss, on n'en sort pas :)
--
Dix grammes d'abstraction valent des tonnes de bricolage.
Loi de Booker.
