Nouveau rebondissement dans l'affaire du pilote PWC

Posté par  (site web personnel) . Modéré par Nÿco.
1
31
mai
2005
Noyau
Le début de l'affaire du pilote pwc remonte à août 2004. Jusqu'à cette époque, la partie libre de ce pilote pour webcams basés sur des chipsets Philips était disponible dans la version officielle du noyau Linux. Toutefois, ce pilote ne permettait de gérer que les modes de basse qualité des webcams, un module supplémentaire propriétaire, pwcx, étant nécessaire pour accéder aux modes évolués qui nécessitaient des routines de décompression.

En août 2004, un différent opposa les développeurs du noyau Linux au développeur du pilote. En effet, le module libre mettait en place un hook spécifique dans le noyau permettant au module non-libre de mettre à disposition ses fonctionnalités avancées de décompression. Or, les développeurs noyau, et en particulier Linus Torvalds, ne souhaitaient pas mettre à disposition un hook particulier pour les besoins d'un module propriétaire : "if a change is needed to be made to the kernel in order to get a closed source module to work, that module must be made opensource".

L'auteur du pilote a alors fait savoir que ce hook existait depuis longtemps et qu'il ne comprenait pas cette décision. Au final, la discussion a amené l'auteur à demander le retrait du pilote.

Le noyau Linux ne disposait alors plus de pilote pour les webcams à base de composants Philips, pourtant très répandues. Heureusement, un français, Luc Saillard, a repris le développement de ce dernier. À la mi-septembre 2004, il envoie un patch contenant une nouvelle version du pilote, entièrement libre, et permettant d'utiliser certains modes de décompression qui n'étaient auparavant utilisables qu'avec le module propriétaire, grâce à de l'ingénierie inverse. Tout semblait donc s'arranger.

Mais, tout récemment, nouveau coup de théâtre : le développeur originel du pilote demande de nouveau le retrait de ce dernier, arguant du fait que le pilote de Luc Saillard aurait été réalisé plus par décompilation du pilote propriétaire que par ingénierie inverse. Après une investigation plus poussée, Alan Cox a trouvé que les remarques de l'auteur originel étaient recevables. Il a par ailleurs eu une discussion amicale avec Philips qui a abouti au retrait du code litigieux des décompresseurs.

À ce jour, le noyau Linux supporte donc toujours les webcams à base de composants Philips, mais uniquement dans les modes basiques. Toutefois, ce rebondissement n'est certainement pas le dernier dans cette saga, et l'espoir de disposer un jour d'un pilote complètement libre et dégagé de tout problème reste présent.

