Intel ne maintient plus le pilote Linux Poulsbo depuis un an et demi

Posté par (page perso) . Modéré par tuiu pol.
Tags : aucun
32
31
oct.
2009
Serveurs d'affichage
Poulsbo ou « Intel GMA 500 » est une puce graphique utilisée dans de nombreux netbooks, téléphones et autres équipements embarqués, qui fleurissent dans nos magasins. Elle est supportée par Ubuntu 8.04, 9.04 et 9.10, Fedora 11 et Mandriva Linux.

Sauf que le pilote utilise des briques propriétaires et n'est plus maintenu depuis mars 2008. C'est pourquoi il n'existe pas, par exemple, dans Debian et risque de disparaître à court terme. D'ailleurs, l'installation est délicate (exige des manipulations) et le pilote n'est pas exempt de bug.

Cet article tente d'expliquer la situation actuelle du pilote Linux et vise à avertir les futurs acquéreurs de netbooks associant forcément (à tort) Intel à « pilotes libres ». Poulsbo dans les netbooks

Séduit par un excellent compromis entre son autonomie (10 heures) et sa taille (écran de 11,6 pouces, clavier confortable), je me suis offert un Eee PC 1101HA blanc (un vrai appeau à geek !). Je me suis empressé de remplacer Windows XP par Debian Sid. Le son et le réseau (ethernet et wifi) sont bien reconnus, par contre Xorg se lance avec le pilote générique (VESA) qui ne possède pas d'accélération matérielle.

En enquêtant (lspci), j'ai découvert que le contrôleur graphique est le Poulso (Intel GMA 500). Il fait parti de la puce « Intel System Controller Hub US15W » qui comprend également des contrôleurs mémoire, audio, USB 2.0, PATA, PCI Express, etc. Cette puce est utilisée sur de nombreux netbooks récents pour sa faible consommation mémoire.

Puces SGX

Le Poulsbo date de 2007 et est un assemblage entre un i810 (pour la 2D), un PowerVR SGX 535 (pour la 3D) et un PowerVR VXD 370 (pour l'accélération vidéo).

Les puces graphiques SGX sont populaires dans l'embarqué, l'iPhone 3GS utilise également un SGX 535. Les microprocesseurs OMAP3 et OMAP4 incluent un processeur ARM Cortex A8/A9 et un SGX 530/540, et sont utilisés, par exemple, dans la majorité des téléphones Nokia de la série N ou sur le Beagle Board.

Le pilote Linux de Poulsbo...

J'ai appris à mes dépends que le support Linux du Poulsbo est exécrable et a une longue histoire.

Contrairement aux autres GPU Intel, le Poulsbo utilise donc des puces PowerVR d'Imagination Technologies. Intel a commandé le pilote à Tungsten Graphics en 2007 et l'a publié début 2008. Le pilote est composé de plusieurs parties :
  • psb-kmod : Module noyau sous licence GPLv2, charge le firmware ;
  • psb-firmware : Microcode propriétaire (fichier msvdx_fw.bin) pour la 3D et l'accélération vidéo ;
  • libdrm-poulsbo : Interface noyau/espace utilisateur basée sur libdrm 2.3.0, licence MIT ;
  • xorg-x11-drv-psb : pilote 2D pour Xorg implémentant EXA (accélération 2D) ;
  • xpsb-glx : pilote Xorg propriétaire pour la 3D et l'accélération vidéo (distribué sous forme de bibliothèques dynamiques précompilées) ;
Le pilote Linux n'est plus maintenu par Intel depuis mars 2008. Alors que le pilote Windows (XP et Vista) est toujours mis à jour : la dernière version du pilote date du 11 août 2009.

Tentative d'inclusion dans le noyau Linux

Greg Kroah-Hartman a proposé l'intégration du pilote Poulsbo dans le noyau Linux en mars 2009. Le pilote ne peut pas être inclus tel quel, il faudrait supprimer la partie chargeant le firmware, et ne conserver que le support de la 2D. La 3D et l'accélération vidéo, reposant sur un firmware et un pilote Xorg propriétaire, ne peuvent pas être supportées à long terme et ne peuvent donc pas intégrer le noyau. Il faudrait également mettre à jour le pilote pour qu'il utilise la nouvelle version de TTM (gestionnaire de mémoire pour GPU).

Or Greg n'a pas le temps, et personne d'autre ne s'est proposé de le faire. Il n'est pas payé pour ça, et ce devrait être à Intel de faire ce travail. Finalement, la situation n'a pas bougé depuis, le pilote n'est toujours pas intégré dans le noyau.

Packaging dans les distributions Linux

Le pilote a d'abord été packagé pour Ubuntu Hardy (sortie en mars 2008) et notamment utilisé dans le Dell Mini 12 vendu sous Linux. Adam Williamson a adapté le paquet pour Fedora 11 qui est disponible dans RPMFusion nonfree (et non pas Fedora à cause de la licence). Olivier Blin a adapté le paquet pour Mandriva Linux.

Intel ne maintient plus le pilote, mais l'API du noyau et d'Xorg continuant d'évoluer, les packageurs s'échangent des patchs tant bien que mal pour gérer les nouvelles versions du noyau et d'Xorg. Le pilote fonctionne sur un noyau 2.6.31, mais plante sur Xserver 1.7. Bien que seul Fedora 12 utilise Xserver 1.7 pour le moment, les autres distributions devront migrer un jour ou l'autre.

Le support d'Xserver 1.7 va être difficile étant donné que xpsb-glx (pilote Xorg pour la 3D et l'accélération vidéo) n'est distribué que sous forme de bibliothèques dynamiques précompilées, et ne pourra donc pas être patché.

Avenir du pilote

Pour résumer, il est très difficile de faire fonctionner Poulsbo sur les distributions Linux actuelles, et ça ne peut qu'empirer vu qu'Intel ne donne plus de signe de vie.

La seule solution serait de faire de l'ingénierie inverse des puces SGX pour écrire un nouveau pilote. Ce qui serait rentable sur le long terme étant donné le grand nombre d'équipement utilisant les puces SGX... Sauf que Poulsbo est un affreux mélange Intel (i830) et PowerVR (SGX et VXD), configuration exotique qui a peu de chance de réapparaître pour les prochaines puces Intel.

