Journal : Intel livre les spécifications complètes des chipsets graphiques récents, sans NDA
Posté par herodiade () le 01 février 2008
Intel vient de faire un nouveau pas vers les utilisateurs de systèmes d'exploitations libres, en donnant un accès public aux spécifications complètes (y compris en ce qui concerne l'accélération 2D et 3D et les fonctionnalités d'accélération de l'encodage/décodage multimédia) de leurs chipsets vidéos récents (965 et G35, c'est-à-dire tout ce qui utilise les puces GMA X3000 et plus : autrement dit, tout ce qui arrive sur le marché depuis à peu près un an).
Intel se chargeait déjà de développer et fournir aux utilisateurs d'X.org un pilote libre et pleinement fonctionnel (ils ont embauché à cette fin la fine fleur des développeurs X.org : http://www.intellinuxgraphics.org/team.html), mais ne diffusait pas de documentations publiques et sans NDA permettant à d'autres développeurs non affiliés de participer aisément au développement ou de corriger des anomalies. Ces spécifications sont placés sous la licence CC-By-ND, non libre, mais qui nous garanti la disponibilité publique et le droit de rediffuser ces documents. La documentation n'est donc pas entachée de NDA.
Par ailleurs, des développeurs Intel ont lancé, il y a deux semaines, un appel à la communauté invitant les utilisateurs d'X.org possédant un chipset graphique Intel à se joindre à leur programme de test des pilotes (ps : dépêchez-vous, la sortie de la version 2.2.1 du pilote, celle qui sera probablement intégrée dans les prochaines versions de Fedora et Ubuntu, est imminente et nous sommes plus particulièrement invités à trouver et signaler les anomalies rapidement).
Rappelons qu'AMD/ATI a aussi entamé une démarche de fond pour mettre les spécifications de ses produits - ou une partie de celles-ci - à disposition des développeurs (tout n'est pas encore disponible), et pour aider au développement d'un pilote libre pour ses produits récents (pilote encore très jeune). Nvidia n'a pas entamé de démarche de documentation ou libération des pilotes, et mérite de brûler aux enfers avec des bananes plantés dans les narines.
Les spécifications : http://www.x.org/docs/intel/
L'annonce officielle : http://www.intellinuxgraphics.org/
Intel Graphics Media Accelerator : http://en.wikipedia.org/wiki/Intel_GMA
Community Testing Members : http://www.intellinuxgraphics.org/community_members.html
xf86-video-intel 2.2.1 release testing : http://lists.freedesktop.org/archives/xorg/2008-January/0321(...)
Call for community testers for intel driver : http://lists.freedesktop.org/archives/xorg/2008-January/0319(...)
Intel se chargeait déjà de développer et fournir aux utilisateurs d'X.org un pilote libre et pleinement fonctionnel (ils ont embauché à cette fin la fine fleur des développeurs X.org : http://www.intellinuxgraphics.org/team.html), mais ne diffusait pas de documentations publiques et sans NDA permettant à d'autres développeurs non affiliés de participer aisément au développement ou de corriger des anomalies. Ces spécifications sont placés sous la licence CC-By-ND, non libre, mais qui nous garanti la disponibilité publique et le droit de rediffuser ces documents. La documentation n'est donc pas entachée de NDA.
Par ailleurs, des développeurs Intel ont lancé, il y a deux semaines, un appel à la communauté invitant les utilisateurs d'X.org possédant un chipset graphique Intel à se joindre à leur programme de test des pilotes (ps : dépêchez-vous, la sortie de la version 2.2.1 du pilote, celle qui sera probablement intégrée dans les prochaines versions de Fedora et Ubuntu, est imminente et nous sommes plus particulièrement invités à trouver et signaler les anomalies rapidement).
Rappelons qu'AMD/ATI a aussi entamé une démarche de fond pour mettre les spécifications de ses produits - ou une partie de celles-ci - à disposition des développeurs (tout n'est pas encore disponible), et pour aider au développement d'un pilote libre pour ses produits récents (pilote encore très jeune). Nvidia n'a pas entamé de démarche de documentation ou libération des pilotes, et mérite de brûler aux enfers avec des bananes plantés dans les narines.
Les spécifications : http://www.x.org/docs/intel/
L'annonce officielle : http://www.intellinuxgraphics.org/
Intel Graphics Media Accelerator : http://en.wikipedia.org/wiki/Intel_GMA
Community Testing Members : http://www.intellinuxgraphics.org/community_members.html
xf86-video-intel 2.2.1 release testing : http://lists.freedesktop.org/archives/xorg/2008-January/0321(...)
Call for community testers for intel driver : http://lists.freedesktop.org/archives/xorg/2008-January/0319(...)
> Lire le journal (17 commentaires, moyenne: 4,6).
Vous avez demandé le commentaire #900673.
Run by 
Cette page a été générée par Templeet en 0.0562s (dont 0.0042 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Tester le dernier pilote sous Ubuntu ou Debian
Puisque je vous parle de tests urgents (si vous souhaitez que le pilote dans les prochaines versions de Fedora et Ubuntu soit de bonne qualité), voici comment je m'y prend pour générer un package, sous Ubuntu, à partir de la dernière versions des sources dans ledépôt git des sources du pilote.
Je ne suis pas certain que ce soit la meilleure méthode, mais ça génère un paquet fonctionnel, qu'il est facile d'installer et désinstaller (pour remettre le paquet d'origine fournis par la distribution, trouvez-le dans /var/cache/apt/archives/ et installez-le avec "dpkg -i lepackage.deb"). Pas sûr que ça marche aussi sous Debian (mais les adaptations devraient être mineures).
sudo apt-get build-dep xserver-xorg-video-intel
sudo apt-get install automake autoconf libtool xutils-dev git-core fakeroot
git-clone git://anongit.freedesktop.org/git/xorg/driver/xf86-video-intel
apt-get source xserver-xorg-video-intel
cd xf86-video-intel/
cp -rf ../xserver-xorg-video-intel-*/debian/ .
rm debian/patches/* # on veut tester le git head nu, pas les patchs de sa distro
perl -pi -e 's#usr/share/xserver-xorg/pci/.*##g' debian/*.install
git log > ChangeLog
./autogen.sh
debchange --nmu "git head snapshot"
dpkg-buildpackage -rfakeroot -uc -b
Vous trouverez le paquet ".deb" dans le répertoire parent. N'oubliez pas de tester les choses fragiles, comme le suspend-to-ram, l'hibernation, le switch vers la console (ctrl-alt-f1) et retour, ...
Une méthode équivalente pour générer des paquets pour Fedora serait bienvenue, si quelqu'un connait...
[^]Re: Tester le dernier pilote sous Ubuntu ou Debian
Plus simple mais beaucoup moins propre :
http://bgoglin.livejournal.com/10936.html
[^]Re: Tester le dernier pilote sous Ubuntu ou Debian
> Une méthode équivalente pour générer des paquets pour Fedora serait bienvenue, si quelqu'un connait...
Je n'ai pas de puce Intel...
Mais, si j'en avais une, dans les grandes lignes je ferai ça :
* Récuparation du paquet de développement de Fedora (le paquet xorg-x11-drv-i810 a aussi les sources xf86-video-intel)
- rpm -i http://fr2.rpmfind.net/linux/fedora/development/source/SRPMS(...)
* Récupération des sources
- git-clone git://anongit.freedesktop.org/git/xorg/driver/xf86-video-intel
* remplacement du xf86-video-intel-*.tar.bz2 du rpm par les sources récupérés avec git-clone
* réajustement du fichier .spec
* construction du paquet ("rpmbuild ... " ou "mock ...").
* Installation : "rpm -Uvh ..."
> Puisque je vous parle de tests urgents (si vous souhaitez que le pilote dans les prochaines versions de Fedora et Ubuntu soit de bonne qualité),
Tout le monde ne peut avoir les connaissances nécessaires pour faire un paquet deb ou rpm.
Une autre voie, et tout aussi excellente, est de tester l'Ubuntu ou Fedora en préparation. Il *faut* aussi s'inscrire sur les mailings pour les testeurs. C'est une mine d'information et d'aide.
Puis faire un rapport de bug. Au niveau distributeur ou en upstream. Mais en cas de doute, il faut le faire au niveau distribution. Un développeur de la distribution regardera si ça concerne un problème lié à la distribution ou un autre paquet (bref, il va trier les bugs). Si c'est une problème upstream, il va créer un rapport de bug au niveau upstream.
* Important : une fois qu'un rapport de bug a été fait, il faut le suivre ! Il faut tester si une nouvelle version corrige le bug et si c'est le cas renseigner le rapport de bug.
Il ne faut pas forcément tester toutes les versions, mais de temps à autre.
* Important : Avant de créer un rapport de bug, vérifiez si le bug n'a pas déjà été remonté.
Une participation au développement/mise au point d'une distribution profite au projet upstream et donc à toutes les distributions.