Fonctionnement de FFB Probe

Le parcours guidé

FFB Probe suit un court parcours de test : écran de présentation, détection du manche, validation de la checklist de sécurité, ressenti de chaque effet live, réponse sur ce qui s’est produit, puis conservation ou partage du rapport. Chaque écran se concentre sur la tâche en cours pour que le testeur sache toujours quoi faire.

Étape 01

Atterrir

Le premier écran explique ce que teste FFB Probe, ce que vous obtenez et pourquoi la base de données publique du matériel existe. Rien ne sollicite le matériel tant que vous n’avez pas continué.

Étape 02

Détecter

L’écran d’accueil identifie le périphérique à retour de force, son VID:PID et ses effets pris en charge, et affiche le manche en direct avant qu’aucune force ne soit jouée.

Étape 03

Préparer

La liste de contrôle règle l’intensité du test, vous demande d’accepter l’avertissement de sécurité et confirme que les autres logiciels sont fermés et que le manche a de la place pour bouger.

Étape 04

Sentir

Chaque effet est joué pendant une fenêtre fixe tandis que l’écran affiche la section, le signal attendu et un compte à rebours. « Stop run » reste visible, et Échap arrête le test à tout moment.

Étape 05

Répondre

Après chaque effet, touchez chaque puce qui correspond à ce que vous avez ressenti. Les puces sont publiques ; le champ de notes facultatif reste privé. « Continue », « Run test again » ou « Skip » permet de passer à la suite.

Étape 06

Conserver ou partager

Le rapport est d’abord enregistré sur votre ordinateur. « Share my results » envoie les données expurgées ; l’application affiche ensuite un code d’assistance et un lien vers la page publique du périphérique.

Accueil : détection et autres programmes

L’écran d’accueil recherche les périphériques à retour de force et affiche celui qui sera testé, avec son VID:PID, le nombre d’effets pris en charge et un affichage en direct du manche. Seul ce périphérique est testé. Re-scan relance la détection après que vous avez branché un appareil ou fermé un autre programme.

Si un programme susceptible d’accaparer le périphérique est en cours d’exécution, comme un simulateur de vol, FFB-Bridge, MOZA Cockpit ou Pit House, les outils de Brunner ou Logitech G HUB, une carte orange Other software running le nomme et explique comment le fermer. L’avertissement ne bloque pas le test ; cliquez sur Re-check après avoir fermé le programme.

Les bases Brunner sont livrées en mode CLS2Sim, qui n’a pas d’interface de retour de force. Quand aucun périphérique à retour de force n’est trouvé, FFB-Probe recherche une base Brunner et propose Switch to DirectX mode ; rien n’est basculé sans ce clic. Switch back to CLS2Sim mode when finished est coché par défaut : la base revient donc en mode CLS2Sim après le test, à la fermeture de FFB-Probe, ou au démarrage suivant si FFB-Probe a été fermé de manière inattendue. Seul le réglage du mode USB est écrit, après l’enregistrement de votre mode d’origine, et si une étape échoue, la base est remise dans son état d’origine.

Si Simux, CLS2Sim, le Brunner USB Config Tool ou FFB-Bridge occupe la base, la carte le nomme et vous demande de le quitter, y compris depuis la zone de notification, avant de cliquer sur Re-scan. Un firmware sans mode DirectX est signalé et rien n’est écrit.

Liste de contrôle : intensité, sécurité et préparation

Test strength règle la force avec laquelle chaque effet sollicite le périphérique, de 0 % à 75 % par pas de 5 %. Les manches sur lesquels les tests ont été validés démarrent à 75 % : le SideWinder Force Feedback 2, les adaptateurs USB pour SideWinder FFB Pro (03EB:2056, CAFE:4004), les Logitech G940, Force 3D Pro et WingMan Force 3D, ainsi que le Brunner FFB-G Joystick, reconnu au type de base qu’il signale par le canal de configuration de Brunner, quelle que soit la poignée montée. Tous les autres périphériques, y compris les autres bases Brunner, les bases de vol MOZA et le matériel que FFB-Probe ne connaît pas encore, démarrent à 35 %. Si Simux, CLS2Sim, le Brunner USB Config Tool ou FFB-Bridge occupe ce canal, le type de base ne peut pas être lu : la base démarre alors à 35 % et la liste de contrôle vous demande de fermer le programme et de cliquer sur Re-scan. FFB-Probe mémorise l’intensité que vous avez choisie en dernier pour chaque périphérique.

