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

• # quel hardware ?

  Posté par ploum (site web personnel, Mastodon) le 27 mai 2009 à 11:21. É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)

  Mes livres CC By-SA : https://ploum.net/livres.html

  • [^] # Re: quel hardware ?

    Posté par David Sporn (site web personnel) le 27 mai 2009 à 13:37. É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 Mr Kapouik (site web personnel) le 27 mai 2009 à 12:47. Évalué à -2.

  

  Ca aurait pu être intéressant pour les Unix libre autre que linux ...

  • [^] # Re: Dommage ...

    Posté par David Sporn (site web personnel) le 27 mai 2009 à 13:49. É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 Mr Kapouik (site web personnel) le 28 mai 2009 à 00:31. É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 David Sporn (site web personnel) le 28 mai 2009 à 12:15. É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 grid le 27 mai 2009 à 18:07. É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 bibitte le 27 mai 2009 à 20:58. É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 David Sporn (site web personnel) le 28 mai 2009 à 00:16. É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.