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) ;
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 Misc (site web personnel) . Évalué à 6.
[^] # Re: Le poulsbo...
Posté par FantastIX . Évalué à 2.
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 reno . Évalué à 2.
# Chantons les louanges des pilotes propriétaires
Posté par GeneralZod . Évalué à 10.
"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 Ph Husson (site web personnel) . Évalué à 1.
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 gUI (Mastodon) . Évalué à 10.
... 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.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Chantons les louanges des pilotes propriétaires
Posté par gojul . Évalué à 2.
[^] # Re: Chantons les louanges des pilotes propriétaires
Posté par franckd . Évalué à 2.
[^] # Re: Chantons les louanges des pilotes propriétaires
Posté par Gniarf . Évalué à 2.
[^] # Re: Chantons les louanges des pilotes propriétaires
Posté par Brioche4012 (site web personnel) . Évalué à 10.
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 Misc (site web personnel) . Évalué à 6.
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 houra . Évalué à 6.
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 benoar . Évalué à 10.
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
[^] # Re: Chantons les louanges des pilotes propriétaires
Posté par benoar . Évalué à 7.
[^] # Re: Chantons les louanges des pilotes propriétaires
Posté par M . Évalué à 1.
[^] # Re: Chantons les louanges des pilotes propriétaires
Posté par benoar . Évalué à 3.
[^] # Re: Chantons les louanges des pilotes propriétaires
Posté par gnumdk (site web personnel) . Évalué à 4.
Si un jour Nvidia arrête son pilote linux, peut être qu'il sera plus facile de négocier...
Mais en attendant:
- Ils en ont rien à foutre
- Ca ne leur apporterait rien
Et pour les enfoncer, les heureux pocesseurs de carte Nvidia legacy ont du passer au module "nv" sous ArchLinux car pas de drivers pour xorg 1.7 \o/
[^] # Re: Chantons les louanges des pilotes propriétaires
Posté par Gof (site web personnel) . Évalué à 8.
« The source code for a work means the preferred form of the work for making modifications to it. »
[^] # Re: Chantons les louanges des pilotes propriétaires
Posté par Misc (site web personnel) . Évalué à 4.
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 benoar . Évalué à 9.
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 Olivier (site web personnel) . Évalué à 4.
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 M . Évalué à 3.
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 Olivier (site web personnel) . Évalué à 2.
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 Octabrain . Évalué à 2.
[^] # Re: Chantons les louanges des pilotes propriétaires
Posté par Misc (site web personnel) . Évalué à 5.
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 netsurfeur . Évalué à 3.
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 jseb . Évalué à 7.
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).
Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr
[^] # Re: Garder sa 3DFX ?
Posté par nodens . Évalué à 5.
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 jseb . Évalué à 4.
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.
Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr
[^] # Re: Garder sa 3DFX ?
Posté par DLFP est mort . Évalué à 3.
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 psychoslave__ (site web personnel) . Évalué à 5.
Je crois que ça résume bien le problème. On ne peut pas aller dans un magasin et acheter une carte graphique utilisable avec un pilote libre (qui à un tant soit peu de gestion de 3D).
Bah vivement que OGP sortent leur matos
http://wiki.opengraphics.org/tiki-index.php?page=Open-Graphi(...)
[^] # Re: Garder sa 3DFX ?
Posté par Brioche4012 (site web personnel) . Évalué à 2.
[^] # Re: Garder sa 3DFX ?
Posté par gnumdk (site web personnel) . Évalué à 3.
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 monde_de_merde . Évalué à 4.
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 reno . Évalué à 2.
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 benoar . Évalué à 7.
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 Victor STINNER (site web personnel) . Évalué à 2.
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 benoar . Évalué à 4.
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 Antoine . Évalué à 3.
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 Aissen . Évalué à 1.
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 Misc (site web personnel) . Évalué à 2.
"designed in california, made in china", comme sur les macbooks :)
[^] # Re: C'est pas faute d'avoir prévenu
Posté par benoar . Évalué à 2.
[^] # Re: C'est pas faute d'avoir prévenu
Posté par Stephane Marchesin (site web personnel) . Évalué à 1.
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 deluxe . Évalué à 3.
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 Gwenole Beauchesne . Évalué à 5.
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 Antoine . Évalué à 3.
[^] # Re: GMA 500 != GMA 950
Posté par deluxe . Évalué à 1.
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 deluxe . Évalué à 1.
[^] # Re: GMA 500 != GMA 950
Posté par Antoine . Évalué à 3.
[^] # Re: GMA 500 != GMA 950
Posté par Antoine . Évalué à 3.
[^] # Re: GMA 500 != GMA 950
Posté par deluxe . Évalué à 1.
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 deluxe . Évalué à 5.
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 Victor STINNER (site web personnel) . Évalué à 7.
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 jepostesurlatribune . Évalué à 2.
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 deluxe . Évalué à 2.
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 Gwenole Beauchesne . Évalué à 6.
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 Victor STINNER (site web personnel) . Évalué à 2.
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 Gwenole Beauchesne . Évalué à 0.
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 Antoine . Évalué à 3.
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 Gwenole Beauchesne . Évalué à 0.
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 Antoine . Évalué à 3.
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 Antoine . Évalué à 5.
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 zarbatrip . Évalué à 2.
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
[^] # Re: Un petit lien qui pourrait vous remonter le moral
Posté par Victor STINNER (site web personnel) . Évalué à 3.
Il me semble que cet OS ait été publié en Avril 2008 environ. Quant est-il de Moblin 2 (avril 2009), Linux 2.6.31 et Xserver 1.7 ?
[^] # Re: Un petit lien qui pourrait vous remonter le moral
Posté par benoar . Évalué à 4.
C'était avec un nouveau driver (quoique j'ai peut-être lu ça dans l'autre article), plus récent, et avec des MàJ qui devraient arriver dans le 2.6.32 ...
Alors, traduction selon moi : on aura peut-être un DRI mis à jour en libre, mais à mon avis on peut toujours aller se la mettre pour avoir des specs ou un driver libre.
Quant aux perfs, c'est pas non plus transcendant de faire tourner Quake 3 (qui a 10 ans, quand même). Pour référence, regardez ce qu'on fait sur iPhone : c'est le même chip ...
[^] # Re: Un petit lien qui pourrait vous remonter le moral
Posté par Quzqo . Évalué à 1.
[^] # Re: Un petit lien qui pourrait vous remonter le moral
Posté par dguihal . Évalué à 3.
Un gros un nouveau driver basé sur Gallium3D et partiellement libre pour le chipset poulsbo d'ici quelques mois
[^] # Re: Un petit lien qui pourrait vous remonter le moral
Posté par Gwenole Beauchesne . Évalué à 1.
Le driver GMA500 actuel utilise déjà Gallium3D...
[^] # Re: Un petit lien qui pourrait vous remonter le moral
Posté par inico (site web personnel) . Évalué à 1.
[^] # Re: Un petit lien qui pourrait vous remonter le moral
Posté par Antoine . Évalué à 2.
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
Sur un MSI Wind U115 ?
Ils sont sympas Moblin/Intel, mais ce serait encore mieux s'ils pouvaient partager leurs résultats avec les autres distribs. Si je pouvais avoir ne serait-ce que la 2D correcte sur mon U115 je serais très content (cf. témoignage plus haut).
# Support Mandriva
Posté par the_tac . Évalué à 2.
http://moblinzone.com/blog/712/37/Mandriva_folds_in_Moblin_t(...)
# et le BIOS
Posté par Zorro (site web personnel) . Évalué à 3.
# A propos de moblin/Poulsbo
Posté par Aissen . Évalué à 1.
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 Misc (site web personnel) . Évalué à 2.
[^] # Re: A propos de moblin/Poulsbo
Posté par benoar . Évalué à 2.
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 Antoine . Évalué à 3.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.