Bonjour!
Depuis (très) longtemps j'ai un gamepad Gravis Gamepad Pro. Il est simple, il est efficace, il est solide, il fonctionne très bien. Oui mais voilà: il a besoin d'un port joystick DB-15 et il n'y en a plus sur les ordinateurs modernes (ou même pas très modernes).
Donc je me suis fabriqué un adaptateur pour le brancher sur un port USB et pouvoir continuer à m'en servir.
J'ai commencé à y réfléchir il y a longtemps, mais pour différentes raisons je n'avais jamais pu terminer ce projet. C'est maintenant chose faite.
La première étape a été de comprendre le fonctionnement de ce gamepad. On pourrait penser que c'est simple, mais en fait non. Le port Joystick du PC est normalement prévu pour connecter deux joysticks comportant chacun 2 axes analogiques (haut/bas et gauche/droite) et deux boutons. Le matériel est assez simple mais ça rend le logiciel plus compliqué: il faut faire des mesures précises de timings pour en déduire la position du joystick, ce qui doit être calibré en fonction de la vitesse du processeur. Et de toutes façons ça ne suffit pas pour ce gamepad qui comporte 10 boutons et un pavé directionnel (et on peut en brancher deux sur un port Joystick pour jouer à plusieurs).
J'ai pu trouver quelques informations sommaires sur le principe de fonctionnement, complétées par une lecture du pilote existant pour ce gamepad dans le noyau Linux, et enfin de quelques mesures avec un oscilloscope pour confirmer les choses. J'avais alors écrit un article documentant tout ça de façon assez détaillée.
Pour faire simple: le gamepad utilise les deux "boutons" pour établir une liaison série unidirectionelle avec l'ordinateur. L'un des boutons sert d'horloge et permet de savoir quand un nouveau bit de données est disponible. Le deuxième bouton transmet un à un l'état de tous les boutons du gamepad, avec quelques bits fixes en plus qui permettent de reconnaître le début du message et de se synchroniser.
Le deuxième gamepad fait bien sûr la même chose avec les deux autres "boutons" disponibles.
Une fois ceci bien compris, j'ai implémenté le code pour décoder ces trames. J'ai fait quelques essais avec un microcontrôleur STM32 mais finalement j'ai utilisé un Atmel AT90USB, beaucoup plus simple à utiliser (aussi bien d'un point de vue logiciel que matériel, moins de pattes à souder et moins de composants à rajouter autour). J'ai d'abord fait quelques essais avec une carte de développement AT90USBKEY, avant de concevoir mon propre circuit électronique.
J'ai eu quelques soucis lors de la commande des composants, le microcontrôleur choisi étant en rupture de stock jusqu'en septembre 2022. Cependant j'ai pu en importer quelques uns de chine. Après avoir assemblé le circuit et programmé le microcontrôleur, tout fonctionne sans prolème!
L'adaptateur comporte 2 ports Joystick et permet donc d'utiliser jusqu'à 4 gamepads en même temps.
Côté firmware il n'y a finalement rien de très compliqué: le projet LUFA rend très facile la programmation d'un périphérique USB sur ces microcontrôleurs. Il ne restait plus qu'à relier ça à mon code pour lire les infos provenant du gamepad. L'adaptateur est un périphérique USB HID standard et fonctionne sans pilote particulier. La seule spécificité est l'utilisation de plusieurs "reports" HID, permettant de voir 4 contrôleurs indépendants même s'il n'y a qu'un seul périphérique USB.
Maintenant il ne me reste plus qu'à trouver un bon choix de jeux multijoueurs… ou à en programmer quelques uns. Je vias peut être aussi me décider à travailler sur le panneau de préférences des contrôleurs de jeux dans Haiku, ça manque un peu pour pouvoir tester facilement ce genre de choses.
Si vous souhaitez fabriquer vous-même un tel adaptateur, les informations se trouvent sur un project github (schéma, fichier GERBER pour la production du circuit, sources du firmware et binaire précompilé).
D'autre part, j'ai commandé 10 PCBs (c'est le minimum pour lancer une production de circuits imprimés) donc je peux assembler quelques adaptateurs supplémentaires. Le prix est de 15€, à peu près de quoi rembourser l'achat des composants et les frais d'expédition.
# Lien cassé
Posté par martoni (site web personnel, Mastodon) . Évalué à 3.
Super projet !
Par contre le lien github ne fonctionne pas chez moi.
Par curiosité: Où à tu fais produire les PCB ? Et quel logiciel de CAO as tu utilisé ?
J'ai plus qu'une balle
[^] # Re: Lien cassé
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 6.
En effet, erreur dans le lien, le projet se trouve ici: https://github.com/pulkomandy/avrstuff/tree/master/grip2hid
Je fais mes schémas et PCBs avec Kicad et la production est faite par Seeed Studio
[^] # Re: Lien cassé
Posté par Ysabeau 🧶 🧦 (site web personnel, Mastodon) . Évalué à 4.
J'ai corrigé le lien dans le journal.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Lien cassé
Posté par martoni (site web personnel, Mastodon) . Évalué à 8.
Merci,
N'hésite pas à venir dans l'espace de rédaction de LinuxFR pour contribuer à la dépêche sur Kicad 6 !
Je cherche des gens d'expérience pour m'aider à rédiger ;)
J'ai plus qu'une balle
# Haiku
Posté par devnewton 🍺 (site web personnel) . Évalué à 9.
Je ne sais pas si tu as déjà une spec, mais voici ce que j'aimerais voir sur un OS digne de ce nom:
Bref tout ce que font déjà les émulateurs multi consoles comme Retroarch :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Haiku
Posté par Nibel . Évalué à 4.
Steam fait la même chose également. Vu que la quasi intégralité de ma ludothèque est dessus, c'est super pratique de brancher ma manette et "ça juste marche" dans la majorité des cas. Surtout que pour les jeux les plus populaires, sont proposés divers paramétrages (par l'éditeur et par la communauté des joueurs). Donc même si on est paresseux, on peut s'en sortir en choisissant un paramétrage pré-établi et ça conviendra pour la majorité des joueurs.
Il y a parfois des petits conflits (bouton A reconnu comme B par le jeu et inversement) qui se résolvent en inversant également les paramètres ingame, c'est relativement rare mais ça m'est déjà arrivé.
Possibilité de gérer différents profils par jeu et même par manette (parce que même en 2021, on peut jouer a plusieurs sur la même machine sans connexion Internet, je vous jure).
Et pour les jeux non-Steam, il est possible d'ajouter un lanceur dans Steam directement afin de profiter de l'API "controller".
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
[^] # Re: Haiku
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 4.
Pour le binding, SDL2 permet déjà de le faire mais il faut lui fournir ce fichier: https://github.com/gabomdq/SDL_GameControllerDB
Je vais probablement réutiliser ces informations dans Haiku également. Par contre je trouve la liste de boutons disponibles dans SDL2 un peu limitée: http://wiki.libsdl.org/SDL_GameControllerButton (pas de bouton SELECT par exemple?)
C'est difficile de faire ça bien parce que la plupart des contrôleurs ne fournissent pas d'infos sur la position physique des boutons (alors que c'est possible dans l'USB HID). Donc il faut renseigner à la main ce genre de fichier pour avoir les infos nécessaires.
[^] # Re: Haiku
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Ça doit être SDL_CONTROLLER_BUTTON_BACK.
Ah ? Comment ça fonctionne ?
Si je devais refaire l'histoire des pads, je changerais les YAXB et 🔺✖️🔲⚫ en Nord, Sud, Ouest, Est histoire de pouvoir enfin arrêter de rater les quicktime events :-)
Certes on va me dire que je fais encore du colonialisme et que certaines cultures font des cartes avec le sud vers le haut et que tout ça c'est compliqué ça change de sens selon comment on est tourné, mais merde.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Haiku
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 3.
Il y a plusieurs choses qui devraient normalement être listées pour chaque bouton:
Malheureusement, la plupart des gamepads font plutôt quelque chose du genre "voici 15 boutons dans un ordre aléatoire" sans donner plus de détails.
La liste des "usages" possibles: https://usb.org/sites/default/files/hut1_22.pdf (mises à jour régulièrement, on peut voir sur le site usb.org la liste des nouveaux usages en cours de discussion, c'est tout aussi divertissant que la liste des emojis dans Unicode)
La spécification USB HID et en particulier la section 6.2.3 pour les descripteurs physiques: https://usb.org/sites/default/files/hid1_11.pdf
Le seul truc que je n'ai pas trouvé, c'est comment décrire la couleur des boutons. Ce qui est dommage parce que mon gamepad Gravis a juste des couleurs pour différencier les boutons, et pas de texte ou de symboles.
[^] # Re: Haiku
Posté par Thomas Debesse (site web personnel) . Évalué à 6. Dernière modification le 29 octobre 2021 à 04:58.
Pour les boutons en croix, tu peux toujours utiliser les codes de couleur classiques, RGBY (Red, Green, Blue, Yellow), bon R existe peut-être déjà pour Right…
Après, puisque tu dis avoir le droit à tout unicode, tu peux être créatif:
🔴🟠🟡🟢🔵🟣🟤
🟥🟧🟨🟩🟦🟪🟫
Et en fait, pour diverses raisons, tu auras peut-être plus de variation avec l’emoji cœur:
❤🧡💛💚💙💜🤎🖤🤍
Note que le premier cœur peut t’apparaître comme noir car il est appelé “HEAVY BLACK HEART” mais il est aussi indiqué que “displayed with a red color when used in emoji style“ (affiché en rouge si utilisé comme emoji), probablement la faute aux rézos socios, je ne crois pas qu’il y ait de réel cœur rouge dans unicode bien que ce serait utile pour lever complètement l’ambiguïté et être indépendant du contexte.
Le problème c’est que tu n’as pas de cœur Cyan (entre le Vert et le Bleu) et le cœur Bleu est généralement affiché Cyan, ce qui n’aide pas.
Donc là dans ma liste il y a un cœur Vert et un cœur Bleu tandis que le cœur Cyan manque entre les deux, mais il est possible qu’à l’écran tu vois un cœur Vert et un cœur Cyan tandis que le cœur Bleu manque à droite du cœur Bleu… C’est comme si tu avais le Orange appelé Rouge et que le Orange n’existait pas.
Et je ne crois pas qu’il y ait les variantes communes de ces couleurs mêlées de Blanc comme le Rose (étonnant pour un cœur et la fonction emoji !), le Bleu clair, le Vert pâle, le Gris…
Tu as aussi le droit à un cœur inversé: 💟 (HEART DECORATION), avec le cadre souvent rendu en rose (va comprendre…).
Et si tu pensais ne pas avoir assez de cœurs noirs et de cœurs blancs, tu as aussi :
♥ BLACK HEART SUIT / valentine
♡ WHITE HEART SUIT
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Haiku
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Je ne sais pas pourquoi, j'ai pensé au Mastermind
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Haiku
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Très intéressante cette spec, mais elle parait si complexe qu'aucun jeu / OS / hard ne doit la gérer correctement…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Haiku
Posté par Thomas Debesse (site web personnel) . Évalué à 9.
Proue, Poupe, Bâbord, Tribord, car c’est c’est ta manette le référentiel, et la manette est orientée par rapport à toi. Et par exemple Pont, Cale pour dessus et dessous (s’il y a des marins dans la salles, qu’ils se manifestent s’il y a un vocabulaire déjà préconisé pour dessus/dessous).
Sachant que pour les axes des joysticks, bah il y a Roulis, Tangage, et Lacet, qui justement se définissent de manière non-ambiguë avec le vocabulaire précédent.
Ou puisque c’est toi le référentiel, Devant, Derrière, Gauche, Droite, Tête, Pied (on pourrait aussi faire Face/Dos mais ça apporte une confusion contradictoire : Face est-il parce que la face est dans le même sens que ma face, ou parce que je vois la face ?), mais pour les axes on risque de reprendre les mêmes.
Le truc de bien avec le vocabulaire maritime c’est que même si tu tiens ta manette à l’envers, c’est toujours cohérent. =)
De rien.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Haiku
Posté par ptit_poulet . Évalué à 2.
Alors plutôt que Pont et Cale, je dirai plutôt coque et mâture.
[^] # Re: Haiku
Posté par Thomas Debesse (site web personnel) . Évalué à 5.
J’avais aussi pensé à Quille et Mat, même si c’est moins universel y compris dans la marine, que Poupe/Proue/Bâbord/Tribord. =)
Le souci de Coque c’est que c’est homonyme (en fait c’est même exactement le même mot mais la sémantique a des aspects propres au contexte) avec l’intégralité de la surface de la manette. Pour Cale j’avais aussi pensé à Fond, mais en dehors de la marine, le fond ça peut être dans toutes les directions et sens. Et j’imagine qu’on doit aussi pouvoir parler de mâture dans d’autres contextes que la marine et où la gravité n’est pas un élément signifiant.
C’est pour ça que j’ai choisi Pont et Cale, parce que par exemple, même si en impesanteur il n’y a pas d’orientation ciel/terre (mer), à partir du moment où l’on définit une surface comme étant le Pont, alors la Cale est évidente, car la Cale est sous le Pont.
C’est ce que j’apprécie dans Proue, Poupe, Bâbord et Tribord (ainsi que Roulis, Tangage et Lacet) c’est que c’est complètement indépendant de référentiels extérieur, le « navire » est suffisant pour définir le référentiel, il suffit par exemple de désigner arbitrairement la Proue et alors tous le reste en découle de manière non-ambiguë. De la même manière, dès lors que l’on définit arbitrairement le Pont, alors la Cale est définie de manière non-ambiguë.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Haiku
Posté par ptit_poulet . Évalué à 4.
Le problème de la cale c'est qu'il s'agit d'une zone/local interne du bateau.
Par exemple si tu dis j'ai un trou dans la cale, ça peut très bien être au-dessus, un trou entre la cale et un pont). Ce qui ne présente pas beaucoup de danger dans l'immédiat. Par contre si tu annonces un trou dans la coque, ça craint… et tout le monde comprend où est le trou avec par exemple un trou dans la coque avant bâbord.
Et le pont n'est ni la "couche" inférieure ou supérieure du bateau mais un "niveau", car un bateau peut posséder plusieurs ponts, c'est comme des étages dans un immeuble. Donc tu peux parler de pont inférieur/supérieur (par rapport à la ligne d'eau) ou principal (celui auquel tu fais allusion).
D'ailleurs pour la partie du dessus à la place de mâture on pourrait aussi employer le terme château (rien à voir avec les chevaliers :D ). Il s'agit de la super structure.
[^] # Re: Haiku
Posté par Thomas Debesse (site web personnel) . Évalué à 4.
Je ne faisais pas allusion à un pont en particulier. L’idée derrière ma proposition de Pont/Cale vient de la relation entre les deux : quelque soit la quantité de ponts qui se superposent, la cale est par définition située sous un pont. Cette relation est sensée être non ambiguë et c’est cette relation qui m’a intéressée. Ce qui me gêne plus dans Pont/Cale c’est que le Pont désigne une surface par dessus, mais Cale ne désigne pas une surface par dessous (et un mot comme plafond est super ambiguë).
L’idée du Château est excellente. Ce qui me gênait aussi avec l’idée de Coque pour le dessous, c’est que des navires avec des coques qui couvrent toutes les directions ça existe : des sous-marins. L’avantage du Château par rapport au pont c’est qu’il n’est pas sensé avoir un autre Château au dessus de lui.
Château/Cale est donc peut-être une bonne idée. =)
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Haiku
Posté par ptit_poulet . Évalué à 3.
Pour un sous-marin tu as l'équivalent du château qu'on appelle le kiosque. C'est la superstructure qui sera donc toujours au-dessus de la coque.
[^] # Re: Haiku
Posté par Loïs Taulelle ࿋ (site web personnel) . Évalué à 3.
Zénith et Nadir ?
Proverbe Alien : Sauvez la terre ? Mangez des humains !
[^] # Re: Haiku
Posté par Thomas Debesse (site web personnel) . Évalué à 5.
Ah c’est pas mal ça ! Mais avec la contrainte qu’il faut définir un point de référence, car sur une sphère, tout est Zénith de quelque chose. On peut définir que le point de référence est à l’intersection des axes Proue/Poupe et Bâbord/Tribord, mais alors il nous reste à déterminer si c’est au dessous ou au dessous, et œuf, poule, toussa…
Ou alors on détermine arbitrairement le Zénith par rapport à certains éléments standard qu’on décrit par convention, comme par exemple la présence d’un bouton start qui serait rendu obligatoire et qui devrait être placé sur la surface qui est dirigée vers le Zénith.
Un point qui peut être déroutant avec le Zénith et le Nadir est qu’ils déterminent une direction et un sens depuis l’objet, et ici on parle d’un objet vu à la troisième personne, c’est à dire que potentiellement, la surface qui est orientée vers le Zénith est vue au Nadir de l’observateur.
Par exemple pour un observateur placé sur Terre, le sol à ses pieds est au Nadir de l’observateur mais est au Zénith du centre de la Terre…
Tandis que le train d’un avion, ou la quille d’un bateau sont définis par rapport à l’objet lui-même et non par un observateur qui pourrait être extérieur à l’objet. Et la gravité, mais sans gravité il suffit de déterminer une surface comme étant le dessus pour obtenir le dessous ou inversement, en référence à l’objet lui-même et non un observateur.
De toute façon on ne peut pas se passer d’établir une convention comme l’idée qu’un bouton start rendu obligatoire définirait le Zénith/Pont/Dessus/Tête… Zénith et Nadir sont une bonne trouvaille ! Ce qui me chagrine c’est que c’est déterminé par l’observateur faisant référence et non par l’objet observé faisant référence.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Haiku
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Bonne idée pour le bâton de style* gauche.
Il manque encore des noms à trouver pour le standard gamepad du W3C:
*: traduction entendu dans un jeu Wii:-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Haiku
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Je m'y connais pas du tout, donc ceci peut expliquer cela, mais en tout cas je ne vois pas en quoi la/le légende/libellé influe sur les quicktime events
Et sinon, moi je verrai plutôt ⥼⥾⥿⥽ ou ◄▲▼► (◁△▽▷) et ♠♥♦♣ (♤♡♢♧)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Haiku
Posté par Clément V . Évalué à 2.
Les QTE te demandent souvent d'appuyer rapidement sur le bouton représenté par son symbole sans que ça ait un rapport avec l'utilisation habituel du bouton en question. Si tu ne connais pas bien les symboles de ta manette, il faut que tu la regardes pour trouver le bouton… et c'est trop tard.
Si le symbole donne clairement la position du bouton (par exemple ◁△▽▷), on peut trouver le bouton sans regarder la manette et sans devoir la connaître par cœur.
La manette de Nintendo 64 avait 4 boutons supplémentaires (en plus de A et B) avec des flèches, mais ils se sont fait remplacés par le second joystick, donc les flèches ne sont pas restées.
C'est le même problème que la notation Sony : la position de chaque symbole n'est pas évidente.
[^] # Re: Haiku
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Idem pour les pads avec des boutons ABXY, voire pire puisque selon la manette ils ne sont pas au même endroit.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Haiku
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Merci, c'est plus clair pour moi : les loupés de QTE parce-que le temps de repérer les bonnes touches. Malheureusement, un standard ne règlera pas ce problème, à mon avis, car les dispositions peuvent varier d'un constructeur/modèle à un autre (par exemple la croix chez l'un sera le losange chez l'autre, mais normalement pas trop de différence jusque là ; par contre ça se corse si on dispose en ligne, en carré, en T inversé, etc.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Super projet !
Posté par WrathOfThePixel . Évalué à 2.
Mais qu'est ce que j'ai pu détester ce pad… :/
# Chinoiserie
Posté par geekborg . Évalué à -2.
Ça existe aussi en chinoiserie déjà toute prête :
https://a.aliexpress.com/_u9na3i
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.