L’avertissement Safety est toujours affiché : les périphériques à retour de force peuvent bouger soudainement et avec une force réelle ; gardez donc une main posée légèrement sur la poignée, éloignez doigts, câbles et objets, et arrêtez à tout moment avec Échap ou « Stop run ». Arm probe reste désactivé tant que vous n’avez pas coché I understand and accept responsibility et confirmé chaque élément de la liste de contrôle. Augmenter l’intensité au-delà de la valeur par défaut du périphérique ajoute un avertissement : les bases à entraînement direct puissantes peuvent heurter violemment leurs butées.

La liste de contrôle s’adapte au périphérique. Le SideWinder FFB2 et le Logitech G940 ajoutent un élément de présence de la main, car leur capteur de poignée coupe la sortie moteur quand personne ne tient le manche. Pour un VID:PID absent de la table matérielle de l’application, le fabricant et le modèle réels sont demandés.

Bases de vol MOZA

Pour une MOZA AB9, AY210, AB6 ou AY90, la liste de contrôle ajoute une carte MOZA BASE. Elle lit, sans rien modifier, si la base jouera réellement les effets : une base en mode Telemetry de MOZA Cockpit, ou dont le retour de force est désactivé, la sortie de couple bloquée ou le gain de jeu à 0, accepte tous les effets mais ne bouge pas.

Si la base n’est pas prête, la carte en indique les raisons et propose Prepare base for testing, qui sauvegarde vos réglages, passe la base en mode DirectInput et ouvre ses verrous de sortie de force. Restore my MOZA settings when finished est coché par défaut et rétablit vos réglages après le test ou à la fermeture de FFB-Probe. Les limites de course, l’étalonnage et Force Sensing ne sont jamais modifiés. Si MOZA Cockpit, MOZA Pit House ou FFB-Bridge occupe le port de réglages, la carte le nomme ; fermez-le et cliquez sur Re-check.

Exécution : ressentir, répondre, arrêter

Le test est divisé en quatre sections : Constant, Periodic, Condition et Ramp. Chaque effet est joué pendant une fenêtre fixe, cinq secondes sous Windows et deux secondes et demie sous Linux, et s’arrête dès la fin de cette fenêtre. La carte de réponse vous demande ensuite ce que vous avez ressenti : touchez chaque puce qui correspond, ajoutez si vous le souhaitez une note privée, puis choisissez Continue, Run test again ou Skip.

Stop run est visible dans l’en-tête et à côté du compte à rebours, et Échap arrête le test à tout moment. Fermer la fenêtre pendant un test arrête d’abord les effets et libère le périphérique. Ce qui a été mesuré avant l’arrêt est enregistré localement.

Résultat : conserver, partager et assurer le suivi

L’écran de résultat indique où le rapport a été enregistré, avec Show in folder et See my results. Share my results envoie les données expurgées ; sinon, rien n’est envoyé. Après le partage, l’application affiche un code d’assistance et un lien vers la page publique du périphérique, que le bouton « Share » du rapport HTML affiche aussi. Conservez ce code si vous souhaitez plus tard poser une question sur votre soumission ou la faire supprimer. Un champ facultatif d’adresse courriel vous inscrit aux actualités, notamment pour savoir quand FFB-Bridge prendra en charge votre manche.

Si un autre programme détenait le périphérique en exclusivité, le résultat nomme ce programme et explique que le test n’a rien mesuré du périphérique. Une base Brunner basculée pour le test, ou une base MOZA préparée pour celui-ci, est restaurée une fois le moteur de sonde arrêté.

Ce que FFB Probe demande au matériel de faire