Aller plus loin

  • # Décidément

    Posté par  . Évalué à 6.

    Sauf erreur de ma part, c'est à cause d'un certain procédé de compression qu'une partie du pilote n'est pas libérée par Philips.

    Je ne pense qu'on verra ce pilote se libérer si Philips veut garder cet algorithme de compression et quelque part il y a une certaine logique.

    Donc à mon avis la vraie question c'est si Philips va libérer ou non ce procédé de compression....
    • [^] # Re: Décidément

      Posté par  . Évalué à 8.

      Non, la vraie question c'est :

      quand est-ce qu'un constructeur malin verra tout l'intérêt qu'il y a à développer un pilote linux, soit-il propriétaire, pour ses webcams ?

      Perso, si un seul constructeur s'y met, j'achète direct sa webcam, et je fais de la pub auprès de mes amis, collègues, pour son produit.

      Les gens linux se jettent sur les cartes NVIDIA parce que leur pilote est facile à installer, fonctionne, et est clairement supporté.

      Faut vraiment être bête pour ne pas voir l'intérêt qu'il y a à se lancer là-dedans, alors que sous Windows, la concurrence est acharnée et l'utilisateur lambda est face à une myriade de fabricants de webcam.

      Le premier fabricant qui fera un pilote linux efficace pour sa webcam, sera, le seul et unique sur le marché, et se fera des nuts en or :p
      • [^] # Re: Décidément

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

        bête ? bof.
        Le portage d'un driver qui n'a pas été fait pour être porté ça peut prendre des ressources. Les webcam ce n'est pas quelque chose de très cher. Les linuxiens sont aussi probablement moins succeptibles d'acheter une webcam que monsieur tout le monde (si j'en crois mon entourage).
        Vu le nombre de gens avec un linux en desktop, tu m'excuseras mais c'est pas si évident que ce soit si rentable que ça si derrière il faut assurer le suivi, les correctifs et l'évolution avec le noyeau.

        Nvidia le fait mais ils ont déjà un secteur plus répandu (tout le monde a une carte graphique), plus rémunérateur (vu le prix des cartes) et beaucoup plus concurrentiel (on choisit la marque avant la carte en général, pour les webcam ça m'étonnerait).

        Tu as peut être (probablement) raison sur le fait que ce soit une bonne idée pour le constructeur, mais c'est loin d'être aussi binaire que ça.
        • [^] # Re: Décidément

          Posté par  . Évalué à 7.

          Certes, mon commentaire était un peu restrictif, mais si tu regardes le nombre de gens qui utilisent des messageries instantanées, qui utilisent par ailleurs leur webcam, et si tu prends en compte le prochain passage de Skype à la video (il serait le premier à fonctionner efficacement sous Windows, Linux, et autres),
          l'intérêt est loin d'être négligeable.

          Par ailleurs, tu prends un peu le pb à l'envers. Encore une fois, les gens ne sont que peu sous un Desktop linux, car certaines choses que les gens demandent à un desktop ne sont pas encore disponibles, ou facilement accessibles sous Linux : la webcam en fait partie, mais je parle également des jeux (des mauvaises langues diront que les jeux n'ont rien à faire avec le terme "desktop").

          C dommage d'être obligé de quitter son nunux et d'aller sous Windows, quand on veut faire FACILEMENT de la visio et du chat avec des gens qui sont en grande majorité sous MSN messenger.

          Enfin, on verra ce qui se passera.

          S'il y a un constructeur malin, ou pas....
          • [^] # Re: Décidément

            Posté par  . Évalué à 7.

            nan, le constructeur malin, il developpe pour windows et il renvoie chier les linuxiens. Le jour ou linux atteint un seuil critique, il libere son pilote, laisse les devel du libre le porter et colle ensuite un logo linux friendly sur ses boites.
            tout benef pour pas cher.

            Je suis plutot d'accord avec le commentaire precedent, si c'etait vraiment si trivial, ils le feraient, t'inquietes pas qu'ils ont du se poser la question de savoir si c'etait rentable ou pas pour eux.
            Tout comme le jour ou ca serait vraiment rentable de fourguer des linux preinstalles sur des machines de desktop, on trouvera facilement des machines linux preinstallees pour le desktop.

            patience, jeune padawan.
            • [^] # Re: Décidément

              Posté par  . Évalué à 9.

              Le jour ou linux atteint un seuil critique, il libere son pilote, laisse les devel du libre le porter

              Le problème, c'est pourquoi attendre un "seuil critique" ?

              Publier des specs n'est pas un travail énorme (comparé au développement lui-même, et dans la mesure où ces specs existent forcément en interne) et effectivement la communauté fera le boulot. Elle le fera de toute façon si elle en a vraiment besoin, mais la grosse différence c'est l'image de marque du constructeur (surtout si "il renvoie chier les linuxiens"). Je pense que les constructeurs sous-estiment la communication dans la communauté, une bonne ou une mauvaise pub circule très vite (à la vitesse du troll au galop, en fait).

              En ce qui concerne les concurrents qui auraient ainsi accès au design, ne vous en faites pas, ils l'ont déjà : eux aussi ils font du reverse-engineering, et pas avec des moyens amateurs.

              Quant à savoir si c'est rentable, encore faudrait-il avoir des chiffes fiables concernant le nombre d'utilisateurs de GNU/Linux (et BSD, Hurd, Minix ...) pour parler de parts de marché, et prendre en compte tous ceux qui ne passent pas au Libre parce que leur périphérique chéri n'est pas (bien) supporté ...

              Finalement, je ne sais pas si "malin" est le bon adjectif ...
              • [^] # Re: Décidément

                Posté par  . Évalué à -2.

                Je pense que les constructeurs sous-estiment la communication dans la communauté, une bonne ou une mauvaise pub circule très vite (à la vitesse du troll au galop, en fait).
                ca se deplace vite, oui, mais dans une communaute de quelle taille? et encore, combien de personnes susceptibles d'acheter une webcam parmi elle?

                Quant à savoir si c'est rentable, encore faudrait-il avoir des chiffes fiables concernant le nombre d'utilisateurs de GNU/Linux (et BSD, Hurd, Minix ...)
                mouhahahaha, t'es serieux quand tu cites hurd et minix? remarque, meme bsd deja...
                ceux qui ne passent pas au libre, on s'en fout, ils ont deja achete leur cam pour windows.
                et les autres sont visiblement trop peu nombreux, sinon philips et ses potes ne cracheraient pas sur leur argent.
                • [^] # Re: Décidément

                  Posté par  . Évalué à 2.

                  dans une communaute de quelle taille ?
                  Justement, c'est la question que je pose juste après ...

                  ceux qui ne passent pas au libre, on s'en fout, ils ont deja achete leur cam pour windows
                  La question qu'on peut se poser, c'est la raison qu'ont ceux qui restent avec un système onéreux, buggé et liberticide alors que l'alternative existe. Il y a entre autre le manque d'information/pub, la réticence au changement, les formats fermés et effectivement le manque de support pour certains périphériques.
                  Je considère qu'on ne s'en fout absolument pas, et qu'il y a sans doute des gens qui n'utilisent pas Linux juste parceque leur webcam ne marche pas avec ! Tu essayes de promouvoir les logiciels libres, ou de faire fuir les newbies ?

                  trop peu nombreux, sinon philips et ses potes ne cracheraient pas sur leur argent.
                  [Ca me rappelle la devise du Virus Informatique. 50G mouches ne peuvent pas _toutes_ avoir tort !]
                  Là aussi, qu'est-ce qui prouve que leur estimation du marché est juste ? Le nombre d'utilisateurs de Linux est bien moins facile à mesurer que les profits de M$ ! Et ces paramètres sont liés : si les fabricants étaient plus coopératifs, ca encouragerait les gens à utiliser les logiciels libres, et réciproquement.
                  • [^] # Re: Décidément

                    Posté par  . Évalué à 0.

                    Tu essayes de promouvoir les logiciels libres, ou de faire fuir les newbies ?

                    Mais t'es contre moi ou avec eux?!?
                    heuuu non.. ca doit pas etre ca.. je recommence

                    Soit t'es provincial, soit t'es provencal.
                    merde, non plus.

                    Nous sommes en guerre, dont l'issue ne peut etre autre que l'eradication complete de l'adversaire, si tu n'es pas avec nous, tu es contre nous.
                    aaaah, voila, a y est j'ai trouve.

                    Je ne fait aucune promotion (enfin, si, ponctuellement, quand on me demande mon avis et que c'est justifie) pour la simple et bonne raison que je n'ai pas envie d'emmerder les gens avec des choses qui ne les interessent pas (tout comme ca m'emmerde quand on me fait de la pub sur un truc dont je n'ai rien a battre).

                    En passant, le "on s'en fout" etait une tournure de style ou le sujet de la phrase represente Phillips.

                    La question qu'on peut se poser, c'est la raison qu'ont ceux qui restent avec un système onéreux, buggé et liberticide alors que l'alternative existe. Il y a entre autre le manque d'information/pub, la réticence au changement, les formats fermés et effectivement le manque de support pour certains périphériques.
                    Bon, j'ai pas specialement envie de commencer un troll la dessus, mais ca t'a jamais traverse l'esprit que certaines personnes peuvent apprecier Windows et ne pas avoir envie du tout de chambouler leurs habitudes pour au final avoir grosso modo la meme utilisation de leur machine?
            • [^] # Re: Décidément

              Posté par  . Évalué à 9.

              > nan, le constructeur malin, il developpe pour windows et il renvoie chier les linuxiens. Le jour ou linux atteint un seuil critique, il libere son pilote, laisse les devel du libre
              > le porter et colle ensuite un logo linux friendly sur ses boites.
              > tout benef pour pas cher.

              Vous êtes trop marrant à diaboliser les constructeurs.
              Certes ils font pas toujours le meilleur boulot, mais la première chose à faire si vous voulez un jour une meilleure intégration des périphériques dans linux c'est bien de commencer par les considerer commes des éventuels partenaires et non comme des traitres à la solde de Windaube.

              Ensuite, contrairement aux votes et moinssages, je suis désolé mais il y a quand même un certain nombres d'utilisateurs desktop linux que ça saoule de pas avoir de bon systeme de video conf compatible avec le monde windows. G mm du faire un vilain hack au driver de ma webcam pour pouvoir l'utiliser ds v4l...

              D'autre part, vous n'imaginez pas l'effet sur mes corespondants MSN windaube qd je leur dit le classique 'non dsl je px pas faire de video là chuis ss linux et g pas le tps de tt configurer...".

              Bref, soi on accepte clairement que linux reste un system perché reservé aux initiées qui font tout en console ss emacs, soit on veut ouvrir le système à d'autres utilisateurs et alors il faut penser aussi à leurs besoins, qu'ils soient constructeurs ou consommateurs.

              Romain
              • [^] # Re: Décidément

                Posté par  . Évalué à 4.

                D'autre part, vous n'imaginez pas l'effet sur mes corespondants MSN windaube qd je leur dit le classique 'non dsl je px pas faire de video là chuis ss linux et g pas le tps de tt configurer...".

                autre excuse :
                non desole microsoft ne veux pas liberer son protocole, et donc c'est beaucoup plus dur a faire marcher sous linux.
                Et paf c'est plus linux qui ne sait meme pas comment faire marcher une webcam ; mais microsoft qui empeche les utilisateurs de tutux a pouvoir utiliser leurs logiciels.
                L'histoire du verre a moitie plein et a moitie vide...

                oui tu dis pas toute la veritee , mais accessoirement si ils font des raccourcis comme ca ; qui t'en voudras?
              • [^] # Re: Décidément

                Posté par  . Évalué à 3.

                je ne diabolise rien et j'etais tout a fait serieux, c'est effectivement le comportement le plus "malin" qu'on puisse avoir.
                En renvoyant chier les utilisateurs, tu leur donnes envie de se demerder par eux meme, en liberant le pilote tu ne payes pas les couts de dev.
                resultat, tu bouffes a tous les rateliers et c'est tout benef pour le constructeur.
                Apres, je n'ai pas sous entendu, ni meme entendu que c'etait le comportement qu'avait les constructeurs.

                et j'ai n'ai pas l'habitude de parler de "windaube" (sauf quand je parle de win98, mais en 2005, ca devient de moins en moins frequent).
      • [^] # Re: Décidément

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

        Les gens linux se jettent sur les cartes NVIDIA parce que leur pilote est facile à installer, fonctionne, et est clairement supporté.

        Ça me semble assez contestable:
        . NVidia et ATI sont clairement leaders du marché, en raison, certainement, de la qualité de leur produit, des stratégies de distribution (OEM), du prix (lié à la distribution), etc
        . il devient difficile de trouver une carte autre que NVidia ou ATI chez les assembleurs de PC qui se tournent de plus en plus vers le jackyisme/jeu que vers l'informatique (d'ailleurs, nombreux sont ceux qui n'ont de disques SCSI que sur commande),
        . les drivers NVidia et ATI proprio sont sources d'un nombre de problèmes incroyables, ils sont pas faciles à installer ni à mettre à jour, ne sont pas souvent intégrés au système de gestion de paquetages, etc,
        . la société qui avait monté un projet de carte vidéo 'libre' a finalement laissé tomber, manque d'engouement certainement.

        En revanche, j'ai acheté une matrox Gxxx, car les drivers mga et mga_vid sont particulièrement performants, en raison de la publication des spécs. DirectFB en a fait bon usage d'ailleurs.
        J'ai aussi fait attention à l'achat de ma webcam, d'en prendre une supportée par les drivers ov51x.

        Bref, je suis plus intéressé par les fabricants publiant leurs spécs ou fournissant carrément des drivers libres (VIA pour le CLE266) que ceux faisant des drivers proprios.

        My 2 ¢.
        • [^] # Re: Décidément

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

          Matrox fourni encore des drivers libres et les specs de leurs cartes (je veut dire, meme les nouvelles ?)
          • [^] # Matrox

            Posté par  . Évalué à 0.

            Matrox, c'est bon pour les dinos. Va en trouver dans les magazins ! A part Ebay, ca va êtr dur.
            • [^] # Re: Matrox

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

              Y'a t'il alors un autre fabricant qui distribue une bonne carte avec toutes les specs ?
        • [^] # Re: Décidément

          Posté par  . Évalué à 5.

          > . la société qui avait monté un projet de carte vidéo 'libre' a finalement laissé tomber, manque d'engouement certainement.

          En fait la raison exacte est connue : d'après la news de fanf du 4 mai 2005 ( http://linuxfr.org/2005/05/04/18867.html(...) ), et plus précisément dans le mail d'annonce ( http://lists.duskglow.com/open-graphics/2005-May/003113.html(...) ) : << At that time, management decided that OGP would not be profitable within the time they wanted. >>

          Donc voilà, ils ont prédit un manque d'engouement dans les délais qu'ils s'étaient impartis, pour être précis.

          L'histoire ne dit pas (encore) s'ils ont eu raison, ni si leur décision est basée sur des études sérieuses.
          • [^] # Re: Décidément

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

            En attendant voici le message que j'ai envoyé à philips à cette adresse:
            http://www.feedback.philips.com/consumer/?country=FR&hlp=1&searchtxt=webcams&param1=&param2=&param3=&param4=&language=FR

            (Trouvée aprés avoir cherché simplement sur le site francophone de philips l'aide pour les webcam, il y a peut être un chemin plus court)

            ----------------------------------------------------------------

            Serait il un jour envisageable d'avoir des pilotes pour le système Linux pour vos produits et en particulier vos webcam.
            Comme l'illustre le débat à cette page :
            http://linuxfr.org/2005/05/31/19026.html
            Un tel pilote encouragerait l'achat de vos webcam, surtout s'il est libre, par la communauté des utilisateurs de logiciels libres.
            Je m'engage personnellement à en acheter une le jours ou vous publierez un pilote libre pour webcam sous GNU/Linux.
            ----------------------------------------------------------------------------

            C'est direct, c'est mieux que rouspeter dans son coin (je le fait aussi, toujours, avant de passer à l'action) et on sait jammais. Ça peut leur donner des idées.
            • [^] # Re: Décidément

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

              Voilà la réponse que je viens de recevoir de Philips:
              <<Cher Monsieur Smith,

              Merci de la confiance que vous portez à Philips.

              Récemment vous nous avez demandé des informations sur votre webcam.

              Concernant votre demande, nous sommes désolés mais nos produits ne sont pas supportés sous Linux.

              Je vous invite à consulter les sites spécialisés Linux pour y trouver potentiellement des pilotes développés par des passionnés.

              Nous espérons avoir répondu à votre question de façon satisfaisante.

              Votre numéro de référence est XS0206050213. (Veuillez inclure la totalité de l'e-mail en cas de futur contact.)

              Cordialement,

              Rodrigue Mocciola
              Philips Customer Care Centres >>

              On a vu mieux, mais on a vu pire aussi. Au moins ils ne sont pas contre le principe de l'existence de pilotes libres.
              Au fait. les spécifications necessaires à l'écriture d'un pilote sont elles publiées?
              • [^] # Re: Décidément

                Posté par  . Évalué à 4.

                Au fait. les spécifications necessaires à l'écriture d'un pilote sont elles publiées?

                Bien sûr que non, vu l'importance qu'a prise l'affaire, si c'était le cas il n'y aurait aucun problème.

                Pour ma part, j'apprécierais plus de pilotes libres fournis par les constructeurs, mais je pense que ça les regarde. Par contre, disposer des spécs des produits que j'achète ou m'engage à acheter si les specs vont avec, ça me semble légitime et je le demande souvent (sans succès).
              • [^] # Re: Décidément

                Posté par  . Évalué à 4.

                Je vous invite à consulter les sites spécialisés Linux pour y trouver potentiellement des pilotes développés par des passionnés.
                Réponds-leur que les passionnés t'ont vivement déconseillé d'acheter leur cam, et t'ont conseillé une webcam concurrente (si possible dont les specs sont connues)
                • [^] # Re: Décidément

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

                  Oui, mais il faudrait leur donner des exemples nominatifs de matériels et de marques. ils doivent connaitre le marché des webcams mieux que moi...

                  Voici le message que je leur ai envoyé en réponse hier, samedi 4 juin.
                  ( Je voulais attendre leur réponse pour en parler ici.)
                  -----------------------------------------------------------------------
                  Le développement de pilote libre nécessite la publication des spécifications complètes du matériel.
                  il semblerait que non seulement cette publication n'ai pas eu lieu, mais comme l'illustre la conversation citée en
                  http://linuxfr.org/2005/05/31/19026.html(...)
                  philips s'oppose à l'usage de certains procédés algorithmique de compression.
                  Ceux-ci n'étant pas en Europe couverts par les brevets, leur publication et l'autorisation de leur emploi pour réaliser des pilotes libres ne devrait pas poser de problème.
                  L'écriture de tels pilotes libres ne peut que favoriser la vente et la
                  réputation du matériel Philips.

                  Je vous prie donc de faire part de ma demande aux décideurs de votre
                  entreprise. Ce n'est pas une demande isolée. elle est représentative des
                  demandes de nombreux membres de la communautés du logiciel Libre.

                  ------------------------------------------------------------------------

                  Si je peux connaître des webcam qui plaisent aux geek parceque performante et avec des spécifications publiées ou un pilote libre, alors naturelement j'attirerai leur attention desus.
                  • [^] # Re: Décidément

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

                    Voici déjà ce que j'ai pu apprendre sur le site de mandriva, ex mandrakesoft, où on peut consulter une base de donnée de matériel compatible. Bien sùr ce n'est qu'indicatif.

                    CREATIVE LABS Webcam NX pro (Mandrakelinux 10.1, x86) Compatible

                    LOGITECH Quickam Express (Mandrakelinux 10.1, x86) Compatible

                    LOGITECH Quickam web (Mandrakelinux 10.1, x86) Compatible

                    LOGITECH Quickcam Pro 4000 (Mandrakelinux 10.1, x86) Compatible

                    PHILIPS ToUcam Pro II (Mandrakelinux 10.1, x86) Compatible

                    Apparement il n'y a de pilotes GNU/Linux chez aucun fabricant.
                    Ne parlons pas de pilotes libres.

                    Je vais quand même les démarcher à ce sujet.
                    L'un d'entre eux finira peut être par comprendre qu'i peut gagner un avantage concurentiel en étant pleinement compatible Linux, et/ou en laissant écrire un pilote libre.
  • # la decompilation c'est interdit ?

    Posté par  . Évalué à 8.

    "Mais, tout récemment, nouveau coup de théâtre : le développeur originel du pilote demande de nouveau le retrait de ce dernier, arguant du fait que le pilote de Luc Saillard aurait été réalisé plus par décompilation du pilote propriétaire que par ingénierie inverse."

    La décompilation n'est elle pas la plus repandue des méthodes d'ingenierie inverse ? Je vois pas ce que peut etre l'ingenierie inverse pour un pilote de webcam.
    • [^] # Re: la decompilation c'est interdit ?

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

      Je crois que c'est interdit dans pas mal de pays ce procédé quand même : il y a une différence entre essayer de comprendre comment réagi un programme dans son environnement, et s'attaquer directement au binaire.
      Dans le deuxième cas il n'y a aucune recherche.

      Enfin c'est comme ça que moi, non programmeur, je le conçois.
    • [^] # Re: la decompilation c'est interdit ?

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

      On peut faire de l'ingénieurie inverse en examinant le comportement du driver propriétaire.

      D'autre part, la décompilation est *autorisée* par la loi française à des fins d'interopérabilité:

      http://europa.eu.int/smartapi/cgi/sga_doc?smartapi!celexapi!prod!CE(...)
      (voir notament 5.3 et 6)

      Il y a bien sûr des restrictions, mais c'est applicable.
      • [^] # Re: la decompilation c'est interdit ?

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

        Hum, c'est même applicable à l'*Europe*

        (Oui, c'est bien possible que ce soit interdit aux US, alors le driver libre n'est-il légal qu'en Europe ?)
      • [^] # Re: la decompilation c'est interdit ?

        Posté par  . Évalué à -1.

        "On peut faire de l'ingénieurie inverse en examinant le comportement du driver propriétaire."

        Et sur une webcam ou sur une carte graphique c'est quoi ce comportement, ca se passe où ? Que peut on observer si ce n'est les octets que l'on envoie/recoit de la carte graphique et qui sont lisibles seulement en décompilant.
        • [^] # Re: la decompilation c'est interdit ?

          Posté par  . Évalué à 3.

          Dans le cas d'une webcam USB, en utilisant un driver _USB_ qui sniffe le transfert entre le driver de la webcam et la webcam, c'est très fesable. (à mon avis, idem pour firewire)
          Pour une carte graphique, un peu moins :) (et pour un port série/parallèle, c'est les doigts dans le nez).
    • [^] # Re: la decompilation c'est interdit ?

      Posté par  . Évalué à 3.

      La décompilation n'est elle pas la plus repandue des méthodes d'ingenierie inverse ?
      bin si...mais le point de probleme c'est que cette pratique et le resultat obtenue est illegale dans un grand nombre de pays. Notemment les US et je ne vois pas le kernel contenir une version pour l'EU et une autre version pour les US. D'ailleur je crois bien que tout travail de reverse engenering est illegal la bas.
      Je vois pas ce que peut etre l'ingenierie inverse pour un pilote de webcam.
      Le pilote doit etre considerer comme une boite noire inviolable, on positionne une mire au plus pres du capteur ccmos on fait des acquisitions en compresser et d'autre en non compresser et on analyse les packets usb transitants sur le bus.
      Bon je penche qu'une bonne connaissance mathematique et des algos existant de compression d'image serait un plus...
      • [^] # Re: la decompilation c'est interdit ?

        Posté par  . Évalué à 10.

        je ne vois pas le kernel contenir une version pour l'EU et une autre version pour les US.
        Ce serait pourtant la meilleure chose à faire pour faire réaliser par tout le monde (les entreprises, les états, le marché) l'inanité de la situation et de ce fait, la faire évoluer, dans un sens ou dans l'autre.

        Après tout, il y a bien des briques logicielles interdites à l'exportation vers certains pays. Pourquoi ne donc pas faire des patches du kernel selon la situation légale de la zone juridique de sa distribution ?
        • [^] # Re: la decompilation c'est interdit ?

          Posté par  . Évalué à 7.

          je ne vois pas le kernel contenir une version pour l'EU et une autre version pour les US.
          Ce serait pourtant la meilleure chose à faire pour faire réaliser par tout le monde (les entreprises, les états, le marché) l'inanité de la situation et de ce fait, la faire évoluer, dans un sens ou dans l'autre.

          Que le Reverse Engineering soit interdit aux USA... c'est une chose.
          Je ne comprends pas que le résultat d'un travail de RE soit interdit. Et d'ailleurs, ca m'étonne que ce soit le cas. Tant que le droit d'auteur a été respecté, je ne vois pas où est le souci.
          A moins que ce soit une histoire de brevet sur les structures de données? Dans ce cas, il me semble que l'interopérabilité prend le pas sur le brevet? Bon... sur ce coup-là, je suis pas sûr... :-/ Quelqu'un a + de réponses que moi?
      • [^] # Re: la decompilation c'est interdit ?

        Posté par  . Évalué à 5.

        bin si...mais le point de probleme c'est que cette pratique et le resultat obtenue est illegale dans un grand nombre de pays. Notemment les US et je ne vois pas le kernel contenir une version pour l'EU et une autre version pour les US. D'ailleur je crois bien que tout travail de reverse engenering est illegal la bas.

        Pourtant c'est pas le seul pilote qui se trouve dans le noyau linux qui a ete RE.
        Y en a meme qui ont ete RE a partir de la description fournie par des brevets :
        drivers/input/joystick/sidewinder.c


        /*
        * sw_read_packet() is a function which reads either a data packet, or an
        * identification packet from a SideWinder joystick. The protocol is very,
        * very, very braindamaged. Microsoft patented it in US patent #5628686.
        */
      • [^] # Re: la decompilation c'est interdit ?

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

        > je ne vois pas le kernel contenir une version pour l'EU et une autre version pour les US

        Ca je comprend maintenant il faut choisir :

        - on respecte uniquement les lois qui sont là dans tous les pays (ou presque) et c'est à ceux qui ont un cas plus restrictif de ne compiler que ce qui convient. A priori ce n'est pas la solution choisie (l'europe est assez grande et importante dans le LL pour ne pas être dans le "ou presque")

        - on respecte à chaque fois le plus restrictif. Ca veut dire que si une loi interdit la crypto forte mais que c'est autorisé dans aux US on n'aura pas de crypto forte (la crypto n'est qu'un exemple). A priori ce n'est pas la solution retenue, même si on excepte les quelques pays de faible importance avec une législation hors norme.


        > le point de probleme c'est que cette pratique et le resultat obtenue est illegale
        > dans un grand nombre de pays.

        Sur ? moi j'ai l'impression que c'est parce que c'est illégal dans un grand nombre de pays ... dont les US. Je doute que la problématique aurait été la même sinon. En même temps je comprend tout à fait Linus et le choix fait, en même temps ça me gêne beaucoup que ce soit la loi US plus qu'une autre qui gère les LL.
  • # le développeur originel...

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

    C'est quand même un vieu grincheux je trouve, et non pas pour sa réaction de départ : il avait codé un truc lui-même, il s'est senti "trahi" par Linus et les autres dévs et il a donc demandé le retrait de son module, ça c'est compréhensible.

    Mais quel intérêt de ressortir ça 6 mois plus tard ?
    Il n'a quand même pas mis 6 mois avant de voir que le nouveau module proposé était issu d'une décompilation de son module proprio ? -.-

    Une explication possible serait que lui s'en fout un peu mais que Philips lui a mis la pression en découvrant ça (d'où les 6 mois), car d'après ce dont je me souviens le développeur originel a/avait un contrat avec Philips qui lui donnait accès aux spéc en contrepartie de ne livrer qu'un module binaire/proprio.
    • [^] # Re: le développeur originel...

      Posté par  . Évalué à 4.

      Bah la situation n'est pas saine : on ne peut pas faire du Libre et accepter de signer un non-disclosure agrement, donc ça devait péter un jour ou l'autre.

      Le monde des drivers Libres n'est pas simple .. peut-être les grosses boites commerciales comme Novell ou RH devraient user de leurs poids pour entrer en contact avec les fournisseurs de hard et assainir tout ça ..
    • [^] # Re: le développeur originel...

      Posté par  . Évalué à 4.

      >Une explication possible serait que lui s'en fout un peu mais que Philips lui a mis la pression en découvrant ça car d'après ce dont je me souviens le développeur originel a/avait un contrat avec Philips qui lui donnait accès aux spéc en contrepartie de ne livrer qu'un module binaire/proprio.

      Juste pour Rappel, il avait signé un NDA avec Philips. Ce NDA a expiré il y a 2 ans environ. Légalement, celà veut dire qu'il est autorisé à tout révéler du fonctionnement de la bête.

      En lisant ses emails des 6 derniers mois dans la LKML, on se rend compte que c'est juste un problème d'ego.
      • [^] # Re: le développeur originel...

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

        Il y avait un NDA, le NDA est expiré, mais je ne crois pas qu'on ait eu accès à l'accord. A l'époque il y avait deux interprétations et aucune n'avait été confirmée ou infirmée par les concernés :
        - c'est fini donc il peut tout révéler
        - c'est fini donc il n'a plus accès aux infos auxquelles il avait le droit pendant deux ans (mais il est toujours tenu par le secret)
  • # Précision

    Posté par  . Évalué à 2.

    Quelqu'un pourrais expliquer la différence qu'il existe entre "décompilation" et "ingénierie inverse".

    De ce que j'en ai compris, les dévellopeurs du noyau ne veulent toujours pas intégrer ce code car il a été écrit à partir d'informations "décompilées".
    Pourquoi la décompilation à l'air d'être une méthode refusée, c'est "illégale" quand il s'agit de code propriétaire ? (vous me direz ... si ce n'est pas propriétaire ... c'est surement inutile)

    Je ne comprend pas tout.
    Et moi qui me réjouissait d'avoir fait (re)fonctionner ma webcam :/

    Pour information : j'ai compilé ce module sur des noyaux 2.6.5 (=< v10.0.5) & 2.6.11 (v10.0.7) sans soucis et il fonctionne à merveille.

    Il existe une très bonne documentation (wiki) ici http://www.lavrsen.dk/twiki/bin/view/PWC/WebHome(...), notamment sur l'API.
    • [^] # ... à la ramasse

      Posté par  . Évalué à -2.

      tululu tutut
      3 plombes pour poster :/
      • [^] # Re: ... à la ramasse

        Posté par  . Évalué à 3.

        jamais content :
        pour faire en rapide (mais pas forcement juste , j'ai pas la pretention de tout savoir ;):
        l'ingenierie inverse c'est l'art de comprendre comment quelquechose marche ; sans pouvoir ouvrir la boite noire.
        Donc la boite noire peut etre par exemple une puce , ou un binaire.
        Ensuite suivant les pays , on a le droit de faire de l'ingenierie inverse sur differents types de boite noire, mais pas forcement sur tous , et suivant certaines conditions.

        La decompilation est de l'ingenierie inverse sur les boites noires qui sont des binaires.
        On extrait le code assembleur d'un programme (donc on "lis" le binaire) et on essaie de comprendre ce qu'il essaie de faire.
        C'est bien entendu plus difficile de lire de l'assembleur que du C (enfin souvent :-D )
        • [^] # Re: ... à la ramasse

          Posté par  . Évalué à -1.

          sauf que la décompilation te donne un langage évolué (du C par exemple) et non pas de l'assembleur. Pour obtenir de l'assembleur, il suffit de désassembler et c'est *bien* plus simple que de décompiler ... mais le résultat est plus difficile à comprendre.
          Si le type a réellement decompilé en C et mis le source obtenu quasiement sans modif dans son module, on est quand meme loin du reverse engeneering !!
          • [^] # Re: ... à la ramasse

            Posté par  . Évalué à 2.

            on dois pas parler de la meme decompilation.
            si tu debugge un programme compile avec l'option g de gcc ; oki tu peux retrouver le code source.
            Mais a partir d'un binaire retrouver un code source en c ???
            si j'en crois mes experiences et cette faq :
            http://www.tech-faq.com/decompiler.shtml(...)
            c'est tres tres tres dur .

            A moins qu'il y a un logiciel que je connaisse pas et qu'il le fasse , dans ce cas je suis tres interesser (et a mon avis je suis pas tout seul)
            Ps si c'etait aussi simple; pas besoin de se prendre la tete avec les drivers proprio non?
            • [^] # Re: ... à la ramasse

              Posté par  . Évalué à 2.

              si tu debugge un programme compile avec l'option g de gcc ; oki tu peux retrouver le code source.

              Meme pas....
  • # Juste une question

    Posté par  . Évalué à -5.

    On pourrait pas faire en sorte que le noyau integre facilement des modules proprios ?

    Parce que devoir mettre open source un module quelque soit le pilote, ça risque de freiner l'adoption de Linux par les grands constructeurs de périphériques...
    • [^] # Re: Juste une question

      Posté par  . Évalué à 2.

      Ils n'ont pas besoin d'être intégrés au noyau, mais simplement utilisables, ou intégrés par les distrib.
    • [^] # Re: Juste une question

      Posté par  . Évalué à 10.

      Le modules proprios ralentissent le dévelopement de Linux:
      1- Ils font planter le noyau (un module est une partie du noyau, pas un pilote externe), donc nuisent à l'image de Linux.
      2- Comme on ne sait pas de quoi ils sont faits, on ne peut pas trouver la cause du plantage dû à un module, rend les tâches de débogage ardues, donc celà nuit encore à Linux.
      3- Les interfaces internes de Linux ne sont pas garanties de rester stables. C'est un choix de design (et un bon choix). La compatibilité avec des modules externes empêcherait la modification des interfaces, donc l'évolution du noyau.

      Par ailleurs, ce que tu demandes est incompatible avec la GPL.
      • [^] # Re: Juste une question

        Posté par  . Évalué à 2.

        C'est un choix de design (et un bon choix)

        Ah ben moi je trouve que c'est un choix extrêmement mauvais.

        Clairement, ça amuse qui de revoir son driver tous les six mois parce que l'API a complètement changée ? Se replonger dans les docs (quand il y en a, et vu que ça change souvent, il faut encore prier pour qu'elles soient à jour), retoucher le code, juste pour que ça fonctionne comme avant.

        Apple à réussi à fournir une API relativement évolutive et assez générique (IOKit), je doute que sur Windows, la compatibilité soit flinguée à chaque rc. À mon avis le Hurd pourra enfoncer Linux à ce niveau.

        Il me semble que Linus n'a jamais voulu s'occuper de ça. Pour lui, une API stable passe forcément par un organisme (Posix, ISO, ....). En attendant ce jour très lointain et hautement hypothétique, je salut le courage de tous ceux qui s'investisse là dedans. Je l'ai fait il y a un ou deux ans, et je n'ai clairement pas trouvé ça fun.
        • [^] # Re: Juste une question

          Posté par  . Évalué à 6.

          Tu exagères un peu à mon avis ;-)

          D'abord, je n'ai pas parlé de l'API.

          Deuxio, tu as vu où que sous Linux, l'API est "flinguée" à chaque RC ?

          Ce que tu oublies aussi de prendre en compte, c'est que si tu fais un module libre, il est mis à jour par les gentils développeurs du noyau quand ils changent l'interface. Bref, c'est mieuc que sous les autres OS... tu n'as rien à faire.

          Quand un choix d'interface s'est révélé inapproprié, mieux vaut corriger de suite que de se retrouver avec des bogues, des trous de sécurité et autres joyeusetés parce que on ne veut pas changer quelques dizaines de lignes de code dans des modules.

          Voici quelques liens expliquant ce qui est stable et ce qui ne l'est pas:
          http://marc.theaimsgroup.com/?l=linux-kernel&m=108787026221678&(...)
          dans lequel on peut lire:
          "NOTE: the source API with the kernel modules must not be confused with the _binary_ ABI with userspace. the ABI with userspace is a completely different matter. The ABI with userspace (like syscalls) must be the same for all linux versions. That is very important. The kernel API to modules not being fixed is a feature and not a bug."

          http://marc.theaimsgroup.com/?l=linux-kernel&m=109948719902664&(...)

          http://marc.theaimsgroup.com/?l=linux-kernel&m=109771007604729&(...)

          et ici, une justification par Al Viro de pourquoi cette instabilité est désirable:
          http://marc.theaimsgroup.com/?l=linux-kernel&m=107113743013983&(...)
      • [^] # Re: Juste une question

        Posté par  . Évalué à 4.

        C'est justement là que je pense que Linux a un petit défaut :
        Il n'y a aucun compromis entre le mode user (les applis normales) et le mode kernel (cette zone magique et obscure).
        Peut-être manque-t-il une couche "driver" au kernel, avec une gestion limitée des droits d'accès au matos, vérifiée au moment du chargement du driver. Un truc du style "c'est un driver graphique, on n'a accès qu'à la carte graphique".
        Cette couche doit avoir une API stable.

        Après tout, comment font-ils sous Windows ? (je ne connais pas la réponse)
        • [^] # Re: Juste une question

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

          Sous Win comme sous Linux, un driver mal fait peut tout casser. C'est l'objet des certifications MS pour les drivers et du gros warning qu'ils mettent (mettaient ?) quand on installe un driver non certifié par MS.
    • [^] # Re: Juste une question

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

      Un module est intimement lié au kernel.

      Imagine que Microsoft developpe un module proprietaire pour le noyau (pour par exemple ses joysticks).
      Il (MS) pourrait tres bien faire en sorte que son module effectue de mauvaise operation dans le noyau, cela decredibiliserais linux.
      • [^] # Re: Juste une question

        Posté par  . Évalué à 1.

        Perso, si en ajoutant un module proprio à mon kernel ce dernier se met à planter, ce n'est pas le kernel que je blamerai (et que je ficherai dehors à coups de pieds).
        • [^] # Re: Juste une question

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

          Ce n'est pas toujours evident de savoir d'où vient le probleme, j'ai par exemple rencontré le probleme avec un module libre (celui pour les carte wifi ralink) qui faisait un kernel panic lorsque le nombre de paquet etait trop important, je n'ai pas fait la relation aussitot.
  • # Hooks sur binaires

    Posté par  . Évalué à 5.

    On se demande bien pourquoi Linus accepte les hooks pour charger les firmwares binaires pour la majorité des nouveaux chipsets wifi, voir carrément des drivers incluant les binaires sans les sources (comme le driver tg), et refuse le hook pour PWC...
    • [^] # Re: Hooks sur binaires

      Posté par  . Évalué à -2.

      Normal, comme tout individu, il n'a pas toujours raison.
    • [^] # Re: Hooks sur binaires

      Posté par  . Évalué à 10.

      Ben y a quand meme une difference entre un firwmare proprio qui est execute sur le periperique et qui n'accede pas dirrectement au kernel et un hook pour un driver proprio qui peut acceder au partie intime du kernel et qui tourne sur le meme "cpu" que le kernel.
    • [^] # Re: Hooks sur binaires

      Posté par  . Évalué à 3.

      Linus s'est déjà exprimé tellement souvent à ce sujet, et on en a déjà parlé tellement de fois sur ce site que je ne recollerai pas les liens vers les messages de la LKML (je l'ai dé jà fait 3 fois ici, je suis las). Si tu es vraiment intéressé de savoir pourquoi il y a des firmwares binaires dans le noyau, cherches un peu dans les archives de la LKML. Chaque année, le sujet revient et chaque année, quelqu'un doit perdre son temps à ré-expliquer.
      • [^] # Re: Hooks sur binaires

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

        Chaque année, le sujet revient et chaque année, quelqu'un doit perdre son temps à ré-expliquer
        Un petit lien vers une page web FAQ?
        (corrigez-moi si je me trompe, mais me semblais que les FAQ répondaient justement a ce genre de besoin...)
      • [^] # Re: Hooks sur binaires

        Posté par  . Évalué à 2.

        s vraiment intéressé de savoir pourquoi il y a des firmwares binaires dans le noyau

        J'aimerai plutôt savoir pourquoi c'est autorisé dans certains cas et pas dans d'autres.

        Pour le reste, oui, j'ai déjà lu les explications oiseuses de Torvalds sur le "pragmatisme" qui le conduit a accepter des blobs binaires propriéraires dans son kernel ...
        • [^] # Re: Hooks sur binaires

          Posté par  . Évalué à 10.

          J'aimerai plutôt savoir pourquoi c'est autorisé dans certains cas et pas dans d'autres.
          il n'y as pas vraiment de regle mais la difference est grande entre un firmware pour une carte et un binaire s'executant dans l'espace kernel.
          Si tu as une carte avec un fpga a base de cellule SRAM (qui a besoin donc d'etre charge avant d'utiliser la carte), que va tu faire d'un module avec du code vhdl a compiler sur une chaine de dev proprio comme xilinx ou altera sur ton poste? reponse : rien, c'est inutilisable pour 99.999% des gens voulant utiliser la carte.
          Alors que le fichier issu de la compilation vhdl sous forme binaire tu peut le telecharger directement dans la carte via le module kernel.

          A l'inverse le pilote pwc (old generation) integrait du code binaire pour x86 qui etait le module de decodage des images de la webcam. Resultat : Un trou de securite (du binaire inconnu qui tourne dans le kernel), une portabilité inexistante pour les autre architecture que x86.
  • # question juridique

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

    Si j'ai bien compris c'est l'action de décompiler qui est interdite dans certains pays, pas le résultat (qui lui ne contrevient à priori pas aux droits d'auteurs s'il ne s'agit pas d'une simple recopie de la décompilation). Quelle est à votre avis la légalité aux US du driver issu de la décompilation si cette décompilation se fait en Europe ou dans un autre pays l'autorisant ?

    Ceci dit ça me montre une chose, c'est que dans l'ensemble les gros logiciels libres refusent ce qui n'est pas conforme à la loi US. Je n'ai pas d'exemple en tête mais j'avais déjà vu ça une fois sur le DMCA et une fois sur la question du brevet GIF Unisys . Quand quelque chose est interdit dans un pays spécial on dit que ce n'est pas grave et que ça ne concerne pas la GPL. Par contre quand c'est interdit aux US là on retire les choses.
    • [^] # Re: question juridique

      Posté par  . Évalué à 3.

      Ceci dit dans le cas présent, c'est un peu logique que Linus, travaillant aux US, respecte la loi du pays dans lequel il est..
    • [^] # Re: question juridique

      Posté par  . Évalué à 1.

      C'est intéressant comme remarque, quelqu'un peut-il confirmer ou infirmer ce constat ? Est-ce que cette "discrimination" USA / reste du monde est vérifiée ?

      Ca me parait gros cette théorie, mais après tout pourquoi pas ?
  • # différent != différend

    Posté par  . Évalué à 3.

    "Avoir un différend" a un sens, "avoir un différent" n'en as pas. Subtile différence ! ;)
  • # Je commence a en avoir MARRE !

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

    J'utilise une webcam phillips TOUCAM pro, parce que je suis astronomoe amateur et que c'est LA meilleure cam en astro (et toute la clique des "pro" chez phillips et creative).
    http://astrosurf.com/djibb/new/images/astro/(...)
    (tout fait a la webcam)
    Pas de bol !! ces webcams sont dirigées par un module proprio appelé PWCX, basé sur PWC (GPL) et pas de bol, ce module n'est pas inclus dans la noyau... ca veut dire qu'a chaque fois que je veux faire une version de ceci : http:/www.lin4astro.org je me tape des ajouts de modules (et ca devient galère quand on veut tout automatiser un peu). C'est pourquoi la version de dev est basée sur knoppix 3.7, que la stable a plus de 1 an et demi et est basée sur knoppix 3.3.
    J'ai vraiment été heureux quand j'ai vu que pwc rentrait dans le noyau et la je suis dégouté. Dégouté pourquoi ? Parce qu'un dev du libre a une problème avec son ego, a été vexé parce que son code ne satisfaisait personne sauf lui et qu'il a signé un DNA qui est expiré depuis bien longtemps et que donc, il pourrait très bien le mettre en GPL sans que ca gene personne. (meme pas Phillips... !)
    Bref -> Ca me gave !
    • [^] # Re: Je commence a en avoir MARRE !

      Posté par  . Évalué à 4.

      qu'il a signé un DNA qui est expiré depuis bien longtemps et que donc, il pourrait très bien le mettre en GPL sans que ca gene personne. (meme pas Phillips... !)
      pour en avoir deja signé un ou deux je peut t'indiquer que l'expiration d'un NDA (NonDisclosure Agreement) limité dans le temps ne signifie pas qu'as sont expiration tu peut rendre publique les informations que tu as recue, mais plutot qu'en le signant tu garantit que le contracteur reste propriaitaire unique de la divulgation ou non des informations (dans le cas present c'est philips).
      Il faudrait avoir le NDA pour savoir si c'est une question d'ego ou une question de respect d'un contrat passé.
      • [^] # Re: Je commence a en avoir MARRE !

        Posté par  . Évalué à 2.

        mais plutot qu'en le signant tu garantit que le contracteur reste propriaitaire unique de la divulgation ou non des informations (dans le cas present c'est philips).
        Ben si le contrat est valable ad vitam aeternam ; il est aps limite dans le temps non?

        je ne comprend pas tres bien .
        Si il est limite dans le temps; et que le delai est depasse, ca veux donc dire que le contrat n'as plus aucune valeur , et donc tu peux tout devoiler.
        Sinon il est pas limite dans le temps :
        tu as ton nda sur la partie titi qui dis "tout ce que vous avez appris est et restera propriete de toto.corp"

        Enfin en gros je vois pas tres bien pourquoi on dirais limite dans le temps si ca ne l'est pas .
        • [^] # Re: Je commence a en avoir MARRE !

          Posté par  . Évalué à 3.

          Ben si le contrat est valable ad vitam aeternam ; il est aps limite dans le temps non?
          ce qui est limité dans le temps c'est l'acces qui t'est donné au informations (evolution des specs ou des algos proprio) fournit .
          C'est un peut comme la location d'un appartement pendant le bail tu peut y faire des choses, un fois le bail finie tu est dehors.
          Normalement un NDA prevoit que le logiciel que tu as developper pendant le partenariat peut etre utiliser par la suite (avec ou sans royaltie suivant le contrat) mais que tu t'engage a leur redemander l'autorisation de devolopper un autre logiciel re-utilisant les infos collectée.
          La evidemment je parle des NDA avec lesquels j'ai deja eut as faire, pas celui dont je n'ai pas connaissance entre philips et l'ancien dev du module.
        • [^] # Re: Je commence a en avoir MARRE !

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

          prenons comme exemple le 1er lien fourni par :

          http://www.google.fr/search?hl=fr&q=non+disclosure+agreement+ex(...)

          http://www.legaldocs.com/htsgif.d/xnondisc.mv(...) (c'est du html)

          Mon interprétation (IANAL ;-) ) : quand bien même cet exemple de NDA est limité dans le temps, il n'octroie pas de droit des diffusions des documents reçus dans le cadre du NDA.
          En revanche, tout le travail résultant de la coopération, sous réserve d'y avoir apposé la licence qui va bien, doit pouvoir être diffusé dans le cadre de la licence retenue : j'ai l'impression que le souci est là, mais je me trompe peut-être.
          La seule chose que Nemosoft a dit c'est que le NDA est terminé mais que ça porterait potentiellement préjudice s'il donnait le tout, il n'a pas précisé sous quelle licence sa librairie binaire avait été faite. Après dans l'élan, il a dû admettre qu'il pourrait tout à fait donner le code, mais qu'il préfère ne pas le faire, si ma mémoire ne me fait pas trop défaut (je te laisse retrouver et parcourir les threads de l'époque...).
          • [^] # Re: Je commence a en avoir MARRE !

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

            Merci de ses précisions, c'est très intéressant ! Je comprends bien le pb du NDA fini mais qu'on a pas le droit de dévoiler les technologies. Cependant, effectivement, il a dit "je pourrais (si je le voulais) le faire".
            Je vous laisse aller voir ca http://linuxfr.org/2004/08/26/17101.html(...) ATTENTION -> 536 commentaires... le top du top du troll, du debat... je n'ai pas pu l'afficher avec mon PIII 500 :(

            Allez... Bonne bourre.
    • [^] # Re: Je commence a en avoir MARRE !

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

      C'est la faute d'un dev vexé ? peut être, je te laisse libre de ce jugement. Mais à la limite ce qui me parait limite encore moins joli c'est qu'on lui reproche.

      Il refuse suite à un problème d'égo ? peut être, s'il est dans son droit c'est son choix.
      Si tu n'es pas content tu prend tes mimines et tu fais la même chose que lui au lieu de lui reprocher (ou tu payes quelqu'un pour le faire). Lui ne te doit rien, on n'a rien à exiger de lui.
      Notes d'ailleurs que le problème existe justement parce que ce n'est pas libre comme soft. Ca fait parti des choses à prendre en compte au départ en acceptant les licences.

      Sinon techniquement si tu vas voir sur les archives noyeaux il y a une RC qui contient le dit drivers. Il y a aussi des anciens noyeaux qui contiennent l'ancien driver qui marche avec le binaire proprio. Il est probable qu'il suffise de recopier le module dans ton nouveau noyeau pour que ça marche.
      • [^] # Re: Je commence a en avoir MARRE !

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

        Part en c** ce fil... c'est marrant, a chaque fois qu'on parle de pwc, ca part en c**... Passons.

        Tout a fait d'accord avec toi. Mon pb étant que je n'ai pas envi de changer de machine pour refaire un LiveCd (voir projet Lin4astro). Mon pb (et uniquement le mien) étant que j'y capte que dalle en prog et suis juste bon a suivre (mal) un howto, mon pb étant que ca m'enerve que phillips laisse son algorithme en proprio alors que TOUT LE MONDE sait qu'il est basé sur le jpeg (et c peut etre pour ca que ca pose pb de la liberer ?) vu que tous les firmwares ont deja éta decodés depuis 1 an avec l'arrivée du mode RAW de ces webcams (flashage de la ROM de la cam pour avoir accès a des modes non debayerisés par exemple) http://astrosurf.com/astrobond/ebrawf.htm(...)
        Bref, je suis un astronome amateur, ma camera est une des plus sensible au monde, (explosion du temps de pose + capteur uniquement noir et blanc ss les filtres couleurs devant- je fais de la visioconférence fenetre fermé juste éclairé par l'ecran et personne n'y voit rien (moi non plus d'ailleurs - ), je connais les registres de la cam, je les bidouille meme de temps en temps. Donc dans cette caméra, y'a plus rien de secret depuis longtemps. !! Il faudrait que phillips s'en rende compte un jour... elle est trop chere cette camera, y'a que les astronomes qui l'achete a ce prix ;) (90 ¤ contre 20 euros pour une webcam bas de gamme).
        J'aurais des mimines et une interface mimines/pensée éduqué au C, ca ferait très longtemps que je l'aurais fait. Malheureusement... je me fais vieux, et je n'ai jamais touché un seul bout de C dans ma vie... (la chimie... a part des logiciels de modelisation). Donc, ne te soucis pas de moi je m'en veux dejà assez d'être une bille notoire, j'ai RTFM bien souvent et si je pouvais, je le ferais.
        • [^] # Re: Je commence a en avoir MARRE !

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

          >ma camera est une des plus sensible au monde
          >elle est trop chere cette camera, y'a que les astronomes qui l'achete a ce prix ;) (90 ¤ contre 20 euros pour une webcam bas de gamme)

          90 ¤ pour une des meilleurs webcam au monde ça me semble pas excessif, faut savoir ce que l'on veut.


          Sinon je suis d'accord avec le reste de ton post.
          • [^] # Re: Je commence a en avoir MARRE !

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

            faut juste rajouter le capteur... hein :) puis le CMOS, les resistsances tout ca... 100 euros le capteur N&B... ca commence a faire deja plus cher.
            Et Ce n'est pas parce que c'est la meilleure qu'elle ne doit pas etre libre (au contraire)


            (et puis ca reste une webcam... qui se fait exploser en sensiblité par les CCD pures en ciel profond. (16 bits))
    • [^] # Re: Je commence a en avoir MARRE !

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

      LA meilleure cam en astro
      Faudrait savoir :
      1/ soit c'est la meilleure, les inconvenients (que tu comiles toi meme ton noyau, ou que tu passes sous MS Windows) y compris, et donc je ne vois pas pourquoi tu rales vu qu'il n'y a pas mieux et que tu trouves que c'est la meilleure.
      2/ soit il y a mieux ailleurs (support Linux etc...) et donc vaut mieux pendre ailleurs plutot que de raler.

      Si c'est 1/, alors pourquoi pas ecrire a Philips pour que le meilleur soit encore meilleur, plutot que de rouspeter sur un gars qui a fait du boulot sur son temps personnel? Chacun est libre de faire ce qu'il veut de son travail non?
    • [^] # Re: Je commence a en avoir MARRE !

      Posté par  . Évalué à 4.

      Parce qu'un dev du libre

      C'est pas un dev du libre, c'est un dev proprio du NDA proprio avec phillips (c) (r) (tm).
  • # patch externe ?

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

    Si j'ai bien compris le pilote de Luc Saillard :
    - fonctionne
    - est en GPL
    - a été obtenu par des métodes légales en europe (la décompilation pour reverse engeenering c'est légal ici)

    pourquoi ne pas simplement en faire un patch externe (en fait ca à l'air d'être déjà le cas) ?

    Evidemment ca ne sera plus par défaut dans le kernel, mais c'est pas, IMHO, un si grand probléme. N'importe quel particulier pourra utiliser le driver si c'est légal dans son pays (ou à ses risques et périls) et il en vas de même les distributions non ?

    Enfin je ne comprend pas pourquoi à l'air de trouver ca si terrible que ce ne soit plus par défaut dans le Kernel ?
    • [^] # Re: patch externe ?

      Posté par  . Évalué à 3.

      > a été obtenu par des métodes légales en europe (la décompilation
      > pour reverse engeenering c'est légal ici)

      C'est le côté "pour reverse engeenering" qui est remis en cause ici justement. Le problème, c'est les similarités entre le driver libre et celui proprio, qui laissent penser qu'une partie du code de l'un est un peu trop directement inspirée de celui de l'autre. Si c'est le cas (et je parle bien d'un doute qui plane et pas d'autre chose, je n'en ai perso pas la moindre idée), alors ça serait parfaitement illégal, en Europe autant qu'ailleurs, puisque ça s'apparenterait plus à de la copie qu'à de l'ingénierie inverse.
      • [^] # Re: patch externe ?

        Posté par  . Évalué à 1.

        Heu il me semble que le pilote en question se base largement sur les alghos de décompression jpeg non???Donc il y aura toujours une similitudes sur son implémentation mais ça ne veut pas dire qu'il y a copie pour autant.J'avoue je n ai pas lu le source ni de l'un ni de l'autre, donc je ne peux être catégorique sur ce que j'avance ( j'ai pas de webcam :p ) .
        • [^] # Re: patch externe ?

          Posté par  . Évalué à 2.

          Disons que si on passe par une etape realsisation de spec on a moins de chance d'avoir du code similaire. Meme mieux quelq'un le RE et realise des spec et une autre personne cree une implem libre a partir des specs.
          • [^] # Re: patch externe ?

            Posté par  . Évalué à 3.

            Il semble que ces techniques ont un nom: "Clean Room":
            http://www.ardi.com/reveng.php(...) [en]

            http://lwn.net/Articles/137823/(...) (pas compris si c'est AC (author) ou LT (commiter) qui écrit) dit :
            "Someone else can then redo the decompressors properly (clean room) in user space."

            Je ne suis pas expert en décompression, mais quand je vois que des pans entiers de code sont des tableaux de bits, je ne sais pas comment on peut traduire ça en spec autre que "verbatim".

            Pourquoi est-ce que Philips ne se prononce pas sur le NDA et ne libère pas ce code qui lui permettrait de vendre encore plus de matériel?

            ça éviterait cette énergie perdue.
            • [^] # Re: patch externe ?

              Posté par  . Évalué à 3.

              Je ne suis pas expert en décompression, mais quand je vois que des pans entiers de code sont des tableaux de bits, je ne sais pas comment on peut traduire ça en spec autre que "verbatim".
              Je ne suis pas non plus un expert, mais la compression video necessite beacoup de tableaux de bit (coeficients de quantification , table de huffman, ...) et a part recuperer les valeurs dans le binaire, je vois pas ce que tu peux faire...
      • [^] # boycot???

        Posté par  . Évalué à 8.

        Alors là, je comprend pas la politique des boites (grosses boites).
        Tout d'abord ils sont fondeurs de circuits intégrés. Ils les vendent et en tirent un bénéfice. Ensuite ils sortent un bouquins avec les specs, qu'ils vendent également. Ils en tirent également un bénéfice. Ils fabriquent des cams dans lesquelles ils placent leurs circuits intégrés, et ils veulent pas qu'on leur fasse leur drivers, qui leur permettraient de ne se concentrer que sur le matériel. NON, ils veulent pas. Ils font pas payer les drivers, mais ils veulent absolument qu'on les utilisent sur l'OS qu'ils ont décidés.
        Mais qu'on fasse un site (je n'ai jamais chercher pour voir si ça existait) avec le matériel non supporté, que chaque fois que quelqu'un a envie d'acheter du matos, il regarde si les drivers libres (LIBRES je dis bien) sont existant. Non, ils n'existent pas, et bien une demande est faite via le site. Suite à la réponse, on saura chez qui acheter. Qui est le patron? celui qui vends, ou celui qui achète?
        J'ai quelques années de bouteilles, et c'est toujours la même chanson que j'entend. Ne râlons plus, et faisont front...
        Des idées?
      • [^] # Re: patch externe ?

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

        alors je ne comprend pas ...

        Aprés tout, si j'étudie le fonctionnement d'un programme (en le décompilant ce qui n'est stricto senso qu'une traduction des op-codes en un truc humaine lisibles, càd n'a rien d'illégal ou alors on peut pas lire le binaire non plus ... ). Puis si je comprend le fonctionnement dudit programme et que je réimplémente ce fonctionnement dans un language de haut-niveau (tel le C) alors c'est une copie illégale ?

        Je pensait que c'étais justement çà le RE. Ou alors je me plante complétement ?

        Cela me semble évident que il doit avoir des ressemblances entre deux programmes qui doivent utiliser le même algorithme pour remplir la même tâche non ?

        alors si le type a fais un copier/coller du code ASM et l'a mis dans ses sources, ok c'est pas net. Mais s'il a vraiment recodé from scratch je vois pas le probléme.
        • [^] # Re: patch externe ?

          Posté par  . Évalué à 3.

          Ben c'est exactement ça le sens de ma question, car partant from scratch et realisant une decompression jpeg, quelque soit x, nos programmes auront des similitudes.Donc si je veux poser la question autrement à partir de quel moment parle-t-on de copie quand il s'agit de l'implementation d'un algorithme??
        • [^] # Re: patch externe ?

          Posté par  . Évalué à 5.

          > alors je ne comprend pas ...

          Mais si... :)

          > alors si le type a fais un copier/coller du code ASM et l'a mis dans
          > ses sources, ok c'est pas net. Mais s'il a vraiment recodé from
          > scratch je vois pas le probléme.

          Exactement. La difficulté, c'est que la frontière entre ces deux cas est très floue. Si tu écris avec un modèle sous les yeux, est-ce que tu recopies ou est-ce que tu fais un oeuvre originale ? Ça dépend... Note que ça n'est pas parce que c'est du C que c'est du code original - une réécriture quasi automatique, ou au moins systématique, depuis une décompilation est parfaitement possible. On ne sait pas vraiment je crois de quel côté de cette frontière est le driver libre aujourd'hui.

          Pour Neosoft, l'auteur du driver proprio original, il est clairement du côté "copie" : « In case you hadn't noticed, that code has been reverse compiled (I would not even call it "reverse engineered"), and is simply illegal. »

          Quant à Alan Cox, il lui donne plutôt raison, d'où le retrait du driver (même si c'est probablement plus une mesure préventive qu'un jugement définitif) : « I *am* concerned by your comments about how the reverse work may have been done, and whether proper process was followed. », et plus tard : « The points he raised still seem valid to me. »
        • [^] # Re: patch externe ?

          Posté par  . Évalué à 6.

          tgl a dit :
          C'est le côté "pour reverse engeenering" qui est remis en cause ici justement. Le problème, c'est les similarités entre le driver libre et celui proprio, qui laissent penser qu'une partie du code de l'un est un peu trop directement inspirée de celui de l'autre. Si c'est le cas (et je parle bien d'un doute qui plane et pas d'autre chose, je n'en ai perso pas la moindre idée), alors ça serait parfaitement illégal, en Europe autant qu'ailleurs, puisque ça s'apparenterait plus à de la copie qu'à de l'ingénierie inverse.

          Edouard Geuten a dit :
          Cela me semble évident que il doit avoir des ressemblances entre deux programmes qui doivent utiliser le même algorithme pour remplir la même tâche non ?

          Après le commentaire fort à propos de tgl, et en réfléchissant un peu, je pense avoir compris (enfin!!... :P ) le problème. Donc ce problème n'est pas tant d'avoir fait un RE sur le binaire ; c'est la similitude trop grande entre l'original et le nouveau. Prenons un exemple : si demain, je sors une pièce de théâtre dramatique en vers de 12 pieds qui raconte l'histoire d'un fier guerrier gascond affublé d'oreilles géantes (why not?), locace, ayant le verbe agile, et épris de sa cousine au point de la courtiser par le biais d'un bleu-bite qui a l'avantage d'être beau mais le désavantage d'être sot... je pense que les fans d'Edmond Rostand me fustigeraient.

          En gros, l'implémentation peut être dans un autre langage, peut avoir des variables avec des noms différents de l'original... il y a _plagiat_ du code original, et non pas une étude des entrées/sorties/traitements menant à une nouvelle implémentation qui serait originale.

          Un autre exemple : je prends une application GPL populaire, écrite en langage C et je la "traduis" en Java, en gardant les mêmes fonctions, la même structure de code, etc... penses-tu que je pourrais commercialiser mon soft sous la licence de mon choix?... évidemment pas! et c'est heureux. On peut recopier l'effet d'un programme. On peut étudier le code source à but d'interopérabilité. On peut tromper 1 fois 1 personne mais on ne peut pas tromper 1000 fois 1000 personnes. Mais on ne peut pas plagier un programme.
          • [^] # Re: patch externe ?

            Posté par  . Évalué à 3.

            Je suis globalement d'accord avec toi. Je veux être sûr que j'ai bien compris :

            On peut recopier l'effet d'un programme
            Il s'agit donc de copier l'algorithme, et d'en faire une nouvelle implémentation. C'est l'implémentation qui est protégée par le droit d'auteur, pas l'algo qui lui n'appartient à personne (formule mathématique, patrimoine de l'humanité, toussa).
            Enfin, tant qu'il n'y a pas de brevets sur les logiciels. :-/
            Un reverse-engineering par analyse des entrées/sorties de la boîte noire (façon Tridge pour Samba) est donc acceptable.

            Mais on ne peut pas plagier un programme
            Là où c'est difficile, c'est de faire la distinction entre une implémentation "sincère" de l'algo, qui ressemble à l'implémentation protégée juste parce qu'il était logique de faire comme ca (structures de données classiques, nommage explicite, ...), et un repompage intégral avec "obfuscation" et mauvaise foi.
            Un reverse-engineering par décompilation permet de faire l'un ou l'autre, selon l'effort et l'intelligence qu'on met dans la compréhension (abstraction) et la re-création (implémentation) du programme.

            Pour reprendre l'exemple littéraire, si j'invente un super-pipotron avec analyse sémantique et générateur de synonymes, et que j'y passe un roman célèbre, ce sera toujours la même histoire, juste avec des mots différents. C'est clairement un plagiat, je n'ai pas crée de contenu culturel. (quoique, un bô pipotron comme ca, c'est pas simple à faire et ca intéresserait sûrement les hommes politiques ...)

            Maintenant, si je mixe plusieurs romans sur le même thème, ou que je réécris des passages pour brouiller les pistes, que j'influe sur le style ou le vocabulaire utilisé par le programme, à partir de quel moment cela devient-il une oeuvre originale ? Comment faire la différence avec une simple "inspiration", une référence culturelle ? Si je réécris un San-Antonio avec le vocabulaire de Molière (ou l'inverse, c'est vous qui voyez) est-ce encore la même oeuvre?

            L'exemple marche aussi pour la musique, avec l'échantillonnage (sample), les remixes et autres reprises (dont certaines sont créditées en tant que thème "traditionnel" pour ne pas reverser de droits).

            Finalement, c'est encore l'autorisation (ou non) des travaux dérivés par les licences Creative Commons qui est la plus claire ...
            • [^] # Re: patch externe ?

              Posté par  . Évalué à 2.

              Il s'agit donc de copier l'algorithme, et d'en faire une nouvelle implémentation.

              Là où c'est difficile, c'est de faire la distinction entre une implémentation "sincère" de l'algo, qui ressemble à l'implémentation protégée juste parce qu'il était logique de faire comme ca (structures de données classiques, nommage explicite, ...), et un repompage intégral avec "obfuscation" et mauvaise foi.

              1 - Il n'est pas nécessaire d'avoir obfuscation et mauvaise foi pour être en désaccord. Si les gens ne s'accordent pas sur les définitions, et notamment sur l'originalité du travail, on peut avoir un code source disponible (ou connu par une poignée de personnes) et être en désaccord.

              2 - En effet, c'est là qu'on entre dans une dimension qui n'est pas "objectivable". De mon point de vue, une implémentation originale (légitime) doit faire suite à un travail de conception avec identification des étapes (traitements, vérifications, entrées/sorties) nécessaires et suffisantes (ceci devrait d'ailleurs être corroboré par un document récapitulatif des données techniques identifiées). Si le travail de RE supposé (et je reprécise qu'on est dans la _supposition_) a consisté à identifier les branchements et débranchement dans le code assembleur, et à reproduire les traitements, ca mérite d'être mis à la poubelle...
            • [^] # Re: patch externe ?

              Posté par  . Évalué à 0.

              L'exemple marche aussi pour la musique, avec l'échantillonnage (sample), les remixes et autres reprises (dont certaines sont créditées en tant que thème "traditionnel" pour ne pas reverser de droits).

              je sais pas comment ca marche dans les autres pays, mais en france t'as le droit de sampler moins de 4 mesures (un cycle quoi, enfin dans la majorite des productions) d'un morceaux sans avoir a payer de droits.
              • [^] # Re: patch externe ?

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

                Il n'y a aucune référence à des nombres de mesures ou de notes. Tu as le droit à une courte citation. Le contexte est largement plus important que la longueur.
                Tu peux faire une analyse détaillée avec plein de citations dont certaines de plus de 4 mesures. Si le contexte est bien une analyse avec des citations et des références à l'oeuvre originale il n'y a aucun problème.
                Inversement, si tu fais une pub, que tu joues juste les 4 première notes de la marche impériale pour illustrer un méchant bonhomme qui avance, va falloir passer à la caisse parce que ça n'a rien d'une citation.

                (après reste à voir si les ayants droits autorisent sans contraintes les extraits d'une certaine taille, mais c'est quelque chose de défini par l'ayant droit et qui est vrai que tu sois en France ou pas)
                • [^] # Re: patch externe ?

                  Posté par  . Évalué à 1.

                  mmmhhh...
                  marrant ce point de vue.

                  c'est une info que je tiens de source a priori sure : les recommandations du collectif des sound systems pour eviter les galeres juridiques avec la sacem et consorts a l'epoque de la chasse aux sorcieres^W^W organisateurs de free party, recommandations ecrites avec l'aide d'un conseiller juridique competent.

                  bon, apres, je remet pas en cause ce que tu dis, mais ya pitetre une subtilite quelque part.
                  • [^] # Re: patch externe ?

                    Posté par  . Évalué à 2.

                    > c'est une info que je tiens de source a priori sure : les
                    > recommandations du collectif des sound systems

                    C'est pas forcement contradictoire avec ce que disait Éric : les machins sound systems, c'est probablement considéré comme un contexte bien particulier : les règles qui y sont applicables peuvent être celles que tu cites, alors que d'autres différentes le seraient dans les contextes (pub et traité de musicologie) qu'il avait lui pris en exemple. Non ?
                    • [^] # Re: patch externe ?

                      Posté par  . Évalué à 2.

                      Il y a eu le cas récent qui avait fait du bruit (!) du type qui siffle quelques notes de l'internationale dans un film et la prod a du payer les ayants droits.
                  • [^] # Re: patch externe ?

                    Posté par  . Évalué à 2.

                    4 mesures, ça ne veut strictement rien dire, surtout en musique contemporaine où elles ne sont pas toujours utilisées.

                    D'après ces recommandations, ai-je le droit de sampler entièrement les 4'33" de John Cage ?
                    (cf. http://www.johncage.info/workscage/433.html(...) )
  • # aurtaugrafe.

    Posté par  . Évalué à 0.

    Je passe sur certaines tournures de phrases, en revanche :

    s/différent/différend/

    Voilà, mes 0.02¤.
  • # pourquoi tant d'obstination ?

    Posté par  . Évalué à 3.

    Ce que j'ai du mal à comprendre pour ma part c'est l'insistance de Philips à garder secret son algorithme de compression.

    OK c'était une arme très importante pour eux à l'époque... mais maintenant avec l'USB2, n'importe quel constructeur de webcam pourrait faire d'aussi bonnes webcams sans cet algorithme !!!
  • # c'est space

    Posté par  . Évalué à 1.

    ça a sans doute déjà été discuté, mais pourquoi la décompression doit se faire dans un module du noyau ?

    Il n'y a pas moyen de faire un module tout bien GPL qui sorte le flux compressé pour ensuite le gérer avec un soft proprio-pa-bo ?


    (je suppose que le problème dans ce cas est que la webcam philips n'est pas vu comme une webcam par tous les logiciels qui attendent un périph v4l)
    • [^] # Re: c'est space

      Posté par  . Évalué à 2.


      (je suppose que le problème dans ce cas est que la webcam philips n'est pas vu comme une webcam par tous les logiciels qui attendent un périph v4l)

      Justement v4l, supporte les formats raw et ca devrait etre a l'application de faire le boulot de decompression.

      Le probleme c'est que la plupart des appli s'attende a ce que le periph supporte des formats standart.

      Ce qu'il faudrait faire c'est une bibliotèque de decompression pour les differentes webcam et qui si possible fasse une surcouche a v4l, pour le faire de facon transparente.
    • [^] # Re: c'est space

      Posté par  . Évalué à 2.

      Oui, ça permet aux softs qui utilisent v4l (et maintenant v4l2) de recevoir un flux vidéo et non un flux binaire opaque et compréssé.
      En l'occurence, ça permet de manipuler la webcam depuis mplayer, ImageMagick, motion, xawtv, gnomemeeting, camE etc.
      L'utilisation d'un soft de decompression intermediaire "spécialiserai" énormément la caméra.
      • [^] # Re: c'est space

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

        Oui, mais alors c'est v4l qu'il faut blâmer : il me semble que d'autres interfaces pour matériel utilisent des librairies pour faire ça. Je pense à ALSA ou sane par exemple...

        "Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier

  • # Boing boing

    Posté par  . Évalué à 1.

    Tant que le pilote rebondit, il ne se crash pas.
  • # et maintenant, on prend quoi ?

    Posté par  (Mastodon) . Évalué à 2.

    Voilà, je viens de tenter de faire marcher une webcam Quickcam Express [1] dans ma Debian testing, et c'est trop la galère. J'ai téléchargé deux "drivers" dans sourceforge, mais ensuite il faut installer les sources du kernel, compiler je ne sais pas trop quoi, s'apercevoir que le kernel qui tourne ne correspond (peut-être pas) aux sources, et est-ce que ça va pas exploser au passage en Sarge ?... Avec la crainte de devoir recommencer le même cirque si je passe ma webcam sur le portable en Slack... Bref, loin du plug'n'play.

    Je veux donc aller acheter une webcam qui marche out of the box avec une Sarge et une Slack. Je veux bien bidouiller le noyau de la Slack, mais pas celui de la Sarge. Je n'ai pas besoin d'une grande qualité, ni d'un débit de furieux. Avez-vous des suggestions de modèle ou un lien kivabien ?

    [1] http://bellvis.zehome.com/gniii/webcam.txt(...)

    Merci de votre soutien.

Suivre le flux des commentaires

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