Journal Sortie du driver Via openchrome 0.6

Posté par  . Licence CC By‑SA.
19
7
mar.
2017

Pour les gens ayant usage de ce driver, Openchrome continue d'évoluer \o/
Après la version 0.4 sortit fin mars 2016, une 0.5 est sortit entre temps, suivit de la 0.6 aujourd'hui.

Rappel, ce driver concerne les igp (chipset graphique) de marque Via.

La 0.5

-correction de bugs
-apporte un support initial a l'utilisation de plusieurs écrans
-le support VIA VT1632A TMDS pour la sortie dvi
-une amélioration de la mise en veille en mode S3
-ainsi qu'un nettoyage du code pour une meilleur compréhension.

La 0.6 :

-ajoute un 1er support pour Silicon Image SiI 164 TMDS transmitter
-apporte une meilleur réinitialisation de l'écran pour certains notebook après une mise en veille.
-améliore la détection automatique permettant éventuellement de se passer d'un xorg.conf
-une meilleur stabilité en mode dual screen
-et corrige un bug apporté lors de la 0.5 concernant un conflit entre le wifi et openchrome pour le netbook hp 2133.

Le drm a également reçu un paquet de corrections, cependant il semblerait que ce drm codé a la base par James Simmons soit pour le moment compatible uniquement avec un kernel 3.19 maximum.
En effet, de gros changements ont été apportés a la conception du drm a partir des kernel 4.* et demande un gros travail de refonte du code.

Pour faciliter l’installation du driver, un utilisateur a créé un ppa pour ubuntu.

  • # Beau travail

    Posté par  . Évalué à 8.

    C'est toujours beau de voir quelqu'un batailler avec du matériel démodé, pour l'amener à fonctionner. Ça a l'air inutile au départ, puis on découvre que des milliers de machines sont recyclées grâce à ce travail.

    J'ai eu utilisé un portable avec cette famille de puces graphiques, vers 2003. Ça fonctionnait sur Linux avec de l'OpenGL 1.2… ce qui suffit aujourd'hui pour Minetest ;-)

    ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

    • [^] # Re: Beau travail

      Posté par  . Évalué à 3.

      c'est clair, que ce dev est très courageux de reprendre tout seul ce projet, surtout vu le peu d'aide ou de réponses qu'il obtient de la part des autres dev.
      "On a separate note, I tried contacting Dave Airlie, who maintains DRM, but I got completely ignored."

      Je trouve cela malheureux pour quelqu'un qui passe tout son temps libre sur un projet open source.

      Si, j'ai bien compris, on lui a même recommandé d'abandonner le drm actuel et d'en faire un nouveau très basic avec juste le support vga et kms pour ensuite l'ajouter dans le kernel et l'améliorer au fur et a mesure.
      Quand on sait que le drm actuel a pris 4 ans a James pour être conçu "(James appears to have spent 4 years on drm-openchrome.)", je trouve cela assez fou, limite du foutage de gueule.

      Les autres dev trouvent cela compliqué d'ajouter/vérifier un "gros" drm dans le kernel actuel, ce que je peux comprendre, mais il fallait ptet le dire avant aussi …

      • [^] # Re: Beau travail

        Posté par  . Évalué à 3.

        Les autres dev trouvent cela compliqué d'ajouter/vérifier un "gros" drm dans le kernel actuel, ce que je peux comprendre, mais il fallait ptet le dire avant aussi …

        Ils l'ont dit avant, c'est-à-dire dès qu'ils ont su qu'il travaillait dessus. Il faut comprendre et accepter qu'on n'a pas les ressources pour intégrer toutes les dernières technologies graphiques tout en portant dessus des pilotes obsolètes.

        Je trouve le résultat équilibré : il propose du code, s'il arrive à le rendre assez propre - cela veut dire sûr - il sera accepté dans le noyau officiel. Pour l'instant, on peut le picorer à la main.

        ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

        • [^] # Re: Beau travail

          Posté par  . Évalué à 2.

          Et ce drm, une fois "sur" sera accepté dans son intégralité dans le kernel ?
          A l'époque quand James avait tenté de le "push" dans le kernel, si je dis pas de bêtise on lui avait demandé de diviser tout ce code en 20 patchs, je ne suis pas développeur mais j'imagine la dose de travail que ça doit demander.

          Il serait intéressant que certains dev, plus renseigné/plus compétent sur le sujet puissent lui apporter de l'aide pour le drm (le plus gros) même si je me doute bien que les ressources sont limitées, ça fait quand même suffisamment longtemps que ça traîne cette histoire du drm Via au sein du kernel.

          Il y'a encore pas mal de matos qui tourne avec du Via, netbook, les carte mères Via epia, et pas mal d'autres cartes mères dit a faible budget, ça serait très intéressant que ce matos puisse tourner correctement sous linux.
          Je possède depuis 2/3 mois, un netbook 12 pouces avec via nano 1.6ghz + chipset vx800, bien que ce netbook date de 2009, il tourne plutôt pas mal (et un écran 12 pouces, c'est nettement plus agréable qu'un 10 ou 9 pouces, bref c'est un bon compromis)

          • [^] # Re: Beau travail

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

            Et ce drm, une fois "sur" sera accepté dans son intégralité dans le kernel ?
            A l'époque quand James avait tenté de le "push" dans le kernel, si je dis pas de bêtise on lui avait demandé de diviser tout ce code en 20 patchs, je ne suis pas développeur mais j'imagine la dose de travail que ça doit demander.

            Oui redécouper les correctif cela représente beaucoup de travail, mais tout contributeur du noyau sait que c'est une étape importante. Cela ne devrait pas être une si grande surprise pour lui.
            Il faut comprendre que plus ton correctif est petit et unitaire, plus il est simple à appréhender et à maintenir. Le noyau est un très grand projet, l'un des plus dynamiques du monde, il est essentiel que la maintenance soit simplifiée et c'est très clair dans la politique du développement du noyau de tout faire pour faire des correctifs le plus unitaire possible.

            Puis, on ne peut pas dire que son travail soit une priorité pour justifier une exception ou un coup de main de la part des mainteneurs (qui sont assez occupés).

            C'est d'ailleurs l'une des raisons pour laquelle seuls des petits bouts du correctifs grsecurity a été accepté dans le noyau officiel, son auteur n'ayant jamais voulu redécouper son travail.

Suivre le flux des commentaires

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