Windows regroupe les tests en direct dans les sections Constant, Periodic, Condition et Ramp. Linux présente les effets evdev équivalents annoncés par chaque appareil. Le nombre exact varie selon le pilote et le matériel sur les deux plateformes.

Intensité du test et limite de 75 %

Chaque effet est joué à l’intensité du test choisie dans la liste de contrôle. Rien de ce que joue FFB-Probe ne dépasse 75 % de la pleine échelle, sur aucun périphérique et dans aucun test, y compris avec l’option de ligne de commande --magnitude et les modes de diagnostic. Les effets joués simultanément se partagent l’intensité, si bien qu’ensemble ils ne la dépassent jamais. Chaque rapport enregistre l’intensité et indique si vous l’avez modifiée.

Centrage automatique et arrêt des effets

Le ressort de centrage automatique propre au périphérique est désactivé pendant les tests en direct puis rétabli ; il ne contrarie donc pas et ne masque pas l’effet testé. Chaque effet s’arrête dès la fin de sa fenêtre de lecture, et non quand vous répondez. Le Logitech G940 sous Linux fait exception : son pilote ignore le réglage de centrage automatique, donc FFB-Probe n’y touche pas et indique que le centrage automatique matériel était actif.

Mouvement mesuré

Pendant chaque effet, la sonde échantillonne les axes X et Y du manche sous Windows et sous Linux, et enregistre le déplacement maximal sous forme de pourcentage signé de la demi-course de chaque axe, par exemple X peak +25.1%, Y peak -0.8%. Le signe indique la direction, ce qui transforme une réponse de direction en preuve vérifiable. Le déplacement est mesuré à partir de la position de repos du manche au début de l’effet ; un manche reposant hors du centre peut donc afficher plus de 100 %. Les effets Condition comme le ressort et l’amortisseur ne déplacent pas un manche centré : aucun mouvement au repos n’est donc attendu pour eux. La mesure reste dans le champ privé des notes de réponse et n’est pas affichée sur les pages publiques des périphériques.

Bases Brunner

Une base Brunner multiplie chaque effet DirectX par des gains qu’elle stocke elle-même, 50 % en sortie d’usine. Pour les tests en direct, FFB-Probe règle FX master et les gains d’effet à 100 %, jamais plus et sans toucher à l’amortissement global, puis restaure vos valeurs, y compris lorsque vous arrêtez un test. En mode DirectX, la base associe ses axes avec une rotation de 90° : 0° tire vers la droite, 90° vers l’avant, 180° vers la gauche et 270° vers l’arrière. C’est le comportement du firmware de Brunner ; FFB-Probe l’enregistre tel qu’il est mesuré et ne le corrige pas.

Les deux fichiers écrits à chaque exécution

Les rapports sont enregistrés dans %LOCALAPPDATA%\Programs\ffb-probe\Results\FFB-Probe-<timestamp>\ sous Windows et dans ~/.local/share/ffb-probe/Results/FFB-Probe-<timestamp>/ sous Linux. Chaque test écrit deux fichiers : le rapport HTML et le JSON de partage. Le HTML intègre le JSON dans un bloc <pre> ; le rapport local et les données envoyées sont donc les mêmes octets. Les anciens fichiers texte, README et ZIP d’assistance ne sont écrits que si FFB_PROBE_KEEP_LEGACY=1 est défini.

Installation sous Windows et vérifications de l'éditeur

FFB Probe est publié par Rohsam Inc. Le programme d'installation est une installation par utilisateur — aucun mot de passe administrateur requis, aucune invite UAC. Il place le binaire sous %LOCALAPPDATA%\Programs\ffb-probe et écrit un raccourci sur le bureau et une entrée Start Menu. Le sélecteur de répertoire est masqué afin que vous ne puissiez pas l'installer accidentellement dans un endroit étrange. Les versions stables de Windows sont signées ; confirmez que Windows affiche bien Rohsam Inc. comme éditeur et vérifiez le SHA-256 sur la page de téléchargement avant de l'exécuter.

