Premiers pilotes libres pour les imprimantes Samsung

Posté par  (site web personnel) . Modéré par Benoît Sibaud.
Étiquettes :
0
27
août
2006
Linux
Depuis le temps qu'on les attendait, ils sont arrivés. Voici donc la première version des pilotes libres pour imprimantes SPL2 (Samsung Printer Language) estampillée 0.0.1. Ceux-ci permettront de faire fonctionner une grande partie des imprimantes Samsung et apparemment quelques Xerox en utilisant leur langage natif, procurant ainsi des documents au maximum de leur qualité pour un temps de traitement réduit.

Pour l'heure, les imprimantes utilisant la version précédente, SPL, ne sont pas encore supportées mais ça ne saurait tarder (Recherche de possesseurs d'une de ces imprimantes). Si vous êtes concerné, n'hésitez pas à les tester et à retourner vos résultats à l'auteur afin de peaufiner les fichiers PPD propres à chacunes. Après avoir acheté une imprimante Samsung ML-2250 qui avait la mention « Compatible Linux », la joie s'est vite estompée lorsque les pilotes pour Linux ont lamentablement planté et n'ont jamais été capable de sortir un document. Après avoir pu constater que le problème était récurrent à la quasi totalité des possesseurs de ces imprimantes, une lettre a été envoyée à Samsung demandant, dans un premier temps, des explications, puis, dans un second temps, les spécifications techniques du langage dans le but de redévelopper des pilotes au cas où Samsung aurait été dans l'incapacité d'en fournir de nouvelle version (la dernière version remontant à 2001).

La réponse fût claire et précise : « Pour utiliser l'imprimante ML-2250 sous Linux, vous devez vous procurer le module PostScript optionnel. » (Il est à noter que ce module coûte plus de la moitié du prix de l'imprimante).

Après une seconde lettre redemandant les spécifications, qui reste encore sans réponse, l'ambition de développer des pilotes libres et de rédiger une spécification non officielle de ce langage était grande. Et c'est après un peu plus de trois semaines de travail acharné que j'ai l'honneur de vous présenter ces pilotes.

