Je patauge toujours sous mandrake 10.1 official, avec noyau
2.6.8.1-24mdk, udev 030 -24.1.101mdk, kde 3.2.3.
J'ai installé le rpm lirc0.6.6-7mdk dans le modeste dessein d'effectuer
sur mon téléviseur certains réglages que je ne peux faire autrement car
je n'ai pas la télécommande. Quand le soft fonctionnera, les ordres
seront émis par une led infra-rouge attaquée par le port série ttyS0
selon le schéma le plus simple.
Je n'envisage pas dans l'immédiat d'envoyer des ordres au pc avec une
télécommande extérieure.
J'ai trouvé facilement un fichier de configuration correspondant
parfaitement à mon modèle de téléviseur et à sa télécommande d'origine,
dont les caractéristiques techniques me sont connues.
Après bien des difficultés (évoquées dans un post vieux d'une semaine)
me voici à présent en face d'un programme qui vit mais refuse d'émettre
les ordres de télécommande. Voici un échantillon révélateur de cette
attitude révoltante :
$ rc LIST TP720_TV POWER
rc: 000000000000017f POWER <-- OK
$ rc SEND_ONCE TP720_TV POWER
rc: command failed: SEND_ONCE TP720_TV POWER <-- NOK
rc: hardware does not support sending
Et voilà la partie utile de /etc/sysconfig/lircd dans sa version actuelle :
Pour le device, j'ai l'impression que je peux choisir n'importe quoi
pour peu que ce n'importe quoi soit préalablement créé par :
mknod /dev/n'importe_quoi c 61 0, et doté des droits 666.
Mais à mon étonnement je ne peux choisir /dev/ttyS0 sous peine d'obtenir
ceci :
$ rc LIST TP720_TV POWER
rc: could not connect to socket
rc: Connection refused
$ rc SEND_ONCE TP720_TV POWER
rc: could not connect to socket
rc: Connection refused
# service lircd status
lircd (pid 5945) est en cours d'exécution...
Le script de lancement du service lircd comporte une commande préalable
: setserial /dev/ttyS0 uart none. C'est bien pour le rendre disponible ?
Quand au "hardware module", je me suis donné du mal pour rendre
disponibles sous /lib/modules/2.6.8.1-24mdk/kernel/3rdparty/lirc des
fichiers lirc_dev.ko et lirc_serial.ko qui n'étaient pas fournis avec
mon noyau. (Obtenus en compilant la version 0.7 de lirc.) Ce fut pour
moi le seul moyen de rendre possible le choix "HWMOD=lirc_serial". Le
script de lancement de lircd réalise le chargement de ce module.
Je ne sais pas si ces choix sont bons, ils sont seulement ceux qui m'ont
paru le plus logiques, compte tenu de l'inexistence de documentation sur
quelque chose que les habitués considèrent apparemment comme évident.
SVP, à moins que vous ayez vraiment une bonne raison de le faire, ne me
conseillez pas d'installer lirc 0.7 depuis les sources. Je l'ai fait
mais les résultats sont les mêmes et je préfère donc le rpm dont un
avantage est la présence des scripts qui permettent de gérer lircd comme
un service. Pour ce que je veux faire, la version 0.6.6 me semble
amplement suffisante.
Merci d'avance pour vos suggestions, explications, commentaires et
marques de sympathie.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
beebee
Bonjour!
Merci d'avance pour vos suggestions, explications, commentaires et marques de sympathie.
Ben lirc est "designé" pour permettre de piloter un composant infrarouge qui est soit sur carte mère, soit en externe sur port série ou usb! Le prog est là pour que ce soit le pc qui soit piloter avec une télécommande infrarouge!et non l'inverse! Une télécommende universelle coûte dans les 5 euros donc...
Mais bon comme tout est ou devrait être ou devenir possible avec linux, il faudrait rechercher une interface infrarouge "maître" et faire le prog qui va bien comme sur palm os pour ne pas faire de pub...
Sinon dans le même format pda ya le zaurus avec micro os linux qui a une puce usb maître, ce qui permet à l' engin de piloter des périphérique usb...et bien sûr l'infrarouge...
A+ jpierre
Bonjour!
Merci d'avance pour vos suggestions, explications, commentaires et
marques de sympathie.
Ben lirc est "designé" pour permettre de piloter un composant
infrarouge qui est soit sur carte mère, soit en externe sur port série
ou usb!
Le prog est là pour que ce soit le pc qui soit piloter avec
une télécommande infrarouge!et non l'inverse!
Une télécommende universelle coûte dans les 5 euros donc...
Mais bon comme tout est ou devrait être ou devenir possible avec
linux, il faudrait rechercher une interface infrarouge "maître" et faire
le prog qui va bien comme sur palm os pour ne pas faire de pub...
Sinon dans le même format pda ya le zaurus avec micro os linux qui a une
puce usb maître, ce qui permet à l' engin de piloter des périphérique
usb...et bien sûr l'infrarouge...
Merci d'avance pour vos suggestions, explications, commentaires et marques de sympathie.
Ben lirc est "designé" pour permettre de piloter un composant infrarouge qui est soit sur carte mère, soit en externe sur port série ou usb! Le prog est là pour que ce soit le pc qui soit piloter avec une télécommande infrarouge!et non l'inverse! Une télécommende universelle coûte dans les 5 euros donc...
Mais bon comme tout est ou devrait être ou devenir possible avec linux, il faudrait rechercher une interface infrarouge "maître" et faire le prog qui va bien comme sur palm os pour ne pas faire de pub...
Sinon dans le même format pda ya le zaurus avec micro os linux qui a une puce usb maître, ce qui permet à l' engin de piloter des périphérique usb...et bien sûr l'infrarouge...
A+ jpierre
geo cherchetout
Le 18.03.2005 18:34, *beebee* a écrit fort à propos :
Le prog est là pour que ce soit le pc qui soit piloter avec une télécommande infrarouge!et non l'inverse!
C'est ce que la plupart des gens font, mais il est bien dit sur le site de lirc qu'on peut piloter de nombreux appareils depuis le pc, et on y donne même le schéma le plus simple pour commander directement une led infra-rouge branchée sur le port série. D'ailleurs, à quoi servirait la commande rc (ou irsend actuellement) ?
Une télécommende universelle coûte dans les 5 euros donc...
Merci pour le conseil, mais ma tv vaut à peine ce prix...
Le 18.03.2005 18:34, *beebee* a écrit fort à propos :
Le prog est là pour que ce soit le pc qui soit piloter avec
une télécommande infrarouge!et non l'inverse!
C'est ce que la plupart des gens font, mais il est bien dit sur le site
de lirc qu'on peut piloter de nombreux appareils depuis le pc, et on y
donne même le schéma le plus simple pour commander directement une led
infra-rouge branchée sur le port série.
D'ailleurs, à quoi servirait la commande rc (ou irsend actuellement) ?
Une télécommende universelle coûte dans les 5 euros donc...
Merci pour le conseil, mais ma tv vaut à peine ce prix...
Le 18.03.2005 18:34, *beebee* a écrit fort à propos :
Le prog est là pour que ce soit le pc qui soit piloter avec une télécommande infrarouge!et non l'inverse!
C'est ce que la plupart des gens font, mais il est bien dit sur le site de lirc qu'on peut piloter de nombreux appareils depuis le pc, et on y donne même le schéma le plus simple pour commander directement une led infra-rouge branchée sur le port série. D'ailleurs, à quoi servirait la commande rc (ou irsend actuellement) ?
Une télécommende universelle coûte dans les 5 euros donc...
Merci pour le conseil, mais ma tv vaut à peine ce prix...
geo cherchetout
Quand au "hardware module", je me suis donné du mal pour rendre disponibles sous /lib/modules/2.6.8.1-24mdk/kernel/3rdparty/lirc des fichiers lirc_dev.ko et lirc_serial.ko qui n'étaient pas fournis avec mon noyau. (Obtenus en compilant la version 0.7 de lirc.) Ce fut pour moi le seul moyen de rendre possible le choix "HWMOD=lirc_serial". Le script de lancement de lircd réalise le chargement de ce module.
Les lignes ci-dessus montrent bien ma grande ignorance au sujet du noyau et des modules. Mais j'ai bien l'intention d'apprendre. Avant de me lancer dans l'aventure d'une recompilation du noyau, je souhaiterais toutefois avoir l'avis de personnes qualifiées sur les particularités du noyau actuel en rapport avec mon modeste projet. J'ai installé les sources (avec le rpm c'est facile) et parcouru le fichier .config. En voici les lignes qui me semblent en rapport avec LIRC, entrecoupées de quelques questions :
# Linux InfraRed Controller # CONFIG_LIRC_SUPPORT=m CONFIG_LIRC_MAX_DEV=8 CONFIG_LIRC_I2C=m CONFIG_LIRC_GPIO=m CONFIG_LIRC_BT829=m CONFIG_LIRC_IT87=m CONFIG_LIRC_ATIUSB=m # CONFIG_LIRC_MCEUSB is not set # CONFIG_LIRC_PARALLEL is not set CONFIG_LIRC_SERIAL=m
Cette dernière ligne ne signifie-t-elle pas qu'un module LIRC_SERIAL serait normalement chargé si un programme en a besoin ? Devrais-je trouver quelque part sous /lib/modules/2.6.8.1-24mdk/kernel un fichier LIRC_SERIAL.ko, LIRC_SERIAL.o ou LIRC_SERIAL.ko.gz ? Un fichier LIRC_DEV.ko, LIRC_DEV.o ou LIRC_DEV.ko.gz ? (Ces fichiers n'existaient pas avant que j'en dépose dans le sous-répertoire /3rdparty/lirc créé par mes soins.)
# CONFIG_LIRC_HOMEBREW is not set
Est-ce une option que je devrais ajouter en vue de la recompilation que j'envisage ? Mon périphérique est constitué d'une simple led infra-rouge attaquée par le port série.
# CONFIG_LIRC_SERIAL_ANIMAX is not set CONFIG_LIRC_SERIAL_IRDEO=y # CONFIG_LIRC_SERIAL_IRDEO_REMOTE is not set CONFIG_LIRC_SERIAL_TRANSMITTER=y
Cette dernière ligne signifie-t-elle comme je le crois que, sans faire appel à un module extérieur, LIRC serait en mesure de moduler en tout ou rien la porteuse (faisceau IR cadencé à fréquence fixe) générée par un dispositif matériel appelé émetteur connecté à un port du pc ?
CONFIG_LIRC_SERIAL_SOFTCARRIER=y
Celle-là signifie-t-elle que la fréquence porteuse modulée serait directement disponible sur le port, sans faire appel à un émetteur ni à un module ? Est-ce possible en chargeant le module LIRC_SERIAL ? Est-ce possible sans le charger ? Est-ce possible malgré l'absence de LIRC_HOMEBREW ?
# CONFIG_LIRC_SERIAL_IGOR is not set CONFIG_LIRC_SERIAL_COM1=y # CONFIG_LIRC_SERIAL_COM2 is not set # CONFIG_LIRC_SERIAL_COM3 is not set # CONFIG_LIRC_SERIAL_COM4 is not set # CONFIG_LIRC_SERIAL_OTHER is not set CONFIG_LIRC_PORT_SERIAL=0x3f8 CONFIG_LIRC_IRQ_SERIAL=0x4 CONFIG_LIRC_SIR=m # CONFIG_LIRC_ON_SA1100 is not set CONFIG_LIRC_SIR_IRDA=y # CONFIG_LIRC_SIR_TEKRAM is not set # CONFIG_LIRC_SIR_ACTISYS_ACT200L is not set CONFIG_LIRC_SIR_COM1=y # CONFIG_LIRC_SIR_COM2 is not set # CONFIG_LIRC_SIR_COM3 is not set # CONFIG_LIRC_SIR_COM4 is not set # CONFIG_LIRC_SIR_OTHER is not set CONFIG_LIRC_PORT_SIR=0x3f8 CONFIG_LIRC_IRQ_SIR=0x4
Merci d'avance pour vos suggestions, explications, commentaires et marques de sympathie.
Et votre indulgence.
Quand au "hardware module", je me suis donné du mal pour rendre
disponibles sous /lib/modules/2.6.8.1-24mdk/kernel/3rdparty/lirc des
fichiers lirc_dev.ko et lirc_serial.ko qui n'étaient pas fournis avec
mon noyau. (Obtenus en compilant la version 0.7 de lirc.) Ce fut pour
moi le seul moyen de rendre possible le choix "HWMOD=lirc_serial". Le
script de lancement de lircd réalise le chargement de ce module.
Les lignes ci-dessus montrent bien ma grande ignorance au sujet du noyau
et des modules. Mais j'ai bien l'intention d'apprendre. Avant de me
lancer dans l'aventure d'une recompilation du noyau, je souhaiterais
toutefois avoir l'avis de personnes qualifiées sur les particularités du
noyau actuel en rapport avec mon modeste projet.
J'ai installé les sources (avec le rpm c'est facile) et parcouru le
fichier .config. En voici les lignes qui me semblent en rapport avec
LIRC, entrecoupées de quelques questions :
# Linux InfraRed Controller
#
CONFIG_LIRC_SUPPORT=m
CONFIG_LIRC_MAX_DEV=8
CONFIG_LIRC_I2C=m
CONFIG_LIRC_GPIO=m
CONFIG_LIRC_BT829=m
CONFIG_LIRC_IT87=m
CONFIG_LIRC_ATIUSB=m
# CONFIG_LIRC_MCEUSB is not set
# CONFIG_LIRC_PARALLEL is not set
CONFIG_LIRC_SERIAL=m
Cette dernière ligne ne signifie-t-elle pas qu'un module LIRC_SERIAL
serait normalement chargé si un programme en a besoin ?
Devrais-je trouver quelque part sous /lib/modules/2.6.8.1-24mdk/kernel
un fichier LIRC_SERIAL.ko, LIRC_SERIAL.o ou LIRC_SERIAL.ko.gz ? Un
fichier LIRC_DEV.ko, LIRC_DEV.o ou LIRC_DEV.ko.gz ?
(Ces fichiers n'existaient pas avant que j'en dépose dans le
sous-répertoire /3rdparty/lirc créé par mes soins.)
# CONFIG_LIRC_HOMEBREW is not set
Est-ce une option que je devrais ajouter en vue de la recompilation que
j'envisage ? Mon périphérique est constitué d'une simple led infra-rouge
attaquée par le port série.
# CONFIG_LIRC_SERIAL_ANIMAX is not set
CONFIG_LIRC_SERIAL_IRDEO=y
# CONFIG_LIRC_SERIAL_IRDEO_REMOTE is not set
CONFIG_LIRC_SERIAL_TRANSMITTER=y
Cette dernière ligne signifie-t-elle comme je le crois que, sans faire
appel à un module extérieur, LIRC serait en mesure de moduler en tout ou
rien la porteuse (faisceau IR cadencé à fréquence fixe) générée par un
dispositif matériel appelé émetteur connecté à un port du pc ?
CONFIG_LIRC_SERIAL_SOFTCARRIER=y
Celle-là signifie-t-elle que la fréquence porteuse modulée serait
directement disponible sur le port, sans faire appel à un émetteur ni à
un module ?
Est-ce possible en chargeant le module LIRC_SERIAL ? Est-ce possible
sans le charger ?
Est-ce possible malgré l'absence de LIRC_HOMEBREW ?
# CONFIG_LIRC_SERIAL_IGOR is not set
CONFIG_LIRC_SERIAL_COM1=y
# CONFIG_LIRC_SERIAL_COM2 is not set
# CONFIG_LIRC_SERIAL_COM3 is not set
# CONFIG_LIRC_SERIAL_COM4 is not set
# CONFIG_LIRC_SERIAL_OTHER is not set
CONFIG_LIRC_PORT_SERIAL=0x3f8
CONFIG_LIRC_IRQ_SERIAL=0x4
CONFIG_LIRC_SIR=m
# CONFIG_LIRC_ON_SA1100 is not set
CONFIG_LIRC_SIR_IRDA=y
# CONFIG_LIRC_SIR_TEKRAM is not set
# CONFIG_LIRC_SIR_ACTISYS_ACT200L is not set
CONFIG_LIRC_SIR_COM1=y
# CONFIG_LIRC_SIR_COM2 is not set
# CONFIG_LIRC_SIR_COM3 is not set
# CONFIG_LIRC_SIR_COM4 is not set
# CONFIG_LIRC_SIR_OTHER is not set
CONFIG_LIRC_PORT_SIR=0x3f8
CONFIG_LIRC_IRQ_SIR=0x4
Merci d'avance pour vos suggestions, explications, commentaires et
marques de sympathie.
Quand au "hardware module", je me suis donné du mal pour rendre disponibles sous /lib/modules/2.6.8.1-24mdk/kernel/3rdparty/lirc des fichiers lirc_dev.ko et lirc_serial.ko qui n'étaient pas fournis avec mon noyau. (Obtenus en compilant la version 0.7 de lirc.) Ce fut pour moi le seul moyen de rendre possible le choix "HWMOD=lirc_serial". Le script de lancement de lircd réalise le chargement de ce module.
Les lignes ci-dessus montrent bien ma grande ignorance au sujet du noyau et des modules. Mais j'ai bien l'intention d'apprendre. Avant de me lancer dans l'aventure d'une recompilation du noyau, je souhaiterais toutefois avoir l'avis de personnes qualifiées sur les particularités du noyau actuel en rapport avec mon modeste projet. J'ai installé les sources (avec le rpm c'est facile) et parcouru le fichier .config. En voici les lignes qui me semblent en rapport avec LIRC, entrecoupées de quelques questions :
# Linux InfraRed Controller # CONFIG_LIRC_SUPPORT=m CONFIG_LIRC_MAX_DEV=8 CONFIG_LIRC_I2C=m CONFIG_LIRC_GPIO=m CONFIG_LIRC_BT829=m CONFIG_LIRC_IT87=m CONFIG_LIRC_ATIUSB=m # CONFIG_LIRC_MCEUSB is not set # CONFIG_LIRC_PARALLEL is not set CONFIG_LIRC_SERIAL=m
Cette dernière ligne ne signifie-t-elle pas qu'un module LIRC_SERIAL serait normalement chargé si un programme en a besoin ? Devrais-je trouver quelque part sous /lib/modules/2.6.8.1-24mdk/kernel un fichier LIRC_SERIAL.ko, LIRC_SERIAL.o ou LIRC_SERIAL.ko.gz ? Un fichier LIRC_DEV.ko, LIRC_DEV.o ou LIRC_DEV.ko.gz ? (Ces fichiers n'existaient pas avant que j'en dépose dans le sous-répertoire /3rdparty/lirc créé par mes soins.)
# CONFIG_LIRC_HOMEBREW is not set
Est-ce une option que je devrais ajouter en vue de la recompilation que j'envisage ? Mon périphérique est constitué d'une simple led infra-rouge attaquée par le port série.
# CONFIG_LIRC_SERIAL_ANIMAX is not set CONFIG_LIRC_SERIAL_IRDEO=y # CONFIG_LIRC_SERIAL_IRDEO_REMOTE is not set CONFIG_LIRC_SERIAL_TRANSMITTER=y
Cette dernière ligne signifie-t-elle comme je le crois que, sans faire appel à un module extérieur, LIRC serait en mesure de moduler en tout ou rien la porteuse (faisceau IR cadencé à fréquence fixe) générée par un dispositif matériel appelé émetteur connecté à un port du pc ?
CONFIG_LIRC_SERIAL_SOFTCARRIER=y
Celle-là signifie-t-elle que la fréquence porteuse modulée serait directement disponible sur le port, sans faire appel à un émetteur ni à un module ? Est-ce possible en chargeant le module LIRC_SERIAL ? Est-ce possible sans le charger ? Est-ce possible malgré l'absence de LIRC_HOMEBREW ?
# CONFIG_LIRC_SERIAL_IGOR is not set CONFIG_LIRC_SERIAL_COM1=y # CONFIG_LIRC_SERIAL_COM2 is not set # CONFIG_LIRC_SERIAL_COM3 is not set # CONFIG_LIRC_SERIAL_COM4 is not set # CONFIG_LIRC_SERIAL_OTHER is not set CONFIG_LIRC_PORT_SERIAL=0x3f8 CONFIG_LIRC_IRQ_SERIAL=0x4 CONFIG_LIRC_SIR=m # CONFIG_LIRC_ON_SA1100 is not set CONFIG_LIRC_SIR_IRDA=y # CONFIG_LIRC_SIR_TEKRAM is not set # CONFIG_LIRC_SIR_ACTISYS_ACT200L is not set CONFIG_LIRC_SIR_COM1=y # CONFIG_LIRC_SIR_COM2 is not set # CONFIG_LIRC_SIR_COM3 is not set # CONFIG_LIRC_SIR_COM4 is not set # CONFIG_LIRC_SIR_OTHER is not set CONFIG_LIRC_PORT_SIR=0x3f8 CONFIG_LIRC_IRQ_SIR=0x4
Merci d'avance pour vos suggestions, explications, commentaires et marques de sympathie.
Et votre indulgence.
geo cherchetout
Le 19.03.2005 17:15 :
CONFIG_LIRC_SERIAL=m
Cette dernière ligne ne signifie-t-elle pas qu'un module LIRC_SERIAL serait normalement chargé si un programme en a besoin ? Devrais-je trouver quelque part sous /lib/modules/2.6.8.1-24mdk/kernel un fichier LIRC_SERIAL.ko, LIRC_SERIAL.o ou LIRC_SERIAL.ko.gz ? Un fichier LIRC_DEV.ko, LIRC_DEV.o ou LIRC_DEV.ko.gz ?
Réponse : Oui, cette paire de fichiers devrait exister depuis l'installation du noyau. Mais lors de la compilation des sources, ces fichiers, ainsi que tous ceux concernant Lirc, ne sont pas fabriqués. Je l'ai vérifié en me livrant à ma première compilation de noyau avec les mêmes bonnes options dans .config.
# CONFIG_LIRC_HOMEBREW is not set
Est-ce une option que je devrais ajouter en vue de la recompilation que j'envisage ? Mon périphérique est constitué d'une simple led infra-rouge attaquée par le port série.
Aucun rapport apparamment mais je ne sais toujours pas au juste de quoi il s'agit.
CONFIG_LIRC_SERIAL_TRANSMITTER=y
Cette dernière ligne signifie-t-elle comme je le crois que, sans faire appel à un module extérieur, LIRC serait en mesure de moduler en tout ou rien la porteuse (faisceau IR cadencé à fréquence fixe) générée par un dispositif matériel appelé émetteur connecté à un port du pc ?
Mauvaise interprétation. Ceci conditionne la possibilité d'émettre par le port série dans tous les cas. (Impulsions brutes ou impulsions modulant une porteuse.)
CONFIG_LIRC_SERIAL_SOFTCARRIER=y
Celle-là signifie-t-elle que la fréquence porteuse modulée serait directement disponible sur le port, sans faire appel à un émetteur ni à un module ?
En effet, cela est nécessaire en plus pour que la porteuse soit directement délivrée sans électronique extérieure.
Est-ce possible en chargeant le module LIRC_SERIAL ?
Cette condition doit en effet être remplie. Et pour que ce soit possible le port série doit préalablement être rendu disponible. (setserial /dev/ttyS0 uart none)
Est-ce possible sans le charger ?
J'y ai échoué mille fois. Mais peut-être est-ce possible avec CONFIG_LIRC_SERIAL=y au lieu de m ?
Est-ce possible malgré l'absence de LIRC_HOMEBREW ?
Oui.
Finalement, le problème avait deux causes : - Celle des modules qui ne peuvent se charger avec le noyau 2.6.8.1-12mdk qui est fourni pour Mandrake 10.1. Le 2.6.8.1-24mdk a le même défaut. (Bug répertorié 12418 dans Bugzilla.) - Celle d'un choix insuffisant d'option lors de la fabrication du rpm lirc-0.6.6-7mdk. Il manque l'option --with-transmitter. (Nouveau bug 14933 dans Bugzilla.)
Tout marche bien quand on installe lirc-0.7.0 depuis les sources car l'installation dépose au bon endroit les fichiers lirc_dev.ko et lirc_serial.ko si nécessaire. Mais un rpm corrigé aura quand-même le gros avantage de mettre en place des scripts qui font de lirc un service et réalisent les actions préliminaires nécessaires au lancement du demon.
En espérant que ces explications aideront un jour quelqu'un à y comprendre quelque chose.
Le 19.03.2005 17:15 :
CONFIG_LIRC_SERIAL=m
Cette dernière ligne ne signifie-t-elle pas qu'un module LIRC_SERIAL
serait normalement chargé si un programme en a besoin ? Devrais-je
trouver quelque part sous /lib/modules/2.6.8.1-24mdk/kernel un
fichier LIRC_SERIAL.ko, LIRC_SERIAL.o ou LIRC_SERIAL.ko.gz ? Un
fichier LIRC_DEV.ko, LIRC_DEV.o ou LIRC_DEV.ko.gz ?
Réponse : Oui, cette paire de fichiers devrait exister depuis
l'installation du noyau. Mais lors de la compilation des sources, ces
fichiers, ainsi que tous ceux concernant Lirc, ne sont pas fabriqués. Je
l'ai vérifié en me livrant à ma première compilation de noyau avec les
mêmes bonnes options dans .config.
# CONFIG_LIRC_HOMEBREW is not set
Est-ce une option que je devrais ajouter en vue de la recompilation
que j'envisage ? Mon périphérique est constitué d'une simple led
infra-rouge attaquée par le port série.
Aucun rapport apparamment mais je ne sais toujours pas au juste de quoi
il s'agit.
CONFIG_LIRC_SERIAL_TRANSMITTER=y
Cette dernière ligne signifie-t-elle comme je le crois que, sans
faire appel à un module extérieur, LIRC serait en mesure de moduler
en tout ou rien la porteuse (faisceau IR cadencé à fréquence fixe)
générée par un dispositif matériel appelé émetteur connecté à un port
du pc ?
Mauvaise interprétation. Ceci conditionne la possibilité d'émettre par
le port série dans tous les cas. (Impulsions brutes ou impulsions
modulant une porteuse.)
CONFIG_LIRC_SERIAL_SOFTCARRIER=y
Celle-là signifie-t-elle que la fréquence porteuse modulée serait
directement disponible sur le port, sans faire appel à un émetteur ni
à un module ?
En effet, cela est nécessaire en plus pour que la porteuse soit
directement délivrée sans électronique extérieure.
Est-ce possible en chargeant le module LIRC_SERIAL ?
Cette condition doit en effet être remplie. Et pour que ce soit possible
le port série doit préalablement être rendu disponible. (setserial
/dev/ttyS0 uart none)
Est-ce possible sans le charger ?
J'y ai échoué mille fois. Mais peut-être est-ce possible avec
CONFIG_LIRC_SERIAL=y au lieu de m ?
Est-ce possible malgré l'absence de
LIRC_HOMEBREW ?
Oui.
Finalement, le problème avait deux causes :
- Celle des modules qui ne peuvent se charger avec le noyau
2.6.8.1-12mdk qui est fourni pour Mandrake 10.1. Le 2.6.8.1-24mdk a le
même défaut. (Bug répertorié 12418 dans Bugzilla.)
- Celle d'un choix insuffisant d'option lors de la fabrication du rpm
lirc-0.6.6-7mdk. Il manque l'option --with-transmitter. (Nouveau bug
14933 dans Bugzilla.)
Tout marche bien quand on installe lirc-0.7.0 depuis les sources car
l'installation dépose au bon endroit les fichiers lirc_dev.ko et
lirc_serial.ko si nécessaire. Mais un rpm corrigé aura quand-même le
gros avantage de mettre en place des scripts qui font de lirc un service
et réalisent les actions préliminaires nécessaires au lancement du demon.
En espérant que ces explications aideront un jour quelqu'un à y
comprendre quelque chose.
Cette dernière ligne ne signifie-t-elle pas qu'un module LIRC_SERIAL serait normalement chargé si un programme en a besoin ? Devrais-je trouver quelque part sous /lib/modules/2.6.8.1-24mdk/kernel un fichier LIRC_SERIAL.ko, LIRC_SERIAL.o ou LIRC_SERIAL.ko.gz ? Un fichier LIRC_DEV.ko, LIRC_DEV.o ou LIRC_DEV.ko.gz ?
Réponse : Oui, cette paire de fichiers devrait exister depuis l'installation du noyau. Mais lors de la compilation des sources, ces fichiers, ainsi que tous ceux concernant Lirc, ne sont pas fabriqués. Je l'ai vérifié en me livrant à ma première compilation de noyau avec les mêmes bonnes options dans .config.
# CONFIG_LIRC_HOMEBREW is not set
Est-ce une option que je devrais ajouter en vue de la recompilation que j'envisage ? Mon périphérique est constitué d'une simple led infra-rouge attaquée par le port série.
Aucun rapport apparamment mais je ne sais toujours pas au juste de quoi il s'agit.
CONFIG_LIRC_SERIAL_TRANSMITTER=y
Cette dernière ligne signifie-t-elle comme je le crois que, sans faire appel à un module extérieur, LIRC serait en mesure de moduler en tout ou rien la porteuse (faisceau IR cadencé à fréquence fixe) générée par un dispositif matériel appelé émetteur connecté à un port du pc ?
Mauvaise interprétation. Ceci conditionne la possibilité d'émettre par le port série dans tous les cas. (Impulsions brutes ou impulsions modulant une porteuse.)
CONFIG_LIRC_SERIAL_SOFTCARRIER=y
Celle-là signifie-t-elle que la fréquence porteuse modulée serait directement disponible sur le port, sans faire appel à un émetteur ni à un module ?
En effet, cela est nécessaire en plus pour que la porteuse soit directement délivrée sans électronique extérieure.
Est-ce possible en chargeant le module LIRC_SERIAL ?
Cette condition doit en effet être remplie. Et pour que ce soit possible le port série doit préalablement être rendu disponible. (setserial /dev/ttyS0 uart none)
Est-ce possible sans le charger ?
J'y ai échoué mille fois. Mais peut-être est-ce possible avec CONFIG_LIRC_SERIAL=y au lieu de m ?
Est-ce possible malgré l'absence de LIRC_HOMEBREW ?
Oui.
Finalement, le problème avait deux causes : - Celle des modules qui ne peuvent se charger avec le noyau 2.6.8.1-12mdk qui est fourni pour Mandrake 10.1. Le 2.6.8.1-24mdk a le même défaut. (Bug répertorié 12418 dans Bugzilla.) - Celle d'un choix insuffisant d'option lors de la fabrication du rpm lirc-0.6.6-7mdk. Il manque l'option --with-transmitter. (Nouveau bug 14933 dans Bugzilla.)
Tout marche bien quand on installe lirc-0.7.0 depuis les sources car l'installation dépose au bon endroit les fichiers lirc_dev.ko et lirc_serial.ko si nécessaire. Mais un rpm corrigé aura quand-même le gros avantage de mettre en place des scripts qui font de lirc un service et réalisent les actions préliminaires nécessaires au lancement du demon.
En espérant que ces explications aideront un jour quelqu'un à y comprendre quelque chose.
