Les marques de tablettes graphiques rechignent à collaborer sur les pilotes Linux FLOSS

• David Revoy ne teste les tablettes graphiques que dans un environnement GNU/Linux et FLOSS, et transmet les spécifications matérielles à Peter Hutterer et Benjamin Tissoire de Red Hat pour aider au développement des pilotes udev-hid-bpf
• Comme la répétition des dumps de spécifications et des tests par modèle devenait trop lourde, il a essayé de convaincre des marques comme XpPen, Gaomon et Huion de collaborer directement avec l’équipe hid/input
• Le contact technique obtenu via Gaomon travaillait chez « Shenzhen Huion Trend Technology Co.,Ltd. », ce que Revoy a rapproché de son observation selon laquelle plusieurs paquets Debian propriétaires de différentes marques avaient une structure similaire
• Après examen, Gaomon a répondu ne pas vouloir participer, en invoquant une structure de dépôt perçue comme centrée sur Wacom, un impact jugé limité pour GAOMON, l’exposition de la marque Wacom et des inquiétudes sur le partage des spécifications des appareils
• Les références persistantes à Wacom dans l’infrastructure Linux des tablettes graphiques constituent un obstacle pratique à la collaboration des concurrents, et Revoy revient pour l’instant à une approche consistant à tester les tablettes une par une et à documenter leurs spécifications

---

Une méthode de test FLOSS devenue trop lourde

• David Revoy échange avec des marques de tablettes graphiques pour réaliser des tests vidéo détaillés pour sa chaîne YouTube
• Ses conditions de test sont au nombre de deux
  • tester la tablette sous GNU/Linux
  • n’utiliser que des logiciels libres/open source (FLOSS), pilotes compris
• Pour les modèles intéressants, il extrait les spécifications matérielles et les transmet à Peter Hutterer et Benjamin Tissoire de Red Hat
• Ceux-ci peuvent ensuite convertir ces spécifications en pilotes FLOSS pour GNU/Linux via le projet udev-hid-bpf
• Sa dernière vidéo de test remonte à un an, et l’enchaînement dump des spécifications, tests de pilotes, évaluation du produit, production vidéo et rédaction d’un billet technique l’a poussé à chercher une autre méthode

Tenter d’amener les marques à partager elles-mêmes les spécifications

• La nouvelle stratégie consistait à faire collaborer directement les fabricants pour le support GNU/Linux et à leur faire partager les spécifications avec l’équipe hid/input
• Revoy espérait une coopération similaire à celle que Wacom pratique depuis des décennies
• Les échanges avec des marques comme XpPen, Gaomon et Huion passaient principalement par les équipes marketing plutôt que par les services techniques
• En général, les réponses se résumaient à « nous allons en discuter en interne et reviendrons vers vous si cela nous intéresse », sans suite concrète, malgré ses relances

Un interlocuteur technique lié à Huion obtenu via Gaomon

• Dans ses échanges récents avec Gaomon, il a fini par être mis en relation avec un véritable interlocuteur technique, ce qui a semblé rendre l’issue plus prometteuse
• Cette personne technique travaillait chez « Shenzhen Huion Trend Technology Co.,Ltd. »
• Dans de précédents tests, Revoy avait remarqué que les paquets Debian de pilotes propriétaires de Gaomon, XpPen, Huion et Ugee utilisaient une structure et des outils similaires
• Il a supposé que cet interlocuteur pouvait gérer les pilotes de plusieurs marques, puis lui a transmis les spécifications, les liens et la méthode, tout en l’invitant à contacter Peter Hutterer et Benjamin Tissoire

Pourquoi Gaomon a refusé : une infrastructure perçue comme Wacom

• Après nouvelle discussion avec l’équipe technique, le service marketing de Gaomon a répondu que l’entreprise ne lancerait pas pour le moment de projet de pilote Linux
• Le projet wacom-hid-descriptors faisait partie des éléments étudiés
• Voici les motifs de refus avancés par Gaomon
  • le projet paraît principalement piloté par Wacom
  • les bénéfices potentiels pour GAOMON sont jugés limités
  • même si l’appareil lui-même est affiché comme un modèle GAOMON, la configuration globale peut laisser apparaître la marque Wacom
  • participer est perçu comme un partage direct des spécifications matérielles avec Wacom
• Revoy dit avoir été surpris par cette réponse, mais il comprend que des fabricants hésitent à divulguer leurs spécifications si l’infrastructure porte le nom de leur plus grand concurrent

Le nom Wacom reste omniprésent dans l’infrastructure Linux des tablettes

• Pour des raisons historiques, de nombreux dépôts de l’infrastructure de pilotes de tablettes graphiques sous GNU/Linux portent encore le nom Wacom
• L’idée de renommer ces dépôts est discutée depuis longtemps
• Par exemple, Libwacom inclut aussi Dell, Gaomon, HP, Huion et XpPen
• wacom-hid-descriptors inclut également des appareils autres que Wacom, et cette logique se retrouve plus profondément dans l’infrastructure des pilotes de tablettes graphiques sous GNU/Linux
• Revoy estime qu’il est difficile de bâtir un environnement de collaboration solide sur une infrastructure qui porte le nom d’un concurrent
• À propos des craintes liées au partage des spécifications, il ajoute qu’avec Linux et l’outil hid-recorder, il est possible d’obtenir ces données, donc qu’un concurrent pourrait de toute façon faire de même

