Journal Patch pwc pour le support des webcams Philips

Posté par  (site web personnel) .
Étiquettes : aucune
0
28
août
2004
Le driver Philips a donc bien été retiré du kernel, depuis la version 2.6.9-rc1-bk3 pour être précis. J'ai décidé de faire un patch pour combler ce manque, rien de bien compliqué en fait. J'ai simplifié le bouzin pour n'avoir plus que:

a. Un patch contre le kernel courant contenant tout le code libre
b. Le module libpwcx.a propriétaire (un pour chaque architecture)

L'installation est donc plus simple qu'avant, avec un patch à appliquer, et, optionnellement, un seul fichier à copier.

Je pense ne pas avoir de problèmes à redistribuer les libpwcx.a mais je serais content d'avoir votre avis.

Les fichiers se trouvent ici: http://cercle-daejeon.homelinux.org/linux/(...)

Pour appliquer le patch sur les nouveaux kernels:

$ cd /usr/src/linux
$ zcat /path/to/pwc-20040828.diff.gz | patch -p1

Si vous voulez pwcx (par exemple pour x86):

$ tar xvfj libpwcx-20040828.tar.bz2
$ cp libpwcx-20040828/x86/libpwcx.a /usr/src/linux/drivers/usb/media

Puis recompilez votre kernel (ou seulement les modules)