Aller plus loin

  • # Merci!

    Posté par  . Évalué à 9.

    Bravo pour ce travail et les acheteurs de cette imprimante peuvent te dire un grand merci. En meme temps, vu la mauvaise volonte de Samsung (et leur pub mensongere "compatible Linux"), ca n'a pas du etre tres motivant, non ? Si j'ai bien compris, tu as du faire du reverse engineering pour parvenir a communiquer avec l'imprimante ?

    Sinon, j'ai vu qu'elle etait aux alentours de 110 euros. Y-a-t-il d'autres imprimantes laser recommandees, economiques a la recharge et qui soient vraiment compatibles linux (avec des standards de communication ouverts) ? Chez HP par exemple ?

    • [^] # Re: Merci!

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

      Tu as visé juste. Les imprimantes HP marchent très bien pour la plupart, une liste complète est disponible ici : http://www.linuxprinting.org/printer_list.cgi?make=HP

      Pour le travail, je commande essentiellement des HP Laserjet avec carte réseau et force est de constater que ce sont celles qui m'ont données le moins de problème.

      Par contre, leur support c'est pas gangé ...
      http://weblog.frlinux.net/?p=73

      Steph

    • [^] # Re: Merci!

      Posté par  . Évalué à 5.

      Brother 5150 (enfin ça doit être la 5250 maintenant qui l'a remplacée).
      Pour ~250euros, elle fait du postscript, du recto verso, compatible linux, et pour pas beaucoup plus cher, il y a même la version ethernet.
      D'ailleurs, mention spécial pour le SAV Brother : la mienne déconnait ; quelques minutes avec la hotline le vendredi et j'avais un technicien pour changer le laser le mardi chez moi.

    • [^] # Re: Merci!

      Posté par  . Évalué à 2.

      Quelle modele as tu vu a 110¤ ???

      • [^] # Re: Merci!

        Posté par  . Évalué à 1.

        ml-2250, celui qui est marque "supporte".

    • [^] # Re: Merci!

      Posté par  . Évalué à 4.

      nous on a une kyocera au travail, laser couleur particulièrement économique, il y avait les spécifications PPD avec, j'ai eu un peu de mal à la faire fonctionner avec ce qu'ils donnaient sur le cd, mais j'ai pu y arriver en m'y penchant un peu plus. C'est le modèle : Kyocera_Mita_FS-C5016N

      Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

    • [^] # Re: Merci!

      Posté par  . Évalué à 2.

      Il y a une gamme de brother qui fonctionnent tres bien entre 100 et 250 euros.
      J'ai une 2070N payée environ 200 euros, elle est économique et fonctionne tres bien avec CUPS et a un port ethernet.

      Le premier prix de cette gamme, la HL 2030, est a 95 euro et ca doit fontionner également (elle est listée comme compatible).

      Avant d'acheter, vous pouvez verifier si l'imprimante est supportée la:
      http://www.linuxprinting.org/printer_list.cgi

      a++

      • [^] # Re: Merci!

        Posté par  . Évalué à 4.

        Oui la HL 2030 fronctionne mais il faut installer un drivers binaire qui n'est semble-t-il pas GPL. Je n'ai pas trouvé les sources chez Brother du drivers LPD. Par contre on trouve les sources du wrapper CUPS qui lui utilise le driver binaire LPD. (je n'ai pas essayé de leur écrire pour obtenir les sources).

        Ceci dit, le paquet debian du wrapper ne s'installe pas correctement sous testing car le fichier /etc/init.d/cups a été renommé en /etc/init.d/cupsys.
        Une installation à la main de l'imprimante via l'interface web de cups et tout rentre dans l'ordre. (cela focntionne par contre avec la stable).

        J'avais essayé le driver hl1250 fourni avec cups mais cela ne fonctionnait pas très bien.
        La zone d'impression ne représentait que la moitié dans la largeur d'un feuille A4.

        Donc je ne conseille pas d'acheter ce modèle HL2030, mais plutot un modèle postscript supporté par le driver hl1250.

        Bonne journée.

        • [^] # Re: Merci!

          Posté par  . Évalué à 1.

          toujours à propos de brother, j'ai banché la mienne, j'ai emergé cups, j'ai été dans l'interface web pour l'ajouter, j'ai choisi le driver PCL machin, le port usb déja surligné (avec Brother 5140 écrit sur la même ligne), suivant, suivant, suivant, terminer.

          et voila, même pas du réfléchir pour installer ma brother.

          et le driver utilisé ?
          pas la moindre idée, mais ca marche :)

    • [^] # Re: Merci!

      Posté par  . Évalué à 2.

      Comme imprimante Laser autour des 110 Euros, je vois que personne n'a mentionné la Lexmark e120n.

      J'en ai acheté une il y a quelques mois que j'avais payé un peu moins de 110 Euros.

      C'est une imprimante réseau qui supporte (entre autres) le protocole lpr/lpd. Pour ce qui est du langage, elle a un interpréteur PCL 6. Elle est donc parfaitement compatible Linux.

  • # La force du libre

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

    Une fois de plus, cela démontre un bel exemple de ce que le libre est capable de faire. Un grand bravo à la personne à l'initiative de ce projet. Je suis sur que les possesseurs d'imprimantes Samsung ne manqueront pas de contribuer dans un avenir proche pour faire grandir le projet.

    Je me posais une question d'ailleurs concernant les pilotes d'imprimantes. J'ai du dépanner des personnes passant de Windows vers Linux et il serait appréciable qu'un consorcium similaire à l'OSDL se penche sur une initiative pour sensibiliser les fabriquants d'imprimantes à fournir des vrais pilotes.

    • [^] # Re: La force du libre

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

      Lors de ce travail, j'ai pu me familiariser avec le monde des démons d'impression sous UNIX qui m'était vraiment pas familier ; et j'ai été assez étonné de voir l'excellente idée adoptée par CUPS.

      Pour rappel, CUPS a étendu le domaine d'application des fichiers PPD, qui étaient initialement utilisés pour les imprimantes PostScript, à toutes les imprimantes. Une nouvelle entrée dans ces fichiers, baptisé Filter, indique le chemin du programme (filtre) à utiliser pour convertir le document dans le langage de l'imprimante. Étant donné que le langage n'est pas réinventé à chaque nouvelle imprimante, l'idée devient intéressante.

      Alors, pour chaque nouvelle imprimante, le fichier PPD est utilisé pour renseigner le filtre des fonctionnalités de l'imprimante : les nouvelles résolutions, le recto-verso etc. Enfin, lors de l'appel du (ou des) filtres, le fichier PPD correspondant à l'imprimante est passé.

      Tout ça pour dire que cette approche, loin de celle adopté ailleurs, permet de très rapidement mettre en ½uvre des pilotes pour imprimantes. Enfin, il est important de noter le fait que cette approche a aussi été adoptée par LinuxPrinting ; mais sous forme de fichiers XML. Donc certes, il reste du chemin à faire pour rendre tout cela homogène mais à l'heure actuel, il est vraiment très aisé d'écrire un pilote pour imprimante.

      • [^] # Re: La force du libre

        Posté par  . Évalué à 1.

        Je ne souhaite pas faire de pub pour une marque particulière mais je suis très satisfait de ma brother laser usb HL 5040 qui a fonctionné directement, que ce soit sous suSe ou Mandriva.

        Je m'étais orienté vers ce modèle car les tests sur internet la classaient en tête pour le coût à l'impression et en rapport qualité / prix, le tout avec mention compatible linux sur le carton.

  • # Méthode !

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

    Ceci est très intéressant ! Merci pour ton travail !

    Sinon, est-ce que tu pourrais détailler la méthode que tu as utilisée pour trouver ces informations ? Utilisation du pilote sous Windows et sniff des paquets USB ? Et ensuite, pour essayer de trouver une structure dans ce bazar, comment as-tu procédé ?

    • [^] # Re: Méthode !

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

      A mon avis oui, un site travaillant sur un pilote de webcam a quelques documentations sur le sujet : http://zc0302.sourceforge.net/zc0302.php?page=docs

    • [^] # Re: Méthode !

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

      Pour commencer, j'ai d'abord regardé l'allure des données transmises à l'imprimante en utilisant l'option « imprimer dans un fichier » sous Windows (les données ainsi stockées dans le fichier sont les données sorti du pilote donc dans le langage de l'imprimante).
      Par la suite, j'ai décompilé les pilotes pour Linux et Win puis j'ai analysé le code asm pour tenter de retrouver les différentes structures envoyées puis les algos. J'avoue que le pilote sous linux m'a beaucoup aidé car il utilise ghostscript pour obtenir un fichier PBM ce qui donne une bonne base de départ pour continuer la progression dans le code décompilé.

      Malheureusement le pilote Linux n'intégrant pas toutes les fonctionnalités du langage, je continue ce travail sur celui de windows.

      • [^] # Re: Méthode !

        Posté par  . Évalué à 4.

        Eh bien j'espere que Samsung ne se comportera pas comme Plextor qui m'ont menace de proces (ainsi qu'Alex Noe) pour avoir publie un logiciel permettant de scanner la qualite des DVDs avec leur graveur sous Linux (sans meme faire de reverse engineering des pilotes, juste en ecoutant le port I/O).

        • [^] # Re: Méthode !

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

          Ils peuvent me menacer de ce qu'ils veulent, je m'y suis préparé psychologiquement. J'ai la chance d'habiter dans un pays (la France) où l'ingénierie inversée est autorisée pour des raisons d'interopérabilité, ce qui me semble être le cas ici. Tant que je n'ai pas utilisé leur code pour faire mes pilotes, ils ne peuvent pas grand chose.
          À mon avis, ils comptent surtout sur l'intimidation provoquée.

          • [^] # Re: Méthode !

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

            Au sujet du Reverse Engeneering, une excellente présentation (en Anglais) sur le sujet : http://www.foo.be/re/

          • [^] # Re: Méthode !

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

            Aurélien++ :-)

          • [^] # Re: Méthode !

            Posté par  . Évalué à 1.

            Je vais me faire l'avocat du diable, mais on se situe dans ce cas aux frontières (floues, certes) du domaine de l'inter-opérabilité. Cette dernière vaut surtout pour des liaisons entre systèmes informatiques, entre processus et établit le fait que des données générées par un système A puissent être convenablement par un système B. Pour un périphérique de sortie, du reste non "vital" (pour l'écran ce serait autre chose), cela me semble plus discutable. A moins d'établir le fait qu'aucune imprimante ne fonctionne sous Linux, invoquer la clause d'interopérabilité est contestable dans la mesure où l'on peut se voir répondre "qu'il existe pléthore d'autres marques qui fonctionnent nickel sous Linux"...

            Cela-dit, j'aime quand la communauté, souvent mise en mouvement par un seul individu, fait la nique aux industriels qui déclarent qu'"Economiquement, le développement que vous demandez ne nous rapporte rien donc vous n'aurez rien dans ce sens.". Là où ça peut devenir moche, c'est quand les boîtes susdites, "doublées" sur leur propres produits par l'intelligence collective des utilisateurs, sont mauvaises joueuses et s'appuient de tout leur poids sur des lois protectionnistes et des brevets à la c.. pour faire avorter ces projets "concurrents".

            • [^] # Erratum

              Posté par  . Évalué à 1.

              Ne pouvant corriger mon entrée précédente, je me réponds à moi-même pour une micro-correction. Vous aurez de vous-même corrigé la phrase :
              "...que des données générées par un système A puissent être convenablement par un système B."

              en
              "...que des données générées par un système A puissent être convenablement exploitées par un système B."

              • [^] # Re: Erratum

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

                A moins d'établir le fait qu'aucune imprimante ne fonctionne sous Linux, invoquer la clause d'interopérabilité est contestable dans la mesure où l'on peut se voir répondre "qu'il existe pléthore d'autres marques qui fonctionnent nickel sous Linux"...
                heureusement que la clause d'interopérabilité concerne le matériel récalcitrant en question et ne se résume pas, comme tu sembles le faire, à dire "z'avez qu'à acheter un autre modèle qui lui marche" (toute ressemblance avec le discours des constructeurs serait purement fortuite).

          • [^] # Re: Méthode !

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

            Oublie pas que la FSF France a décidé de mettre en place une réserve pour les logiciels libres menacés, et qu'elle a décidé d'aller en justice quand ce sera nécessaire. Hésite pas à te tourner vers eux.

        • [^] # Re: Méthode !

          Posté par  . Évalué à 3.

          S'ils ont mis "compatible linux" sur la boîte et que cela ne fonctionne pas sans l'ajout d'un module, n'est-ce pas de la publicité mensongère?

      • [^] # ghostscript

        Posté par  . Évalué à 2.

        j'ai décompilé les pilotes
        Tu est bien courageux!

        car il utilise ghostscript pour obtenir un fichier PBM
        C'est risible. Tant de secret pour utiliser ghostscript comme raster.

      • [^] # Re: Méthode !

        Posté par  . Évalué à 3.

        Juste une question en passant,

        Décompiler un programme est une démarche de reverse enginering ? Pour faire du RE, ne doit on pas se limiter aux interactions entre la "boite noire" et l'extérieur (réseau, appels systèmes ...)

        Je me demande simplement oùse trouve la limite entre RE et réutilisation de code. Si quelqu'un peut éclairer ma lanterne ...

        Gnol

        • [^] # Re: Méthode !

          Posté par  . Évalué à 2.

          Je suis loin d'être spécialiste, mais j'avais compris comme toi : la décompilation est expréssément interdite par la licence du soft en général, et ça dépasse le "reverse ingeneering". Mais peut-être me trompe-je...

          • [^] # Re: Méthode !

            Posté par  . Évalué à 2.

            Devant l'affluence de réponses, j'ai été faire un tour sur mon copain wikipedia. Et j'y apprends que je me trompje !


            La rétro-ingénierie s'applique aussi au logiciel. Ceci peut être réalisé en utilisant des outils d'analyse comme le décompilateur. Les méthodes employées sont similaires à celle du débogage


            Donc la décompilation est parfaitement légale pour le RE... sauf si c'est prévu dans la licence ?

            • [^] # Re: Méthode !

              Posté par  . Évalué à 2.

              Si c'est légal, alors la licence ne peut rien y faire (d'ailleurs, c'est souvent marqué : sauf disposition contraire gna gna pays de résidence). Mais bon, personnellement, je ne l'aurais pas fait non plus. Je pensais que le reverse ingeneering consistait à reproduire le contenu de la boite noire sans y toucher. Soit. Il apparait qu'on a le droit de tout pêter et d'essayer d'ouvrir la boite noire pour voir comment c'est foutu dedans.

              Une question cependant : dans quelle mesure a-t-on le droit de s'inspirer du code assembleur? Est-ce que le code assembleur est une oeuvre de l'esprit, et est protégé comme tel? Je pense que c'est le cas, parce que 1) des masochistes codent parfois direct en assembleur, et 2) un même algo, en fonction du "talent" du codeur, peut donner différents résultats en assembleur, même en tenant compte des performances du compilo.

              Je persiste à penser que la décompilation est limite limite 1) vis-à-vis de la protection des logiciels et du respect de la licence associée, et 2) vis-à-vis de la propriété intellectuelle. L'interopérabilité est légale, mais je ne sais pas où sont les limites à ne pas franchir : l'interopérabilité n'est pas au dessus des autres lois; on ne peut pas prendre Bill Gates en otage pour avoir les specs du .doc, on ne peut pas payer un agent secret pour aller piquer les plans et les specs de la dernière ATI, etc.

              • [^] # Re: Méthode !

                Posté par  . Évalué à 1.

                Malgré l'article que j'ai lu, je continue aussi à me dire que c'est limite limite...
                exactement pour les même raison que toi.

              • [^] # Re: Méthode !

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

                Lorsque je parle d'utiliser l'ingénierie inverse pour développer les pilotes, je n'ai certainement pas décompilé les sources, traduit l'asm en C et mis tout ça dans un fichier pour le mettre en ligne. Cette technique étant interdite.

                Ce que j'ai fait, c'est décompiler les sources pour comprendre l'algorithme de compression des données. Car même un génie aura bien du mal à retrouver l'algorithme de compression en ne s'inspirant que du résultat compressé. Ensuite, une fois l'algo compris, j'ai fermé les sources et j'ai recodé juste à l'aide de la spécification que j'ai écrite, le pilote. Et à mon humble avis, les deux codes génèrent le même résultat mais ils diffèrent allègrement !

                Par conséquent, j'estime avoir utilisé l'ingénierie inverse uniquement dans le cadre de l'interopérabilité et qu'il n'y a eu en aucun cas pillage de code. Par conséquent, rien n'est répréhensible.

                • [^] # Re: Méthode !

                  Posté par  . Évalué à 2.

                  OKOK je comprends mieux. J'aurais pensé (peut-être naïvement?) que le nombre de méthodes de compression était fini. Tu veux dire qu'ils utilisent leur propre algo de compression? Quel est l'intérêt de ce truc, à part éviter le reverse-ingeneering? Est-ce que tu ne devrais pas éviter d'expliquer que tu as décompilé le driver original (même si vu ton explication, c'était légitime?). Vu la technique utilisée, personne ne l'aurait jamais deviné, par contre je doute toujours de la légalité de l'acte de décompiler)

                  • [^] # Re: Méthode !

                    Posté par  . Évalué à 4.

                    Tu n'es pas naïf en pensant que le nombre est fini : il l'est. Mais il est grand ;o)

                    En gros, tu as deux parties dans un résultat de compression : les données compressées et des méta-données (p.ex. le nom original, la taille, le prénom de la petite nièce du directeur...). Si la méthode utilisée est une méthode classique, sans (trop) de modification (genre, juste un décalage), on peut la retrouver (p.ex. avec hachoir). Mais ça devient vite difficile.

                    En ce qui concerne la décompilation : le principe est de retrouver le format des données et le protocole de communication, par le biais de l'algorithme. C'est là que la décompilation est légale car c'est le (seul) moyen de trouver l'algorithme.

                    Et mentir est rarement une bonne idée.

                • [^] # Re: Méthode !

                  Posté par  . Évalué à 1.

                  Je n'ai jamais remis en cause ton travail, je n'avais même pas imaginé que tu avais fait autre chose que chercher l'explication à certaine. Je sais bien, pour avoir fait la même chose, que ton code C ne ressemble certainement pas à l'original. La question n'est pas là.

                  Je voulais juste savoir dans quelle mesure on a le droit de le faire même si c'est la seule solution technique.

                  Après m'être renseigné de ci et de là, ma conclusion est que décompiler, c'est du reverse engineering. Mais que avoir le droit de décompiler n'est pas systématique : d'un côté tu peux argumenter sur le cadre de l'interopérabilité et sur ta bonne foi, de l'autre tu peux argumenter sur le non respect de la licence qui donne seulement le droit d'utiliser le binaire. Bref en cas de conflit, c'est bras de fer juridique.

                  • [^] # Re: Méthode !

                    Posté par  . Évalué à 3.

                    >d'un côté tu peux argumenter sur le cadre de l'interopérabilité et sur ta bonne foi, de l'autre tu peux argumenter sur le non respect de la licence qui donne seulement le droit d'utiliser le binaire. Bref en cas de conflit, c'est bras de fer juridique.

                    Non, car il est précisé dans le texte de la licence que la loi du pays prévaut sur les restrictions qu'elle pourrait contenir.
                    Ainsi, les constructeurs veulent faire peur aux utilisateurs en espérant (à juste titre, d'ailleurs) que ces derniers ne connaissent pas leurs droits.

  • # Chapeau bas...

    Posté par  . Évalué à 3.

    Je ne possède pas d'imprimante Samsung mais à la lecture de ce journal j'ai envie de te féliciter pour ton excellente initiative et ton investissement personnel (et exemplaire!).

    Encore bravo.

  • # RMS ?

    Posté par  . Évalué à 6.

    Richard, c'est toi ?

  • # Et Lexmark dans tous ça...

    Posté par  . Évalué à 1.

    Pour ma part, j'ai toujours pas la chance avec moi pour mon imprimante Lexmark X83 qui reste désespérément inactive depuis que je suis passé sous Linux totalement...

    j'embête de temps en temps la hotline de Lexmark pour savoir quand est ce qu'il compte "faire de drivers" ou "rendre public les spécifications" (si ce n'est pas déja fait :-) )...

    Si quelqu'un a des infos...

    • [^] # Re: Et Lexmark dans tous ça...

      Posté par  . Évalué à 1.

      en essayant de faire fonctionner mon scanner Mustek, j'ai vu je sais plus comment (scanImage -L je crois) que le scanner de mon X83 (en état végétatif depuis plus d'un an) semblait être reconnu...

      ca ferait quand même un truc d'utilisable sur la x83 :)

      • [^] # Re: Et Lexmark dans tous ça...

        Posté par  . Évalué à 1.

        tu veux dire qu'avec les drivers de ton scanner Mustek, je pourrais piloter mon scanner ? non je rêve...

        • [^] # Re: Et Lexmark dans tous ça...

          Posté par  . Évalué à 2.

          non, je veux dire qu'en scannant les ports usb pour trouver mon Mustek, j'ai également trouvé le scanner intégré à mon X83

          quand à trouver un driver pour scanner avec la X83, je me souviens plus si j'avais vraiment cherché, mais j'étais tombé sur un truc qui y ressemblait sur je sais plus quel site...

          va voir la doc gentoo concernant les scanner, c'est par la que j'ai trouvé toute ma doc ;)

    • [^] # Re: Et Lexmark dans tous ça...

      Posté par  . Évalué à 1.

      Un ami a acheté une Lexmark X1190 pour son prix très bas. C'est une multifonction.
      Comme je lui avais installé Linux en dual boot il m'a demandé de la faire marcher sur notre système préféré. Après quelques recherches j'ai vu que qu'un driver d'un modèle moins récent marchait très bien. Je pense qu'en général cela doit être souvent le cas. Les nouveaux modèles apportent des fonctionnalités ou des performances en plus. Mais le pilotage est grosso le même.
      Donc pour la Lexmark X1190, le driver z600 fonctionne très bien. Tu peux l'essayer:
      http://www.ubuntuforums.org/showthread.php?t=49714

      • [^] # Re: Et Lexmark dans tous ça...

        Posté par  . Évalué à 1.

        Merci, je vais essayé ça.
        On ne sais jamais les constructeurs ne changes pas leur spéc tout le temps d'une imprimante a une autre.

  • # Est-ce la bonne solution ?

    Posté par  . Évalué à 2.

    Au final est ce qu'on ne ferait pas mieux de ne pas acheter tous ces accessoires non compatibles linux, ou non livrés avec un pilote libre, plutôt que de les rendre compatibles sur le temps libre de bénévoles ?
    Vu la tournure prise par les lois actuellement (pas de reverse engineering, etc etc) non seulement le volontaire se met en danger dans certains pays s'il développe ce pilote sans le constructeur mais en plus c'est le constructeur qui va récolter encore plus d'argent en rajoutant un logo "compatible linux".
    C'est comme les personnes qui font des efforts pour liberer l'iPod de ses DRM (http://ipodlinux.org/Main_Page) et nous permettre de l'utiliser en restant libres, combien de temps avant qu'Apple leur fasse un procès ?

    • [^] # Re: Est-ce la bonne solution ?

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

      Justement, cette imprimante était marquée "compatible linux" par Samsung.
      Et si tu relis bien le texte de la dépèche, elle l'est effectivement, mais sous certaines conditions qui ne plaisaient vraiment pas à l'auteur du projet.

      • [^] # Re: Est-ce la bonne solution ?

        Posté par  . Évalué à 5.

        Compatible moyennant l'achat d'un module optionnel, je n'appelle pas ça compatible...

        • [^] # Re: Est-ce la bonne solution ?

          Posté par  . Évalué à 4.

          C'est comme si on te vend une voiture sans te dire qu'il faut acheter le moteur en option pour qu'elle puisse rouler.. ;-)

        • [^] # Re: Est-ce la bonne solution ?

          Posté par  . Évalué à 3.

          Il ne faut pas se plaindre, ça pourrait être compatible linux via un serveur windows.

    • [^] # Re: Est-ce la bonne solution ?

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

      Pour ma part, comme tout matériel avant achat, j'ai contrôlé sur le net si des pilotes pour GNU/Linux étaient disponibles. La seule chose que j'ai trouvé, c'est la note sur le site du constructeur « Compatible Linux RedHat, Mandrake, SuSe, .. ». Linuxprinter n'ayant pas encore répertorié l'imprimante. J'ai donc daigné faire confiance à Samsung. Sauf que, une fois acheté, plus moyen de la rendre donc quitte à avoir une imprimante, autant qu'elle serve non ?
      Et si procès il y a, Samsung devra sûrement rendre des comptes à la notice « Compatible Linux ». Sans ça, jamais je n'aurais choisi ce modèle !

      Moralité, ne plus jamais se fier à cette notice et si non répertorié sur linuxprinter, ne surtout pas acheter :)

    • [^] # Re: Est-ce la bonne solution ?

      Posté par  . Évalué à 2.

      Y a aussi des gens qui basculent sous Linux et qui se retrouvent avec du matériel non-compatible... :-)

      • [^] # Re: Est-ce la bonne solution ?

        Posté par  . Évalué à 8.

        Sans compter qu'il me parait difficile de dire à un bénévole "Non, ne fais pas ça, tu devrais plutôt t'atteler à l'intégration du CMNJ dans The Gimp, c'est beaucoup plus utile". Le mec a une imprimante, du temps libre, les compétences pour ´écrire un driver, bah il le fait, c'est son choix. Ensuite qu'il le partage avec le reste de la communauté, c'est bien pour tout le monde, non? (au passage, ce gars peut demain envoyer une lettre de motivation à Samsung en disant qu'il a fait en trois semaine ce que les branquignoles du service dev. n'ont pas été foutu de faire correctement depuis que les Samsung marquent "compatible Linux" sur les boîtes. Je pense que ça peut marquer un DRH à vie :-) ).

        Par contre, ça permet de s'apercevoir que la mise au point de drivers d'imprimantes par une procédure tortueuse (reverse-ingeneering par exemple) est l'affaire de quelques semaines pour quelqu'un de motivé. Alors imaginons combien de temps ça prendrait à une équipe de professionnels qui a le protocole de communication sous les yeux et qui vient de faire les drivers pour Windaube/Mac la semaine d'avant. Si ces boites ne fournissent pas de drivers Linux corrects, c'est pas parce qu'elles n'en n'ont pas les moyens, c'est parce qu'elles s'en foutent complètement, ou qu'elles ne daignent pas embaucher un seul gusse compétent qui connaisse un minimum Linux.

  • # Un mauvais produit!

    Posté par  . Évalué à 5.

    La réponse fût claire et précise : « Pour utiliser l'imprimante ML-2250 sous Linux, vous devez vous procurer le module PostScript optionnel. » (Il est à noter que ce module coûte plus de la moitié du prix de l'imprimante).
    La réponse est très pertinente.

    Je voudrais bien savoir qu'elle est intérêt (pour la humanité) d'inventer des langages (propriétaires), alors que PostScript est ouvert, un standard, et fût révolutionnaire en son temps en comparaison. Combien coûte le développement d'un asic comparé à un moteur de rendu ps standardisé? Et Linux dans l'imprimante?

    De même, qu'elle est l'intérêt de vendre dans le même magasin une imprimante avec un autocollant samsung et une autre avec un autocollant xerox?

    Un élément de réponse:

    D'après ta doc, spl est un langage point par point. Ce qui veut dire que l'imprimante n'a pas de moteur de rendu. Ce qui semble donc être une logique low cost. On vend l'imprimante fabriqué en chine par des quasi esclaves pour quelques euros, puis on raquette le consommateur avec l'encre pour beaucoup d'euros. Quand l'imprimante est morte, soit quelque temps après la fin de la garantie (très écologique), on recommence le processus.

    Mon avis: boycottons ses produis!

    • [^] # Re: Un mauvais produit!

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

      Je voudrais bien savoir qu'elle est intérêt (pour la humanité) d'inventer des langages (propriétaires), alors que PostScript est ouvert, un standard, et fût révolutionnaire en son temps en comparaison


      C'est facile, supporter tout PostScript sur une imprimante ca coute cher, faire un sous-language facile a supporter par l'imprimante, et traduire le postscript (ou autre) dans ce language, ca coute moins cher

      http://l-lang.org/ - Conception du langage L

      • [^] # Re: Un mauvais produit!

        Posté par  . Évalué à 2.

        ça coûte cher
        Il y a 10 ans sûrement. Mais avec les progrès de l'électronique une plate forme Linux embarqué coûtera presque rien pour de tel volume. Le Palm Z22 coûte 120 euros. Si tu soustrais le prix de l'écran (cher!), le boîtier, la boîte, la puce de l'imprimante ... Évidement avec des budgets low cost de 50, 100 euros pas moyen.

        En faîte pour ce type d'imprimante le moteur de rendu (coûteux en cpu) est déporté sur l'ordinateur. Pour une imprimante personnelle c'est plus économique, et corrigible après la fabrication 1)2). Mais qu'ils utilisent un standard!

        1) et encore il faut gérer l'usb et // (payer le core ip), le protocole, décoder les données, l'imprimante ... cela requiert moins de puissance cpu mais ça doit pas être un petit code VHDL. C'est plus une logique low cost qu'économique et écologique.

        2) avec l'inconvénient majeur d'un débit monstrueux, du 600*600 en a4 ça fait de l'ordre de 4.5Mo. C'est sûrement pour cette raison que cette technique est utilisé uniquement sur les imprimantes bas de gamme car 10 pages/s => 45Mo/s = 360Mb/s sur le bus (bande passante théorique: usb 12Mb/s et usb2 480Mb/s).

        • [^] # Re: Un mauvais produit!

          Posté par  . Évalué à 6.

          Sauf que pour pouvoir prétendre qu'une imprimante embarque un interpréteur PostScript, il faut payer Adobe. Et ca, c'est cher...

  • # Rehabiliter Samsung

    Posté par  . Évalué à 2.

    Je souhaite rehabiliter Samsung car ce sont les premiers a avoir fait des imprimantes laser grand-public compatibles linux.

    Ma ML-4600 (pas toute recente je dois l'admettre) est compatible PCL, elle contient de la RAM (4Mo, extensible avec de la RAM EDO), un processeur (RISC 66MHz) et debite 8ppm. En 2001, elle coutait 200E.

    On peut juste regreter que la ML-4600 soit la seule de la serie a utiliser des driver vraiment open-source.

    • [^] # Re: Rehabiliter Samsung

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

      > En 2001, elle coutait 200E.

      En 2001 tu payais déjà en Euros ? Fort le mec !

      ok, je sors :)

    • [^] # Re: Rehabiliter Samsung

      Posté par  . Évalué à 3.

      Hein?
      Ce n'est pas parce qu'ils ont fait quelque-chose de bien sur un modèle qu'il n'y a pas de quoi s'indigner quand ils prétendent être compatible Linux, mais ne le sont pas sur un autre modèle: c'est de la publicité mensongère!

  • # Chez moi ça marche !

    Posté par  . Évalué à 2.

    Il fait avoir installé des paquets du genre libcups-xxx-devel sur sa machine pour installer ces drivers. Suite à quelques problème de miroirs et dépendances dus à des bidouillages excessifs, j'ai dû installer cups 1.1.3 à la main.
    Ensuite l'installation s'est faite sans aucun problème et maintenant mon imprimante Samsung ML 2010 marche parfaitement sous Linux !

    Merci au développeur de ce projet !

  • # Imprimer dans un fichier

    Posté par  . Évalué à 1.

    imprimer dans un fichier, lire le postcript, avoir le PBM, lire de l'asm pour comprendre l'algo, chapeau bas... Il faut le faire.

    Je n'emploie pas Samsung mais je t'encourage à continuer.

Suivre le flux des commentaires

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