J'ai une station météo qui doit obligatoirement être sur le pilote usbsérie ttyUSB0 parce que si elle change de numéro de pilote USB, ma station ne peut plus transmettre ses données via Internet.
Y a-t-il moyen de forcer le pilote à rester le même même si la station est débranchée de temps à autre pour une raison quelconque? Parce que là udev me met ttyUSB1 si la station est débranchée par le système et rebranchée dans les 5 minutes suivantes.
Si vous avez une solution, je suis preneur et vous en remercie. Je suis sous Mandriva 2009.
Paul
--
R: Parce que ça renverse bêtement l'ordre naturel de lecture !
Q: Mais pourquoi citer en fin d'article est-il si effroyable ?
R: Citer en fin d'article.
Q: Quelle est la chose la plus désagréable sur les groupes de news ?
J'ai une station météo qui doit obligatoirement être sur le pilote usbsérie ttyUSB0 parce que si elle change de numéro de pilote USB, ma station ne peut plus transmettre ses données via Internet.
Y a-t-il moyen de forcer le pilote à rester le même même si la station est débranchée de temps à autre pour une raison quelconque? Parce que là udev me met ttyUSB1 si la station est débranchée par le système et rebranchée dans les 5 minutes suivantes.
Si vous avez une solution, je suis preneur et vous en remercie. Je suis sous Mandriva 2009.
Utiliser uuid:
Monter le périph usb et récupérer son uuid en faisant:
ls -l /dev/disk/by-uuid/
Puis inclure le machin dans fstab avec comme identifiant l'uuid.
-- François Patte Université Paris Descartes
Le 06.12.2008 23:21, Paul Pygeon a écrit :
Bonjour,
J'ai une station météo qui doit obligatoirement être sur le pilote
usbsérie ttyUSB0 parce que si elle change de numéro de pilote USB,
ma station ne peut plus transmettre ses données via Internet.
Y a-t-il moyen de forcer le pilote à rester le même même si la
station est débranchée de temps à autre pour une raison quelconque?
Parce que là udev me met ttyUSB1 si la station est débranchée par le
système et rebranchée dans les 5 minutes suivantes.
Si vous avez une solution, je suis preneur et vous en remercie. Je
suis sous Mandriva 2009.
Utiliser uuid:
Monter le périph usb et récupérer son uuid en faisant:
ls -l /dev/disk/by-uuid/
Puis inclure le machin dans fstab avec comme identifiant l'uuid.
J'ai une station météo qui doit obligatoirement être sur le pilote usbsérie ttyUSB0 parce que si elle change de numéro de pilote USB, ma station ne peut plus transmettre ses données via Internet.
Y a-t-il moyen de forcer le pilote à rester le même même si la station est débranchée de temps à autre pour une raison quelconque? Parce que là udev me met ttyUSB1 si la station est débranchée par le système et rebranchée dans les 5 minutes suivantes.
Si vous avez une solution, je suis preneur et vous en remercie. Je suis sous Mandriva 2009.
Utiliser uuid:
Monter le périph usb et récupérer son uuid en faisant:
ls -l /dev/disk/by-uuid/
Puis inclure le machin dans fstab avec comme identifiant l'uuid.
-- François Patte Université Paris Descartes
Erwan David
François Patte écrivait :
Le 06.12.2008 23:21, Paul Pygeon a écrit :
Bonjour,
J'ai une station météo qui doit obligatoirement être sur le pilote usbsérie ttyUSB0 parce que si elle change de numéro de pilote USB, ma station ne peut plus transmettre ses données via Internet.
Y a-t-il moyen de forcer le pilote à rester le même même si la station est débranchée de temps à autre pour une raison quelconque? Parce que là udev me met ttyUSB1 si la station est débranchée par le système et rebranchée dans les 5 minutes suivantes.
Si vous avez une solution, je suis preneur et vous en remercie. Je suis sous Mandriva 2009.
Utiliser uuid:
Monter le périph usb et récupérer son uuid en faisant:
ls -l /dev/disk/by-uuid/
Puis inclure le machin dans fstab avec comme identifiant l'uuid.
C'est pas du montage de disque : c'est du port série...
Il doit y avoir le moyen de faire des choses en ajoutant des règles UDEV, mais je ne maitrise pas le comment.
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
François Patte <francois.patte@mi.parisdescartes.fr> écrivait :
Le 06.12.2008 23:21, Paul Pygeon a écrit :
Bonjour,
J'ai une station météo qui doit obligatoirement être sur le pilote
usbsérie ttyUSB0 parce que si elle change de numéro de pilote USB,
ma station ne peut plus transmettre ses données via Internet.
Y a-t-il moyen de forcer le pilote à rester le même même si la
station est débranchée de temps à autre pour une raison quelconque?
Parce que là udev me met ttyUSB1 si la station est débranchée par le
système et rebranchée dans les 5 minutes suivantes.
Si vous avez une solution, je suis preneur et vous en remercie. Je
suis sous Mandriva 2009.
Utiliser uuid:
Monter le périph usb et récupérer son uuid en faisant:
ls -l /dev/disk/by-uuid/
Puis inclure le machin dans fstab avec comme identifiant l'uuid.
C'est pas du montage de disque : c'est du port série...
Il doit y avoir le moyen de faire des choses en ajoutant des règles
UDEV, mais je ne maitrise pas le comment.
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
J'ai une station météo qui doit obligatoirement être sur le pilote usbsérie ttyUSB0 parce que si elle change de numéro de pilote USB, ma station ne peut plus transmettre ses données via Internet.
Y a-t-il moyen de forcer le pilote à rester le même même si la station est débranchée de temps à autre pour une raison quelconque? Parce que là udev me met ttyUSB1 si la station est débranchée par le système et rebranchée dans les 5 minutes suivantes.
Si vous avez une solution, je suis preneur et vous en remercie. Je suis sous Mandriva 2009.
Utiliser uuid:
Monter le périph usb et récupérer son uuid en faisant:
ls -l /dev/disk/by-uuid/
Puis inclure le machin dans fstab avec comme identifiant l'uuid.
C'est pas du montage de disque : c'est du port série...
Il doit y avoir le moyen de faire des choses en ajoutant des règles UDEV, mais je ne maitrise pas le comment.
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Paul Pygeon
Erwan David a papoté sur Usenet le dimanche 07 décembre 2008 09:47:
C'est pas du montage de disque : c'est du port série...
Il doit y avoir le moyen de faire des choses en ajoutant des règles UDEV, mais je ne maitrise pas le comment.
En effet, mais en cherchant un peu plus j'ai trouvé la solution. Il faut créer une règle dans /etc/udev/rules.d/ pour que peu importe la numérotation du port USB lors de sa détection, il porte toujours le même nom. Dans mon cas, le port ttyUSBx se nommera toujours wview et une commande dans la règle udev redémarre le service idoine. Voici d'ailleurs le fichier 40-weather.rules.
Merci quand même d'avoir répondu. Paul -- R: Parce que ça renverse bêtement l'ordre naturel de lecture ! Q: Mais pourquoi citer en fin d'article est-il si effroyable ? R: Citer en fin d'article. Q: Quelle est la chose la plus désagréable sur les groupes de news ?
Erwan David a papoté sur Usenet le dimanche 07 décembre 2008 09:47:
C'est pas du montage de disque : c'est du port série...
Il doit y avoir le moyen de faire des choses en ajoutant des règles
UDEV, mais je ne maitrise pas le comment.
En effet, mais en cherchant un peu plus j'ai trouvé la solution. Il faut créer une règle dans /etc/udev/rules.d/ pour que peu importe la numérotation du port USB lors de sa détection, il porte toujours le même nom. Dans mon cas, le port ttyUSBx se nommera toujours wview et une commande dans la règle udev redémarre le service idoine. Voici d'ailleurs le fichier 40-weather.rules.
Merci quand même d'avoir répondu.
Paul
--
R: Parce que ça renverse bêtement l'ordre naturel de lecture !
Q: Mais pourquoi citer en fin d'article est-il si effroyable ?
R: Citer en fin d'article.
Q: Quelle est la chose la plus désagréable sur les groupes de news ?
Erwan David a papoté sur Usenet le dimanche 07 décembre 2008 09:47:
C'est pas du montage de disque : c'est du port série...
Il doit y avoir le moyen de faire des choses en ajoutant des règles UDEV, mais je ne maitrise pas le comment.
En effet, mais en cherchant un peu plus j'ai trouvé la solution. Il faut créer une règle dans /etc/udev/rules.d/ pour que peu importe la numérotation du port USB lors de sa détection, il porte toujours le même nom. Dans mon cas, le port ttyUSBx se nommera toujours wview et une commande dans la règle udev redémarre le service idoine. Voici d'ailleurs le fichier 40-weather.rules.
Merci quand même d'avoir répondu. Paul -- R: Parce que ça renverse bêtement l'ordre naturel de lecture ! Q: Mais pourquoi citer en fin d'article est-il si effroyable ? R: Citer en fin d'article. Q: Quelle est la chose la plus désagréable sur les groupes de news ?
Erwan David
Paul Pygeon écrivait :
Erwan David a papoté sur Usenet le dimanche 07 décembre 2008 09:47:
C'est pas du montage de disque : c'est du port série...
Il doit y avoir le moyen de faire des choses en ajoutant des règles UDEV, mais je ne maitrise pas le comment.
En effet, mais en cherchant un peu plus j'ai trouvé la solution. Il faut créer une règle dans /etc/udev/rules.d/ pour que peu importe la numérotation du port USB lors de sa détection, il porte toujours le même nom. Dans mon cas, le port ttyUSBx se nommera toujours wview et une commande dans la règle udev redémarre le service idoine. Voici d'ailleurs le fichier 40-weather.rules.
ça me console de voir que j'étais sur la bonne piste.
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Paul Pygeon <paul.pygeon@gmail.com> écrivait :
Erwan David a papoté sur Usenet le dimanche 07 décembre 2008 09:47:
C'est pas du montage de disque : c'est du port série...
Il doit y avoir le moyen de faire des choses en ajoutant des règles
UDEV, mais je ne maitrise pas le comment.
En effet, mais en cherchant un peu plus j'ai trouvé la solution. Il faut créer une règle dans /etc/udev/rules.d/ pour que peu importe la numérotation du port USB lors de sa détection, il porte toujours le même nom. Dans mon cas, le port ttyUSBx se nommera toujours wview et une commande dans la règle udev redémarre le service idoine. Voici d'ailleurs le fichier 40-weather.rules.
Erwan David a papoté sur Usenet le dimanche 07 décembre 2008 09:47:
C'est pas du montage de disque : c'est du port série...
Il doit y avoir le moyen de faire des choses en ajoutant des règles UDEV, mais je ne maitrise pas le comment.
En effet, mais en cherchant un peu plus j'ai trouvé la solution. Il faut créer une règle dans /etc/udev/rules.d/ pour que peu importe la numérotation du port USB lors de sa détection, il porte toujours le même nom. Dans mon cas, le port ttyUSBx se nommera toujours wview et une commande dans la règle udev redémarre le service idoine. Voici d'ailleurs le fichier 40-weather.rules.
ça me console de voir que j'étais sur la bonne piste.
Puisque je constate qu'il y a des connaisseurs en udev, une chose dans laquelle je suis très nul ;( je vous expose mon problème:
Je voudrais avoir un pavé numérique externe USB branché sur ma machine, mais que ne soit pas "couplé" au clavier principal: pour le moment, avec la reconnaissance automatique, ce que je tape sur le pavé externe arrive sur le stdin du programme qui a le focus. Et ça c'est pas bon pour moi.
Le but est d'avoir ce pavé numérique géré par un programme autonome: { pave = open("/dev/keypad42", O_RDONLY); } puis lecture des codes ascii, ou mieux, lecture des évenements <key-up> et <key-down>, traitement et pour finir: pilotage d'un expandeur MIDI.
ça me console de voir que j'étais sur la bonne piste.
Puisque je constate qu'il y a des connaisseurs en udev, une chose
dans laquelle je suis très nul ;( je vous expose mon problème:
Je voudrais avoir un pavé numérique externe USB branché sur ma
machine, mais que ne soit pas "couplé" au clavier principal:
pour le moment, avec la reconnaissance automatique, ce que je
tape sur le pavé externe arrive sur le stdin du programme qui
a le focus. Et ça c'est pas bon pour moi.
Le but est d'avoir ce pavé numérique géré par un programme
autonome: { pave = open("/dev/keypad42", O_RDONLY); } puis
lecture des codes ascii, ou mieux, lecture des évenements
<key-up> et <key-down>, traitement et pour finir: pilotage
d'un expandeur MIDI.
ça me console de voir que j'étais sur la bonne piste.
Puisque je constate qu'il y a des connaisseurs en udev, une chose dans laquelle je suis très nul ;( je vous expose mon problème:
Je voudrais avoir un pavé numérique externe USB branché sur ma machine, mais que ne soit pas "couplé" au clavier principal: pour le moment, avec la reconnaissance automatique, ce que je tape sur le pavé externe arrive sur le stdin du programme qui a le focus. Et ça c'est pas bon pour moi.
Le but est d'avoir ce pavé numérique géré par un programme autonome: { pave = open("/dev/keypad42", O_RDONLY); } puis lecture des codes ascii, ou mieux, lecture des évenements <key-up> et <key-down>, traitement et pour finir: pilotage d'un expandeur MIDI.
Il n'y a pas de gestion des dependance dans la Slack, elle n'est pas calamiteuse, elle n'existe pas.
C'est bien ce que je te dis. Elle est calamiteuse parce qu'elle n'existe pas
--{ JKB, in fcol.debats }--
Jonathan ROTH
Le 07.12.2008 19:21, Thierry B. s'exprima:
Je voudrais avoir un pavé numérique externe USB branché sur ma machine, mais que ne soit pas "couplé" au clavier principal: pour le moment, avec la reconnaissance automatique, ce que je tape sur le pavé externe arrive sur le stdin du programme qui a le focus. Et ça c'est pas bon pour moi.
Le but est d'avoir ce pavé numérique géré par un programme autonome: { pave = open("/dev/keypad42", O_RDONLY); } puis lecture des codes ascii, ou mieux, lecture des évenements <key-up> et <key-down>, traitement et pour finir: pilotage d'un expandeur MIDI.
Je crois bien que pour l'instant ce n'est pas possible: tout périphérique d'entrée de type clavier est connecté à stdin.
Ca pourrait être géré avec un pilote usb-hid modifié, mais plus simplement, pour ton soucis, tu peux utiliser un bête joystick/joypad.
Le 07.12.2008 19:21, Thierry B. s'exprima:
Je voudrais avoir un pavé numérique externe USB branché sur ma
machine, mais que ne soit pas "couplé" au clavier principal:
pour le moment, avec la reconnaissance automatique, ce que je
tape sur le pavé externe arrive sur le stdin du programme qui
a le focus. Et ça c'est pas bon pour moi.
Le but est d'avoir ce pavé numérique géré par un programme
autonome: { pave = open("/dev/keypad42", O_RDONLY); } puis
lecture des codes ascii, ou mieux, lecture des évenements
<key-up> et <key-down>, traitement et pour finir: pilotage
d'un expandeur MIDI.
Je crois bien que pour l'instant ce n'est pas possible: tout
périphérique d'entrée de type clavier est connecté à stdin.
Ca pourrait être géré avec un pilote usb-hid modifié, mais plus
simplement, pour ton soucis, tu peux utiliser un bête joystick/joypad.
Je voudrais avoir un pavé numérique externe USB branché sur ma machine, mais que ne soit pas "couplé" au clavier principal: pour le moment, avec la reconnaissance automatique, ce que je tape sur le pavé externe arrive sur le stdin du programme qui a le focus. Et ça c'est pas bon pour moi.
Le but est d'avoir ce pavé numérique géré par un programme autonome: { pave = open("/dev/keypad42", O_RDONLY); } puis lecture des codes ascii, ou mieux, lecture des évenements <key-up> et <key-down>, traitement et pour finir: pilotage d'un expandeur MIDI.
Je crois bien que pour l'instant ce n'est pas possible: tout périphérique d'entrée de type clavier est connecté à stdin.
Ca pourrait être géré avec un pilote usb-hid modifié, mais plus simplement, pour ton soucis, tu peux utiliser un bête joystick/joypad.
Nicolas George
"Thierry B." wrote in message :
Le but est d'avoir ce pavé numérique géré par un programme autonome: { pave = open("/dev/keypad42", O_RDONLY); } puis lecture des codes ascii, ou mieux, lecture des évenements <key-up> et <key-down>, traitement et pour finir: pilotage d'un expandeur MIDI.
Ça, on peut faire. Le device est /dev/input/eventX, et il y a normalement des liens symboliques dans /dev/input/by-path/. Cf. Documentation/input/input.txt dans les sources du noyau.
Ce que je ne sais pas encore faire, cependant, c'est désactiver le fait que ces événements soient également envoyés à la console.
"Thierry B." wrote in message <oqgt06-pj9.ln1@prout.stex>:
Le but est d'avoir ce pavé numérique géré par un programme
autonome: { pave = open("/dev/keypad42", O_RDONLY); } puis
lecture des codes ascii, ou mieux, lecture des évenements
<key-up> et <key-down>, traitement et pour finir: pilotage
d'un expandeur MIDI.
Ça, on peut faire. Le device est /dev/input/eventX, et il y a normalement
des liens symboliques dans /dev/input/by-path/. Cf.
Documentation/input/input.txt dans les sources du noyau.
Ce que je ne sais pas encore faire, cependant, c'est désactiver le fait que
ces événements soient également envoyés à la console.
Le but est d'avoir ce pavé numérique géré par un programme autonome: { pave = open("/dev/keypad42", O_RDONLY); } puis lecture des codes ascii, ou mieux, lecture des évenements <key-up> et <key-down>, traitement et pour finir: pilotage d'un expandeur MIDI.
Ça, on peut faire. Le device est /dev/input/eventX, et il y a normalement des liens symboliques dans /dev/input/by-path/. Cf. Documentation/input/input.txt dans les sources du noyau.
Ce que je ne sais pas encore faire, cependant, c'est désactiver le fait que ces événements soient également envoyés à la console.
YBM
Nicolas George a écrit :
"Thierry B." wrote in message :
Le but est d'avoir ce pavé numérique géré par un programme autonome: { pave = open("/dev/keypad42", O_RDONLY); } puis lecture des codes ascii, ou mieux, lecture des évenements <key-up> et <key-down>, traitement et pour finir: pilotage d'un expandeur MIDI.
Ça, on peut faire. Le device est /dev/input/eventX, et il y a normalement des liens symboliques dans /dev/input/by-path/. Cf. Documentation/input/input.txt dans les sources du noyau.
Ce que je ne sais pas encore faire, cependant, c'est désactiver le fait que ces événements soient également envoyés à la console.
Regarde du côté de la commande libhid-detach-device (paquet libhid0 sous Debian ou Ubuntu).
Nicolas George a écrit :
"Thierry B." wrote in message <oqgt06-pj9.ln1@prout.stex>:
Le but est d'avoir ce pavé numérique géré par un programme
autonome: { pave = open("/dev/keypad42", O_RDONLY); } puis
lecture des codes ascii, ou mieux, lecture des évenements
<key-up> et <key-down>, traitement et pour finir: pilotage
d'un expandeur MIDI.
Ça, on peut faire. Le device est /dev/input/eventX, et il y a normalement
des liens symboliques dans /dev/input/by-path/. Cf.
Documentation/input/input.txt dans les sources du noyau.
Ce que je ne sais pas encore faire, cependant, c'est désactiver le fait que
ces événements soient également envoyés à la console.
Regarde du côté de la commande libhid-detach-device (paquet libhid0 sous
Debian ou Ubuntu).
Le but est d'avoir ce pavé numérique géré par un programme autonome: { pave = open("/dev/keypad42", O_RDONLY); } puis lecture des codes ascii, ou mieux, lecture des évenements <key-up> et <key-down>, traitement et pour finir: pilotage d'un expandeur MIDI.
Ça, on peut faire. Le device est /dev/input/eventX, et il y a normalement des liens symboliques dans /dev/input/by-path/. Cf. Documentation/input/input.txt dans les sources du noyau.
Ce que je ne sais pas encore faire, cependant, c'est désactiver le fait que ces événements soient également envoyés à la console.
Regarde du côté de la commande libhid-detach-device (paquet libhid0 sous Debian ou Ubuntu).
Nicolas George
YBM wrote in message <493e3c44$0$22696$:
Regarde du côté de la commande libhid-detach-device (paquet libhid0 sous Debian ou Ubuntu).
Ça n'a pas l'air d'être exactement ce que j'évoque.
Par défaut, on a à peu près ça :
USB ----> HID ----> console
---> evdev
Ce que j'évoquais, c'est couper le lien HID -> console, en préservant le lien HID -> evdev, qui permet alors de récupérer les événements.
libhid-detach-device, ça coupe le lien entre USB et HID, et on peut récupérer les événements directement en USB, au prix du décodage du protocole HID (d'où la bibliothèque). Ça permet également de faire ce que Thomas voudrait, mais c'est plus compliqué, et moins générique (ça ne marchera pas pour un clavier bluetooth par exemple).
YBM wrote in message <493e3c44$0$22696$426a34cc@news.free.fr>:
Regarde du côté de la commande libhid-detach-device (paquet libhid0 sous
Debian ou Ubuntu).
Ça n'a pas l'air d'être exactement ce que j'évoque.
Par défaut, on a à peu près ça :
USB ----> HID ----> console
---> evdev
Ce que j'évoquais, c'est couper le lien HID -> console, en préservant le
lien HID -> evdev, qui permet alors de récupérer les événements.
libhid-detach-device, ça coupe le lien entre USB et HID, et on peut
récupérer les événements directement en USB, au prix du décodage du
protocole HID (d'où la bibliothèque). Ça permet également de faire ce que
Thomas voudrait, mais c'est plus compliqué, et moins générique (ça ne
marchera pas pour un clavier bluetooth par exemple).
Regarde du côté de la commande libhid-detach-device (paquet libhid0 sous Debian ou Ubuntu).
Ça n'a pas l'air d'être exactement ce que j'évoque.
Par défaut, on a à peu près ça :
USB ----> HID ----> console
---> evdev
Ce que j'évoquais, c'est couper le lien HID -> console, en préservant le lien HID -> evdev, qui permet alors de récupérer les événements.
libhid-detach-device, ça coupe le lien entre USB et HID, et on peut récupérer les événements directement en USB, au prix du décodage du protocole HID (d'où la bibliothèque). Ça permet également de faire ce que Thomas voudrait, mais c'est plus compliqué, et moins générique (ça ne marchera pas pour un clavier bluetooth par exemple).
Thierry B.
--{ Jonathan ROTH a plopé ceci: }--
Je voudrais avoir un pavé numérique externe USB branché sur ma machine, mais que ne soit pas "couplé" au clavier principal:
[...]
autonome: { pave = open("/dev/keypad42", O_RDONLY); } puis lecture des codes ascii, ou mieux, lecture des évenements <key-up> et <key-down>, traitement et pour finir: pilotage d'un expandeur MIDI.
Je crois bien que pour l'instant ce n'est pas possible: tout périphérique d'entrée de type clavier est connecté à stdin.
C'est hélas la conclusion à laquelle je suis provisoirement arrivé. J'entrevois un plongeon dans la kernelle.
Ca pourrait être géré avec un pilote usb-hid modifié, mais plus simplement, pour ton soucis, tu peux utiliser un bête joystick/joypad.
Je préfèrerais quand même que ça fonctionne sur un kernel vanille, éventuellement en créant des rêgles udev, en passant un paramètre au boot...
Quand à la piste joystick, je suis en train de regarder aussi comment ça fonctionne. Après tout, les principes ne doivent pas être très différents.
-- INFINITY is INTEGER, unless declared REAL.
--{ Jonathan ROTH a plopé ceci: }--
Je voudrais avoir un pavé numérique externe USB branché sur ma
machine, mais que ne soit pas "couplé" au clavier principal:
[...]
autonome: { pave = open("/dev/keypad42", O_RDONLY); } puis
lecture des codes ascii, ou mieux, lecture des évenements
<key-up> et <key-down>, traitement et pour finir: pilotage
d'un expandeur MIDI.
Je crois bien que pour l'instant ce n'est pas possible: tout
périphérique d'entrée de type clavier est connecté à stdin.
C'est hélas la conclusion à laquelle je suis provisoirement
arrivé. J'entrevois un plongeon dans la kernelle.
Ca pourrait être géré avec un pilote usb-hid modifié, mais plus
simplement, pour ton soucis, tu peux utiliser un bête joystick/joypad.
Je préfèrerais quand même que ça fonctionne sur un kernel vanille,
éventuellement en créant des rêgles udev, en passant un paramètre
au boot...
Quand à la piste joystick, je suis en train de regarder aussi
comment ça fonctionne. Après tout, les principes ne doivent pas
être très différents.
Je voudrais avoir un pavé numérique externe USB branché sur ma machine, mais que ne soit pas "couplé" au clavier principal:
[...]
autonome: { pave = open("/dev/keypad42", O_RDONLY); } puis lecture des codes ascii, ou mieux, lecture des évenements <key-up> et <key-down>, traitement et pour finir: pilotage d'un expandeur MIDI.
Je crois bien que pour l'instant ce n'est pas possible: tout périphérique d'entrée de type clavier est connecté à stdin.
C'est hélas la conclusion à laquelle je suis provisoirement arrivé. J'entrevois un plongeon dans la kernelle.
Ca pourrait être géré avec un pilote usb-hid modifié, mais plus simplement, pour ton soucis, tu peux utiliser un bête joystick/joypad.
Je préfèrerais quand même que ça fonctionne sur un kernel vanille, éventuellement en créant des rêgles udev, en passant un paramètre au boot...
Quand à la piste joystick, je suis en train de regarder aussi comment ça fonctionne. Après tout, les principes ne doivent pas être très différents.