Un autre compromis serait de supprimer les parties propriétaires et se contenter de la 2D (ce qui est largement suffisant dans la majorité des cas).
  • # Le poulsbo...

    Posté par (page perso) . Évalué à  6 .

    faut frapper dessus pour l'attendrir ?
    • [^] # Re: Le poulsbo...

      Posté par . Évalué à  2 .

      faut frapper dessus pour l'attendrir ?

      Oui mais, comme toute viande coriace, même après avoir tapé dessus, la plupart du temps ça reste coriace (je sais de quoi je parle)... Enfin, ça défoule...
      • [^] # Tapes plus fort

        Posté par . Évalué à  2 .

        J'ai vu un episode de mythbuster ou ils y allaient a coup d'explosion pour attendrir la viande, d'après leur mesures les (petits) bouts de viande qui restaient etaient effectivement plus tendres ;-)
  • # Chantons les louanges des pilotes propriétaires

    Posté par . Évalué à  10 .

    Certains sous le couvert du "pragmantisme" défendent et promeuvent l'inclusion des pilotes propriétaires, et font fi de la possibilité que le constructeur puisse un jour abandonner la maintenance de son pilote. Aujourd'hui, c'est une obscure petite entreprise du nom d'Intel, demain ce sera peut-être le "géant" nVidia.
    "Mais ça n'arrivera jamais !" disaient-ils en ricanant, aujourd'hui le pire est arrivé.

    Les pilotes propriétaires sont et doivent rester des citoyens de seconde zone, une roue de secours pour ceux qui n'ont *vraiment* pas d'autres choix, ceux qui ont achetés du matériel non supporté sans le savoir. Achetez des produits compatibles avec les systèmes libres ou en passe de l'être, boycottez le reste.

    En plus, cette histoire était prévisible, le GMA500 est basé sur des technologies PowerVR, une boite très très amicale avec le libre. PowerVR est très probablement à l'origine de ce fiasco, Intel ne voyant que la rentabilité immédiate s'est fait avoir et par la même occasion a "arnaqué" sa clientèle libriste.

    Le GMA500 est une bouze infâme sans avenir, et les libristes le répétent depuis le début. J'espère que ça fera réfléchir à deux fois les "pragmantiques", ceux qui chantent les grâces des pilotes nVidia actuellement l'un des acteurs les moins collaboratifs dans son domaine.
    • [^] # Re: Chantons les louanges des pilotes propriétaires

      Posté par (page perso) . Évalué à  1 .

      Le cas des pilotes nVidia n'a rien à voir avec le cas d'intel.
      Pour la simple raison du professionnalisme: les drivers nVidia Linux existent non pas pour faire plaisir aux Linuxiens, mais parce que y a une vraie demande des professionnels en tout genres, et les drivers nVidia Linux sont certifiés ou je sais pas trop quoi, et donc faire ces drivers est un clair bénéfice à nVidia.
      Le jour où on aura plus de driver c'est soit que nVidia aura coulé, soit que Linux aura coulé.
      Après c'est sûr que les drivers nVidia ne sont pas tout blancs, mais je préfère largement ça aux drivers "libres" que je peux voir chez les autres marques. (bien que les intel non poulsbo ont l'air pas trop mal encore.), qui sont cassés tous les 4 matins, et dont les 3/4 des features manquent à l'appel (On peut faire de l'OpenCL sur GPU avec un driver libre ?).
      Par contre le problème avec les drivers nVidia c'est pour les vieilles cartes, et encore je trouve qu'elles sont plutôt bien supportées, quand je vois à quel point je galère pour essayer de faire marcher une matrox, mais on ne peut pas bénéficier des dernières fonctionnalités genre KMS (bon on me dira qu'avec les cartes récentes non plus.).
      • [^] # Re: Chantons les louanges des pilotes propriétaires

        Posté par . Évalué à  10 .

        Le jour où on aura plus de driver c'est soit que nVidia aura coulé, soit que Linux aura coulé.

        ... ou que nVidia aura décidé que ce n'est plus assez interressant pour eux. nVidia c'est pas l'Abbé Pierre, ils sont là pour faire du pognon. Point. Demande de "pros" ou pas, le jour où ils ne rentrent plus dans leurs fonds ils arrêteront.

        Reste à prier pour que ce jour-là ils préfèrent ouvrir leurs drivers plutot que de laisser sur la paille leurs utilisateurs.
        • [^] # Re: Chantons les louanges des pilotes propriétaires

          Posté par . Évalué à  2 .

          Ils risquent de laisser sur la paille les utilisateurs, dans le sens où 95% du code des drivers NVidia est cross-platform. C'est une des raisons pour lesquelles ils ne veulent pas les ouvrir.
          • [^] # Re: Chantons les louanges des pilotes propriétaires

            Posté par . Évalué à  2 .

            En quoi ça change quelque chose ? un GPU Nvidia c'est quand même pas une simple webcam revendue sous 50 habillages... Si?
          • [^] # Re: Chantons les louanges des pilotes propriétaires

            Posté par (page perso) . Évalué à  10 .

            Ce n'est pas ça qui les empêche de mettre à disposition les specs et la doc complête de leurs matériel, ce que AMD fait. De cette manière, on peut écrire ses propres pilotes le cas échéant.

            Acheter un matos et ne pas avoir de doc, c'est un foutage de gueule absolu. Tous ceux qui ont fait de l'électronique ou bossé sur des systèmes embarqués confirmeront.
            • [^] # Re: Chantons les louanges des pilotes propriétaires

              Posté par (page perso) . Évalué à  6 .

              AMD ne file pas la doc compléte, tout la partie sur le HDMI, et tout ce qui est lié aux DRMs, décodage de vidéo protégé, hein, pas le gestionnaire de rendu direct ) est caché. Notament certains flags de debug, pour lire la mémoire de la puce directement, car ça impliquerais de pouvoir lire les frames décodés.

              Comme les constructeurs sont liés par des NDAs et autre accord de ce genre, ils ne peuvent pas filer leur doc. Mais en aucun cas ceci excuse leur façon de faire, car ils ont décidés de signer le NDA donc ils sont responsables de la non divulgation dans tout les cas.
              • [^] # Re: Chantons les louanges des pilotes propriétaires

                Posté par . Évalué à  6 .

                Certes , mais ce NDA a été signé avant la décision de libérer la doc.
                Et ce NDA n'empêchera jamais le fonctionnement complet de drivers 3D libres, par contre, on ne peut qu'espérer que les pilotes libres puissent un jour décoder le flux HD à l'aide de l'UDV et de l'UDV2 .
                Jusqu'à présent, AMD n'est pas revenu en arrière depuis sa décision de libérer les specifications de leurs GPU. Et la maison mère, sachons le fait ceci aussi complètement pour l'OpenCL ( depuis que l'OpenCL existe ) et pour les processeurs ( depuis plus de 15 ans ) .
                Je ne pense vraiment pas qu'on puisse mettre au même niveau les 3 protagonistes sur cette affaire de libération des spécifications .

                Sedullus dux et princeps Lemovicum occiditur

        • [^] # Re: Chantons les louanges des pilotes propriétaires

          Posté par . Évalué à  10 .

          Reste à prier pour que ce jour-là ils préfèrent ouvrir leurs drivers plutot que de laisser sur la paille leurs utilisateurs.
          Pour rappel, quand même, le jour où ils ont arrêté de développer le driver libre NVidia (il y a longtemps, hein, c'était encore XFree86, et ça ne gérait que la 2D) ils ont obfusqué le code ... (et demandé aux mainteneurs de laisser leur patch obfusquant le code tel quel ; leurs quelques contributions futures, genre pour ajouter des PCI-id et mettre à jour des petits bouts de code, ce sont ensuite toujours faites par des patchs obfusqués). Ça donne une idée de comment ils traiteront les libristes dans le futur.
          • [^] # Re: Chantons les louanges des pilotes propriétaires

            Posté par (page perso) . Évalué à  3 .

            Si le pilote en question était libre, pourquoi est-il obfusqué ? Si le code avant obfuscation était libre, il l'est toujours…
            • [^] # Re: Chantons les louanges des pilotes propriétaires

              Posté par . Évalué à  7 .

              Oui il l'est toujours, c'est le pilote nv. Sauf que toutes les améliorations depuis se sont faites de manière obfusquées, donc tu as le choix entre un driver clair mais qui ne supporte pas les cartes de moins de 5 ans, ou un driver obfusqué (on peut dire qu'il est "libre", c'est la licence qu'il y a dessus, mais vu qu'on peut rien en faire ... d'ailleurs la FSF a fait quelque chose là-dessus avec la GPLv3 je crois, en disant que le code devait être sous sa forme "originale") qui supporte les nouvelles cartes.
          • [^] # Re: Chantons les louanges des pilotes propriétaires

            Posté par (page perso) . Évalué à  4 .

            Pour les gens qui veulent une url vers cet histoire :

            http://airlied.livejournal.com/34017.html

            ceci dit, pour nvidia, on a également vu les devs passer sur du code libre, pour par exemple les pilotes forcedeth ( d'abord pilote proprio, puis pilote en RE, puis nvidia qui abandonne le pilote proprio pour aider le driver forcedeth directement ).

            Je me souviens aussi d'une histoire avec les cartes scsi ( http://www.redhat.com/archives/fedora-devel-list/2004-Novemb(...) ), mais visiblement, dan le cas des cartes graphiques, les DRMs changent la mise.
            • [^] # Re: Chantons les louanges des pilotes propriétaires

              Posté par . Évalué à  9 .

              ceci dit, pour nvidia, on a également vu les devs passer sur du code libre, pour par exemple les pilotes forcedeth ( d'abord pilote proprio, puis pilote en RE, puis nvidia qui abandonne le pilote proprio pour aider le driver forcedeth directement ).
              Ho, que c'est mignon. Ils sortent de la merde en barre, des mecs font bénévolement du reverse-engineering et écrivent un driver libre mieux que ceux de NVidia, au début ils se font ignorer, puis au bout d'un moment NVidia dit "bon ok, on arrête de faire de la merde et on switch sur votre driver". Comment doit-on prendre ce genre d'attitude ? Doit-on dire "ho merci grand NVidia pour ta grande générosité" ? Ou alors essayer de leur gueuler dessus pour leur faire comprendre que ce n'était pas la bonne manière de faire, et qu'ils sont en train de faire pareil avec leurs CGs ?

              En fait, c'est juste un problème de pouvoir/domination : il y a ceux qui aiment bien se prendre des coups du moment qu'ils ont leur susucre de temps en temps, et ceux qui n'acceptent pas ce rapport de force.

              Un matériel _doit_ être vendu avec ses spécifications. "période".
      • [^] # Re: Chantons les louanges des pilotes propriétaires

        Posté par (page perso) . Évalué à  4 .

        Par contre le problème avec les drivers nVidia c'est pour les vieilles cartes, et encore je trouve qu'elles sont plutôt bien supportées, quand je vois à quel point je galère pour essayer de faire marcher une matrox

        Ces derniers mois, la situation s'est dégradée pour les vielles cartes vidéo nvidia.
        Je supporte plusieurs machines (Debian Squeeze/Testing) qui ont des cartes compatibles uniquement avec les drivers "Legacy 71xx".
        - Il a fallut bidouiller un peu pour les faire passer du kernel 2.6.2x au 2.6.30
        - Mais par contre les dernières versions de Xorg (1:7.4+4) sont incompatibles ces vieux drivers...

        La seul solution que j'ai trouvé, a été de limiter la mise à jours des paquets xorg... :=(
        • [^] # Re: Chantons les louanges des pilotes propriétaires

          Posté par . Évalué à  3 .

          Tu es sur de ton coup http://www.nvidia.com/object/linux_display_ia32_71.86.11.htm(...) m'a l'air assez récent pour supporter le 2.6.30 .

          Par contre le support de ces cartes c'est dégradé dans *debian*. J'ai du attendre des mois avant qu'ils integrent la version du legacy 96xx compatible avec les kernel récent...
          • [^] # Re: Chantons les louanges des pilotes propriétaires

            Posté par (page perso) . Évalué à  2 .

            m'a l'air assez récent pour supporter le 2.6.30 .

            pour le support du kernel 2.6.30, cela marche. J'arrive à compiler le module (nvidia.ko) .

            Le problème, c'est le support de xorg "1:7.4+4", le code "glue" entre le module proprio nvidia et le serveur X. C'est lui qui ne suit plus. Sous Debian, c'est le paquet "nvidia-glx-legacy-71xx" qui pose ce problème.

            Par contre le support de ces cartes c'est dégradé dans *debian*. J'ai du attendre des mois avant qu'ils integrent la version du legacy 96xx compatible avec les kernel récent...

            Moi, j'ai dus aller chercher le paquet "nvidia-kernel-legacy-71xx" dans "unstable" (alors que je suis en "testing") pour avoir un module qui se compile.

            Passé un temps, il y avait ceci qui fonctionnait avec un kernel 2.6.30 : http://desiato.tinyplanet.ca/~lsorense/debian/nvidia-71xx-le(...) : Les paquets "glx" (pour xorg) et "kernel" (pour le kernel).
            Mais les dernières mises à jours de xorg ont tout cassé, d'où l'obligation de limiter la version de xorg... :=(
      • [^] # Re: Chantons les louanges des pilotes propriétaires

        Posté par . Évalué à  2 .

        A propos, un interview de nVidia à propos du support Linux : http://www.phoronix.com/scan.php?page=article&item=nvidi(...) (20 octobre 2009)
    • [^] # Re: Chantons les louanges des pilotes propriétaires

      Posté par (page perso) . Évalué à  5 .

      Nvidia a déja mis des pilotes de coté, via la branche legacy qui visiblement n'est plus supporté sur les X trop récents. Cf http://doc.fedora-fr.org/wiki/Carte_graphique_NVIDIA_:_insta(...) ou http://www.nvnews.net/vbulletin/showthread.php?t=127576

      On peut citer le cas du vieux driver proprio pour modem, conexant, je crois, qui finalement n'a pas été mis à jour pourle nouveau noyau.

      Et en matiére de poudre aux yeux en terme de driver proprio, on peut aussi citer le nokia n900, qui va bientot sortir, et qui sera pour ( je cite ) "les amoureux du libre", mais avec une puce sans driver ouvert. ( powervr sgx 530 ). Voir aussi http://blog.1407.org/2009/09/01/nokias-free-software-bullshi(...)
    • [^] # Re: Chantons les louanges des pilotes propriétaires

      Posté par . Évalué à  3 .

      J'ai l'impression de comprendre ce que tu dis et partager ton opinion.
      Pour en être sûr, pourrais-tu préciser ce que tu entends par 'pragmantique' ?
      Est-ce différent de Pragmatique ?
  • # Garder sa 3DFX ?

    Posté par (page perso) . Évalué à  7 .

    LE gros problème de Linux, c'est quand même les drivers propriétaires.

    Je suis prêt à acheter n'importe quelle carte de n'importe quel constructeur, même si les performances sont un peu à la traine, du moment qu'il y a un driver libre.

    J'ai tout essayé, que ce soit sur les portables ou les desktops.
    Les drivers proprios sont certes plus performants avec les puces récentes, mais à quel prix!
    intel (l'accélération 3D ne fonctionnait plus en sortie d'hibernation)
    amd/ati (horribles bugs qui ont longtemps empêchés la mise en hibernation)
    nvidia (que je soupçonne de freezer mon linux aléatoirement. Plantages inexpliqués et totaux (plus de réseau, tout est bloqué) avec des drivers à jour).

    Bref j'en peux plus. Je regarde régulièrement l'avancée des pilotes libres, surtout du côté de AMD qui semblait s'être engagé dans cette voie. Ça ne bouge pas depuis au moins deux ans.
    M'en fiche, je ne rachèterai pas de matos tant que le problème du driver libre ne sera pas rêglé (je sais que cette déclaration publique va faire trembler et réfléchir les géants de la carte graphique).
    • [^] # Re: Garder sa 3DFX ?

      Posté par . Évalué à  5 .

      Bref j'en peux plus. Je regarde régulièrement l'avancée des pilotes libres, surtout du côté de AMD qui semblait s'être engagé dans cette voie. Ça ne bouge pas depuis au moins deux ans.

      Heu, tu es sûr d'avoir les bonnes sources d'information ? Regarde du côté de http://www.phoronix.com/ par example. Les drivers libres pour les cartes AMD, ça bouge. DRM, KMS, Gallium3D... Les cartes les plus récentes ne sont peut-être pas encore supportées, mais ça va venir.
      • [^] # Re: Garder sa 3DFX ?

        Posté par (page perso) . Évalué à  4 .

        Oui, oui, phoronix je connais, mais je t'assure. Ma X1600 (famille R500) qui a quand même plus de 4 ans commence seulement à être supportée.
        Quand à la famille R600, dont les plus anciens représentants auront bientôt 3 ans, on ne peut pas dire que ce soit utilisable (plantages intempestifs, seule la 2D fonctionne correctement).
        R700, même pas la peine d'y rêver.

        Ou alors j'ai pas de bol.

        J'attendrai donc prudemment les premiers cris de joie et la dépèche de linuxfr.org qui ne manquera pas de sonner trompettes et résonner musettes.
        • [^] # Re: Garder sa 3DFX ?

          Posté par (page perso) . Évalué à  3 .

          J'ai une ATI X1950 Pro et sauf erreur c'est le modèle le plus puissant avec un driver libre et stable (mais ça a l'air de bouger vite). Environ 50€ (occasion, ça existe plus en neuf).

          Bon évidemment on va pas jouer aux tout derniers jeux vidéos avec… mais c’est quand même un véritable bonheur de pouvoir virer les drivers nVidia.

          DLFP >> PCInpact > Numerama >> LinuxFr.org

        • [^] # Re: Garder sa 3DFX ?

          Posté par (page perso) . Évalué à  2 .

          Je suis heureux propriétaire d'une carte a base de R700... et je l'utilise en 2D uniquement, le pilote d'AMD étant un cauchemar, les pilotes libres offrent un plus grand confort d'utilisation.
        • [^] # Re: Garder sa 3DFX ?

          Posté par (page perso) . Évalué à  3 .

          Pareil, j'ai une radeon hd 3600 qui fonctionne en 2D mais avec des freezer régulier.

          Du coup, j'utilise une GForce 9 avec driver proprio...

          Je viens de tester avec le dernier xorg, ca fonctionne toujours aussi mal pour ma carte ATI.
        • [^] # Re: Garder sa 3DFX ?

          Posté par (page perso) . Évalué à  4 .

          Je suis l'heureux propriétaire d'une radeon hd 4870 (que j'utilisais encore pour jouer il y a peu). Aujourd'hui je l'utilise avec KDE (Kwin) et les effet openGL et ça marche bien, je n'ai pas encore souffert de crash intempestif.
          Auparavant je l'utilisais en 2D et je n'ai jamais connus ces plantages intempestifs dont tu parles.

          Sur mon autre desktop c'est une X1xxx (me souviens plus mille excuses) qui fonctionne avec Kwin et ce depuis déjà quelques mois de manière stable. De la même façon, le drivers libre me permet de l'utiliser en 2D de manière stable depuis de long moi déjà.

          Et r600 et r700 partage la même architecture (à peu de choses prés) et les drivers sont developpés en parallèle, le support est donc identique pour ces deux générations.

          Je pense pour ma part que tu généralises à partir d'une expérience malheureuse. Et je serais ravis de t'aider à changer d'avis...
    • [^] # Re: Garder sa 3DFX ?

      Posté par . Évalué à  2 .

      >LE gros problème de Linux, c'est quand même les drivers propriétaires.

      N'exagères pas: les multiples problèmes récurrent lié au son sous Linux ne sont pas due a des driver propriétaire, plutôt à un manque d'intérêt et au distributions qui fournissent du code instable ou même package mal le code fourni.

      Et puis il y a l'interopérabilité avec le monde Windows aussi..


      >Bref j'en peux plus. Je regarde régulièrement l'avancée des pilotes libres, surtout du côté de AMD qui semblait s'être engagé dans cette voie. Ça ne bouge pas depuis au moins deux ans.

      Tu vois que les drivers libre ne sont pas forcément meilleur, il faut qu'il y ai suffisamment de développeurs intéressé..
  • # C'est pas faute d'avoir prévenu

    Posté par . Évalué à  7 .

    Bon, je n'ai jamais fait de dépêche, mais je tempère l'engouement des libristes depuis quelques temps pourtant ...
    https://linuxfr.org//comments/969276.html#969276
    https://linuxfr.org//comments/1062046.html#1062046
    https://linuxfr.org//comments/1046786.html#1046786
    https://linuxfr.org//comments/936039.html#936039
    https://linuxfr.org//comments/1013123.html#1013123
    https://linuxfr.org//comments/1061391.html#1061391

    Je regarde depuis quelques temps les netbooks et autres tablettes embarquées, mais ce chipset, présent aussi bien sur x86 que sur ARM, m'a fait reculer à chaque fois.

    Bref, faites attention !
    • [^] # Re: C'est pas faute d'avoir prévenu

      Posté par (page perso) . Évalué à  2 .

      Oh, chouette, tu as l'air bien renseigné ! Déjà, pour être franc, je n'ai pas vérifié la compatibilité du matériel avec Linux. Comme les premiers netbooks étaient vendus sous Linux, j'ai pensé que les netbooks étaient toujours compatibles Linux... Or, j'ai vite déchanté :-(

      Donc si j'ai bien compris Imagination Technologies vend des très bonnes puces (graphiques), mais vend les pilotes à part oi propose des NDA pour que le constructeur écrive ses propres pilotes ? Quel est l'intérêt d'avoir un chouette puce 3D sans pilote (cas du N800) !? La licence pour le pilote et/ou NDA est trop cher, et certains constructeurs préfèrent s'en passer ?! Enfin, l'intérêt pour Imagination Technologies est flagrant : gagner un max de fric. Mais pour le constructeur, je trouve que c'est quand même un point bloquant (absence de pilote correct).

      Je trouve ça assez étonnant de vendre du matériel sans pilote. Mais bon, je ne connais pas trop le domaine, peut-être que c'est une chose normale.
      • [^] # Re: C'est pas faute d'avoir prévenu

        Posté par . Évalué à  4 .

        Je comprend ta déception ...

        Les puces que vend ImgTech sont des "bonnes" puces pour l'embarqué : un bon compromis performances / consommation (ça ne vaut rien en performance pure face à un AMD ou NVidia, hein). C'est aussi quasiment les seuls sur ce segment (pour tout dire, je ne leur connait aucun concurrent).

        Pour le pilote, je ne pense pas avoir dit qu'ils ne le développaient pas ... au contraire ! Je pense que ImgTech vend un driver source à ceux qui signent des NDA, pour très cher et s'ils vendent beaucoup de puces. Ils ont un gros partenariat (selon moi) avec TI pour vendre leur puce en tant que solution graphique de la plateforme OMAP, c'est pour ça qu'on en retrouve partout (en plus d'Apple avec son iPhone).

        Pour le N8x0, c'était un cas spécial : les kits OMAP sont vendus avec tout ou rien (matériellement), et Nokia ne voulait pas de carte graphique : ils n'ont simplement pas eu de driver. La bête n'a jamais été vendue avec dans ses specs "carte graphique 3D". Bon, pour un libriste, ça semble dommage de laisser dormir une telle puce ...

        En tous cas, selon moi, les perspectives de libération sont très minces : ImgTech est quasi-seul dans ce segment (si quelqu'un avait des références d'autres constructeurs plus coopératifs, ça m'intéresserait) et vend plein de puce sans que trop de libristes ne l'ait encore fait chier. Bref, comme je l'ai déjà dit avant, la 3D dans l'embarqué est sur un encore plus mauvais chemin que la 3D sur le desktop (en libre, hein).
        • [^] # Re: C'est pas faute d'avoir prévenu

          Posté par . Évalué à  3 .

          Bref, comme je l'ai déjà dit avant, la 3D dans l'embarqué est sur un encore plus mauvais chemin que la 3D sur le desktop (en libre, hein)

          Ben le problème avec le Poulsbo c'est que même le driver proprio est une merde non maintenue.
          Sur mon MSI Wind U115, j'ai essayé plusieurs distros (Ubuntu, Fedora, Mandriva stable & beta), sur aucune le driver ne voulait fonctionner correctement : plantage au démarrage de X. C'est peut-être une série de chipset légèrement différente de ce qui est utilisé sur d'autres netbooks, je n'en sais rien, mais c'est pas normal que ça ne marche pas (vu que Windows, lui, fonctionne, ou plutôt fonctionnait avant que je le vire du disque dur :-)).

          Résultat, je suis en vesafb avec une résolution de 800x600 (au lieu de 1024x600). La 3D je m'en fiche, mais si la 2D pouvait marcher ça m'arrangerait bien...
        • [^] # Re: C'est pas faute d'avoir prévenu

          Posté par . Évalué à  1 .

          Juste pour clarifier: Apple utilise des processeurs Samsung, et ce depuis le début dans sa gamme iPhone, iPod Touch. Donc oui c’est bien du ARM + PowerVR pas beau, mais non c’est pas de l'OMAP.
          Après il peut être facile de se tromper, vu que les spécificités des System-on-chip sont très proches, et que la puce est « Apple branded » : logo Apple et pas de mention de Samsung. Mais c’est un secret pour personne:
          http://www.ifixit.com/Teardown/iPhone-3G/600/3
          http://www.ifixit.com/Teardown/iPhone-3GS/817/2
          http://www.ecranmobile.fr/Samsung-announces-world-s-fastest-(...)

          TI n’est pas le seul fabricant de puces à base de Cortex-A8: Freescale, Broadcom, Qualcomm, Samsung, ST etc: http://www.arm.com/products/licensing/licencees.html
      • [^] # Re: C'est pas faute d'avoir prévenu

        Posté par (page perso) . Évalué à  1 .

        Donc si j'ai bien compris Imagination Technologies vend des très bonnes puces (graphiques), mais vend les pilotes à part oi propose des NDA pour que le constructeur écrive ses propres pilotes ?
        Non, imgtec ne vend pas les pilotes en sus. Il y a un pilote proprio pour SGX sur ARM et tu peux l'avoir en t'enregistrant sur leur site. Le problème c'est aussi que imgtec ne cible pas x86 à la base alors que poulsbo si...

        Quel est l'intérêt d'avoir un chouette puce 3D sans pilote (cas du N800) !?
        La raison principale pour laquelle le n800 n'a pas l'accélération 3D, c'est que les batteries n'auraient pas pu le supporter, l'autonomie aurait été massacrée. Et pour un appareil comme le N800, avoir une autonomie ridicule c'est pire que ne pas avoir de 3D. Et si on l'activait quand même les utilisateurs auraient du mal à comprendre pourquoi utiliser des jeux/applis 3D tue les batteries.
  • # GMA 500 != GMA 950

    Posté par . Évalué à  3 .

    Poulsbo ou « Intel GMA 500 » est une puce graphique utilisée dans de nombreux netbooks, téléphones et autres équipements embarqués, qui fleurissent dans nos magasins. Elle est supportée par Ubuntu 8.04, 9.04 et 9.10, Fedora 11 et Mandriva Linux.

    La majorité des Netbooks utilisent des GMA 950, pas des Poulsbo/GMA 500...
    Les deux seuls Netbooks répandus l'utilisant à ma connaissance étant le Dell Mini 12 et... l'Eee PC 1101HA !

    Quant aux téléphones, ils utilisent pour la plupart des SoC ARM, donc pas de Poulsbo non plus.
    Note : Le problème reste cependant valable pour eux puisque beaucoup de ces SoC ont une partie graphique signée PowerVR. On y revient.
    • [^] # Re: GMA 500 != GMA 950

      Posté par (page perso) . Évalué à  5 .

      Les deux seuls Netbooks répandus l'utilisant à ma connaissance étant le Dell Mini 12 et... l'Eee PC 1101HA !

      Il y en a quand même plus que deux netbooks qui utilisent le Poulsbo. Il y a aussi des MIDs, etc.
      • [^] # Re: GMA 500 != GMA 950

        Posté par . Évalué à  3 .

        Oui, il semble que la plupart des netbooks récents utilisent le Poulsbo, et pour une bonne raison : il consomme beaucoup moins que l'ancien chipset.
        • [^] # Re: GMA 500 != GMA 950

          Posté par . Évalué à  1 .

          Non (à moins bien sûr que le vent ait tourné tout dernièrement).
          Et ce pour une simple et bonne raison : Poulsbo ne gère pas le SATA. PATA uniquement, et maximum 1 Go de mémoire. Un chipset économe pour sûr, mais limité.
          • [^] # Re: GMA 500 != GMA 950

            Posté par . Évalué à  1 .

            Correction : 2 Go de mémoire.
            • [^] # Re: GMA 500 != GMA 950

              Posté par . Évalué à  3 .

              Sur un netbook, je ne vois pas ce que le PATA apporterait par rapport au SATA.
              • [^] # Re: GMA 500 != GMA 950

                Posté par . Évalué à  3 .

                Heu, et vice-versa :)
                • [^] # Re: GMA 500 != GMA 950

                  Posté par . Évalué à  1 .

                  On est d'accord que ce n'est pas primordial.

                  Mais pour tous les netbooks possédant un véritable disque dur dedans (pas une 'carte SSD') comme le NC10, certains Asus, etc., le fait d'avoir du PATA au lieu du SATA veut dire augmentation des tarifs en cas de remplacement... puisque désormais, les disques PATA sont plus chers/de plus faible capacité que les SATA.

                  Ce ne sera pas un problème pour la plupart des utilisateurs mais c'est un inconvénient tout de même, et qui ne va pas aller en s'arrangeant.
        • [^] # Re: GMA 500 != GMA 950

          Posté par . Évalué à  5 .

          Je dois m'avouer vaincu... Il semblerait effectivement que de plus en plus de Netbooks/MIDs utilisent Poulsbo. Le vent a bien tourné pendant mon absence. =/

          A ce sujet, une news de Phoronix toute fraîche concernant le driver : http://www.phoronix.com/scan.php?page=news_item&px=NzY2M(...)
    • [^] # Re: GMA 500 != GMA 950

      Posté par (page perso) . Évalué à  7 .

      Les deux seuls Netbooks répandus l'utilisant à ma connaissance étant le Dell Mini 12 et... l'Eee PC 1101HA !

      Je ne voulais pas copier/coller Wikipédia dans ma dépêche, de peur d'avoir une liste incomplète (alors que Wikipédia est complété en continu). Mais bon, tant pis. Si tu suis le 1er lien de la dépêche, tu verras :

      Intel System Controller Hub US15/W/L-SGX535(Intel GMA500) + VXD370

      * Abit (USI) MID-100
      * Abit (USI) MID-150
      * Abit (USI) MID-200
      * Acer Aspire One AO751h
      * Advantech MICA-101
      * Aigo MID P8860
      * Aigo MID P8880
      * Aigo MID P8888
      * Arbor Gladius G0710
      * Archos 9
      * ASUS EeePC T91
      * ASUS EeePC S121
      * ASUS EeePC 1101HGO
      * ASUS R50A
      * ASUS R70A
      * Averatec (TriGem) MID
      * BenQ Aries2
      * BenQ S6
      * Clarion MiND
      * CLEVO TN70M
      * CLEVO TN71M
      * Clevo T89xM
      * Colmek Stinger
      * Compal jAX10
      * CompuLab Fit-PC2
      * Dell Inspiron Mini 12
      * Dell Inspiron Mini 10
      * Dell Inspiron Mini 1010 Tiger
      * Digifriends WiMAX MID
      * DT Research DT312
      * DUX HFBX-3800
      * EB mobile internet device
      * FMV-BIBLO LOOX U/C40
      * FMV-BIBLO LOOX U/C30
      * Fujitsu UMPC U2010
      * Fujitsu LifeBook U2020
      * Fujitsu LifeBook U820
      * Gigabyte M528
      * Hanbit Pepper Pad 3
      * Kohjinsha/Inventec S32
      * Kohjinsha/Inventec SC3
      * Kohjinsha W130
      * Kohjinsha SX3KP06MS
      * KOHJINSHA SC3KX06A
      * Kohjinsha/Inventec X5
      * Kohjinsha PM series
      * Lenovo IdeaPad U8
      * LG XNote B831
      * MaxID BHC-100
      * MaxID iDLMax
      * mis MP084T-001G
      * MSI Wind U115
      * MSI Wind U110
      * MSI X-Slim 320
      * NEC VersaPro UltraLite type VS
      * NEXCOM MRC 2100
      * NEXCOM MTC 2100
      * NEXCOM MTC 2100-MD
      * Nokia Booklet 3G
      * NOVA SideArm2 SA2I
      * OMRON Panel PC
      * OQO Model 2+
      * Panasonic Toughbook CF-U1
      * Panasonic CF-H1 Mobile Clinical Assistant
      * Portwell Japan UMPC-2711
      * Quanta mobile internet device
      * Sony Vaio P series
      * Sony Vaio X series
      * TCS-003-01595 - Intel ATOM Rugged Tablet PC 8.4"
      * Toshiba mobile internet device
      * Trigem LLUON Mobbit PS400
      * UMID Clamshell
      * Viliv (YuKyung) S5
      * Viliv (YuKyung) S7
      * Viliv (YuKyung) X70
      * WiBrain i1
      * WiBrain M1
      * WILLCOM D4 (Sharp WS016SH)
      * Various system boards and computer on modules including:
      o Adlink Express-MLC
      o Advantech SOM-5775
      o AXIOMTEK PICO820
      o Congatech conga-CA
      o Congatech-IVI Starterkit
      o CoreExpress-ECO
      o Eurotech Catalyst
      o Eurotech Isis
      o Eurotech Proteus
      o IBASE IB822
      o Inhand FireFly
      o Kontron nanoETXexpress-SP
      o Kontron microETXexpress-SP
      o Kontron KTUS15/miTX
      o LiPPERT CoreExpress-ECO COM
      o MEN Micro XM1
      o MSI MS-9A06
      o MSC Q7-US15W
      o Portwell PEB-2736
      o Portwell PCS-8230
      o Portwell NANO-8044
      o Portwell WEBS-2120 (Nano-ITX)
      o Portwell WEBS-1310/1320 (ECX)
      o PROTEUS COM EXPRESS
      o RadiSys Procelerant Z500
      o RadiSys Procelerant CE5XL
      o RadiSys Procelerant CE5XT
      o Woodpecker Z5xx Micro COM Express
      o Xilinx XA Spartan-3E FPGA

      Je ne sais pas si les modèles listés sont « répandus », et je n'ai pas non plus regardé ce dont il s'agit (si c'est des netbooks ou non), mais en tout cas, il existe plus de deux modèles :-) J'ai entendu parlé de problèmes de Poulsbo (du pilote Linux) sur MSI Wind U115 et sur Sony Vaio P.

      Quant aux téléphones, ils utilisent pour la plupart des SoC ARM, donc pas de Poulsbo non plus.
      Note : Le problème reste cependant valable pour eux puisque beaucoup de ces SoC ont une partie graphique signée PowerVR. On y revient.


      Moui, j'ai fait un raccourci. À vrai dire le problème n'est pas le Poulsbo, mais le pilote pour les puces PowerVR (SGX). Et les puces SGX équipent beaucoup de monde de l'embarqué.
      • [^] # Re: GMA 500 != GMA 950 et autres ???

        Posté par . Évalué à  2 .

        En complément de cette liste, l'un d'entre nous aurait il celle concernant les netbooks dont les pilotes sont bien supportés et/ou le code est fournis/libre ?

        Envisager un netbook , ne devrait plus être un casse-tête !?
        Le conseil sera plus éclairant pour les néophytes dans la situation de recherche.

        question subsidiaire : alors ou trouver un netbook supporté, dans la gamme de prix basse (<300€) ?
      • [^] # Re: GMA 500 != GMA 950

        Posté par . Évalué à  2 .

        Effectivement, comme je disais dans mon message précédent je me suis bien trompé à propos du nombre de Poulsbo dans la nature.
        Ils étaient peu utilisés, au profit des chipsets avec Intel 945 (GMA950), mais ils se sont maintenant bien répandus. Dommage pour l'évolutivité des Netbooks (PATA).

        Quant au SGX, on est bien d'accord.
  • # Drivers maintenus

    Posté par (page perso) . Évalué à  6 .

    Il n'y a qu'un seul driver officiellement maintenu pour US15W (Poulsbo): IEGD. Ce driver bénéficie de mises à jour trimestrielles. Voir: http://edc.intel.com/Software/Downloads/IEGD/

    Quant au driver GMA500 il n'a jamais été le driver officiel. Cependant, il reste maintenu. Maintenir veut dire correction de bugs. Les nouvelles fonctionnalités et support de la branche Moorestown ne sont pas backportées dans GMA500, sauf quand il y a du temps. D'ailleurs, il n'y a qu'une seule personne qui maintient le driver GMA500. Ubuntu 9.04 étant supporté, l'argument 'plus supporté depuis un an et demi' n'est pas valable.
    • [^] # Re: Drivers maintenus

      Posté par (page perso) . Évalué à  2 .

      Il n'y a qu'un seul driver officiellement maintenu pour US15W (Poulsbo): IEGD

      Ah bon ? Pourquoi Ubuntu, Fedora et Mandriva utilisent le vieux pilote non maintenu alors ?

      l'argument 'plus supporté depuis un an et demi' n'est pas valable.

      Au sujet de xorg-x11-drv-psb (et ses amis, cf. ma dépêche plus haut), il y a un dépôt git officiel (maintenu par Intel) qui est mort depuis 1 an 1/2 :
      http://git.moblin.org/cgit.cgi/deprecated/xf86-video-psb/
      (il est d'ailleurs marqué comme étant déprécié)

      Ce qui est reproché à Intel, au sujet du Poulsbo, est de ne pas chercher à être intégré au noyau et/ou à Xorg. Il y aurait au moins la 2D qui pourrait être intégrée car (tout?) le code est libre (GPL ou MIT).
      • [^] # Re: Drivers maintenus

        Posté par (page perso) . Évalué à  0 .

        Ah bon ? Pourquoi Ubuntu, Fedora et Mandriva utilisent le vieux pilote non maintenu alors ?

        Parce qu'ils n'ont pas été capables d'ouvrir les yeux et d'utiliser le bon driver, et conclure les bons accords avec Intel. Les deux drivers sont totalement propriétaires. Ils préfèrent être guidés par un fanatisme libriste qui les contraint à utiliser des éléments obsolètes.

        Ce qui est reproché à Intel, au sujet du Poulsbo, est de ne pas chercher à être intégré au noyau et/ou à Xorg. Il y aurait au moins la 2D qui pourrait être intégrée car (tout?) le code est libre (GPL ou MIT).

        Justement, non. C'était une erreur de publier les sources. Donc ce code est totalement obsolète et dépassé par les nouveaux drivers qui sont propriétaires.
        • [^] # Re: Drivers maintenus

          Posté par . Évalué à  3 .

          Les deux drivers sont totalement propriétaires. Ils préfèrent être guidés par un fanatisme libriste qui les contraint à utiliser des éléments obsolètes.

          Heu, c'est pas un peu contradictoire ? Où est le « fanatisme libriste » consistant à incorporer des pilotes propriétaires ?

          Et puis, ce n'est pas qu'eux : personne sur Internet ne semblait au courant de ces nouveaux pilotes, et Intel ne semble pas avoir pris la peine de signaler leur existence. C'est tout de même bizarre.
          • [^] # Re: Drivers maintenus

            Posté par (page perso) . Évalué à  0 .

            Heu, c'est pas un peu contradictoire ? Où est le « fanatisme libriste » consistant à incorporer des pilotes propriétaires ?

            S'ils ne voulaient pas absolument des morceaux avec code source, ils auraient vu les drivers propriétaires. Donc, du fait qu'ils insistent à vouloir des drivers avec des bouts open source, ils contraignent leurs utilisateurs à utiliser des vieux drivers buggés. Au final, ces distributeurs s'en foutent de l'expérience de leurs utilisateurs mais satisfont ceux qui veulent absolument des bouts open source, même si c'est tout pourri. C'est sûr, il faut choisir...

            Et puis, ce n'est pas qu'eux : personne sur Internet ne semblait au courant de ces nouveaux pilotes, et Intel ne semble pas avoir pris la peine de signaler leur existence. C'est tout de même bizarre.

            Il faut croire qu'il n'y que les gens d'OpenSUSE qui fassent des efforts... Et puis il suffit de demander, c'est sûr. Tu penses vraiment que Intel a choisit OpenSUSE comme ça pour le plaisir? Non, les caméléons se sont bougés le c*l pour obtenir au moins les sources pour eux et bosser sur les drivers, éventuellement indirectement (via une autre boîte). C'est sûr, il faut aussi être capable de développer des drivers.

            Et puis, c'est vrai que tant qu'il y a des gens qui entretiennent le mythe des 'drivers non maintenus', comme ce présent journal, ces informations erronées sont plus prépondérantes que les informations véritables. i.e. ce sont elles qui sont le plus visibles sur Internet.
            • [^] # Re: Drivers maintenus

              Posté par . Évalué à  3 .

              Au final, ces distributeurs s'en foutent de l'expérience de leurs utilisateurs mais satisfont ceux qui veulent absolument des bouts open source, même si c'est tout pourri.

              Drôle de procès d'intention...

              Non, les caméléons se sont bougés le c*l pour obtenir au moins les sources pour eux et bosser sur les drivers, éventuellement indirectement (via une autre boîte). C'est sûr, il faut aussi être capable de développer des drivers.

              Tu veux dire que les drivers propriétaires « récents » eux-mêmes ne sont pas prêts à l'emploi et qu'il faut bosser dessus sous NDA pour qu'ils fonctionnent correctement ?
              Ben, dans ce cas, je comprends que ça rebute... Si on cache le source histoire de protéger des secrets de fonctionnement, faut pas attendre que des développeurs tierce partie corrigent les bugs pour soi.

              Et puis, c'est vrai que tant qu'il y a des gens qui entretiennent le mythe des 'drivers non maintenus', comme ce présent journal, ces informations erronées sont plus prépondérantes que les informations véritables. i.e. ce sont elles qui sont le plus visibles sur Internet.

              Oui, enfin on peut pas dire qu'Intel se soit bougé le cul au niveau communication. Après, si Intel n'en a rien à foutre, ça en dit long sur leur respect du client.
              (parce que, si c'était l'OS dominant qui livrait de vieux drivers pourris, je pense qu'ils seraient intervenus depuis longtemps au lieu de se tourner les pouces en rigolant)
            • [^] # Re: Drivers maintenus

              Posté par . Évalué à  5 .

              Il faut croire qu'il n'y que les gens d'OpenSUSE qui fassent des efforts...

              D'ailleurs, ce serait sympa que tu détailles un peu, parce qu'après quelques recherches je tombe sur :

              https://features.opensuse.org/306413

              « The driver is a mess. Thus it's simply not possible to integrate it. If you're interested into more details, see enhancement Bug #462707. »

              https://bugzilla.novell.com/show_bug.cgi?id=462707

              « Situation didn't change. Intel still cannot provide any appropriate driver
              sources for the current X.Org/Kernel stack. Reassigning. Sunny, openSUSE 11.2
              uses the same X.Org/kernel stack as Moblin 2.0. »

              « Closing out due to Intel refusing to help with this. »

              L'auteur de la dernière phrase étant Greg Kroah-Hartman, un développeur du noyau.
  • # Un petit lien qui pourrait vous remonter le moral

    Posté par . Évalué à  2 .

    Bonjour,

    voici un petit article sur de la lecture vidéo HD et de la 3D avec un GMA500 sous Maemo.

    [http://www.liliputing.com/]

    Probably the most impressive demo showed an MSI Wind U115 with an Atom Z530 processor and GMA 500 graphics running Quake III in HD resolutions on an external display at about 35 frames per second.

    For the demo, the netbook was running Moblin Linux. As far as I know, the Windows drivers for this chipset won’t allow this kind of performance.


    En gros, pour ceux qui ne parlent pas du tout anglais :

    La démonstration la plus impressionnante est certainement celle montrant un MSI Wind U115 équipé d'un Atom Z530 et d'une puce graphique GMA500 faisant tourner Quake 3 en HD sur un ècran déporté à 35fps.
    Pour la démo, le netbook tournait sous Moblin Linux. Autant que je sache, le pilote Windows pour cette puce ne permet pas ce genre de performance
  • # Support Mandriva

    Posté par . Évalué à  2 .

    Pour info l'intégration dans la prochaine Mandriva (2010.0) est automatique : l'outil de config (drakxconf si je me trompe pas) est capable de détecter la puce et tout faire tout seul, voir par exemple :
    http://moblinzone.com/blog/712/37/Mandriva_folds_in_Moblin_t(...)
  • # et le BIOS

    Posté par (page perso) . Évalué à  3 .

    Oublie pas de mettre à jour ton BIOS, pour ce netbook. La version que j’avais essayée avait un BIOS qui donnait des mauvaises informations sur le chipset Poulbo, justement. Une mise à jour plus tard et c’était bon. Bon, c’était sous Windows 7, OK. Mais quand même.
  • # A propos de moblin/Poulsbo

    Posté par . Évalué à  1 .

    Un monsieur de linuxjournal a écrit une lettre ouverte à Intel leur demandant d'arreter de se foutre de leur client:
    http://www.linuxjournal.com/content/how-kick-your-friends-fa(...)
    Et un monsieur de moblin zone a répondu:
    http://moblinzone.com/blog/743/64/Blaming_Intel_for_how_the_(...)
    En disant que c'était pas la faute d'Intel et que les consommateurs avaient rien compris au marché visé.
    Et la réponse de linuxjournal:
    http://www.linuxjournal.com/content/more-poulsbo-gma500-inte(...)

    Il me semble d'ailleurs que même la prochaine version de Moblin (2 et 2.1) ne pourra pas supporter le chipset poulsbo…
    • [^] # Re: A propos de moblin/Poulsbo

      Posté par (page perso) . Évalué à  2 .

      Enfin le monsieur de moblin zone, on sait pas trop qui c'est, donc bon.
      • [^] # Re: A propos de moblin/Poulsbo

        Posté par . Évalué à  2 .

        Ça a été discuté dans les commentaires, et c'est bien un mec d'Intel.
        Par contre ça ne l'empêche pas de filer que des arguments fallacieux (pour rester poli).
        • [^] # Re: A propos de moblin/Poulsbo

          Posté par . Évalué à  3 .

          Oui et en plus les commentaires de son blog sont fermés, ce qui empêche de lui dire ce que mon U115 sous Linux (j'ai testé Fedora, deux Mandriva et deux Ubuntu) pense de la soi-disant « divergence de stratégie marketing » alléguée dans ses écrits.

Suivre le flux des commentaires

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