Utiliser l'équipement PRO FLIGHT CESSNA® TRIM WHEEL de Saitek® avec X-plane 10 sous GNU/linux

Introduction

X-plane 10 est un superbe logiciel de simulation de vol. Débutant dans son utilisation, l'auteur de cette page a constaté que, sitôt branché, son joystick était reconnu et utilisable mais que ce n'était pas nécessairement le cas pour tous les équipements. Cette page prend le cas du compensateur de profondeur "PRO FLIGHT CESSNA® TRIM WHEEL de Saitek®" pour expliquer une méthode simple pour mettre en fonction un équipement USB récalcitrant.

Les causes

Le site des développeurs de X-plane explique, dans un article de 2012, les raisons pour lesquelles certains équipements ne sont pas directement reconnus ; linux est strict sur la sécurité et restreint les droits des périphériques USB pour empêcher les nuisances : "If the device LOOKS like a joystick, anyone’s allowed to access it since the security risk associated with joysticks are pretty much zero. But […] Trim wheels don’t have any buttons either and they only have one axis. Because of this, the ACL for the devices does not kick in and you now need root access to read from the device."

Autrement dit, certains équipements comme le compensateur de profondeur ne sont pas reconnus immédiatement et, par mesure de sécurité, seul l'administrateur a le droit de les lire. Comme X-plane n'a pas les droits d'administration (et il est souhaitable que cela ne change pas!), il faut mettre en place une règle spécifique pour autoriser chaque équipement bien identifié comme non dangereux à être lu par le programme. Comme, en fait, le risque est ici nul, il est plus simple de le rendre accessible en lecture et écriture à tout le monde.

La reconnaissance de l'équipement

La première chose à faire est d'être sûr de bien identifier l'équipement. GNU/Linux donne d'abord un moyen aisé de savoir quels sont les équipements connectés en USB à la machine. Il suffit pour cela d'ouvrir un terminal et d'y entrer la commande :

lsusb

En l'exécutant juste avant de brancher l'équipement et juste après, par différence on voit la nouvelle ligne qui identifie le produit qui vient d'être branché. Par exemple, ici, la réponse obtenue après connexion est :

Bus 002 Device 002: ID 8087:8000 Intel Corp.
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:8008 Intel Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 003: ID 5986:0400 Acer, Inc
Bus 003 Device 002: ID 8087:07dc Intel Corp.
Bus 003 Device 066: ID 06a3:0bd4 Saitek PLC           <<<< nouvelle ligne
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

et la nouvelle ligne signalée identifie le compensateur de profondeur. Il est branché sur le bus n°3, en tant qu'appareil n°66 (ce numéro change à chaque connexion), et il est caractérisé par :

En fait, les deux premiers nombres (hexa) caractérisent le modèle d'équipement de façon unique.

L'attribution des permissions au branchement

Le but est de programmer une règle qui attribue automatiquement à tout utilisateur de l'ordinateur les droits de lecture (et d'écriture, le cas échéant) sur le périphérique dès qu'il est branché. Linux permet de faire cela grâce au processus udev qui détecte les périphériques lorsqu'ils sont physiquement connectés et qui est capable d'exécuter des règles du type "Si …, alors …". C'est exactement ce qu'il faut ici: "Si le noyau de linux détecte le branchement du produit 0bd4 du vendeur 06a3, alors donner les droits de l'utiliser à tout le monde".

Pour l'utilisation par udev, les droits peuvent se coder de différentes manières. La plus compacte consiste à utiliser un nombre octal sur quatre chiffres, de forme XXXX, appelé aussi le mode. Le premier chiffre sert surtout à donner temporairement à l'utilisateur d'un fichier les privilèges d'EXÉCUTION du propriétaire (valeur 4) ou du groupe (2) du fichier. Il est évidemment sans effet si ceux-ci n'ont pas la permission d'exécution. Il peut aussi affecter le "bit collant" (1) ; sur les systèmes modernes, ce bit est surtout utile appliqué aux dossiers pour dire si un fichier qui s'y trouve peut être détruit ou renommé par un utilisateur autre que son propriétaire. En général, ce premier chiffre est à utiliser avec circonspection et prudence. Dans le cas présent, l'exécution n'est pas pertinente et le premier chiffre doit être mis à zéro.

Les trois chiffres suivants codent les permissions respectivement pour l'utilisateur du fichier ou du périphérique, pour le groupe d'utilisation et pour le reste du monde en sommant, selon le résultat voulu, 4 pour signifier le droit de lecture, 2 le droit d'écriture et 1 le droit d'exécution.

Ainsi, pour donner uniquement le droit de lecture à tout le monde, le mode est 0444. Dans le cas présent, l'auteur de cette page imagine que le périphérique peut aussi avoir besoin de recevoir des informations de la part de X-plane qui devrait donc avoir aussi le droit d'écriture. Dans le doute, les deux droits de lecture et d'écriture seront accordés à tout le monde, puisque cela ne présente aucun risque ; le mode correspondant est 0666.

Finalement, la règle "Si …, alors …" s'écrit avec la syntaxe propre à udev :

KERNEL=="event*", ATTRS{idProduct}=="0bd4", ATTRS{idVendor}=="06a3", MODE="0666"

où "==" effectue un test "si" et "=" effectue l'affectation de valeur à MODE si tous les tests sont vrais. Cette règle doit être placée dans un fichier .rules enregistré au bon endroit pour être vu par udev. La pratique recommandée de Ubuntu (et d'autres distributions) est de l'enregistrer dans le dossier /etc/udev/rules.d (voir le fichier README qui s'y trouve). Il faut être administrateur pour créer ce fichier. Ici, on crée donc le fichier /etc/udev/rules.d/99-trimwheel.rules qui contient deux lignes, une ligne de commentaire pour mémoire et la ligne de la règle :

# Au branchement USB de PRO FLIGHT CESSNA TRIM WHEEL, ouvrir les droits read et write pour tous
KERNEL=="event*", ATTRS{idProduct}=="0bd4", ATTRS{idVendor}=="06a3", MODE="0666"

Une fois le fichier enregistré, il faut le faire prendre en compte par udev. Ceci peut se faire en relançant la machine (ce n'est pas très élégant) ou bien, par exemple, en demandant au service udev de recharger les règles en entrant dans un terminal la commande udevadm suivante, en tant qu'administrateur :

sudo udevadm control --reload-rules

qui demande le mot de passe mais ne produit pas de réponse.

Utilisation

Ayant effectué les opérations précédentes, le compensateur doit être (débranché au besoin puis) rebranché sur une prise USB, ainsi que le joystick. Au lancement, X-plane déclare qu'un nouveau joystick non calibré est détecté et demande d'agir sur tous les axes. En ce qui concerne le compensateur, il semble que l'absence de butée de la roue puisse poser un petit problème de réglage : en tournant indéfiniment la roue, il est possible d'accroître d'autant sa plage de variation en diminuant sa sensibilité en proportion inverse. L'utilisateur sera ainsi peut-être amené à recommencer le calibrage pour l'adapter à ses préférences.

Une fois X-plane lancé classiquement, l'onglet "Axe" de son menu "Joystick et équipements" fait apparaître un nouvel axe qui reste à configurer en "trim profondeur" et à recalibrer/centrer le cas échéant.
axe de trim

A partir de là, le périphérique est actif. Cette méthode a été mise au point et testée sous Ubuntu 14.04 "Trusty Tahr", puis retestée sous Ubuntu MATE 22.04 "Jammy Jellyfish" avec X-Plane 12.


Retour à l'accueil LINUX

logo html 5 Validé avec le vérificateur du W3C