Si Windows n'affiche pas Rohsam Inc. comme éditeur vérifié de votre programme d'installation, ou si le hachage ne correspond pas au manifeste de version publié, n'exécutez pas ce fichier.

Le manifeste de version fait foi pour les noms de fichiers, les tailles et les hachages. Le programme d'installation Windows et l'AppImage Linux sont tous deux des téléchargements facultatifs ; l'exécution de la sonde conserve toujours les rapports en local jusqu'à ce que vous choisissiez Share.

Autorisations AppImage plus evdev

Le Linux construit des navires comme un AppImage autonome. Marquez-le comme exécutable, exécutez-le et gardez la clé alimentée avec de la place pour bouger :

chmod +x ./FfbProbe-*.AppImage
./FfbProbe-*.AppImage

L'AppImage peut être exécutée directement, ou ./FfbProbe-*.AppImage --install peut ajouter une intégration au bureau pour l'utilisateur sous ~/Applications. Utilisez --uninstall pour supprimer cette copie et son entrée de menu.

La détection peut fonctionner avec un accès en lecture seule, mais les effets live nécessitent un accès en écriture au nœud /dev/input/event* du joystick. Si l'assistant signale des échecs d'autorisation, corrigez une seule fois les autorisations du nœud d'événement de l'appareil au lieu d'exécuter l'intégralité de l'AppImage avec sudo.

1. Recherchez le nœud d'événement

Le rapport ou le texte d'erreur le nomme généralement sous une forme telle que event=/dev/input/event2. Vous pouvez également inspecter les liens symboliques des événements du joystick :

ls -l /dev/input/by-id/*event-joystick

2. Essayez une autorisation temporaire

Remplacez event2 par le nœud de votre manche. Cela dure jusqu'à ce que l'appareil soit débranché ou que la machine redémarre ; c'est donc un moyen sûr de confirmer le problème :

sudo setfacl -m "u:$USER:rw" /dev/input/event2
./FfbProbe-*.AppImage

3. Rendez-le persistant avec udev

Demandez à udev les identifiants USB de la clé :

udevadm info -q property -n /dev/input/event2 | grep -E 'ID_VENDOR_ID|ID_MODEL_ID|NAME'

Utilisez ces identifiants hexadécimaux en minuscules dans une règle spécifique à l'appareil. Cet exemple concerne un SideWinder FFB2, VID:PID 045e:001b :

sudo tee /etc/udev/rules.d/70-ffb-probe-045e-001b.rules > /dev/null <<'EOF'
# FFB Probe: allow the active desktop user to open this joystick's event node.
SUBSYSTEM=="input", KERNEL=="event*", ATTRS{idVendor}=="045e", ATTRS{idProduct}=="001b", TAG+="uaccess"
EOF

sudo udevadm control --reload-rules
sudo udevadm trigger --subsystem-match=input

Débranchez et rebranchez le manche, puis exécutez l'AppImage normalement. La règle s'applique par appareil, elle est donc plus sûre que d'ajouter votre utilisateur au large groupe input.

4. Bases Brunner : l’interface de configuration

Pour basculer une base Brunner entre les modes CLS2Sim et DirectX, et pour relever ses gains pendant le test, FFB-Probe utilise l’interface de configuration hidraw de la base, réservée par défaut à root. Si l’accès est refusé, FFB-Probe affiche la règle à ajouter. La règle udev de FFB-Bridge la contient déjà ; sinon, créez ce fichier et rebranchez la base :

sudo tee /etc/udev/rules.d/71-ffb-probe-brunner.rules > /dev/null <<'EOF'
SUBSYSTEM=="hidraw", KERNEL=="hidraw*", ATTRS{modalias}=="usb:v25BBp*in01", TAG+="uaccess"
EOF

sudo udevadm control --reload
sudo udevadm trigger

5. Bases MOZA : le port de réglages

La vérification de l’état des bases MOZA et Prepare base for testing communiquent avec la base via son port série USB de réglages, /dev/ttyACM*. Si FFB-Probe ne peut pas ouvrir le port, il suggère le groupe dialout ; déconnectez-vous puis reconnectez-vous après l’avoir ajouté :

sudo usermod -aG dialout "$USER"

Une règle par périphérique donne le même accès au seul utilisateur actif du bureau :

sudo tee /etc/udev/rules.d/70-ffb-probe-moza.rules > /dev/null <<'EOF'
SUBSYSTEM=="tty", KERNEL=="ttyACM*", ATTRS{idVendor}=="346e", TAG+="uaccess"
EOF

sudo udevadm control --reload-rules
sudo udevadm trigger --subsystem-match=tty

Quand un autre programme détient le périphérique

Avant les tests, le processus de travail Linux ouvre une fois le nœud d’événement. Si le nœud est occupé (EBUSY), FFB-Probe nomme les processus qui le détiennent, trouvés via /proc/*/fd. Si l’accès est refusé (EACCES ou EPERM), il renvoie aux étapes d’autorisation ci-dessus. Les processus exécutés par d’autres utilisateurs ou par root ne peuvent pas être listés sans privilèges, et le message le précise.

