Tester votre adaptateur et votre manette

Table des matières:

Introduction

Cette page a pour but d'expliquer comment tester un adaptateur au niveau du système d'exploitation.

Par exemple, si votre manette ne fonctionne pas, cela n'est pas nécessairement causé par une défectuosité de l'adaptateur. Cela peut aussi être dû (c'est souvent le cas) à un problème de configuration du jeu ou de l'émulateur. Pour la plupart des émulateurs et beaucoup de jeux, la manette à utiliser doit au préalable être sélectionnée. Parfois il faut également associer une fonction à chaque bouton.

Tester l'adaptateur à l'extérieur du jeu en utilisant des outils standards permet de confirmer si l'adaptateur fonctionne normalement. S'il fonctionne, il faudra regarder du côté du jeu ou de l'émulateur. Dans le cas contraire, le problème pourrait être du côté de l'adaptateur ou de la manette.

Tester sous Windows

À propos de Direct Input et XInput

Il y a deux systèmes différents à la disposition des développeurs de jeux pour supporter des contrôleurs. Le premier système, Direct Input, existe depuis plus de 20 ans. Nos adaptateurs implémentent le standard USB HID qui leur permet de fonctionner presque partout (Linux, Mac, PS3, Android...) et aussi sous Windows, avec Direct Input.

L'autre système à la disposition des développeurs se nomme Xinput. Il s'agit d'une API un peu plus récente conçue spécialement pour les manettes pour Xbox 360. Cela permet aux développeurs de savoir à l'avance la disposition et le nombre des boutons, puisqu'il s'agit uniquement de mannettes de type Xbox 360.

Cela facilite la vie des développeurs qui n'ont plus à faire l'effort de vous offrir la possibilité à vous, l'usager, de configurer les boutons et les axes de votre manette préférée (pas Xbox 360) pour contrôler le jeu adéquatement. Autrement dit, le jeu est conçu pour une manette spécifique qu'on vous impose.

Mais le plus gros problème set que le pilote Xinput ne supporte que les manettes pour Xbox 360 (ou les imitations). Conséquence directe de la popularité croissante de Xinput, de plus en plus de pourtant excellents joysticks, manettes, volants et adaptateurs ne fonctionnent pas avec les nouveaux jeux.

Si votre adaptateur et manette fonctionne bien avec les tests inclus dans Windows (voir prochaine section) mais pas dans votre jeu, vérifiez si ce dernier support Direct Input. S'il ne supporte que Xinput, vous devrez utiliser un émulateur de manette Xbox 360 tel que x360ce.

L'outil de test de Windows

Un outil de test pour contrôleurs de jeu est inclus avec Windows. La fenêtre Contrôleurs de jeu affiche une liste des contrôleurs de jeu installés. Les adaptateurs ayant plusieurs ports y apparaîtront plusieurs fois.



Sélectionnez un des contrôleurs puis cliquez sur le bouton Propriétés pour ouvrir la fenêtre de test qui vous permettra de vérifier le fonctionnement de votre manette.




Comment accéder à la fenêtre « Contrôleurs de jeu »?

Pendant longtemps il s'agissait simplement de double-cliquer sur l'icône du même nom dans le panneau de configuration, mais cela a changé dans les versions plus récentes de Windows.

Windows 7

Étape 1
Sous Windows 7, ouvrez d'abord le Panneau de configuration, puis double cliquez ensuite sur Appareils et imprimantes. Vous devriez pouvoir repérer un icône correspondant à l'adaptateur, comme celui-ci:


Étape 2
Cliquez sur cet icône en utilisant le bouton droit de la souris, puis cliquez sur Game Controller settings (note: Nous n'avons pas de version française de Windows pour citer l'expression exacte) pour ouvrir la fenêtre des contrôleurs de jeu.

Windows 10/11

Sous Windows 10/11, le moyen le plus rapide est d'ouvrir la fenêtre des contrôleurs de jeu est de taper Joy.cpl dans la boîte de recherche adjointe au bouton Démarrer.



Alors que vous tapez, les résultats s'afficheront et Joy.cpl devrait être en tête.



Il suffit alors de cliquer pour ouvrir la fenêtre des contrôleurs de jeu.


Problèmes connus impliquant joy.cpl

1. Erreur en cliquant sur Propriétés
On nous dit de temps en temps que bien que tout fonctionne (l'adaptateur est bien détecté par les jeux et les boutons fonctionnent) un message d'erreur apparaît en cliquant sur Propriétés dans joy.cpl

Erreur du contrôleur de jeu dans joy.cpl

L'erreur indique:
Votre contrôleur de jeu n'est pas connecté correctement. Vérifiez qu'il est bien raccordé à votre ordinateur.
Il s'agit clairement d'un message d'erreur générique datant du temps des joysticks PC à 15 broches. Ce message induit en erreur:
  1. Windows ne peut pas savoir qu'il s'agit d'un adaptateur, et Windows ne peut pas non plus déterminer si une manette est branchée à l'adaptateur ou pas. En temps normal, qu'il y ait une manette de branchée ou pas à l'adaptateur, cliquer sur Propriétés fonctionne sans erreur. Il ne s'agit donc pas d'un problème de branchement de manette.
  2. Vérifier le raccord à l'ordinateur? Si le câble USB n'était pas branché, l'adaptateur ne serait tout simplement pas listé dans joy.cpl! Une suggestion bien inutile ici.
Alors qu'est-ce que ce message veut dire? Aucune idée! Windows ou joy.cpl est clairement est "mécontent" de quelque chose mais ne communique pas assez d'information pour nous permettre de comprendre et corriger.

Nous connaissons trois moyens pour contourner le problème:
  1. Ouvrir le gestionnaire d'adaptateurs raphnet et sélectionner l'adaptateur. Tant que le gestionnaire demeure ouvert, joy.cpl cesse de se plaindre.
  2. Simplement ignorer le problème. Comme l'adaptateur fonctionne et est utilisable par les jeux, et si à l'occasion vous souhaitez tester les boutons avec joy.cpl, il suffit d'utiliser le moyen ci-dessus.
  3. Utiliser USBDeview (voir section suivante) pour forcer Windows à complètement oublier l'adaptateur, de sorte qu'au prochain branchement il soit traité comme un nouveau périphérique, qui fonctionnera alors avec joy.cpl correctement. (Jusqu'à ce que pour une raison inconnue le problème revienne)


2. Adaptateur en double
Pour certains utilisateurs, il arrive à l'occasion que bien qu'un seul adaptateur soit branché, deux lignes apparaissent dans joy.cpl. Cela ressemble à ceci:

image de joy.cpl avec adaptateur en double

Nous savons que le problème n'est pas que l'adaptateur est devenu défectueux, puisqu'on nous dit que tout fonctionne lorsque l'adaptateur est utilisé sur un autre ordinateur. Nous ignorons toutefois quelles sont les conditions requises pour que ce problème apparaisse, et comme nous n'avons jamais pu le reproduire et l'analyser sur nos systèmes, nous n'avons pas de solution idéale.

Certains utilisateurs nous disent toutefois que lorsque le gestionnaire d'adaptateurs raphnet est ouvert et que l'adaptateur est sélectionné, le doublon disparaît. Laisser le gestionnaire ouvert peut donc potentiellement aider.

Nous connaissons sinon une autre manière de contourner le problème: Déinstaller l'adaptateur complètement, de sorte qu'au prochain branchement il soit traité comme un périphérique vu pour la première fois. Notez que faire cela via le Gestionnaire de périphériques ne fonctionne pas. Des informations semble être retenues et le périphérique n'est pas complètement "oublié" par Windows. Cependant, à l'aide d'un outil nommé USBDeview cela fonctionne à merveille.
Sélectionnez simplement les périphériques avec le vendor ID 289b (notre code de manufacturier) un par un et utilisez le bouton poubelle de la barre d'outils (ou 'Uninstall Selected Device' du menu).

screenshot de USBDeview avec vendor ID encadrés
Faites très attention de bien sélectionner uniquement les lignes correspondant au vendeur 289b, sans quoi certaines choses pourraient cesser de fonctionner. Utilisez ces instructions à vos propres risques - nous ne sommes pas responsable si vous brisez votre ordinateur.

Une fois terminé, débranchez puis rebranchez l'adaptateur. Tout devrait alors fonctionner, du moins jusqu'à ce que les conditions inconnues qui causent le problème surviennent à nouveau... (Merci de nous contactez si vous trouvez une manière de causer ce problème qui fonctionne à tout coup!)

Tester sous Linux

Vérifier la détection de l'adaptateur

Lors du branchement de l'adaptateur, quelques lignes devraient apparaître dans le journal du kernel. Exécutez dmesg ou sudo dmesg et regardez les quelques dernières lignes pour des messages relatifs à la détection d'un nouveau périphérique USB. Par exemple:
	new full-speed USB device number 15 using xhci_hcd
	New USB device found, idVendor=289b, idProduct=0038
	New USB device strings: Mfr=1, Product=2, SerialNumber=3
	Product: GC/N64 to USB v3.5
	Manufacturer: raphnet technologies
	SerialNumber: 101581
	input: raphnet technologies GC/N64 to USB v3.5 as ...
	...

Vérifier que l'adaptateur est géré comme un joystick

Repérez le groupe correspondant à votre adaptateur dans le fichier /proc/bus/input/devices. Par exemple:
	I: Bus=0003 Vendor=289b Product=0038 Version=0101
	N: Name="raphnet technologies GC/N64 to USB v3.5"
	P: Phys=usb-0000:00:14.0-14/input0
	S: Sysfs=/devices/pci0000:00/0000:00:14.0/usb1/1-14/1-14:1.0/0003:289B:0038.000D/input/input25
	U: Uniq=101581
	H: Handlers=event18 js0
	...
Dans l'exemple ci-dessus, nous voyons que l'adaptateur sera accessible par js0. Si vous avez plusieurs manettes ou adaptateurs, le chiffre sera plus élevé. Mais si vous n'avez qu'un adaptateur, normalement ce sera 0.

Tester votre manette avec jstest

Sous Debian (et dérivés) le package nommé joystick contient un outil de test en ligne de commande simple nommé jstest.

Tapez jstest suivi du chemin d'accès au joystick. Par exemple: 
	jstest /dev/input/js0
Ceci affichera des informations générales ainsi qu'une liste de boutons et d'axe qui se mettent à jour si vous manipulez votre manette. (Notez que le driver version qui sera affiché n'a rien à voir avec le firmware de l'adaptateur. Ne vous en souciez pas.)


Tester votre manette avec jstest-gtk

Il existe une alternative graphique à jstest nommée jstest-gtk. Il suffit de lancer jstest-gtk sans arguments et une liste des joysticks sur le système sera présentée.



Vérifier que l'adaptateur est accessible en tant que "Event device"

De la même manière qu'exposé ci-dessus pour déterminer à quel joystick l'adaptateur correspond, le contenu de /proc/bus/input/devices permet de déterminer le numéro d'input device correspondant. Par exemple:
	I: Bus=0003 Vendor=289b Product=0080 Version=0101
	N: Name="raphnet technologies 1-player WUSBMote v2.2"
	P: Phys=usb-0000:00:14.0-5/input0
	S: Sysfs=/devices/pci0000:00/0000:00:14.0/usb1/1-5/1-5:1.0/0003:289B:0080.09A2/input/input4074
	U: Uniq=431094
	H: Handlers=event24 js0
	...
Contrairement aux joystick cependant, les event devices sont un concept beaucoup plus général qui regroupe, entre autre, les boutons, interrupteurs, souris et claviers. Sur un système typique ils seront nombreux, même si vous n'avez qu'un adaptateur. Dans l'exemple ci-dessus, l'adaptateur est assigné à event24.

Tester avec evtest

Sous Debian (et dérivés) le package nommé evtest contient un outil de test en ligne de commande simple nommé evtest.
Lorsque vous exécutez evtest, une liste de périphériques accessibles est affichée: 
$ evtest
No device specified, trying to scan all of /dev/input/event*
Not running as root, no devices may be available.
Available devices:
/dev/input/event24:     raphnet technologies 1-player WUSBMote v2.2
Select the device event number [0-24]:
Tapez le numéro de périphérique (ici, 24) et validez. Ensuite, selon les manipulations du joysticks, les événements de changement d'état de bouton et d'axes seront affichés.

Vous pouvez également passer le chemin d'accès au périphérique en argument: 
	evtest /dev/input/event24


Permissions et droits d'accès sous Linux

Si evtest et jstest affichent une erreur lorsque vous tentez d'accéder à /dev/jsX ou /dev/input/eventX, mais que lorsque vous essayez en tant que root tout fonctionne, cela signifie que votre utilisateur n'a pas les droits d'accès.

En guise de référence, voici ci-dessous à quoi cela ressemble sur un système où un utilisateur normal est capable d'accéder aux périphériques et où jstest et evtest fonctionnent sans problème.

Les permissions unix de base peuvent être affiché à l'aide de ls -l:
$ ls -l /dev/input/event24
crw-rw----+ 1 root input 13, 88 May  2 10:39 /dev/input/event24

$ ls -l /dev/input/js0
crw-rw-r--+ 1 root input 13, 0 May  2 10:39 /dev/input/js0
Ci dessus, il semble que event24 et js0 soient accessibles en mode lecture/écriture par le propriétaire (root) et les membres du groupe (input).

Nous pouvons constater que l'utilisateur actuel n'est pas dans le groupe input en utilisant la commande id:
$ id
uid=1000(demo) gid=1000(demo) groups=1000(demo),24(cdrom),25(floppy),29(audio),30(dip),44(video)...

Pourtant, l'utilisateur peut accéder au périphérique sans problème. Avez-vous remarqué la présence du signe + à la fin de crw-rw-r--+? Ceci indique que des ACL (access control list - une liste de droits) est configuré sur ce fichier. Sous debian (et certains dérivés), le package 'acl' installe un outil nommé getfacl, qui permet d'inspecter les droits en détails.
$ getfacl /dev/input/event24
getfacl: Removing leading '/' from absolute path names
# file: dev/input/event24
# owner: root
# group: input
user::rw-
user:demo:rw-
group::rw-
mask::rw-
other::---
On constate ci-dessus que l'utilisateur demo est explicitement autorisé pour accéder au périphérique. C'est pourquoi jstest et evtest fonctionnent sur ce système. Ceci semble être fait automatiquement sur ce système Linux Debian de test lorsque l'utilisateur demo ouvre une session locale sur la machine. Ceci n'est pas nécessairement les cas sur toutes les versions de Linux et peut dépendre de la configuration.

Une solution rapide si votre utilisateur n'a pas accès pourrait être d'ajouter votre utilisateur au groupe input, mais ceci pourrait comporter un risque de sécurité. En théorie, votre utilisateur ne devrait pas être dans ce groupe, car s'il en fait partie, cet utilisateur (et les programmes exécutés par cet utilisateur) auront dès lors accès à TOUT les périphérique d'entrée. Par exemple, un logiciel malveillant pourrait ouvrir le event device correspondant au clavier et espionner tout ce que vous tapez! Peut-être que ce n'est pas un problème dans votre environnement, mais ce n'est pas recommandé. (tout comme tout exécuter en tant que root!)

Une autre solution rapide serait de modifier les droits d'accès du fichier. (Par exemple sudo chmod 666 /dev/input/js0 donnerait accès à tous les utilisateurs) mais en raison de la nature dynamique des périphériques USB, qui partent et reviennent, vous auriez à répéter cette étape à chaque branchement et redémarrage.

L'idéal est bien sûr de consulter la documentation de votre distribution ou de poser la question dans le forum ou mailing list de support et faire les choses "correctement" pour votre type système.