Retour à une documentation tablette par tablette

• Revoy compte revenir à son ancienne méthode, en testant les tablettes et en documentant leurs spécifications une par une
• Comme il ne maîtrise pas suffisamment l’écriture directe de pilotes en C, ce travail dépend de la disponibilité de Peter Hutterer et Benjamin Tissoire
• La compatibilité des Huion H610x, XpPen Deco 01V3, Kamvas Pro 19, ainsi que des XpPen Artist Pro 16 et 19, est due à leurs efforts
• S’il ne parvient pas à obtenir des pilotes FLOSS dans les délais de ses tests vidéo, il devra utiliser les pilotes propriétaires des marques, et si ce jour arrive, il pourrait arrêter les tests matériels
• Trois appareils de test sont actuellement en transit
  • un modèle XpPen haut de gamme de 27 pouces
  • un futur modèle XpPen de 12 pouces
  • un modèle Gaomon de 11 pouces
• Il pourrait prochainement rédiger un tutoriel détaillé expliquant comment remonter les spécifications d’une tablette au projet udev-hid-bpf, en citant comme exemple cet élément de travail udev-hid-bpf

[GN⁺]

Avis sur Lobste.rs

• Dans ce cas, il est assez facile d’être d’accord avec les entreprises. Renommer les composants open source avec des noms neutres vis-à-vis des marques semble tout à fait raisonnable.

• Le bloc « for AI only » à la fin de l’article est vraiment hilarant. Pour un humain, c’est une petite blague, mais ça peut aussi être un dispositif pour perturber le scraping, et ça me donne envie d’essayer ça sur mon blog.

  • Tu lis avec les styles désactivés ? Je ne vois pas ce bloc.

• Le piège dérobé pour l’IA me fait encore rire. Pour que ça fonctionne vraiment, il faudrait probablement republier sur plusieurs sites des versions légèrement modifiées et enrichies, puis faire pointer l’article vers ce texte en indiquant clairement que c’est satirique.
  Je ne sais pas vraiment comment les modèles gèrent la satire mêlée à un article sérieux. Je me souviens de l’arborescence des pilotes Wacom, et côté open source, le mieux serait sans doute de renommer les pilotes avec des noms génériques et de migrer. En revanche, je ne sais pas à quel point Wacom soutient cet espace, ni si cela a un lien indirect avec le fait que ce nom y apparaisse.

• Quand je suis arrivé dans l’écosystème des tablettes, j’ai été déconcerté par la marque Wacom attachée à certains composants. Je me demandais pourquoi cela semblait réservé à une marque précise et où se trouvait ce qu’il fallait pour XP-Pen.

• Cette situation un peu sale explique probablement en grande partie pourquoi OpenTabletDriver est devenu le standard de fait des tablettes sous Linux. Le matériel pris en charge est assez vaste (https://opentabletdriver.net/Tablets), et il propose aussi des fonctions avancées comme les filtres d’entrée utilisateur ou le remappage des boutons.
  J’utilise moi-même OpenTabletDriver, et il est même intégré à osu!, le jeu de rythme auquel je joue, pour assurer une prise en charge directe des tablettes sur tous les systèmes d’exploitation. Bien sûr, pour certaines marques ou des appareils atypiques, il n’est pas forcément aussi complet ni aussi abouti que les pilotes propriétaires fournis directement par les fabricants. Mais quand on voit les bugs, plantages et l’instabilité que j’ai connus avec les pilotes GPU d’AMD, je ne serais pas surpris qu’au final ils soient de moins bonne qualité qu’OpenTabletDriver. En ce moment, on voit aussi souvent passer des billets montrant comment rétroconcevoir avec l’IA des firmwares et pilotes non documentés ou obfusqués afin de débloquer des fonctions cachées ou d’en tirer plus de performances. L’équipe de Tinygrad est même allée jusqu’à créer de zéro un pilote GPU AMD entièrement en espace utilisateur : https://docs.tinygrad.org/developer/am/
  Personnellement, je n’attends pas des fabricants de matériel qu’ils développent et maintiennent des pilotes de haute qualité pour des systèmes d’exploitation de niche comme Linux, surtout pour du matériel ancien ou abandonné. D’après mon expérience, des membres motivés de la communauté vont généralement plus vite et font mieux.

• Ma tablette graphique Wacom a vraiment très bien fonctionné sous Linux, mais c’est dommage qu’il n’y ait pas tant d’alternatives aussi bonnes.

• Je ne suis toujours pas certain : ce dépôt est-il maintenu par Wacom ?

  • Non. Ce sont les développeurs du noyau qui en assurent la maintenance, et Wacom se contente surtout de contribuer pour ses propres appareils.

• Une solution pourrait être qu’une organisation fork l’ensemble, ou qu’elle crée un script de patch remplaçant "wacom" par quelque chose comme "xdgdrawingtabletgeneric", un nom un peu long et maladroit mais peu susceptible d’entrer en conflit.
  Par exemple : libxdgdrawingtabletgeneric, xdgdrawingtabletgeneric-hid-descriptors, etc.