Journal Nouvelle version de hidtouch, pilote xorg pour les écrans tactiles USB/HID

Posté par (page perso) .
Tags : aucun
9
27
mai
2009
Bonjour,

Depuis mon dernier journal sur le sujet, j'ai implémenté un meilleur positionnement, basé sur les données émises par le périphérique aux quatre coins de l'écran.

Il y a maintenant un utilitaire en ligne de commande pour examiner (et ainsi collecter) les données émises par un périphérique, et le manuel -en anglais- est relativement décent.

Le projet est désormais hébergé (CVS, téléchargement) sur SourceForge.

Concernant la licence, après avoir réfléchi à l'éventualité d'une double licence afin de permettre une éventuelle intégration dans xorg, j'ai décidé de m'en tenir à la GPL (ma licence préférée pour un logiciel libre) car mes conventions de codage sont résolument incompatibles avec celles de xorg.

Pour télécharger le pilote :
http://www.sporniket-studio.com/page/200905260800

La page du projet sourceforge :
http://sourceforge.net/projects/hidtouchsuite/
  • # quel hardware ?

    Posté par (page perso) . Évalué à 4.

    Ça fonctionne avec quel hardware ? J'ai une poignée de touchscreen au boulot et c'est la galère pour les faire fonctionner et les calibrer. Je n'ai toujours pas réussi à faire du glisser/déposer avec d'ailleurs.

    (pour info, ils s'identifient tous comme eGalax)
    • [^] # Re: quel hardware ?

      Posté par (page perso) . Évalué à 2.

      Le pilote a été testé sur une coque Clévo TN120R équipé d'un touch-screen UT4M de ET&T (et pour cause, c'est pour ça que j'ai du l'écrire...)

      À priori, ça fonctionne si les conditions suivantes sont remplies :
      - un node 'hiddevX' (X étant un nombre) est créé pour le périphérique
      - les coordonnées X, Y et la pression sont envoyés dans des rapports hid de code différent (utiliser l'utiliter 'hidDeviceDump', à télécharger)

      0n ne gère pas de niveau de pression, on ne s'intéresse qu'au fait que la valeur soit nulle ou pas.
  • # Domage ...

    Posté par (page perso) . Évalué à -2.

    Ca aurait pu être intéressant pour les Unix libre autre que linux ...
    • [^] # Re: Dommage ...

      Posté par (page perso) . Évalué à 5.

      Dans le meilleur des cas, l'utilisateur d'un tel système n'a qu'à compiler le code du pilote.

      Dans des cas moins bon, il peut adapter le code à son système (ou engager quelqu'un pour le faire).

      Ce n'est pas comme si je diffusais un blob binaire.
      • [^] # Re: Dommage ...

        Posté par (page perso) . Évalué à 3.

        J'ai beau détester les blobs binaires, ils ont au moins le mérite que quand ils sont redistribuables, ils n'obligent pas le packageur a migrer tout xorg et les éventuel lib utilisé sous GPL v3 sinon il y a un viol de licence. Bref ton code en plus de ne pas être intégrable dans xorg n'est pas packagable.

        Sinon il n'y a rien à adapter sur un drivers xorg vu que c'est xorg lui même qui fait l'interface avec la couche inférieur. Sauf si tu fait des appels kernel ou à la glibc.

        Et puis c'est tellement plus simple de dire : il n'a qu'a le compiler ... bah oui tiens si je suis sur OpenBSD, OpenSolaris ou même un Unix propriétaire c'est que forcement je suis un guru unix qui compile son café au petit déjeuné donc il ne faut surtout pas envisager qu'une équipe de développeur me facilite le travail.
        • [^] # Re: Dommage ...

          Posté par (page perso) . Évalué à 1.

          Pour accéder au périphérique, j'ouvre le node de celui-ci (par exemple /dev/hiddev0) et je récupère les données.

          Ce node et les données dépendent du noyau, pas de xorg.

          Quant aux librairies xorg et autres, ils s'agit de librairies ''systèmes'' et donc n'ont pas besoin d'être incluses dans mon package.
  • # bof

    Posté par (page perso) . Évalué à 7.

    >> j'ai décidé de m'en tenir à la GPL car mes conventions de codage sont résolument incompatibles avec celles de xorg.

    C'est une très mauvaise raison.

    en relisant les anciens journaux, on croit deviner que la vraie raison n'est pas là.

    Le choix de la GPL empêche l'inclusion upstream. L'intégration dans xorg est la MEILLEURE ASSURANCE pour tes utilisateurs.

    Si ce pilote a l'air intéressant (et à son utilité), il faudra de toute façon que quelqu'un le refasse le boulot

    Donc si j'étais jury pour ce projet, je mettrais :
    En note technique : 10/10
    En note esprit communautaire : 5/10

    Pour rappel; même RMS a modifié la licence pour arranger wikipedia.
    Appliquer une licence est un moyen, pas un but en soit.

    Sinon, bon courage à toi.
  • # juste une question..

    Posté par . Évalué à 5.

    car mes conventions de codage sont résolument incompatibles avec celles de xorg.

    sans réellement en connaître les motifs je trouve ca dommage que juste pour une raison de convention de codage ton projet ne puisse pas être repris dans xorg.

    Sinon voici ma question :
    Je ne connais pas les convention de codage de Xorg, elle consiste en quoi, et en quoi cela te pose un problème de s'adapter ?
    • [^] # Re: juste une question..

      Posté par (page perso) . Évalué à 1.

      xorg utilise la convention suivante : la 'casse de chameau' (CamelCase) et la restriction à 78 caractères par ligne.

      J'utilise un mélange de 'casse de chameau' et des '__' (double souligné). J'utilise les doubles soulignés pour simuler les espaces de nom et les classes (on est en C).

      Cette écriture rend les identifiants des fonctions et des symboles très longs, verbeux même, de sorte que la limitation à 78 caractères pourrait se révéler inapplicable de temps à autres.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.