- Modifié
Bonjour,
je me permet d'ouvrir une nouvelle discussion afin de solliciter une nouvelle fois votre aide.
Un grand merci d'avance donc.
J'ai récemment installé le logiciel 'btnx' disponible ici,
ce petit programme remarquable est un utilitaire de configuration des souris sous Linux, il est
particulièrement bien adapté à la configuration des souris à nombreux boutons (et en particulier
à la MX revolution puisque c'est son premier dessein) donc j'ai voulu utiliser btnx pour configurer
ma mx1000.
Aucun problème pour faire fonctionner btnx, la souris est parfaitement détectée et les boutons très facilement
configurés.
Seulement impossible de lancer 'btnx' au démarrage de ma Fedora 7 64bits, 'btnx' nécessite en fait
le chargement du module 'uinput' ... rien de plus facile au démarrage que de charger un module
pourrait on dire, dans ce cas précis en ajoutant au fichier '/etc/modprobe.con f':
permet la création d'un fichier sépcial représentant du matériel vitruel à l'emplacement
'/dev/input/uinput' et ce fichier virtuel va être utilisé par btnx pour communiquer avec le mulot.
Or malgré le chargement du module au démarrage, le lancement de btnx échoue en raison d'une
impossibilité de trouver ce fichier spécial '/dev/input/uinput'.
Le fichier en question étant présent et visible après le démarrage, j'ai pensé un temps
que le module n'était pas chargé assez rapidement (ou trop lentement pour btnx),
en tout cas c'est ainsi que j'ai été aiguillé par btnx (run 'modprobe uinput') ...
j'ai donc supprimé la ligne du fichier '/etc/modprobe.conf' et rajouter les lignes :
en tout début de fichier avant les appels à btnx.
Si je vois bien le résultat de mes commandes au démarrage celui-ci se termine cependant
toujours sur un échec et chaque fois car le fichier '/dev/input/uinput' est introuvable ....
Je me suis alors penché sur la création du fichier spécial en question, et après quelques heures
de googlisation durement récompensées j'ai appris que celui ci était créer par 'udev' et donc que
sa création était soumise à certaines règles (que j'ai trouvée dans le fichier de règles standard
/etc/udev/rules.d/50-udev-default.rules).
Or udev est chargé à la première étape du démarrage, le fichier '/dev/input/uinput' devrait donc
bien être créé avant le lancement de 'btnx'.
Si ce n'est pas le cas sauriez-vous m'indiquer à quel moment ce fichier est il créé ou peut être
plus facilement, comment décaler le chargement de btnx pour que celui-ci soit repoussé à la fin du démarrage
et puisse ainsi fonctionner correctement.
Je précise que je n'ai aucun problème a lancer btnx après la phase de démarrage.
Cordialement.
Je suis également intéressé par tout retour d'utilisation de ce 'btnx' pour pouvoir écrire quelque chose
sur son utilisation dans la doc du site Fedora-fr, merci donc de me faire part de vos impressions si vous
l'utilisé (en particulier sur d'autres versions de Fedora).
@snouffy => C'est pour toi ça 😉
S.
je me permet d'ouvrir une nouvelle discussion afin de solliciter une nouvelle fois votre aide.
Un grand merci d'avance donc.
J'ai récemment installé le logiciel 'btnx' disponible ici,
ce petit programme remarquable est un utilitaire de configuration des souris sous Linux, il est
particulièrement bien adapté à la configuration des souris à nombreux boutons (et en particulier
à la MX revolution puisque c'est son premier dessein) donc j'ai voulu utiliser btnx pour configurer
ma mx1000.
Aucun problème pour faire fonctionner btnx, la souris est parfaitement détectée et les boutons très facilement
configurés.
Seulement impossible de lancer 'btnx' au démarrage de ma Fedora 7 64bits, 'btnx' nécessite en fait
le chargement du module 'uinput' ... rien de plus facile au démarrage que de charger un module
pourrait on dire, dans ce cas précis en ajoutant au fichier '/etc/modprobe.con f':
Seulement cela n'est pas suffisant pour 'btnx', en effet le chargement du module 'uinput'alias char-major-10-223 uinput
permet la création d'un fichier sépcial représentant du matériel vitruel à l'emplacement
'/dev/input/uinput' et ce fichier virtuel va être utilisé par btnx pour communiquer avec le mulot.
Or malgré le chargement du module au démarrage, le lancement de btnx échoue en raison d'une
impossibilité de trouver ce fichier spécial '/dev/input/uinput'.
Le fichier en question étant présent et visible après le démarrage, j'ai pensé un temps
que le module n'était pas chargé assez rapidement (ou trop lentement pour btnx),
en tout cas c'est ainsi que j'ai été aiguillé par btnx (run 'modprobe uinput') ...
j'ai donc supprimé la ligne du fichier '/etc/modprobe.conf' et rajouter les lignes :
au fichier '/etc/init.d/btnx' qui est utilisé au démarrage pour lancer 'btnx', j'ai ajouté les lignes### Add By Slookeur 17/12/2007
UINP=`/sbin/lsmod | grep uinput`
if [ -z "$UINP" ]; then
echo "Loading uinput module"
modprobe uinput
sleep 30 # Pour force une attente .... et j'ai été au delà de la minute !
fi
###
en tout début de fichier avant les appels à btnx.
Si je vois bien le résultat de mes commandes au démarrage celui-ci se termine cependant
toujours sur un échec et chaque fois car le fichier '/dev/input/uinput' est introuvable ....
Je me suis alors penché sur la création du fichier spécial en question, et après quelques heures
de googlisation durement récompensées j'ai appris que celui ci était créer par 'udev' et donc que
sa création était soumise à certaines règles (que j'ai trouvée dans le fichier de règles standard
/etc/udev/rules.d/50-udev-default.rules).
Or udev est chargé à la première étape du démarrage, le fichier '/dev/input/uinput' devrait donc
bien être créé avant le lancement de 'btnx'.
Si ce n'est pas le cas sauriez-vous m'indiquer à quel moment ce fichier est il créé ou peut être
plus facilement, comment décaler le chargement de btnx pour que celui-ci soit repoussé à la fin du démarrage
et puisse ainsi fonctionner correctement.
Je précise que je n'ai aucun problème a lancer btnx après la phase de démarrage.
Cordialement.
Je suis également intéressé par tout retour d'utilisation de ce 'btnx' pour pouvoir écrire quelque chose
sur son utilisation dans la doc du site Fedora-fr, merci donc de me faire part de vos impressions si vous
l'utilisé (en particulier sur d'autres versions de Fedora).
@snouffy => C'est pour toi ça 😉
S.