Le centrage automatique du noyau est désactivé pendant la lecture de chaque effet et rétabli entre les effets. Il n’est jamais modifié sur le Logitech G940, dont le pilote Linux ignore ce réglage et centre toujours à pleine force.

L'assistant Linux utilise les effets de retour de force evdev plutôt que DirectInput. Le schéma de rapport partagé est le même que celui de Windows, de sorte que les soumissions Linux apparaissent dans la même base de données publique et dans la même répartition du système d'exploitation.

Mises à jour avec consentement sous Windows et Linux

L'interface graphique lit un petit manifeste de version stable au démarrage. Il n'envoie aucun ID d'installation, requête de version actuelle, informations sur le périphérique ou résultats de sonde ; les réponses hors ligne et mal formées restent silencieuses.

Aucune mise à jour n’est proposée pendant un test, et rien n’est installé sans votre consentement. Les versions stables ne se voient proposer que des versions stables ; une version bêta se voit proposer les bêtas plus récentes et la version stable qui les remplace.

Après consentement explicite, FFB-Probe télécharge le programme d'installation, vérifie sa longueur exacte et SHA-256, requiert une signature Windows valide de Rohsam Inc., exécute le programme d'installation par utilisateur en silence et redémarre la nouvelle version.

Un Linux AppImage en cours d'exécution peut télécharger et vérifier le nouveau AppImage, appeler son gestionnaire d'installation à l'échelle de l'utilisateur, actualiser l'entrée et les icônes du bureau et lancer la copie installée.

Les versions de développement, les AppDirs extraits, les packages de distribution et les autres installations non AppImage Linux ne sont jamais écrasés. L'invite renvoie à la page de téléchargement et à ces notes de version, et chaque utilisateur peut différer ou ignorer une version.

Problèmes connus et étapes de récupération

Les octets exacts sont la surface d’audit

Vos fichiers de rapport restent locaux tant que vous ne cliquez pas sur Share. Le partage envoie le fichier JSON par POST à /submit ; ce sont les mêmes octets que ceux intégrés au bas du rapport HTML. Séparément, l'interface effectue au démarrage la vérification du manifeste sans identifiant décrite ci-dessus, sans jamais envoyer de données de rapport ou d'appareil.

La base de données publique du matériel affiche une vue agrégée par VID:PID. Elle n’affiche jamais responses[].notes, qui peut contenir du texte facultatif de la personne ayant effectué le test et le mouvement mesuré par la sonde. Les libellés choisis, la classe de périphérique, l’intensité du test (run), les indicateurs de capacité, les effets pris en charge, les codes de résultat, les effets en échec et les erreurs d’exécution peuvent apparaître sur la page du périphérique.

L’avertissement de l’écran d’accueil concernant les autres programmes en cours d’exécution et le message d’accès exclusif ne sont affichés qu’à vous ; les noms de programmes qu’ils contiennent ne sont jamais ajoutés au rapport.

Lire le contrat de confidentialité complet → · Ouvrez l'exemple de rapport téléchargé →