Depuis des années, le nombre de télécommandes à infrarouge (IR) ne cesse de croître chez moi alors que l'équipement électronique qu'elles contrôlaient disparaît. Or la carte d'expansion achetée avec l'ordinateur monocarte Orange Pi Zero contient un récepteur infrarouge. C'était donc prévisible que j'essayerais d'utiliser une télécommande surnuméraire avec l'Orange Pi Zero. En deux billets, voici comment j'ai procédé.
Ce premier billet est consacré au matériel: comment installer le pilote du récepteur IR et comment prendre en charge diverses télécommandes. Le second billet qui ne saurait trop tarder examine le côté logiciel. Ces deux billets constitueront une version améliorée de trois billets rédigés en anglais.
Bien qu'il soit question d'un Orange Pi Zero exécutant Armbian Stretch, une grande partie de ce qui se trouve ici, excluant l'installation du pilote du récepteur IR, serait probablement valable pour le Raspberry Pi. Je compte examiner cela plus tard.
Table des matières
- Installation du module IR du noyau
- Sélectionner le protocole IR
- Obtenir les codes de balayage de la télécommande
- Les codes de clavier
- L'utilitaire
ir-keytable
- Répétition automatique
- Gestion des tables de code
- La règle
udev
défectueuse - Le fichier de configuration
rc_maps.cfg
- Configuration automatique
- Conclusion
Installation du module IR du noyau
Par défaut, le pilote du récepteur infrarouge, appelé
sunxi-cir
, n'est pas installé. Cela a du sens car l’Orange Pi
Zero n’a pas de récepteur IR à bord. Cependant, la carte d’extension en
option en contient un, que j'utiliserai dans ce qui suit. Le moyen le plus
simple, en fait, le seul que je connaisse pour charger le module du noyau
lors du démarrage est d'utiliser l'utilitaire armbian-config
.
Activez le module cir
dans les paramètres
système/matériel (System/Hardware). Si cette procédure n'est
pas familière, voici les détails commençant par le lancement de
l'utilitaire de configuration.
Mettre en surbrillance System à l'aide des touches de curseur haut et bas, puis en "cliquant" sur le bouton < OK >. Pour ce faire, il faut appuyer sur la barre d'espacement ou sur le bouton Entrée lorsque < OK > est sélectionné. Si ce bouton n'est pas en surbrillance, utilisez la touche de tabulation ou les touches de curseur gauche et droite pour le sélectionner.
Dans l'écran System settings
, mettre en surbrillance l'option
Hardware (matériel) et cliquer sur le bouton < OK >.
Dans l'écran Toggle hardware configuration
(basculer la
configuration matérielle), mettre en surbrillance la fonction
cir
et appuyer sur la barre d'espacement
de sorte qu'une étoile '*' apparaisse à gauche de cir
.
Cliquer sur le bouton < Save > (enregistrer),
puis sur le bouton < Exit >.
Enfin, cliquer sur le bouton < Reboot >.
Après environ une minute, démarrer une nouvelle session SSH avec l’OPiZ pour effectuer quelques vérifications, question de voir si le module est chargé et initialisé.
Tout semble en ordre. Le module est chargé, il est initialisé au
démarrage et l'arborescence du dispositif /sys/devices/platform/soc/1f02000.ir/rc/rc0
a été crée par le noyau. Typiquement, on n'accède pas directement au
contenu de ce dossier; on passe plutôt par un lien symbolique.
Les signaux IR décodés provenant de la télécommande infrarouge devraient
s'afficher sur l'entrée event0
. Il est temps d'essayer la
télécommande. Notez que si le filtre xxd
n'est pas installé,
exécutez la commande sans | xxd
. La sortie aura l’air très
bizarre, mais peu importe.
Cela semblait si prometteur, mais rien ne se passa lorsque j’appuyai
sur des boutons de la télécommande infrarouge qu'on peut voir à droite. Comme
on peut le constater, la télécommande est l’une de celles que l'on obtient
chez les vendeurs chinois habituels pour presque rien; environ 1 $US pour la
télécommande et un récepteur IR. Or presque toutes ces télécommandes bon
marché utilisent le protocole NEC. Il est donc temps de regarder le protocole
IR pris en charge par le module IR du noyau. Pour quitter la commande
cat
qui attend toujours un événement, appuyez sur la combinaison
de touches CtrlC.
Sélectionner le protocole IR
Il suffit d'afficher le contenu d'un fichier pour connaître le protocol actuellement utilisé.
Les protocoles connus sont affichés, celui ou ceux pris en charge actuellement sont entre les crochets []. Il est nécessaire de devenir le "superutilisateur" pour activer un autre protocole.
On peut aller directement à la section suivante, car ce qui suit est une explication de la forme un peu complexe de la commande pour changer le protocole et l'élaboration d'un petit script pour simplifier la tâche.
On ne peut pas utilisé la commande sudo
devant
la fonction echo
.
Comme on peut le constater, l'écriture dans le fichier
protocols
ne peut être effectuée que par le propriétaire du
fichier qui est root
. La commande echo
est exécutée
en tant qu'utilisateur root
à cause du préfixe
sudo
, mais l'écriture du résultat dans le fichier est effectuée
en tant qu'utilisateur zéro
qui ne dispose pas de ce privilège.
Cela me rappelle une erreur que je fais parfois. La commande combinée
ne fonctionne pas, car seul update
est fait en tant que
root
. Il faut écrire
Quelque chose de semblable à cela doit être fait. C’est un problème bien connu qui a fait l’objet d’un long dialogue sur stackoverflow depuis 2008. Voici une des deux solutions généralement acceptées.
On peut expliquer ce qui se passe. La sortie de la commande
echo
est introduite dans l'entrée du programme tee
.
Celui-ci est un filtre qui reporte ses entrées dans le fichier spécifié. La
commande sudo
signifie que root
exécute
tee
qui aura le privilège d'écriture nécessaire.
Heureusement que tee
est déjà installé sur Armbian mais que faire si cet utilitaire n'est pas disponible ?
L'autre solution proposée est que root
créé
une session dans laquelle la commande echo
est exécuté par
root
.
J'ai eu à changer le protocole tellement souvent qu'inspiré par hololeap, j'ai
décidé de créer une fonction dans le fichier de configuration de
bash
. Comme on verra, cela n'est pas vraiment nécessaire, car
ir-keytable
sera installé plus tard et il est capable d'en faire
autant.
Il suffit d'ajouter les lignes suivantes.
La session doit être redémarrée pour que la commande soit disponible. Au
lieu d'une page man
expliquant comment l'utiliser, voici une
liste exhaustive d'exemples.
- Afficher les protocoles IR connus et actuellement pris en charge.
- zero@opi:~$ irp IR protocols: rc-5 nec rc-6 [jvc] sony rc-5-sz sanyo sharp mce_kbd xmp imon [lirc]Les protocoles pris en charge sont entre les crochets [].
lirc
est toujours pris en charge. - Activer qu'un seul protocole IR.
- zero@opi:~$ irp nec IR protocols: rc-5 [nec] rc-6 jvc sony rc-5-sz sanyo sharp mce_kbd xmp imon [lirc]
- Activer un protocole IR supplémentaire.
- zero@opi:~$ irp +jvc IR protocols: rc-5 [nec] rc-6 [jvc] sony rc-5-sz sanyo sharp mce_kbd xmp imon [lirc]
- Désactivé un seul protocole IR.
- zero@opi:~$ irp IR protocols: rc-5 [nec] rc-6 [jvc] sony rc-5-sz sanyo sharp mce_kbd xmp imon [lirc] zero@opi:~$ zero@opi:~$ irp -jvc IR protocols: rc-5 [nec] rc-6 jvc sony rc-5-sz sanyo sharp mce_kbd xmp imon [lirc]
- Combinaison d'opérations multiples.
- zero@opi:~$ irp IR protocols: rc-5 [nec] rc-6 [jvc] sony rc-5-sz sanyo sharp [mce_kbd] xmp imon [lirc] zero@opi:~$ zero@opi:~$ irp "-jvc +sony +sanyo" IR protocols: rc-5 [nec] rc-6 jvc [sony] rc-5-sz [sanyo] sharp [mce_kbd] xmp imon [lirc]
- Activer tous les protocoles IR connus.
- zero@opi:~$ irp "rc-5 +nec +rc-6 +jvc +sony +rc-5-sz +sanyo +sharp +mce_kbd +xmp +imon" IR protocols: [rc-5] [nec] [rc-6] [jvc] [sony] [rc-5-sz] [sanyo] [sharp] [mce_kbd] [xmp] [imon] [lirc]
- Désactiver tous les protocoles IR.
- zero@opi:~$ irp lirc IR protocols: rc-5 nec rc-6 jvc sony rc-5-sz sanyo sharp mce_kbd xmp imon [lirc]
Obtenir les codes de balayage de la télécommande
En activant le bon protocol IR, il est maintenant possible d'afficher les codes provenant de la télécommande.
Comme précédemment, appuyer sur la combinaison de touches CtrlC quand l'affichage incompréhensible ne saura plus fasciner.
/dev/input/event0
existe, alors il se peut qu'un autre
processus se soit accaparer le périphérique. On peut vérifier avec l'utilitaire
fuser
.
On peut voir ici que lircd
est installé et utilise
le périphérique. On peut éliminer cette bibliothèque.
Si vous ne savez pas quel protocole est utilisé par une télécommande, activez-les tous pour au moins établir que le noyau peut la prendre en charge. On peut faire cela dans une autre session, les changements de protocoles se manifestent immédiatement dans toutes les sessions ouvertes.
Une autre remarque s'impose. L'utilisateur, ici c'est zero
,
doit être membre du groupe input
pour accéder à la file
d'attente d'événements. En principe, c'est déjà le cas dans Armbian.
Le flux de valeurs lues de la file d'événements event0
n'est
pas facilement interprété. Il y a un programme qui rend intelligible cette
production. Si, comme c'est le cas dans Raspbian,
evtest
n'est pas installé (on peut le faire facilement avec la
commande habituelle&nbps;: sudo apt install evdev. Ce n'est pas
indispensable, ir-keytable -t
, qu'on verra plus loin,
accomplie à peu près la même tâche.
Voici un peu d'information (an anglais) au sujet des types d'événements dont les deux affichés ci-dessus.
- EV_MSC
- Décrit comme des « données d'entrée diverses » (miscellaneous input data) car ces événements ne relèvent pas des autres catégories définies telles que EV_KEY (clavier, boutons ...), EV_REL (mouvements de la souris), EV_SW (commutateurs).
- EV_SYN
- Décrit comme « marqueurs pour séparer les événements » (markers to separate events).
Chaque type a un ensemble de codes identifiant les événements. SYN_REPORT est l'un des 4 codes associés à EV_SYN et il « synchronise et sépare des événements en paquets de modifications de données d'entrée se produisant au même moment dans le temps ». Cela n’a pas grand sens ici, mais il pourrait être utile de faire la distinction entre des mouvements X et Y de la souris se produisant simultanément et deux mouvements séquentiels le long des axes X et Y.
Le code MSC_SCAN n'est pas défini dans la documentation, mais il fait
évidemment référence à un code de balayage généré par le périphérique
d'entrée. Le code de balayage associé à chaque bouton de la télécommande
infrarouge est indiqué dans le champ nommé value
. Le champ
time
est probablement le code MSC_TIMESTAMP qui correspond au
"nombre de microsecondes écoulées depuis la dernière réinitialisation". Il
est censé être une valeur entière non signée sur 32 bits. En fait, la partie
entière est l'heure Posix soit le nombre de secondes écoulées depuis le
1970-01-01 00:00 temps universel coordonnée.
Facilement et rapidement, il a été possible de créer avec
evtest
le tableau suivant qui indique le code de balayage (en
hexadécimal et décimal) de chaque bouton poussoir de la télécommande
Code | Button | Code | Button | |||
---|---|---|---|---|---|---|
0x52 | 82 | 0 | 0x46 | 70 | UP | |
0x16 | 22 | 1 | 0x40 | 64 | OK | |
0x19 | 25 | 2 | 0x15 | 21 | DOWN | |
0x0d | 13 | 3 | 0x43 | 67 | RIGHT | |
0x0c | 12 | 4 | 0x44 | 68 | LEFT | |
0x18 | 24 | 5 | 0x42 | 66 | * | |
0x5e | 94 | 6 | 0x4a | 74 | # | |
0x08 | 8 | 7 | ||||
0x1c | 28 | 8 | ||||
0x5a | 90 | 9 |
Il existe une bibliothèque Python qui peut lire la file d'attente d'événements. Il est donc possible d'écrire un script Python pour traduire les codes de balayage de la télécommande en actions. Toutefois, je ne recommande pas une telle approche, et ce pour deux raisons. Premièrement, si l'on devait changer de télécommande il faudrait refaire le script car les fabricants n'utilisent pratiquement jamais les mêmes codes de balayage. Il est préférable de convertir les codes de balayage en symboles abstraits, dits codes de clavier, et d'établir les actions à prendre en fonction de ces symboles. D'importants programmes comme Kodi (xmbc) et Rhythmbox peuvent être contrôlés avec ces symboles abstraits. Deuxièmement, le noyau prend en charge cette conversion tout en simplifiant le flux d'événements de telle sorte qu'un script Python véritablement utile sera bien plus facile à écrire.
Les codes de clavier
La conversion d'un code de balayage (scancode) en un code de clavier (keycode) est pris en charge par le noyau. Encore faut-il qu'il sache quels sont les codes de balayage de la télécommande et les codes de clavier correspondants.
La table suivante montre une correspondance possible entre les codes de balayage et de clavier pour la télécommande KEYES.
Ce n'est pas la seule définition possible, on pourrait faire correspondre
les boutons numériques à des codes claviers différents et le bouton OK
au code KEY_PLAY
.
Tout cela dépend des attentes du programme qui utilisera la télécommande
infrarouge. Les codes de clavier tels KEY_0
et
KEY_OK
sont en fait des symboles qui correspondent à des
nombres.
Typiquement, il n'est pas nécessaire de connaître les équivalences
numériques des symboles, mais en revanche il est utile d'avoir la liste des
symboles. On retrouve des listes plus ou moins complètes comme celle de Richard Atterer. On peut engendrer une liste avec la
commande irrecord -l
ou
irrecord --list-namespace
qui fait partie de LIRC, on peut utiliser mon script Python keytable.py (avec les options
-l
, -ld
ou -lh
), ou l'on peut consulter
la liste définitive input-event-codes.h.
Le fait qu'un symbole soit contenu dans cette liste ne veut évidemment
pas dire qu'il soit significatir pour un logiciel quelconque qui prend en
charge les télécommandes IR. Un programme pourrait interpréter les
code clavier KEY_1
, KEY_2
, etc comme des nombres,
un autre programme en ferait autant mais avec les codes clavier
KEY_NUMERIC_1
, KEY_NUMERIC_2
L'utilitaire ir-keytable
Il faut une table d'équivalence entre codes de balayage d'une télécommande
et codes de clavier, mais il faut aussi que le module IR du noyau soit
appelé à utiliser cette table. C'est ici qu'intervient l'utilitaire
ir-keytable
. Celui-ci n'est pas présent dans l'image téléchargée
de Armbian. On installe l'utilitaire sans difficulté
de la façon classique.
En plus du programme, plusieurs fichiers sont ajouté au système dont
des tables de conversion pour de nombreuses télécommandes dans de répertoire
/lib/udev/rc_keymaps
, des objets noyau associés dans
/lib/modules/4.19.17-sunxi/kernel/drivers/media/rc/keymaps/
,
une règle udev
, un fichier de configuration et un répertoire
vide dans /etc
.
Cela fait beaucoup, mais avec l'aide abondante sur le Web et
la page man
de l'utilitaire (disponible en
français) on s'y retrouve. Examinons initialement l'utilisation interactive
de l'utilitaire.
L'exécution du programme sans aucun paramètre de ligne de commande affiche des informations sur les pilotes, les périphériques, les protocoles actuellement pris en charge, etc.
On peut fixer les protocoles à prendre en charge.
Notez la nécessité du préfixe sudo
. L'option -p
(forme longue: --protocol
) n'a
pas la souplesse de mon script irp
, mais la facilité avec
laquelle on peut sélectionner tous les protocoles en même temps est fort
utile pour vérifier la compatibilité d'un contrôle à distance IR inconnu.
L'option -t
(ou --test
) est
utilisée pour lire les événements engendrés par la télécommande. Elle est
utilisée ci-dessous avec tous les protocoles pour vérifier qu'une vieille
télécommande Hauppauge est compatible.
Il a été facile de déterminer que la télécommande utilise le protocole
rc-5
. Il est possible de définir les codes de clavier pour les
codes de balayage avec ir-keytable
, puis d’afficher les codes de
balayage reçus et les codes de clavier correspondants s’ils sont
disponibles.
L'option -k
a été utilisé pour définir les codes de clavier,
pour les boutons «1» et «2». Quand ces boutons et le bouton «3» sont activés,
l'utilitaire affiche leur code de balayage et le code de clavier
correspondant lorsque défini. Notez également comment les événements
key_down
et key_up
de type EV_KEY
sont
signalés avec les codes de clavier.
Si l'on utilise evdev
on peut voir les dessous de ce qui
se passe un peu mieux et l'on confirme que c'est bien le noyau qui
modifie les événements quand un code clavier est défini.
Lorsque le bouton «1» est enfoncé, deux événements se produisent. Le
premier, de type EV_MSC
, retourne le code de balayage
0x1e01
dans le champ value
. Le second, de type
EV_KEY
retourne le code de clavier 2
soit
KEY_1
dans le champ code
. La valeur 1
dans le champ value
indique que le bouton a été enfoncé. Quand
le bouton est relâché, ce sont presque les mêmes événements qui sont
engendrés, la seule différence est la valeur 0
dans le champ
value
de l'événement de type EV_KEY
. Ce
0
indique que le bouton a été relâché. Voilà d'où viennent les
key_down
et key_up
qu'on a vus avec
ir-keytable
.
Répétition automatique
La plupart des télécommandes retransmettent à une fréquence régulière le code de balayage d'un bouton qu'on garde enfoncé. Selon ce qui suit, une troisième télécommande, de HP, sur laquelle il est indiqué que le protocole utilisé est RC-6, répète le code à chaque dixième de seconde.
Indépendamment des capacités de répétition du contrôle à distance, le
noyau répète les codes de clavier s'ils sont définis, mais il ne répète pas
les codes de balayage. Les valeurs par défaut sont un délai initial de 1/2
seconde (500 ms) et une période de répétition de 1/8 seconde (125 ms). Ce
sont des valeurs typiques pour un clavier. Le tableau suivant indique les
intervalles de temps entre les codes de balayage et les codes de clavier
lorsque le bouton «1» est maintenu enfoncé pendant 3 secondes. Les événements
de synchronisation EV_SYN
ont été supprimés pour obtenir une
image plus claire. La première colonne est l'horodatage de l'évènement. La
cinquième colonne Delta EV_*
est l'intervalle de temps en
millisecondes entre les événements successifs, qu'il s'agisse de codes de
balayage de la télécommande ou de codes de clavier. La dernière colonne,
Delta EV_KEY
contient les intervalles de temps entre les
codes EV_KEY
. Comme la période de répétition des codes de
clavier est de 125 ms et la période de répétition de la télécommande est de
100 ms, la plupart du temps, il n'y a qu'un code de balayage entre deux codes
de clavier, mais occasionnellement il y en a deux. L'exception est au début
en raison du délai de 500 ms avant la première répétition du code de
clavier.
Heure posix | Événement | Type | Code | Delta EV_* | Delta EV_KEY |
---|---|---|---|---|---|
1549903838.71569 | EV_MSC(0x04) | scancode | 0x800f0401 | ||
1549903838.71569 | EV_KEY(0x01) | key_down | KEY_1(0x0002) | ||
1549903838.82179 | EV_MSC(0x04) | scancode | 0x800f0401 | 106 | |
1549903838.92789 | EV_MSC(0x04) | scancode | 0x800f0401 | 106 | |
1549903839.03404 | EV_MSC(0x04) | scancode | 0x800f0401 | 106 | |
1549903839.14021 | EV_MSC(0x04) | scancode | 0x800f0401 | 106 | |
1549903839.24636 | EV_MSC(0x04) | scancode | 0x800f0401 | 106 | |
1549903839.24705 | EV_KEY(0x01) | key_down | KEY_1(0x0002) | 1 | 531 |
1549903839.35254 | EV_MSC(0x04) | scancode | 0x800f0401 | 105 | |
1549903839.37905 | EV_KEY(0x01) | key_down | KEY_1(0x0002) | 27 | 132 |
1549903839.45869 | EV_MSC(0x04) | scancode | 0x800f0401 | 80 | |
1549903839.51104 | EV_KEY(0x01) | key_down | KEY_1(0x0002) | 52 | 132 |
1549903839.56487 | EV_MSC(0x04) | scancode | 0x800f0401 | 54 | |
1549903839.64305 | EV_KEY(0x01) | key_down | KEY_1(0x0002) | 78 | 132 |
1549903839.67109 | EV_MSC(0x04) | scancode | 0x800f0401 | 28 | |
1549903839.77505 | EV_KEY(0x01) | key_down | KEY_1(0x0002) | 104 | 132 |
1549903839.77717 | EV_MSC(0x04) | scancode | 0x800f0401 | 2 | |
1549903839.88333 | EV_MSC(0x04) | scancode | 0x800f0401 | 106 | |
1549903839.90704 | EV_KEY(0x01) | key_down | KEY_1(0x0002) | 24 | 130 |
1549903839.98951 | EV_MSC(0x04) | scancode | 0x800f0401 | 82 | |
1549903840.03905 | EV_KEY(0x01) | key_down | KEY_1(0x0002) | 50 | 132 |
1549903840.09567 | EV_MSC(0x04) | scancode | 0x800f0401 | 57 | |
1549903840.17105 | EV_KEY(0x01) | key_down | KEY_1(0x0002) | 75 | 132 |
1549903840.20184 | EV_MSC(0x04) | scancode | 0x800f0401 | 31 | |
1549903840.30305 | EV_KEY(0x01) | key_down | KEY_1(0x0002) | 101 | 132 |
1549903840.30798 | EV_MSC(0x04) | scancode | 0x800f0401 | 5 | |
1549903840.41415 | EV_MSC(0x04) | scancode | 0x800f0401 | 106 | |
1549903840.43504 | EV_KEY(0x01) | key_down | KEY_1(0x0002) | 21 | 127 |
1549903840.52032 | EV_MSC(0x04) | scancode | 0x800f0401 | 85 | |
1549903840.56705 | EV_KEY(0x01) | key_down | KEY_1(0x0002) | 47 | 132 |
1549903840.62648 | EV_MSC(0x04) | scancode | 0x800f0401 | 59 | |
1549903840.69904 | EV_KEY(0x01) | key_down | KEY_1(0x0002) | 73 | 132 |
1549903840.73265 | EV_MSC(0x04) | scancode | 0x800f0401 | 34 | |
1549903840.83105 | EV_KEY(0x01) | key_down | KEY_1(0x0002) | 98 | 132 |
1549903840.83879 | EV_MSC(0x04) | scancode | 0x800f0401 | 8 | |
1549903840.94495 | EV_MSC(0x04) | scancode | 0x800f0401 | 106 | |
1549903840.96304 | EV_KEY(0x01) | key_down | KEY_1(0x0002) | 18 | 124 |
1549903841.05119 | EV_MSC(0x04) | scancode | 0x800f0401 | 88 | |
1549903841.09505 | EV_KEY(0x01) | key_down | KEY_1(0x0002) | 44 | 132 |
1549903841.15729 | EV_MSC(0x04) | scancode | 0x800f0401 | 62 | |
1549903841.22704 | EV_KEY(0x01) | key_down | KEY_1(0x0002) | 70 | 132 |
1549903841.26346 | EV_MSC(0x04) | scancode | 0x800f0401 | 36 | |
1549903841.35905 | EV_KEY(0x01) | key_down | KEY_1(0x0002) | 96 | 132 |
1549903841.3696 | EV_MSC(0x04) | scancode | 0x800f0401 | 11 | |
1549903841.47578 | EV_MSC(0x04) | scancode | 0x800f0401 | 106 | |
1549903841.49105 | EV_KEY(0x01) | key_down | KEY_1(0x0002) | 15 | 121 |
1549903841.58194 | EV_MSC(0x04) | scancode | 0x800f0401 | 91 | |
1549903841.62306 | EV_KEY(0x01) | key_down | KEY_1(0x0002) | 41 | 132 |
1549903841.75504 | EV_KEY(0x01) | key_down | KEY_1(0x0002) | 132 | 173 |
1549903841.81905 | EV_KEY(0x01) | key_up | KEY_1(0x0002) | 64 |
Le délai initial avant la première répétition du code de clavier et la période de répétition du code de clavier après peuvent être modifiés avec les options -D et -P.
Gestion des tables de code
La fonction principale d'ir-keytable
est sa capacité à gérer
les tables traduisant les codes de balayage en codes de clavier stockés dans
des fichiers. On a déjà créé un fichier de ce genre pour la télécommande
KEYES (voir le début de la section Les codes de clavier).
Comme indiqué ci-dessus, un bon nombre de définitions de télécommande IR
ont été incluses dans le paquet ir-keytable
. Les fichiers se
trouvent dans le répertoire /lib/udev/rc_keymaps
. Parmi eux, il
en existe un pour les télécommandes RC6: rc6-mce
dont le
contrôleur à distance HP. La commande pour charger ce
fichier de traduction des codes est simple.
Les traductions de code contenues dans le fichier ont été ajoutées à celles déjà
utilisées par le noyau. Pour voir les entrées actuelles, utilisez l’option -r
(forme longue: --read
).
L'enregistrement KEY_COFFEE
n'est pas contenu dans le
fichier rc6_mce
. On efface la table d'enregistrements utilisés
par le noyau avec l'option -c
(ou --clear
) qui peut
être utilisé seul. En combinaison avec l'option d'écriture (-w
ou --write
), nous effectuons une opération de remplacement.
L'utilitaire sait quel protocole IR définir, car il est spécifié dans la première ligne du fichier de définition.
Le paramètre de ligne de commande -p
(ou
--protocol
) a préséance sur le protocole spécifié dans le
fichier de définition, ce qui sera très utile. Le préfixe sudo
doit être utilisé lorsque l'option -w
ou -p
si l'on
veut que le protocole soit modifié.
L'usage veut que l'on ne charge pas le fichier de définition d'une
télécommande directement à partir du répertoire
/lib/udev/rc_keymaps/
. Utilisez plutôt le répertoire
/etc/rc_keymaps
. Si le fichier inclus dans le package
ir-keytable
contient une définition correcte, créez un lien
symbolique vers celui-ci dans le répertoire /etc/rc_keymaps
.
Si la définition fournie doit être modifiée, copiez le fichier depuis
/lib/udev/rc_keymaps/
vers le répertoire
/etc/rc_keymaps
, modifiez cette copie selon vos besoins et
chargez son contenu modifié avec la même commande que ci-dessus. C'est ce que
j'ai fait avec la définition de la télécommande Hauppauge, pour modifier le code de clavier du bouton
«Power» à KEY_POWER
plutôt que KEY_POWER2
et pour
éliminer tous les enregistrements inutiles. Si un nouveau fichier de
définition doit être créé pour une télécommande infrarouge, placez-le dans le
répertoire /etc/rc_keymaps
. C’est ce que j’ai fait pour utiliser
la télécommande KEYES.
La commande suivante remplace la table de code utilisée par le noyau par
deux définitions afin que les télécommandes IR KEYES
et HP puissent être utilisées. Notez comment deux
protocoles IR ont été spécifiés sur la seconde ligne de commande. Cela était
nécessaire, car, sans l'option -p
, ir-keytable
aurait défini le protocole sur nec
uniquement en fonction de la
première ligne du fichier keyes
.
Comme on peut le constater, le code de clavier KEY_NUMERIC_1
est transmis par le noyau, d’abord en réponse au code de balayage
0x800f0401
de la télécommande HP à
l’aide du protocole RC-6, puis à la réception du code de balayage
0x16
via le protocole NEC de la télécommande KEYES.
La règle udev
défectueuse
L'installation de ir-keytable
a ajouté une règle
udev
. Si, comme moi, vous n'êtes pas familier avec
udev
, je recommande le document udev - the Linux dynamic
device management module de Debian, que j'ai
trouvé étonnamment compréhensible. Bravo à l'auteur. Voici la règle qui
devrait charger un fichier de configuration.
La règle ne fonctionne pas, du moins sur le Orange Pi Zero.
Je suppose que cela signifie que le récepteur infrarouge est reconnu par
udev
, mais qu'une erreur de segmentation s'est produite lorsque
ir-keytable
a essayé de charger le fichier de définition. Ceci
peut être une indication qu'un fichier est manquant. Pour en savoir plus,
j'ai modifié la règle.
After un redémarrage, j'ai pu constater que /sys/class/rc
n'avait pas encore été créé.
Peut-être que le répertoire
/sys/devices/platform/soc/1f02000.ir/rc/rc0
réel existait et que
la règle a été invoquée avant que le lien symbolique vers ce répertoire ne
soit créé. Alors j'ai renommé la règle pour qu'elle soit la dernière à être
exécutée et je l'ai encore modifiée.
Le résultat était tout aussi décevant. Il semble qu'il sera nécessaire de
recourir à une tache cron
au moment du démarrage pour
initialiser correctement le pilote IR.
Le fichier de configuration rc_maps.cfg
L'option -a
est utilisé pour charger le fichier de configuration,
rc_maps.cfg
comme dans la règle udev
. La façon dont le fichier de configuration
est censé fonctionner est mystérieuse pour certains, y compris moi. Voici
ce que j'ai pu déchiffré.
Un simple essai montrera que, contrairement à ce qui est écrit dans
l'en-tête, ir-keytable -a
ne fonctionnera pas.
Le chemin complet du fichier de configuration doit être spécifié. De plus,
keytable -a /etc/rc_maps.cfg
(avec ou sans le préfixe
sudo
) ne fait rien.
Pour expérimenter, j'ai supprimé toutes les entrées de la table des
pilotes (driver table), à l'exception de celle de la télécommande RC6.
Encore une fois ir-keytable -a /etc/rc_maps.cfg
n'a
rien fait. Cependant, changer l'enregistrement à
ou
fonctionne et la définition contenue dans rc6_mce est chargée:
Enfin, un peu de progrès. Notez que toute mention de l'objet noyau
rc-rc6-mce
avec ou sans l'extension .ko
et avec
ou sans son chemin complet ne fonctionne pas. L'ajout du pilote
sunxi-ir
comme premier élément ne change rien:
Malheureusement, il ne semble pas possible de charger deux définitions de contrôle à distance avec le fichier de configuration. J'ai essayé de lister les fichiers de traduction souhaités.
Cela ne fonctionne pas, ir-keytable
s’arrête dès que le
premier fichier est chargé.
Configuration automatique
Étant donné les deux dernières sections, voici comment la pile IR est
initialisée au démarrage de l'Orange Pi Zero si une seule télécommande est
utilisée. Commencez par ajouter dans le fichier de configuration
/etc/rc_maps.cfg
le nom d'un fichier de définition contenu dans le
répertoire /etc/rc_keymaps
, comme indiqué ci-dessous.
Créez ensuite une tâche que cron
exécutera au démarrage.
Cela devrait fonctionner!
Si deux ou plusieurs définitions de télécommandes IR doivent être
utilisées, il sera nécessaire d'ignorer rc_maps.cfg
complètement. Conséquemment, la tâche à effectuer au démarrage sera un peu
plus complexe.
Cela peut sembler étrange, mais les commandes sont exécutées dans l’ordre
inverse. La deuxième ligne ajoute les enregistrements contenus dans le fichier
keyes
. Un fichier journal temporaire est crée et tous les
messages ou avertissements provenant de ir-keytable
y sont
redirigés. Ensuite, la commande de la première ligne est exécutée. Elle
ajoute les définitions du fichier rc6_mce
, définit les
protocoles IR nécessaires et tout message de sortie ou d'erreur est ajouté au
fichier journal.
Étant un peu mal à l'aise avec cet ordre inversé, j'ai préféré créer un petit script bash dans lequel l'ordre d'exécution est clair et qui sera plus facile à modifier à l'avenir.
Le fichier de configuration .profile
ajoutera
le répertoire ~/bin
au chemin de recherche et ainsi bash
saura trouver le script. Voici son contenu.
N'oubliez pas que le « shebang » (le premier commentaire) est obligatoire pour que le fichier soit auto-exécutable. Mais il est également nécessaire de le marquer comme un exécutable.
Il ne reste plus qu'à l'ajouter au ficher crontab
.
Conclusion
Si l'on veut utiliser une télécommande IR comme interface avec un lecteur audio tel Rhythmbox ou un lecteur multimédia comme Kodi ce qui précède suffit. Ces logiciels prennent en charge la lecture des files d'attente d'évènements clavier. Il suffit d'associer les bons codes clavier aux codes de balayage de la télécommande. Évidemment, il faut connaître les codes clavier utilisé par les lecteurs, mais il s'agit là d'un autre sujet.
Quand on utilise un Orange Pi Zero, il est peu probable qu'on y installe un des lecteurs mentionnés ci-dessus. Mon objectif est d'utiliser une télécommande pour activer des dispositifs du système de domotique déjà en place. Ce sera le sujet du prochain billet.