Si vous êtes encore en manque de modules pour votre kernel, vous trouverez également sur cette page une version modifiée de cloop qui compile avec les nouveaux noyaux 2.6 et une liste (à compléter) des architectures supportées par la série du 2.6

  • # discussion sur le pourquoi du format binaire

    Posté par  . Évalué à 10.

    Sur la mailing list des developpeurs du kernel, des personnes emettent l'hypothese que l'utilisation d'un binaire par Philips viserait à cacher les spécifications techniques réelles des webcams (cf. thread "reverse engineering pwcx" sur le newsgroup linux.kernel).

    http://groups.google.fr/groups?hl=fr&lr=&ie=UTF-8&threa(...)

    L'idée exposée est que les 640x480 de l'image sont obtenus par interpolation, et que l'argument marketing de Philips ("True 640x480 webcam") ne correspondrait pas à la réalité, ou bien seulement dans le cas d'image fixe ("snapshot").

    Pour certains, cela expliquerait que le developpeur de "pwc" n'a pas voulu publier les sources du binaire, malgré l'arrivée à terme du NDA (Non Disclosure Agreement) qui le liait à Philips. Le developpeur aurait déclaré ne pas souhaité trahir la confiance de Philips en faisant cela. Serait-ce parce que Philips aurait été mis dans l'embarras?

    Cette idée serait étayée par des arguments tels que la trés petite taille du code contenu dans le binaire, qui ne permettrait pas d'implementer des algorithmes de compression trés compliqués, alors même que la bande passante de l'USB 1.1 ne serait pas suffisante pour atteindre cette resolution avec de la video non compressee (rapport 15:1).

    Le reste de la thread cherche à determiner la veracité de ces assertions. L'idée d'une reimplementation open-source du driver semble faire son chemin, car le reverse engineering du driver y est qualifié de relativement aisé.

    De nombreux linuxiens pensent que Ati et Nvidia ne publient pas de drivers open-sources car leurs codes reveleraient (au conditionnel) des tricheries, et des optimisations dégradant la qualité de la video. Il serait ironique que ce soit Philips, un fabricant tiers, qui soit touché le premier par la revelation de telles pratiques, moralement repréhensibles.

    On connaitra le fin mot de l'histoire et les specifications réelles des webcams lorsque le driver open-source aura été réalisé. Ou quand Philips decidera de publier les sources de son driver.


    David.



    PS: (j'aurais bien posté cette information dans un nouveau journal, mais le système de score/expérience ne me le permet pas).

    • [^] # Re: discussion sur le pourquoi du format binaire

      Posté par  . Évalué à 4.

      je peux le poster pour toi si tu veux...

      Je trolle dès quand ça parle business, sécurité et sciences sociales

    • [^] # Re: discussion sur le pourquoi du format binaire

      Posté par  . Évalué à 2.

      >De nombreux linuxiens pensent que Ati et Nvidia ne publient pas de drivers >open-sources car leurs codes reveleraient (au conditionnel) des tricheries, et des >optimisations dégradant la qualité de la video.


      Je crois que le conditionnel sera amené a disparaitre, au mois de mai on apprennait que Nvidia "trichait" afin d'ameliorer les performances aux benchmarks grace a un algorithme de filtrage trilineaire, immiter peu de temps apres par ATI.(Nvidia et ATI preferant parler "d'optimisations")
      (la reponse d'ATI aux accusations ici : http://www.hardware.fr/news/email/6585/(...) )
      La supercherie residait dans les pilotes, donc ce n'est pas idiot de penser qu'il puisse s'y cacher d'autres "astuces", et pas forcement des "secrets technologiques" comme on veut nous le faire croire.

      --
      TiTiX

    • [^] # Re: discussion sur le pourquoi du format binaire

      Posté par  (site web personnel) . Évalué à 10.

      L'idée exposée est que les 640x480 de l'image sont obtenus par interpolation, et que l'argument marketing de Philips ("True 640x480 webcam") ne correspondrait pas à la réalité, ou bien seulement dans le cas d'image fixe ("snapshot").

      C'est intéressant mais attention. D'abord le driver supporte beaucoup de caméras ayant des spécifications différentes et provenant de constructeurs différents.

      Si Philips voulait cacher des choses avec un driver, c'est quand même extremement bizarre que le-dit driver fonctionne également chez les concurrents Logitech, Creative, Samsung et cie. Certes, c'est la même famille de chipset, mais se sont-ils tous mis d'accord ? L'argument marketing ne peut donc pas tellement se défendre.

      Les CCDs utilisés dans ces webcams ont des tailles également différentes. Par exemple, la ToUcam XS PCVC720K a un CCD de résolution 352x288. La Vesta Pro PCVC680K fait 640x480 (capteur Sony ICX098AK ou ICX098BQ). Bien entendu, on va avoir de l'interpolation dans le premier cas. Mais dans le deuxième, quel est l'intérêt de :

      1. Mettre un capteur 640x480 qui coûte plus cher
      2. Faire une acquisition en plus faible résolution
      3. Proposer un driver qui ré-interpole en 640x480

      Sacrifier la qualité pour avoir plus de débit ?

      Bah non, ce n'est pas ce qu'on observe justement. Le débit est en fait le point faible de ce type de caméra. Si on augmente les FPS, on observe des dédoublements de frame parce que le système ne suit pas. En outre, ce n'est pas directement imputable à la caméra, il y a d'autres paramètres comme la luminosité du sujet, l'USB, le système d'exploitation ou le disque dur. Une webcam n'est pas prévue pour faire de la vidéo haut débit.

      Pour avoir fait énormément d'acquisition vidéo avec une Vesta Pro (photos astro), je peux dire honnêtement qu'il n'y a pas de différences de qualité entre une image fixe et une frame issue d'une séquence faite avec cette caméra. En revanche, ça ne sert à rien d'aller à plus de 5 images/s en faible luminosité car le débit ne suit plus.

      Concernant la taille du code, et bien le code est probablement de l'assembleur et il y a un décompresseur pour chaque architecture ce qui réduit d'autant sa taille. Ça ne me gène pas plus que ça.

      Pour finir, je voudrais quand même rappeler qu'une webcam a une utilisation spécifique, où le plus important est la netteté de l'image, le respect des couleurs et la définition. On n'est pas sensé filmer les 24h du Mans avec. Il n'y a vraisemblablement pas d'algo de compression de la morkitu dans pwcx, ni de bidouilles malhonnêtes.

      On peut critiquer Philips à cause de la partie du driver qui est resté propriétaire, probablement, et comme bien souvent, afin de garder un certain contrôle sur le matériel. Mais nous disposons quand même d'un driver libre très bien fignolé depuis plusieurs années.

    • [^] # Re: discussion sur le pourquoi du format binaire

      Posté par  (site web personnel) . Évalué à 1.

      Quelqu'un pourrait extraire une image avec ce type de webcam,
      puis afficher les histogrammes (N&B, R, V, B)?
      On va vite voir que les images sont compréssées avec perte,
      ne serais-ce qu'au niveau des couleurs.

  • # Dommage...

    Posté par  (site web personnel) . Évalué à 1.

    C'est vraiment dommage qu'ils aient retiré pwc des futurs kernels. Même si les dévs du kernel n'étaient pas d'accord avec cette histoire de hook machin truc (trop technique pour moi, désolé :) et bien il n'avait qu'à garder que la partie purement GPL en y enlevant les mécanismes permettant d'y coller la partie binaire (si c'était réllement ça qui les gênait).

    Il faut espèrer que ce driver fera son retour assez rapidement dans le kernel car sinon, beaucoup d'utilisateurs risquent de se retrouver avec une webcam qui ne leur sert plus à rien (et après, allez expliquer à un newbie qu'avec l'open source et bien son matos il fonctionnera encore dans 10 ans parce que ses specs sont connues...).

    Et si on doit attendre un peu pour avoir, au final, un driver qui est l'équivalent de pwc+pwcx réunis alors que les dévs prennent tout leur temps :).

    • [^] # Re: Dommage...

      Posté par  . Évalué à 4.

      et après, allez expliquer à un newbie qu'avec l'open source et bien son matos il fonctionnera encore dans 10 ans parce que ses specs sont connues...).


      Je cois que la reponse est comptenue dans la question.
      pour les webcam en question la partie du driver en binaire fait que toutes les spec ne sont pas connues.....

      Il faut utiliser se genre de 'bidouille' (moitier GPL moitier binaire) en sachant qu'au final il se pourrait qu'il ne reste que la partie GPL, si le proprietaire des binaires ne veutplus supporter son driver .....)

      -> quand tu achetes une ATI / NVIDIA, meme si le binaire disparait, tu pourras encore utiliser ces cartes avec le pilote GPL, mais pour les webcam, winmodem et autre, c'est pas pareil .....

    • [^] # Re: Dommage...

      Posté par  . Évalué à 5.

      et bien il n'avait qu'à garder que la partie purement GPL en y enlevant les mécanismes permettant d'y coller la partie binaire (si c'était réllement ça qui les gênait).

      C'est exactement ce qui a été proposé par le mainteneur : "I just realized that I have to rip this hook out. I say this because we are allowing a change to the kernel that is needed _only_ for a closed source module." (cf http://lkml.org/lkml/2004/8/24/278(...) )

      Du coup, le dev de pwc a pris la mouche, et c'est _lui_ qui a demandé que le code soit enlevé du noyau:
      "In case the answer is "No", then I will:
      - demand that the PWC driver is removed from any further Linux kernel releases; Open source or not, it's still _my_ work."       ...

      Vala vala

Suivre le flux des commentaires

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