tag:linuxfr.org,2005:/users/mjulesLinuxFr.org : les contenus de Mjules2024-01-13T13:49:18+01:00/favicon.pngtag:linuxfr.org,2005:Diary/410252024-01-11T22:32:24+01:002024-01-11T22:32:24+01:00Portal: Revolution remercie Gimp, Blender et d'autresLicence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<p>Je viens de finir <a href="https://store.steampowered.com/app/601360/Portal_Revolution/">Portal:revolution</a>, un mod pour Portal 2[0].</p>
<p>Qu'elle ne fut pas ma surprise de voir dans les crédits des remerciements pour les logiciels utilisés et dans ceux-ci Blender et Gimp sont à l'honneur :</p>
<p><img src="//img.linuxfr.org/img/687474703a2f2f6d6a756c65732e667265652e66722f6469766572732f706f7274616c5f7265766f6c7574696f6e5f312e706e67/portal_revolution_1.png" alt="Crédits 1" title="Source : http://mjules.free.fr/divers/portal_revolution_1.png"></p>
<p>ainsi que d'autres logiciels libres (paint.net, git, audacity, kdenlive, handbrake pour ceux que je reconnais) :</p>
<p><img src="//img.linuxfr.org/img/687474703a2f2f6d6a756c65732e667265652e66722f6469766572732f706f7274616c5f7265766f6c7574696f6e5f322e706e67/portal_revolution_2.png" alt="Crédits 2" title="Source : http://mjules.free.fr/divers/portal_revolution_2.png"></p>
<p>En ce début d'année 2024 (bonne année \o/) un peu frisquet, ça m'a bien réchauffé :D</p>
<p>[0] oui, sapusepalibre. Portal/Portal 2 restent des jeux excellents. Portal: revolution est un bon mod, gratuit, pas trop long ni difficile avec une histoire sympathique, quelques mécanismes de puzzles novateurs et des graphismes impressionnants (ils ont modifiés le moteur Source).<br>
D'ailleurs si vous aimez Portal, je vous conseille aussi <a href="https://store.steampowered.com/app/317400/Portal_Stories_Mel/">Portal Stories: Mel</a> qui est de très bonne tenue (gratuit également sur Steam)</p>
<div><a href="https://linuxfr.org/users/mjules/journaux/portal-revolution-remercie-gimp-blender-et-d-autres.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/134472/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/mjules/journaux/portal-revolution-remercie-gimp-blender-et-d-autres#comments">ouvrir dans le navigateur</a>
</p>
Mjuleshttps://linuxfr.org/nodes/134472/comments.atomtag:linuxfr.org,2005:News/334772012-10-22T13:04:13+02:002012-10-22T18:12:20+02:00Documentation du format du JournalLicence CC By‑SA http://creativecommons.org/licenses/by-sa/3.0/deed.fr<div><p>L’un des reproches fait au <em>journal</em>, l’outil de journalisation système <em>— log —</em> de <em>systemd</em>, est l’utilisation d’un format binaire initialement non documenté et pour lequel <a href="https://docs.google.com/document/pub?id=1IC9yOXj7j6cdLLxWEBAGRL6wl97tFxgjLUEHIX3MSTs">aucune promesse de stabilité n’avait été faite</a>.</p>
<p>Une partie de ces reproches est maintenant caduque, puisqu’un <a href="http://www.freedesktop.org/wiki/Software/systemd/journal-files">document apparu hier</a> sur le wiki de <em>systemd</em> documente en profondeur le format du journal. Le comportement que doit avoir un logiciel souhaitant lire ou écrire le journal sans passer par l’interface de programmation de <em>journald</em> est également décrit.</p>
<p>L’équipe s’est même engagée à <a href="http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart">garantir la stabilité</a>, tant pour le format binaire que pour le format texte d’exportation.</p>
<p><strong>NdM :</strong> <em>merci à Mjules pour son journal.</em></p></div><ul><li>lien nᵒ 1 : <a title="http://linuxfr.org/users/mjules/journaux/documentation-du-format-du-journal" hreflang="fr" href="https://linuxfr.org/redirect/83866">Journal à l’origine de la dépêche</a></li></ul><div></div><div><a href="https://linuxfr.org/news/documentation-du-format-du-journal.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/96099/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/news/documentation-du-format-du-journal#comments">ouvrir dans le navigateur</a>
</p>
MjulesDavy DefaudFlorent ZaraBenoît Sibaudclaudexhttps://linuxfr.org/nodes/96099/comments.atomtag:linuxfr.org,2005:Diary/332762012-10-21T10:59:48+02:002012-10-21T10:59:48+02:00Documentation du format du JournalLicence CC By‑SA http://creativecommons.org/licenses/by-sa/3.0/deed.fr<p>Bonjour</p>
<p>l'un des reproches fait au journal (outil de log de systemd) est l'utilisation d'un format binaire initialement non documenté et pour lequel aucune promesse de stabilité n'avais été faite :<br /><a href="https://docs.google.com/document/pub?id=1IC9yOXj7j6cdLLxWEBAGRL6wl97tFxgjLUEHIX3MSTs">https://docs.google.com/document/pub?id=1IC9yOXj7j6cdLLxWEBAGRL6wl97tFxgjLUEHIX3MSTs</a></p>
<p>Une partie de ces reproches est maintenant caduque puisqu'un document apparu hier sur le wiki de systemd documente en profondeur le format du journal : <a href="http://www.freedesktop.org/wiki/Software/systemd/journal-files">http://www.freedesktop.org/wiki/Software/systemd/journal-files</a></p>
<p>Le comportement que doit avoir un logiciel souhaitant lire ou écrire le journal sans passer par l'api de journald est également décrit.</p>
<p>Enfin, même si aucune promesse de stabilité n'est faite, un mécanisme d'extension compatible du format est là, ce qui laisse présumer d'une volonté de ne pas tout casser dans un futur proche.</p><div><a href="https://linuxfr.org/users/mjules/journaux/documentation-du-format-du-journal.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/96086/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/mjules/journaux/documentation-du-format-du-journal#comments">ouvrir dans le navigateur</a>
</p>
Mjuleshttps://linuxfr.org/nodes/96086/comments.atomtag:linuxfr.org,2005:News/251362009-03-10T09:08:45+01:002009-03-10T09:08:45+01:00Le serveur X 1.6 est disponible<div>La version 1.6 du serveur X édité par X.org est disponible depuis ce 25 février 2009.
<br />
<br />
Au menu des nouveautés : <ul><li>Le support du protocole DRI2 ;
<br />
</li><li>RandR 1.3 ;
<br />
</li><li>Xinput 1.5 avec le support des propriétés ;
<br />
</li><li>Une meilleure gestion de l'accélération du pointeur de la souris ;
<br />
</li><li>Une amélioration des performances de l'architecture d'accélération 2D EXA ;
<br />
</li><li>Beaucoup de corrections de bogues divers et variés (et probablement quelques nouveaux ;) ).</li></ul>
<br />
Pour mémoire, un serveur X implémente la partie serveur du protocole X11, il est donc lancé sur une machine dite « cliente » (poste de travail). La version 1.5 (sortie avec la suite Xorg 7.4) avait notamment apporté une gestion du branchement à chaud des périphériques via HAL.</div><ul><li>lien nᵒ 1 : <a title="http://lists.freedesktop.org/archives/xorg-announce/2009-February/000784.html" hreflang="en" href="https://linuxfr.org/redirect/60968">L'annonce sur Xorg-annouce</a></li><li>lien nᵒ 2 : <a title="http://www.x.org/wiki/" hreflang="en" href="https://linuxfr.org/redirect/60969">Site internet du projet X.Org</a></li><li>lien nᵒ 3 : <a title="http://fr.wikipedia.org/wiki/X_Window_System" hreflang="fr" href="https://linuxfr.org/redirect/60970">X Window System sur Wikipédia</a></li></ul><div><b>DRI2</b> est le remplacement de l'ancien protocole DRI (Direct Rendering Interface). Je serais bien en peine de vous en décrire les arcanes mais cette évolution permet entre autre d'envisager de rediriger des fenêtres en rendu direct et ainsi de pouvoir réaliser de la composition avec. Il sera à terme possible d'avoir une application 3D composée avec une autre (par exemple glxgear sur les faces du cube de Compiz).
<br />
Pour mémoire, la composition est l'opération consistant à rediriger toutes les fenêtres dans un espace mémoire avant affichage afin de réaliser diverses opérations nécessitant de connaître l'ensemble, comme par exemple, les ombres portées, la vraie transparence, etc.
<br />
Description du protocole : <a href="http://wiki.x.org/wiki/DRI2">http://wiki.x.org/wiki/DRI2</a>
<br />
<br />
<b>RandR 1.3</b> est une évolution de l'extension Resize and Rotate. La version 1.2 a permis l'introduction de fonctions comme la gestion du branchement à chaud des écrans doubles, de leurs relations, etc. Toutefois, des manques se sont rapidement fait sentir que les développeurs ont tenté de combler par cette version 1.3.<ul><li>Ainsi, on peut maintenant connaître l'état des moniteurs sans sonder les sorties de la carte graphique, on évite ainsi les scintillements voire les flashs sur l'écran ;
<br />
</li><li>Il est possible de définir un moniteur primaire ;
<br />
</li><li>Le « panning » est maintenant possible, c'est à dire avoir une surface d'affichage supérieure à la taille de l'écran, la zone visible se déplaçant avec la souris ;
<br />
</li><li>Des transformations (rotation, changement d'échelle) sont maintenant possibles.</li></ul>
<br />
Pour plus de détails, suivez cette présentation de Matthias Hopf, concepteur de la version 1.3 : <a href="http://www.vis.uni-stuttgart.de/~hopf/pub/Fosdem_2009_randr13_Slides.pdf">http://www.vis.uni-stuttgart.de/~hopf/pub/Fosdem_2009_randr1(...)</a> (PDF).
<br />
<br />
<b>Xinput 1.5</b> est la dernière évolution de l'extension du même nom avant la très attendue version 2 qui amènera le support des entrées multiples tel le multitouches (comme sur l'iPhone par exemple). Cette version ajoute la gestion des propriétés aux entrées. Tout comme les écrans possèdent une résolution/fréquence/orientation qu'il est possible de faire varier via xrandr ; il est maintenant possible d'obtenir et de gérer un certain nombre de propriétés des périphériques d'entrées comme par exemple, l'attribution des boutons. Le tout grâce à l'utilitaire xinput ( <a href="http://www.manpagez.com/man/1/xinput/">http://www.manpagez.com/man/1/xinput/</a>).
<br />
Plus de détails dans le mail de Peter Hutterer ainsi que sur son blog :
<br />
<a href="http://lists.freedesktop.org/archives/xorg/2008-September/038262.html">http://lists.freedesktop.org/archives/xorg/2008-September/03(...)</a>
<br />
<a href="http://who-t.blogspot.com/">http://who-t.blogspot.com/</a>
<br />
<br />
<b>Predictable Pointer Acceleration</b> est un travail qui remplace totalement l'ancien code d'accélération du pointeur de souris tout en restant compatible. En théorie, le résultat devrait être relativement invisible. Cependant pour ceux qui en ont besoin, il offre une souplesse bien supérieure dans la gestion des caractéristiques du mouvement (ex : accélération, vitesse) avec notamment la possibilité de les modifier à chaud via l'utilitaire xinput ou par le biais d'un fichier de configuration (xorg.conf ou les fichiers fdi de hal).
<br />
Description et spécifications : <a href="http://www.x.org/wiki/Development/Documentatio/PointerAcceleration">http://www.x.org/wiki/Development/Documentation/PointerAccel(...)</a>
<br />
<br />
<b>EXA</b> est une architecture actuelle d'accélération des opérations 2D visant à remplacer XAA. Depuis la version 1.2 du serveur X, le code d'EXA a subit de profondes améliorations qui ont permis des gains substantiels de vitesse. La version 1.6 ne déroge pas à la règle puisqu'elle inclut différentes optimisations, en particulier sur le rendu des polices de caractères. Au lieu d'utiliser un pixmap par glyphe, on alloue un pixmap pour un ensemble de glyphes et on compose au moment du rendu (bien mieux expliqué ici : <a href="http://blog.fishsoup.net/2008/04/20/fast-text-use-a-single-cache-pixmap/">http://blog.fishsoup.net/2008/04/20/fast-text-use-a-single-c(...)</a> ), ce qui permet des gains substantiels en vitesse puisque le moteur de la carte graphique peut traiter les glyphes tous ensemble au lieu de les traiter l'un après l'autre.
<br />
<br />
<b>L'architecture UXA</b> quant à elle n'est pas incluse dans cette version du serveur X et il n'est pas certain qu'elle apparaisse dans les prochaines versions. Pour mémoire, c'est un dérivé d'EXA développé par Intel et optimisé pour les cartes dépourvues de mémoire dédiée. Elle est très dépendante du gestionnaire de mémoire GEM (développé aussi par Intel), ceci expliquant peut être cela.
<br />
<br />
La prochaine version du serveur X (1.7) sera la base de X.org 7.5 et est prévu pour avril. Il y a néanmoins peu de chance qu'elle soit disponible avant août ou septembre 2009, les développeurs X étant notoirement connus pour dépasser les dates qu'ils se sont fixés ;).
<br />
<br />
Bien entendu, toute aide pour respecter ces délais est la bienvenue. Dixit les développeurs, le code du serveur X a beaucoup été remanié ces dernières années et il n'est plus aussi effrayant qu'il a pu l'être. N'ayez pas peur de contribuer si vous le pouvez et le voulez.</div><div><a href="https://linuxfr.org/news/le-serveur-x-16-est-disponible.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/24233/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/news/le-serveur-x-16-est-disponible#comments">ouvrir dans le navigateur</a>
</p>
Mjuleshttps://linuxfr.org/nodes/24233/comments.atomtag:linuxfr.org,2005:News/243542008-07-28T17:05:20+02:002008-07-28T17:05:20+02:00Microsoft clarifie l'Open Specification Promise et donne 100000$ à la fondation Apache<div>Microsoft vient de faire un mouvement vers le libre avec l'annonce, lors de l'<a href="http://port25.technet.com/archive/2008/07/25/oscon2008.aspx">OSCON</a>,
<br />
<ul><li>de la mise sous <i>Open Specification Promise</i>, de plusieurs protocoles auparavant dans le <i>Communication Protocol Program</i> ;
<br />
</li><li>d'un don de 100 000 $ annuel à la Apache Software Foundation. Comme il est précisé dans <a href="http://bahumbug.wordpress.com/2008/07/26/apache-sponsorship-vs-membership/">ce billet</a>, Microsoft ne devient pas membre de la fondation Apache mais donateur (<i>sponsor</i>) ;
<br />
</li><li>et de la contribution d'un patch pour AdoDB qui permet l'utilisation directe de SQL Server avec PHP.</li></ul>Pour mémoire, l'OSP est un engagement écrit de Microsoft de ne pas attaquer pour violation de brevet quiconque implémenterait les spécifications couvertes.
<br />
<br />
Une clarification a également été donnée quant aux développements sous licence GNU/GPL qui est maintenant explicitement couverte par l'OSP (voir la FAQ). Ce point était l'un des reproches principaux fait à cet engagement.</div><ul><li>lien nᵒ 1 : <a title="http://www.groklaw.net/article.php?story=20080725152355696" hreflang="en" href="https://linuxfr.org/redirect/58198">L'article de Groklaw</a></li><li>lien nᵒ 2 : <a title="http://www.microsoft.com/interop/osp/default.mspx#ELPAC" hreflang="en" href="https://linuxfr.org/redirect/58199">FAQ de l'OSP</a></li><li>lien nᵒ 3 : <a title="http://linuxfr.org/~patrick_g/26971.html" hreflang="fr" href="https://linuxfr.org/redirect/58200">Journal de Patrick_g</a></li></ul><div></div><div><a href="https://linuxfr.org/news/microsoft-clarifie-lopen-specification-promise-et-donne-100000.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/23462/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/news/microsoft-clarifie-lopen-specification-promise-et-donne-100000#comments">ouvrir dans le navigateur</a>
</p>
Mjuleshttps://linuxfr.org/nodes/23462/comments.atomtag:linuxfr.org,2005:Diary/262052008-02-23T14:22:01+01:002008-02-23T14:22:01+01:00AMD libère un guide programmation 3D des R5xx
Tout est dans le titre ; AMD vient de libérer un guide pour programmer le moteur 3D de ses R5xx. comme ils l'avaient promis il y a quelques temps.<br />
<br />
L'annonce est ici :<br />
<a href="http://www.botchco.com/agd5f/">http://www.botchco.com/agd5f/</a><br />
<br />
Le guide est là :<br />
<a href="http://www.x.org/docs/AMD/R5xx_Acceleration_v1.1.pdf">http://www.x.org/docs/AMD/R5xx_Acceleration_v1.1.pdf</a><br />
<br />
Je n'y connais pas grand chose mais parcouru rapidement, ça donne l'impression de réellement décrire comment et quoi envoyer à la carte.<br />
<br />
(Les R5xx, ce sont les x16xxet x19xx etc)<div><a href="https://linuxfr.org/users/mjules/journaux/amd-lib%C3%A8re-un-guide-programmation-3d-des-r5xx.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/52599/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/mjules/journaux/amd-lib%C3%A8re-un-guide-programmation-3d-des-r5xx#comments">ouvrir dans le navigateur</a>
</p>
Mjuleshttps://linuxfr.org/nodes/52599/comments.atomtag:linuxfr.org,2005:News/237272008-02-19T17:05:06+01:002008-02-19T17:05:06+01:00Un point sur le projet Nouveau<div>Nouveau est un projet de pilote X libre visant à supporter les cartes NVidia aussi bien en 2D qu'en 3D. Depuis la dernière dépêche sur le sujet, il y a presque un an, le projet a bien évolué.
<br />
<br />
Le présent article a pour but de faire le point sur l'avancement de Nouveau et de son pilote, ainsi que sur les évolutions attendues. C'est une traduction de celui de <a href="http://lwn.net/">Linux Weekly News</a> qui sera publié jeudi. Le site LWN.net nous a gracieusement autorisé à le traduire et publier la version française avant eux. L'article original a été collégialement écrit par les membres du projet.
<br />
<br />
Si vous souhaitez nous rencontrer, vous êtes les bienvenus au <a href="http://www.fosdem.org/2008/">FOSDEM 2008</a> où une partie de l'équipe du projet Nouveau se rendra les 23 et 24 février. Stéphane Marchesin y présentera les étapes pour arriver à un pilote libre (Samedi 23, 16h30 -17H30 Xorg Devroom).
<br />
</div><ul><li>lien nᵒ 1 : <a title="http://nouveau.freedesktop.org" hreflang="en" href="https://linuxfr.org/redirect/55895">Le projet Nouveau</a></li><li>lien nᵒ 2 : <a title="http://nouveau.freedesktop.org/wiki/IrcChatLogs-fr" hreflang="fr" href="https://linuxfr.org/redirect/55896">Les logs IRC et les TiNDC</a></li><li>lien nᵒ 3 : <a title="http://dri.freedesktop.org" hreflang="en" href="https://linuxfr.org/redirect/55897">Le projet DRI</a></li><li>lien nᵒ 4 : <a title="http://xorg.freedesktop.org" hreflang="en" href="https://linuxfr.org/redirect/55898">X.org</a></li><li>lien nᵒ 5 : <a title="http://www.tungstengraphics.com/" hreflang="en" href="https://linuxfr.org/redirect/55899">Tungsten Graphics</a></li><li>lien nᵒ 6 : <a title="http://mjules.free.fr/dotclear/index.php?2006/11/08/85-comment-marche-x11-xorg-et-toute-la-clique" hreflang="fr" href="https://linuxfr.org/redirect/55900">Un résumé du fonctionnement de X11</a></li></ul><div>Cet article fait le point sur l'avancement du projet Nouveau et l'évolution de la pile graphique sous Linux.
<br />
<br />
<strong>== Introduction ==</strong>
<br />
<br />
Nouveau est un projet visant à écrire un pilote X.org libre et complet pour les cartes graphiques Nvidia. L'objectif est de supporter l'accélération 2D et 3D pour toutes les cartes <a href="http://fr.wikipedia.org/wiki/NVIDIA">NVidia</a> depuis les NV04 (TNT) aux dernières G80 (Geforce 8), et de supporter les architectures x86-64, <a href="http://fr.wikipedia.org/wiki/PowerPC">PPC</a> et x86.
<br />
<br />
<br />
<strong>== Historique ==</strong>
<br />
<br />
Le projet a démarré quand Stéphane Marchesin a voulu <a href="http://fr.wikipedia.org/wiki/Code_imp%C3%A9n%C3%A9trable">désobscurcir</a> une partie du pilote nv, maintenu par NVidia. Malheureusement, un certain nombre de règles étaient en place chez NVidia concernant ce pilote, et ils n'avaient à l'époque aucune intention de les changer. Ils refusèrent les patches de Stéphane.
<br />
<br />
Il ne restait donc à notre intrépide hacker que le grand choix du libre : forker ! En février 2006, au FOSDEM, Stéphane a dévoilé ses plans pour un pilote libre pour le matériel NVidia appelé Nouveau. Le nom a été suggéré par la fonction de remplacement automatique de son client <a href="http://fr.wikipedia.org/wiki/Internet_Relay_Chat">IRC</a> qui lui proposait le mot « <i>nouveau</i> » lorsqu'il tapait « <i>nv</i> ». Les gens ont aimé et le nom est resté. La présentation au <a href="http://fr.wikipedia.org/wiki/Free_and_open_source_software_developers'_european_meeting">FOSDEM</a> a amené assez de publicité au projet pour attiser la curiosité d'autres développeurs.
<br />
<br />
Ben Skeggs fut l'un des premiers à s'impliquer. Il avait auparavant travaillé à l'ingénierie inverse des shaders des r300 (un circuit graphique d'ATI) et avait écrit des parties du pilote ; il avait donc une grande expérience avec les pilotes graphiques. Au départ, il s'intéressait uniquement aux shaders des NV40 mais il a par la suite été pris dans le mouvement et a à ce jour travaillé sur à peu près toutes les parties du pilote pour les NV40 et supérieures.
<br />
<br />
Le projet a attiré d'autres développeurs avec des intérêts à plus ou moins long terme. Un utilisateur indépendant a mis en place une promesse de dons, dont le montant final s'est élevé à 10 000$ US, mais pour des raisons indépendantes de notre volonté nous n'avons pas pu recevoir ces dons.
<br />
<br />
Le projet étant principalement développé sur IRC, il était assez difficile pour les nouveaux arrivants de se rendre compte des développements antérieurs, lire des logs IRC n'étant pas très pratique. KoalaBR a donc décidé de résumer le développement dans une série d'articles connus sous le nom de TiNDC (The irregular Nouveau Development Companion). Ceux-ci se sont révélés être très utiles pour attirer des nouveaux développeurs et testeurs autour du projet. Le TiNDC est publié toutes les deux à quatre semaines.
<br />
<br />
Le LCA 2007 a vu la première démonstration réelle de Nouveau. Dave Airlie avait accepté de donner une conférence sur le sujet et a réussi à persuader Ben Skeggs que montrer un glxgears fonctionnel ferait un magnifique final. Ben a travaillé sans répit avec les autres développeurs afin d'avoir une initialisation correcte de la carte de son portable et la présentation fut un véritable succès.
<br />
<br />
Après avoir manqué de place au Google Summer of Code, X.org a fourni à Nouveau une alternative par l'intermédiaire du Vacation of Code. Celui-ci a vu Arthur Huillet rejoindre l'équipe et travailler sur un support performant de Xv dans Nouveau. Arthur a eu une révélation et il a continué à s'impliquer dans Nouveau après la fin du VoC.
<br />
<br />
À l'automne 2007, Stuart Bennett et Maarten Maathuis se sont promis d'améliorer le support de Nouveau pour RandR1.2. Depuis, un flot continuel de patches a permis une nette amélioration du code.
<br />
<br />
Le projet a actuellement 8 contributeurs réguliers (Stéphane Marchesin, Ben Skeggs, Patrice Mandin, Arthur Huillet, Pekka Paalanen, Maarten Maathuis, Peter Winters, Jeremy Kolb, Stuart Bennett) et bien plus de contributeurs occasionnels, testeurs, écrivains et traducteurs.
<br />
<br />
<br />
<strong>== Les familles de cartes NVidia ==</strong>
<br />
<br />
Cet article utilisera les noms techniques des <a href="http://fr.wikipedia.org/wiki/Processeur_graphique">GPU</a> (Graphics Processing Unit) NVidia et non les noms commerciaux : <ul><li>NV04/05 Riva TNT, TNT2</li><li>NV1x GeForce 256, GeForce 2, GeForce 4 MX</li><li>NV2x GeForce 3, GeForce 4 Ti</li><li>NV3x GeForce 5</li><li>NV4x(G7x) GeForce 6, GeForce 7</li><li>NV5x(G8x) GeForce 8</li></ul>
<br />
Pour les noms avec « N » ou « G », nous utilisons de préférence la variante « N » (NV4x et NV5x).
<br />
<a href="http://nouveau.freedesktop.org/wiki/CodeNames">http://nouveau.freedesktop.org/wiki/CodeNames</a> pour plus d'informations
<br />
<br />
<br />
<strong>== Généralités sur le système graphique ==</strong>
<br />
<br />
Avant de nous intéresser au pilote Nouveau, nous allons voir dans cette section un bref aperçu de la complexité du système graphique sous GNU/Linux.
<br />
<br />
Celui-ci a un long historique remontant aux serveurs X Unix et au projet XFree86. Ceci a conduit a une situation très différente de celle des autres pilotes sous Linux. Les pilotes graphiques étaient fournis par le projet XFree86, s'exécutaient principalement en espace utilisateur, et ne requéraient que peu voire pas d'interaction avec le noyau. La partie en espace utilisateur, connue sous le nom de DDX (Device-Dependant X), était responsable de l'initialisation de la carte, de la gestion des modes (NDT : fréquence et résolution) et elle fournissait l'accélération des opérations 2D.
<br />
<br />
Le noyau fournissait également des pilotes framebuffer pour certains systèmes afin d'avoir une console utilisable avant le démarrage de X. Malheureusement, les interactions entre ces pilotes et ceux de X étaient plus ou moins aléatoires et de nombreux problèmes pouvaient survenir, notamment en cas de conflit sur qui doit diriger le matériel.
<br />
<br />
Le projet <a href="http://fr.wikipedia.org/wiki/Direct_Rendering_Infrastructure">DRI</a> a démarré afin d'ajouter le support pour le rendu direct dans les applications 3D sous GNU/Linux. Rendu direct signifie qu'une application peut parler directement à la partie 3D du matériel, sans passer par le serveur X. <a href="http://fr.wikipedia.org/wiki/OpenGL">OpenGL</a> est l'<a href="http://fr.wikipedia.org/wiki/Interface_de_programmation">API</a> 3D standard mais elle est trop complexe et trop grande pour être implémentée dans le noyau, sans compter les différents GPU qui fournissent des interfaces bas-niveaux très différentes. Ainsi, à cause de la complexité de l'interface haut-niveau et de l'absence de standardisation des API matérielles, un composant noyau (<a href="http://fr.wikipedia.org/wiki/Direct_Rendering_Manager">DRM</a>, Direct Rendering Manager) et un pilote en espace utilisateur (DRI, Direct Rendering Infrastructure) furent nécessaires pour exposer sans risque les interfaces matérielles et fournir l'API OpenGL.
<br />
<br />
Les limitations de cette architecture sont apparues au cours des dernières années et le consensus actuel est que l'initialisation du GPU, la gestion de la mémoire et celle des modes doivent migrer dans le noyau. Cela permettra une meilleure cohabitation entre les pilotes X et le framebuffer, un meilleur support de la mise en veille/réveil, une plus grande facilité à rapporter les erreurs noyau (le noyau sera capable d'afficher un message d'erreur à l'écran même si X est lancé), et plus de souplesse pour gérer les futures technologies des cartes graphiques.
<br />
<br />
Le gestionnaire de mémoire des GPU, implémenté par Tungsten Graphics, est connu sous le nom de TTM ( <a href="http://lwn.net/Articles/256772/">http://lwn.net/Articles/256772/</a> ). Bien qu'initialement destiné au matériel Intel, il est conçu comme un gestionnaire de mémoire vidéo généraliste.
<br />
<br />
Au dessus du gestionnaire de mémoire, un architecture de gestion des modes dans le noyau a été implémentée. Elle est basée sur le travail réalisé avec RandR1.2 dans le serveur <a href="http://fr.wikipedia.org/wiki/X.Org">X.org</a>.
<br />
<br />
<br />
<strong>== Architecture du GPU ==</strong>
<br />
<br />
Les cartes graphiques peuvent être programmées de multiples façons mais la plus grande partie de l'initialisation et de la gestion des modes est faite via <a href="http://en.wikipedia.org/wiki/Memory-mapped_IO">MMIO</a> (entrées/sorties projetées en mémoire, Memory Mapped I/O), qui correspond à un ensemble de registres accessibles par le CPU dans son espace d'adressage mémoire standard. Ceux-ci sont ensuite divisés en groupes gérant diverses fonctions telles que gestion des modes, contrôle des sorties vidéos ou encore configuration des fréquences.
<br />
<br />
Une explication plus complète peut être trouvée à l'adresse suivante : <a href="http://en.wikipedia.org/wiki/Memory-mapped_IO">http://en.wikipedia.org/wiki/Memory-mapped_IO</a>
<br />
<br />
Les GPU les plus récents fournissent également des possibilités de traitement de commandes grâce auxquelles il est possible de décharger le CPU de différentes tâches qui seront alors exécutées sur le GPU, réduisant les ressources CPU nécessaires pour les opérations graphiques.
<br />
Ces interfaces sont généralement des <a href="http://fr.wikipedia.org/wiki/First_in%2C_first_out">FIFO</a> (First In, First Out) implémentées comme des tampons circulaires dans lesquels les commandes sont placées par le CPU et exécutées par le GPU. Elles sont situées dans une zone de mémoire partagée (mémoire <a href="http://fr.wikipedia.org/wiki/Accelerated_Graphics_Port">AGP</a>, PCIGART ou RAM vidéo). Le GPU possède également un ensemble d'informations d'état, généralement appelées contextes, qui sont utilisées pour traiter les commandes.
<br />
<br />
La plupart des GPU modernes contiennent une seule machine à états pour traiter les commandes. Le matériel NVidia, quant à lui, a toujours possédé plusieurs « <i>canaux</i> » indépendants qui consistent en une FIFO privée (push buffer), un contexte graphique et un ensemble d'objets de contexte. Le « <i>push buffer</i> » contient les commandes à exécuter par la carte, le contexte graphique stocke les données spécifiques à l'application telles que des matrices, des configuration d'unités de textures, des paramètres de blending, des informations sur les shaders, etc. Chaque canal contient 8 sous-canaux auxquels sont liés les objets graphiques avant leur traitement par la commande dans la FIFO.
<br />
<br />
Chaque carte NVidia dispose, suivant le modèle, de 16 à 128 canaux assignés à différentes tâches de rendu. Chaque client 3D possède un canal associé, quelques canaux sont réservés pour le noyau et pour le serveur X. Les canaux sont intervertis (« <i>changement de contexte</i> ») par voie logicielle à la suite d'une interruption sur les vieilles cartes, et automatiquement par la carte elle-même pour celles postérieures aux NV30.
<br />
<br />
Et maintenant, que placer dans la FIFO ?
<br />
Chaque carte NVidia dispose d'un ensemble d'objets, chacun d'entre eux fournissant différentes méthodes liées à une tâche donnée, par exemple, transfert mémoire <a href="http://fr.wikipedia.org/wiki/Acc%C3%A8s_direct_%C3%A0_la_m%C3%A9moire">DMA</a> ou rendu.
<br />
Ces méthodes sont celles utilisées par le pilote (ou, à un niveau plus élevé, par l'application). Quand un client se connecte, il utilise un ioctl() pour créer un canal. Par la suite, le client crée les objets dont il a besoin à l'aide d'un autre ioctl().
<br />
<br />
Actuellement, nous avons deux types de client possibles :
<br />
X (via le pilote DDX) et OpenGL via DRI/MESA. Un pilote framebuffer accéléré utilisant la nouvelle architecture de gestion de mode (nouveaufb) sera également un client dans le futur, permettant d'éviter les conflits rencontrés avec nvidiafb.
<br />
<br />
Détaillons quelques uns de ces objets :
<br />
<br />
nom de l'objet:
<br />
NV_IMAGE_BLIT
<br />
Description courte:
<br />
Moteur 2D, combine plusieurs images en une autre.
<br />
Disponible sur:
<br />
NV03,NV04,NV10,NV20
<br />
<br />
nom de l'objet:
<br />
NV12_IMAGE_BLIT
<br />
Description courte:
<br />
Version améliorée du précédent.
<br />
Disponible sur:
<br />
NV11,NV20,NV20,NV30,NV40
<br />
<br />
nom de l'objet:
<br />
NV_MEMORY_TO_MEMORY_FORMAT
<br />
Description courte:
<br />
Transfert mémoire DMA.
<br />
Disponible sur:
<br />
V04,NV10,NV20,NV30,NV40,NV50
<br />
<br />
Dans cette liste, vous pouvez remarquer que certains objets sont disponibles sur toutes les cartes (NV_MEMORY_TO_MEMORY_FORMAT) tandis que d'autres ne le sont que sur certaines. Par exemple, chaque famille de carte a son propre objet moteur 3D : NV10TCL sur NV1x, NV20TCL sur NV2x, etc.
<br />
Chaque objet est identifié par un nombre unique : sa « classe ». Cet ID est 0x5f pour NV_IMAGE_BLIT, 0x9f pour NV12_IMAGE_BLIT et 0x39 pour NV_MEMORY_TO_MEMORY_FORMAT.
<br />
Si vous voulez utiliser les fonctionnalités d'un objet donné, vous devez tout d'abord le lier à un sous-canal. La carte fournit un certain nombre de sous-canaux, qui correspondent à un certain nombre d'objet actifs (ou liés).
<br />
<br />
Chaque méthode fournie par un objet possède un offset qui doit être précisé dans la commande.
<br />
<br />
Une commande dans la FIFO est composée d'un en-tête suivi par un ou plusieurs paramètres. L'en-tête contient généralement le numéro du sous-canal, l'offset de la méthode à appeler et le nombre de paramètres (une entête peut également définir un saut dans le FIFO mais cela sort du cadre de cette explication).
<br />
<br />
De façon à limiter la quantité d'entêtes à écrire et donc améliorer les performances, les cartes NVidia peuvent appeler plusieurs méthodes consécutives en une fois si on a correctement fourni plusieurs paramètres.
<br />
<br />
Comment se réfère-t-on à un objet ?
<br />
Les données écrites dans la FIFO ne contiennent aucune information à ce sujet...
<br />
<br />
Lier un objet au sous-canal 1 est réalisé par l'écriture de son ID comme argument de la méthode 0. Par exemple : 00044000 5c00000c lie l'objet dont l'ID est 5c00000c au sous-canal 2. Cet ID est alors utilisé comme clé dans une table de hachage conservée dans la mémoire de la carte et qui est remplie lors de la création des objets. C'est comme ça que l'objet est identifié.
<br />
<br />
La création d'un objet a besoin de zones mémoire spéciales :
<br />
<br />
RAMIN
<br />
<br />
RAMIN signifie « mémoire d'instance », c'est une zone de mémoire à travers laquelle le moteur graphique est configuré. Une zone RAMIN est présente sur toutes les puces NVidia d'une façon ou d'une autre mais elle a évolué au fur et à mesure de la sortie des nouvelles puces.
<br />
En bref, RAMIN est ce qui contient les objets. Ces derniers ne sont généralement pas très gros (128 octets en général, jusqu'à quelques kilooctets dans le cas des objets DMA qui contiennent une liste de pages physiques).
<br />
<ul><li>Pre-NV40 : Zone de mémoire interne dédiée, accessible par les registres MMIO de la carte.</li><li>NV4x : Une ressource PCI de 16Mo est utilisée pour accéder à RAMIN. Cette ressource est représentée sur les 16 derniers mégaoctets de la VRAM. Le premier mégaoctet de RAMIN est également accessible au travers de l'ouverture MMIO (héritée du passé).</li><li>NV5x : La ressource PCI est de 32Mo mais n'est pas utilisable directement au démarrage de la carte. Elle peut être configurée de multiples façons via la mémoire virtuelle des NV5x. L'ouverture MMIO peut être projetée sur n'importe quel segment de 1Mo de VRAM.</li></ul><p>RAMIN contient également quelques zones spécifiques à mentionner :</p>
<br />
RAMFC - Table des contextes FIFO<ul><li> Table globale qui stocke les états/configurations du moteur de FIFO pour chaque canal</li><li> N'existe pas sous cette forme sur les NV5x. Plutôt qu'une table globale unique, les FIFO ont des registres qui contiennent des pointeurs vers les états de chaque canal de FIFO.</li></ul>
<br />
RAMHT - FIFO hash table<ul><li> Table globale, utilisée par le PFIFO pour trouver les objets de contexte</li><li> sauf sur les NV5x où chaque canal a sa propre hashtable.</li></ul>
<br />
Des information supplémentaires sont disponibles sur ces liens :
<br />
<a href="http://nouveau.freedesktop.org/wiki/NvObjectTypes">http://nouveau.freedesktop.org/wiki/NvObjectTypes</a>
<br />
<a href="http://nouveau.freedesktop.org/wiki/HonzaHavlicek">http://nouveau.freedesktop.org/wiki/HonzaHavlicek</a>
<br />
<br />
<br />
<strong>== Sources d'informations et outils d'ingénierie inverse ==</strong>
<br />
<br />
Étant donné que très peu d'informations sont disponibles sur la conception et l'implémentation du matériel NVidia, le projet Nouveau a développé un certain nombre d'outils afin de mieux comprendre l'architecture des cartes et comment les programmer. Ce sont ces outils, accompagnés d'informations préexistantes, qui sont utilisés pour écrire le pilote.
<br />
<br />
Haiku/BeOS dispose d'un pilote issu du <a href="http://fr.wikipedia.org/wiki/Kit_de_d%C3%A9veloppement">SDK</a> NVidia disponible pour les cartes NV03/04 et des informations fournies par le pilote nv non obscurci qui a fait un bref passage dans XFree86. Ce pilote possède un code de gestion des modes amélioré par rapport à nv et un pilote 3D basique utilisant des objets fixes et un contexte unique.
<br />
<br />
D'autres informations sont disponibles dans l'utilitaire nvclock qui permet l'overclocking sous GNU/Linux des GPU NVidia. Son principal auteur, Roderick Colenbrander (Thunderbird) a aidé Nouveau pour la gestion des fréquences, de l'i2c, et de la sortie TV (dont le support n'est pas encore implémenté dans Nouveau).
<br />
<br />
<em>=== REnouveau ===</em>
<br />
<br />
Le premier utilitaire qui a été développé est REnouveau. Il permet l'<a href="http://fr.wikipedia.org/wiki/R%C3%A9tro-ing%C3%A9nierie">ingénierie inverse</a> du pilote binaire nvidia par la méthode de la boîte noire : envoyer des commandes au pilote d'un côté et étudier ce que le pilote commande à la carte de l'autre. Il utilise pour cela un grand nombre de tests OpenGL couvrant la majeure partie des capacités du GPU et génère un ensemble de fichiers résultats à envoyer aux développeurs de Nouveau.
<br />
<br />
Il fonctionne en présentant les registres et les FIFO assignés à l'application courante.
<br />
Il enregistre ensuite l'état des FIFO et des registres, exécute un programme OpenGL simple et compare l'état final avec l'état initial. Enfin, il écrit l'information dans un format pouvant être lu par un humain en utilisant une base de donnée XML des registres/commandes. (Certains développeurs objecteront que l'hexadécimal est tout à fait lisible pour eux).
<br />
<br />
Cet outil a comme avantage d'être simple pour l'utilisateur qui peut le lancer sur de nombreuses configurations, sans avoir besoin d'être root. Il ne perturbe pas le pilote binaire et ne nécessite pas de connaissances techniques approfondies.
<br />
<br />
<em>=== MMioTrace ===</em>
<br />
<br />
MMioTrace est un outil utilisé pour tracer les accès MMIO dans le noyau. Le pilote NVidia contient en effet un module noyau qui est responsable de presque toute l'initialisation de la carte, la gestion des modes, et qui ne peut pas être observé simplement depuis un outil en espace utilisateur comme REnouveau.
<br />
MMioTrace utilise relayFS et debugFS pour remonter les données d'observation vers l'espace utilisateur.
<br />
<br />
MMioTrace agit en remplaçant, dans le pilote à observer, les appels vers les fonctions noyau ioremap, ioremap_nocache et iounmap par des appels à des fonctions de MMioTrace. Lorsque le pilote modifié appelle ioremap() pour accéder aux registres MMIO, les pages à accéder sont alors présentées comme absentes dans l'espace d'adresse du noyau. MMioTrace peut être paramétré pour ne tracer que les adresses qui pourront être touchées par le pilote, réduisant ainsi le volume du fichier final.
<br />
<br />
Lorsque le module du pilote essaye d'accéder à l'espace des registres, une erreur de page va se produire. Le gestionnaire d'erreur de page va alors détecter l'adresse et enregistrer l'action tentée. La page est ensuite marquée comme présente, et l'instruction bloquée va être exécutée. La page est ensuite de nouveau marquée comme absente et le cycle peut recommencer au prochain accès.
<br />
<br />
L'une des restrictions de MMioTrace est qu'il ne peut pas tracer les adresses historiques <a href="http://fr.wikipedia.org/wiki/Industry_Standard_Architecture">ISA</a>, marquer celles-ci comme absentes faisant crasher le noyau. Une solution est peut être en vue mais elle nécessiterait de patcher le noyau.
<br />
<br />
MMioTrace n'est pas seulement utilisable pour les pilotes graphiques mais également pour tous les types de pilotes s'exécutant dans le noyau.
<br />
Jusqu'à la version 2.6.23 du noyau Linux, MMioTrace était fourni sous la forme d'un module externe. La version 2.6.24 a vu le retrait des fonctions nécessaires à MMioTrace, ce qui signifie qu'il devra être inclus dans le 2.6.25 ou suivant pour continuer à fonctionner.
<br />
<br />
Si vous êtes intéressé par plus d'informations, MMioTrace possède une page web dédiée :
<br />
<a href="http://nouveau.freedesktop.org/wiki/MMioTrace">http://nouveau.freedesktop.org/wiki/MMioTrace</a>
<br />
<br />
<em>=== Valgrind-mmt ===</em>
<br />
<br />
Valgrind-mmt est un greffon pour la suite de débogage <a href="http://fr.wikipedia.org/wiki/Valgrind">Valgrind</a>. Il trace les accès MMIO depuis un processus en espace utilisateur, comme par exemple le serveur X.org où le pilote NVidia DDX est chargé. Cet outil a été développé à l'origine par Dave Airlie pour observer le matériel ATI et ensuite étendu par nombre de développeurs. Il est utilisé dans le cadre de Nouveau, d'une façon plus ou moins similaire à REnouveau, pour extraire le contenu des FIFO.
<br />
Valgrind-mmt permet d'observer de façon fiable la FIFO de X.org, ce que REnouveau n'arrive pas très bien à faire. Observer celle-ci est parfois nécessaire pour voir comment certaines fonctions 2D sont implémentées.
<br />
<br />
<br />
<strong>== Utiliser MMioTrace pour rajouter une fonctionnalité ==</strong>
<br />
<br />
Les commandes sont en général envoyées à la carte en écrivant dans la FIFO, pas en écrivant les registres MMIO directement, mais certaines tâches telles que l'initialisation de la carte (sélection d'un mode d'écran) nécessitent d'intervenir sur les registres MMIO.
<br />
<br />
L'exemple ci-dessous montre comment MMioTrace a été utilisé pour effectuer l'ingénierie inverse de l'overlay vidéo <a href="http://fr.wikipedia.org/wiki/YUV">YV12</a>, qui existe sur certaines cartes NVidia.
<br />
<br />
Les vidéos ne sont en général pas stockées en RGB. La plupart des codecs vidéo fonctionnent dans l'espace de couleur <a href="http://fr.wikipedia.org/wiki/YUV">YUV</a>, où Y correspond à la luminance (image monochrome), et U et V sont les informations de chrominance (la couleur). La perception de l'oeil humain est plus fine pour la luminance que pour la chrominance, donc la plupart des codecs suppriment une fraction des informations U et V pour gagner un peu d'espace. Quand X-Video demande à la carte d'afficher une image de vidéo, il lui passe un tampon contenant des données YUV, en général en format YV12 ou YUY2.
<br />
<br />
Bien qu'assez mal fait, le site <a href="http://www.fourcc.org/">http://www.fourcc.org/</a> contient des informations détaillées à propos de ces deux formats. Dans le cadre de cet article, tout ce qui nous intéresse est que YUY2 conserve un échantillon de chrominance (U ou V alternativement) par échantillon de luminance, ce qui signifie que la carte reçoit "YUYVYUYV" (16 bpp). YV12 quant à lui conserve deux échantillons de chrominance (un U, un V) par bloc de luminance de taille 2x2, ce qui donne 12 bits par pixel de video. YV12 est donc 25% plus petit que YUY2, et c'est de très loin le format le plus utilisé par les codecs vidéo. À vrai dire nous n'avons pour l'instant pas trouvé de codec qui sorte autre chose que de l'YV12 (ou du I420, qui est conceptuellement identique - les positions de U et V sont inversées dans le tampon).
<br />
<br />
Au début de l'été 2007, le support Xv de Nouveau était hérité de nv. En plus d'être extrêmement lent, nv ne supportait que le format YUY2, et convertissait les données YV12 en YUY2 logiciellement, avant de les envoyer à la carte. En travaillant sur l'amélioration des performances, nous nous sommes rapidement demandés si les cartes NVidia supportaient YV12 matériellement. En effet, cela aurait permis de réduire le volume des transferts sur le bus de 25%, ceux-ci jouant un rôle très important dans le débit de Xv, surtout sur les cartes PCI.
<br />
<br />
Nous avons vérifié cela en mesurant la performance du pilote propriétaire lors de la lecture de vidéos YV12 et YUY2 (en utilisant mplayer -yuy2). Les résultats ont été très clairs :
<br />
<br />
nvidia propriétaire overlay YUY2 (16 bpp):
<br />
real 0m20.591s
<br />
<br />
nvidia propriétaire overlay YV12 (12 bpp):
<br />
real 0m15.409s
<br />
<br />
Pas besoin de sortir votre calculatrice, il y a une différence de 25%, ce qui correspond à la différence de taille de données. L'explication la plus simple est que ce qui transite sur le bus est en format YV12 : la carte supporte YV12 matériellement.
<br />
<br />
La situation était donc que nous avions un pilote Xv qui supportait uniquement la vidéo YUY2, et nous savions (du moins pensions, avec un certain niveau de certitude - et d'espérance) que le matériel supportait YV12 nativement. Malheureusement aucun pilote existant, tel que rivatv, n'avait de code pour l'overlay YV12 : il y avait de l'ingénierie inverse à faire.
<br />
<br />
MMioTrace ne rentre pas en jeu tout de suite : comme indiqué précédemment, la plupart des commandes sont envoyées en écrivant dans la FIFO, pas en touchant aux registres. La première chose à faire était donc d'utiliser valgrind-mmt, pour regarder si la FIFO X contenait certaines commandes relatives à la vidéo.
<br />
<br />
C'était le cas, mais ces commandes étaient des méthodes logicielles, c'est-à-dire de fausses méthodes pour lesquelles la carte génère une interruption qui demande au noyau de les exécuter. C'est assez similaire à un appel ioctl() vers le module noyau du pilote, sauf que c'est synchronisé avec la FIFO (c'est-à-dire avec le GPU) plutôt qu'avec le CPU. Première conclusion : la sortie vidéo est faite via le module noyau.
<br />
<br />
Nous avons alors MMioTracé le pilote propriétaire lors de la lecture de vidéos YUY2 et YV12 (de même taille, même position de fenêtre, ... (la seule différence étant le format), et comparé les sorties.
<br />
<br />
Au milieu des 150Ko de données (la plupart des traces MMIO sont beaucoup plus grandes), nous avons trouvé :
<br />
<br />
YUY2
<br />
NV_PVIDEO.[0].FORMAT <br />
<br />
YV12
<br />
NV_PVIDEO.[0].FORMAT <br />
NV_PVIDEO+0x800 <br />
NV_PVIDEO+0x808 <br />
NV_PVIDEO+0x820 <br />
<br />
Nous avions donc une valeur différente écrite dans FORMAT, et trois registres inconnus. En cherchant dans la documentation et le code existants, il est apparu que le bit 0 du registre FORMAT nous était inconnu.
<br />
<br />
Nous avons donc essayé de faire marcher l'overlay YV12 dans Nouveau, tout d'abord en mettant simplement à 1 le bit 0 de FORMAT, et sans toucher aux trois registres inconnus. Résultat : pas de vidéo. Il y avait donc un effet, mais nous n'étions pas sûr que le bit 0 de FORMAT correspondait bien au bit "YV12".
<br />
<br />
Une lecture plus approfondie des MMioTraces nous a montré que ce qui était écrit dans les trois registres était en fait assez similaire à ce qui était écrit dans les registres qui servaient à configurer le tampon de données (indiquer son adresse et sa taille notamment). Nous avons pu deviner ce qui devait être écrit à cet endroit (il s'agissait en fait de la configuration du tampon de couleur, sachant que le tampon principal était utilisé pour les informations de luminance).
<br />
<br />
Finalement, nous avons fait marcher YV12 dans Nouveau, sans conversion en YUY2, ce qui représente une amélioration de performance des 25% attendus. MMioTrace nous a permis de découvrir comment la carte devait être programmée pour afficher des données YV12, ce qui n'était semble-t-il connu de personne en dehors de NVidia auparavant.
<br />
<br />
Cela a fini dans nv10_video_overlay.c, dans NV10PutOverlayImage:
<br />
<code> /* Those are important only for planar formats (NV12) */
<br />
if ( uvoffset )
<br />
{
<br />
nvWriteVIDEO(pNv, NV_PVIDEO_UVPLANE_BASE(buffer), 0);
<br />
nvWriteVIDEO(pNv, NV_PVIDEO_UVPLANE_OFFSET_BUFF(buffer), uvoffset);
<br />
}
<br />
</code>
<br />
Il est intéressant de préciser que MMioTrace se contente d'enregistrer les opérations de lecture/écriture réalisées par le noyau - vous pouvez voir presque tout ce que le module noyau fait à la carte. Le désavantage évident étant que « presque tout » représente rapidement une grosse quantité de données :
<br />
plusieurs méga-octets, voire plusieurs dizaines, après quelques minutes de MMioTrace. Parcourir ces centaines de milliers de lignes pour trouver celles qui sont intéressantes peut être difficile et nécessite un peu d'expérience.
<br />
<br />
Nous avons utilisé MMioTrace pour comprendre le fonctionnement de l'overlay YV12, mais aussi pour une majeure partie du code d'initialisation de la carte et de configuration des modes - et il nous servira encore pour beaucoup de choses.
<br />
<br />
MMioTrace n'est pas limité à Nouveau, il peut tracer les opérations MMIO de n'importe lequel de vos modules noyau (binaires), ce qui permet d'effectuer de l'ingénierie inverse pour n'importe quel matériel.
<br />
<br />
<br />
<strong>== Développements actuels dans le domaine graphique sur Unix et leur influence sur Nouveau ==</strong>
<br />
<br />
Nous allons maintenant jeter un oeil sur le futur de l'accélération 3D sous GNU/linux. L'année 2007 a vu un grand nombre de changements majeurs apparaître dans la façon dont Linux et X11 gèrent la partie graphique.
<br />
Un grand nombre d'améliorations vont commencer à être utilisées : EXA pour l'accélération 2D, TTM pour la gestion de la mémoire, Gallium3D pour la 3D, la nouvelle interface DRI2... Tous ces changements nécessitent une adaptation des pilotes qui peut prendre du temps.
<br />
<br />
Avec l'arrivée des cartes graphiques programmables, le design actuel des pilotes graphiques Mesa commence à devenir inadapté. Celui-ci avait en effet été conçu pour des cartes basées sur des fonctions OpenGL fixes, c'est à dire possédant des circuits spécifiques à chaque partie du pipeline GL.
<br />
Le design pour ce type de cartes requiert un appel dans le pilote pour chaque nouvelle fonction fixe, ce qui devient vite complexe et oblige à une duplication de code importante entre les pilotes.
<br />
<br />
Un nouveau design de pilote, Gallium3D, tente de remédier à cela en simplifiant l'interface du pilote tout en maximisant le code partagé. Il est conçu pour fournir tout ce qui est nécessaire à OpenGL 3.0, mais également aux API DirectX ou OpenGL actuelles. Il doit également permettre une portabilité des pilotes sur les OS et plateformes majeurs. Il requiert des circuits graphiques programmables possédant au moins des « <i>fragment shaders</i> ».
<br />
<br />
Maintenant que nous savons pourquoi le design a changé, voyons l'architecture de Gallium3D. Celui-ci sépare le pilote DRI en 3 composantes : un traqueur d'états commun, une couche « <i>winsys</i> » dépendante de l'OS et un pilote spécifique à la 3D du matériel.
<br />
<br />
Le winsys est en charge de la partie 2D, de la plupart des tâches de gestion et des parties spécifiques à un OS, tandis que le pilote "matériel" gère la 3D. Chaque pilote doit implémenter la partie gestion matériel et le winsys. Lorsqu'un pilote est porté vers un autre OS, seule la partie winsys doit être réécrite.
<br />
<br />
La référence complète implémentée de façon logicielle est appelée softpipe. C'est un moteur de rendu logiciel qui permet de présenter les concepts derrière Gallium3D, comment les implémenter et qui agit comme un recours logiciel pour les fonctions que le matériel ne gère pas.
<br />
<br />
Un dernier composant du nouveau système graphique est le gestionnaire de mémoire TTM qui gère dans le noyau et de façon unifiée toute la mémoire accessible au GPU.
<br />
Auparavant, la gestion de la mémoire était séparée entre les pilotes X et utilisait surtout des allocations statiques. TTM a été conçu et implémenté au départ pour les circuits Intel et a dû être adapté pour le matériel NVidia et le design logiciel de Nouveau. La principale fonction, nécessaire pour la gestion des contextes matériels multiples des circuits NVidia, qui a été ajoutée est appelée fence classing.
<br />
<br />
<br />
<strong>== Statut actuel ==</strong>
<br />
<br />
Lorsque, l'année dernière, nous sommes passé de l'ingénierie inverse à l'écriture du pilote, on nous a demandé quand celui-ci serait prêt. Nos prédictions tablaient sur l'automne 2007 mais finalement, seule une partie du travail était finie.
<br />
<br />
À l'exception des NV5x, nous avons un pilote 2D relativement bon. Durant un temps, nous avons même envisagé l'idée de la sortie d'une version uniquement 2D du pilote, idée que nous avons finalement repoussée, l'interface noyau n'étant pas assez stable pour un support à long terme. En effet, lorsqu'un module (comme notre module DRM) est intégré dans le noyau Linux, ses interfaces doivent être par la suite conservées indéfiniment. Ce qui ne serait pas très approprié actuellement pour Nouveau, étant donné que les interfaces vont être amenées à évoluer avec l'arrivée du TTM et de la gestion des modes dans le noyau. Conserver les anciennes interfaces rendrait très complexe l'utilisation et le support des nouvelles.
<br />
<br />
Aujourd'hui, Nouveau est capable des fonctions suivantes :<ul><li> Rendu 2D basique sur toutes les cartes via <a href="http://en.wikipedia.org/wiki/EXA">EXA</a>.
<br />
</li><li> EXA Composite (implémentant l'extension <a href="http://en.wikipedia.org/wiki/XRender">XRENDER</a>) utilise le moteur 3D sur toutes les cartes à l'exception des NV5x et NV04. Dans ce dernier cas, des limitations matérielles rendent l'implémentation difficile si ce n'est impossible. L'implémentation sur NV1x est un récent exploit étant donné que ces cartes ne possèdent pas de shaders mais seulement deux combineurs de registres de fonctions fixes.
<br />
</li><li> Xv est disponible des NV04 aux NV4x grâce au travail d'Arthur Huillet, au travers de l'overlay (NV04 ->NV3x), du <a href="http://fr.wikipedia.org/wiki/Blitter">blitter</a> (toutes les cartes) ou de textures vidéos (NV4x). L'adaptateur de vidéo texturée a été écrit par Stéphane Marchesin qui a travaillé sur un filtrage bicubique pour une meilleure qualité. Les performances de Xv sont équivalentes à celles du pilote binaire nvidia sur de nombreuses cartes.</li><li> Support de l'architecture PowerPC (PPC) Quelques systèmes PPC fonctionnent avec Nouveau. La majorité des problèmes d'ordre des bits a été réglée grâce à l'aide du projet PS3 RSX et de Benjamin Herrenschdmidt. Il reste néanmoins des configurations où surviennent des blocages DMA lorsqu'on essaye d'envoyer des données à la carte. Le code est actuellement audité et la majorité des bogues corrigés.
<br />
</li><li> Le travail sur RandR 1.2 est en cours, la gestion basique des modes fonctionne à peu près sur NV3x, NV4x et NV5x. Les fonctions plus complexes comme le bi-écran sont en développement constant et progressent très vite.
<br />
</li><li> Le code du module DRM de Nouveau possède un support préliminaire pour TTM. Par exemple, une FIFO est allouée exclusivement au DRM. Il reste toutefois beaucoup de travail avant d'avoir quelque chose de réellement utile.</li><li> Ben Skeggs travaille sur un pilote Gallium3D pour les NV4x et NV5x. Il fonctionne sur les NV4x mais n'est aucun cas ni complet, ni dépourvu de bogues. De leur côté les NV5x ne fonctionnent pas du tout.</li><li> Stéphane travaille quant à lui à supporter les cartes dépourvues de <a href="http://fr.wikipedia.org/wiki/Shader">shaders</a> avec Gallium3D. Il cherche à créer une structure générique à toutes les cartes (NVidia, ATI, Intel, etc) permettant de gérer les instructions shaders sur des cartes anciennes comme celles antérieures aux NV30 (>= NV04) chez NVidia, qui ne disposent pas de shaders.</li></ul>
<br />
Actuellement, Les NV5x sont le point faible de notre pilote : elles fonctionnent en 2D de la même façon qu'avec le pilote nv, mais la sauvegarde/restauration de l'état des terminaux virtuels (non-X) ne fonctionne pas.
<br />
<br />
Tout cela est bien beau mais je vous entends demander : « <i>Et la 3D alors ?</i> »
<br />
<br />
La réponse courte est simple : nous n'avons pas de 3D fonctionnelle.
<br />
<br />
La réponse longue est un peu plus nuancée :
<br />
Rien ne fonctionne sur NV5x et comme beaucoup de choses ont changé par rapport aux NV4x, pas mal d'ingénierie inverse va être nécessaire. Pour les autres cartes, nous avons les informations mais il y a encore beaucoup à comprendre et à réaliser avant d'avoir un pilote final.
<br />
<br />
Glxgears fonctionne sur NV1x, NV3x et NV4x mais c'est un prototype et il subsiste différents problèmes. Il faut noter que le travail sur le pilote DRI a cessé au profit de Gallium3D.
<br />
<br />
Un pilote Gallium3D plus ou moins fonctionnel existe mais avec encore de nombreux bogues et erreurs. Même si ça s'améliore quotidiennement pour les NV4x, on est encore loin de pouvoir jouer avec. Cela dit, Gallium3D lui même est toujours en cours de développement, il ne parait donc pas étonnant qu'il en soit de même pour notre pilote.
<br />
<br />
La gestion des modes fait actuellement l'objet d'un travail important d'amélioration par Maarten Maathuis et Stuart Bennett, ce qui à terme devrait amener une gestion de RandR1.2 (bi écran et autres) avec Nouveau.
<br />
Une fois terminé, tout comme d'autres pilotes, nous prévoyons de migrer la gestion des modes dans le noyau. Une API noyau a été définie dans ce but ( <a href="http://lkml.org/lkml/2007/5/17/342,">http://lkml.org/lkml/2007/5/17/342,</a> <a href="http://lwn.net/Articles/218380/">http://lwn.net/Articles/218380/</a> et <a href="http://gitweb.freedesktop.org/?p=MESA/drm.git;a=shortlog;h=modesetting-101">http://gitweb.freedesktop.org/?p=MESA/drm.git;a=shortlog;h=m(...)</a> ). Elle ressemble à une version simplifiée de l'API Randr1.2, ce qui devrait rendre la migration assez simple.
<br />
<br />
<br />
Bon, et à quoi devons nous nous attendre ensuite ?
<br />
<br />
Ceci est seulement une approximation des objectifs à moyen terme : <ul><li> Terminer le travail sur la 2D, gestion des modes et RandR1.2 inclus.
<br />
</li><li> Ingénierie inverse pour les NV5x.</li><li> Implémenter TTM.
<br />
</li><li> Implémenter un pilote Gallium3D. Évident pour les cartes avec des shaders. Pour les plus anciennes, il faudra attendre que la structure générique de Stéphane fonctionne. Dans le cas où elle se révèlerait irréalisable, un pilote DRI pourrait bien être la seule option pour ces anciennes cartes.</li></ul>
<br />
Évidemment, si vous voulez plus de détails, parcourez notre Wiki, lisez les TiNDC ou rejoignez nous sur le canal IRC #nouveau sur freenode (<a href="http://Nouveau.freedesktop.org/wiki/IrcChatLogs-fr">archives disponibles</a> ).
<br />
<br />
Pour ne pas déroger à la tradition, voici quelques captures d'écran, et commençons par le jeu des 7 différences.
<br />
Voici une capture du blob et de Nouveau qui représente le début du premier niveau de NeverBall :
<br />
<br />
<a href="http://mjules.free.fr/nouveau/pics/lwn_neverball_ok.jpg">Capture de Nouveau</a>
<br />
<br />
<a href="http://mjules.free.fr/nouveau/pics/lwn_neverballnouveau.jpg">Capture de NVidia (pilote binaire)</a>
<br />
<br />
Ben Skeggs semble avoir noté quelques petites différences aussi, et après quelques semaines, a corrigé les rendus incorrects.
<br />
<br />
Et voilà ce à quoi ressemble OpenArena avec le pilote Nouveau Gallium3D de janvier 2008 :
<br />
<a href="http://mjules.free.fr/nouveau/pics/lwn_openarenanouveau_ok.jpg">Capture d'OpenArena</a>
<br />
<br />
Il semble que les armes sont un peu trop sombres, mais à part ça, il n'y a pas de différences flagrantes.
<br />
<br />
Plus d'informations sur Gallium3D sur le site de Tungsten Graphics :
<br />
<a href="http://www.tungstengraphics.com/wiki/index.php/Gallium3D">http://www.tungstengraphics.com/wiki/index.php/Gallium3D</a>
<br />
<a href="http://www.tungstengraphics.com/wiki/files/gallium3d-xds2007.pdf">http://www.tungstengraphics.com/wiki/files/gallium3d-xds2007(...)</a>
<br />
<br />
<br />
Bref, voilà où nous en somme aujourd'hui. Notre feuille de route montre que la prochaine étape importante sera Quake. Elle n'est pas trop loin pour les NV4x, un peu plus pour les autres cartes, d'autres problèmes étant sur le chemin.
<br />
Notre première estimation d'automne/hiver 2007 pour une première version n'était finalement pas si mauvaise si on ne regarde que la partie 2D ; même si nous avons du la repousser à cause de certaines décisions architecturales dont nous ne maîtrisons pas forcément tous les délais (TTM et Gallium notamment).
<br />
Nous pensons tout de même que ces décisions étaient bonnes et Nouveau sera l'un des pilotes les plus pérennes et les plus avancés technologiquement.
<br />
<br />
Pour terminer, je (KoalaBr) voudrais remercier Arthur Huillet, Ben Skeggs, David Airlie et Stephane Marchesin pour leur aide dans la rédaction de cet article. Ce fut réellement un vrai travail d'équipe !
<br />
Traduction réalisée par Mjules, avec l'aide de Stéphane Marchesin et Arthur Huillet.</div><div><a href="https://linuxfr.org/news/un-point-sur-le-projet-nouveau.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/22843/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/news/un-point-sur-le-projet-nouveau#comments">ouvrir dans le navigateur</a>
</p>
Mjuleshttps://linuxfr.org/nodes/22843/comments.atomtag:linuxfr.org,2005:Diary/240282007-03-20T19:40:37+01:002007-03-20T19:40:37+01:00Nouveau, X.org et Summer of CodeLe projet Nouveau[1] recherche des étudiants prêt à s'investir dans le développement de ce pilote dans le cadre du Google Summer of Code.<br />
<br />
Pour mémoire, le Summer of Code est un financement destiné à des étudiants qui veulent travailler pendant l'été sur un projet libre.[5]<br />
<br />
Il n'est pas obligatoire d'avoir des connaissances en écriture de pilote. Un niveau correct en programmation est quand même nécessaire pour pouvoir se mettre dans le bain.<br />
Différentes idées de projet sont disponibles sur le wiki[2]. Ce n'est pas une liste exhaustive et vous pouvez venir avec votre projet propre.<br />
<br />
Si vous êtes intéressé, vous pouvez contacter les développeurs via le canal IRC #nouveau sur freenode. Ou directement voir avec marcheu[3].<br />
<br />
Plus généralement, c'est tout le projet X.org qui recherche des étudiants pour le SoC, et propose un grand nombre d'idées pour tous les niveaux [4].<br />
<br />
Les inscriptions sont ouvertes jusqu'au 24 mars donc dépêchez vous ;-) !<br />
<br />
<br />
[1] <a href="http://nouveau.freedesktop.org/wiki/Accueil-fr">http://nouveau.freedesktop.org/wiki/Accueil-fr</a><br />
[2] <a href="http://nouveau.freedesktop.org/wiki/SoC">http://nouveau.freedesktop.org/wiki/SoC</a><br />
[3] <a href="http://linuxfr.org/~bknight/">http://linuxfr.org/~bknight/</a><br />
[4] <a href="http://xorg.freedesktop.org/wiki/SummerOfCodeIdeas">http://xorg.freedesktop.org/wiki/SummerOfCodeIdeas</a><br />
[5] <a href="http://code.google.com/soc/">http://code.google.com/soc/</a><div><a href="https://linuxfr.org/users/mjules/journaux/nouveau-xorg-et-summer-of-code.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/50460/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/mjules/journaux/nouveau-xorg-et-summer-of-code#comments">ouvrir dans le navigateur</a>
</p>
Mjuleshttps://linuxfr.org/nodes/50460/comments.atomtag:linuxfr.org,2005:News/204742006-03-10T03:42:59+01:002006-03-10T03:42:59+01:00OpenOffice.org 2.0.2 et nouveau site francophone<div>La suite bureautique libre la plus connue arrive donc dans une nouvelle version de maintenance.
<br />
<br />
En plus de la correction d'un grand nombre de bugs (mais à priori, pas d'amélioration des performances :-( ), l'utilisateur a maintenant la possibilité de changer à la volée le thème d'icônes utilisé, voire de laisser OO.o choisir son thème d'icône en fonction de l'environnement (Industrial pour GNOME/GTK et Crystal pour KDE/Qt). Parmi les nouveautés, on peut noter un filtre d'importation pour Quattro pro 6 et le support de plusieurs nouvelles langues dont le breton.
<br />
<br />
Au moment de l'écriture de ces lignes, la version française n'est pas encore disponible. Elle devrait néanmoins l'être rapidement (les volontaires sont les bienvenus !).
<br />
<br />
OpenOffice.org est une suite bureautique complète et libre (sous licence LGPL) comprenant un traitement de texte (writer), un tableur (calc), un logiciel de présentation (impress), un gestionnaire de base de donnée (base) et un logiciel de dessin vectoriel (draw). Elle utilise par défaut le format OpenDocument, normalisé par l'OASIS et proposé comme norme internationale auprès de l'ISO.
<br />
<br />
<abbr title="Note de la Rédaction">NdR</abbr> : <i>Merci également à</i> Stefan <i>qui nous a signalé l'existence d'un nouveau site francophone consacré à cette suite bureautique avec forum, tutoriels, modèles etc...</i>
<br />
<abbr title="Note de la Rédaction">NdR</abbr> : <i>Merci aussi à captflam pour avoir proposé l'information.</i></div><ul><li>lien nᵒ 1 : <a title="http://www.openoffice.org/" hreflang="en" href="https://linuxfr.org/redirect/45990">Le site d'OpenOffice.org</a></li><li>lien nᵒ 2 : <a title="http://download.openoffice.org/2.0.2/index.html" hreflang="en" href="https://linuxfr.org/redirect/45991">Téléchargement (en anglais)</a></li><li>lien nᵒ 3 : <a title="http://development.openoffice.org/releases/2.0.2rc4.html" hreflang="en" href="https://linuxfr.org/redirect/45992">Les notes de versions</a></li><li>lien nᵒ 4 : <a title="http://linuxfr.org/2005/10/27/19769.html" hreflang="fr" href="https://linuxfr.org/redirect/45993">Sortie de OOo 2.0, l'article de DLFP</a></li><li>lien nᵒ 5 : <a title="http://www.forum-openoffice.org" hreflang="fr" href="https://linuxfr.org/redirect/45997">Nouveau site www.forum-openoffice.org</a></li></ul><div></div><div><a href="https://linuxfr.org/news/openofficeorg-202-et-nouveau-site-francophone--2.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/19787/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/news/openofficeorg-202-et-nouveau-site-francophone--2#comments">ouvrir dans le navigateur</a>
</p>
Mjuleshttps://linuxfr.org/nodes/19787/comments.atomtag:linuxfr.org,2005:News/201102005-12-23T09:15:21+01:002005-12-23T09:15:21+01:00OpenOffice.org 2.0.1 est disponible<div>Presque 2 mois après la sortie de la version majeure 2.0 de la suite bureautique libre OpenOffice.org, une version mineure 2.0.1 sort aujourd'hui.
<br />
<br />
Elle apporte son lot de corrections de bugs et quelques nouveautés dont entre autres la possibilité pour les administrateurs de masquer certaines options.
<br />
<br />
Pour mémoire, OpenOffice.org est une suite bureautique complète et libre (sous licence LGPL) comprenant un traitement de texte (writer), un tableur (calc), un logiciel de présentation (impress), un gestionnaire de base de donnée (base) et un logiciel de dessin vectoriel (draw).
<br />
Elle utilise par défaut le format OpenDocument, normalisé par l'OASIS et proposé comme norme internationale auprès de l'ISO.</div><ul><li>lien nᵒ 1 : <a title="http://fr.openoffice.org/about-downloads.html" hreflang="fr" href="https://linuxfr.org/redirect/44964">Page de téléchargement</a></li><li>lien nᵒ 2 : <a title="http://fr.openoffice.org/docs/release_2.0.1.html" hreflang="fr" href="https://linuxfr.org/redirect/44965">Releases notes</a></li><li>lien nᵒ 3 : <a title="http://fr.openoffice.org/" hreflang="fr" href="https://linuxfr.org/redirect/44966">Site du projet francophone OpenOffice.org</a></li><li>lien nᵒ 4 : <a title="http://linuxfr.org/2005/10/27/19769.html" hreflang="fr" href="https://linuxfr.org/redirect/44967">Sortie de OOo 2.0, l'article sur DLFP</a></li></ul><div></div><div><a href="https://linuxfr.org/news/openofficeorg-201-est-disponible.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/19423/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/news/openofficeorg-201-est-disponible#comments">ouvrir dans le navigateur</a>
</p>
Mjuleshttps://linuxfr.org/nodes/19423/comments.atomtag:linuxfr.org,2005:Diary/192932005-09-02T18:34:16+02:002005-09-02T18:34:16+02:00Sun retire la SISSL = OOo uniquement LGPLSun vient d'annoncer qu'il retirait sa licence SISSL (Sun Industry Standard Source License) et qu'aucun de ses futurs projets opensource n'utilisera cette licence. Pour les projets actuels sous doubles licences comme OOo (SISSL-LGPL) n'utiliseront plus que la 2° licence.<br />
<br />
OOo devient donc uniquement LGPL.<br />
<br />
Sun annonce faire afin de suivre les recommandations de l'OSI (OpenSource Initiative) pour la simplification des licences<br />
<br />
l'annonce et la FAQ associée :<br />
<a href="http://www.openoffice.org/FAQs/license-change.html">http://www.openoffice.org/FAQs/license-change.html(...)</a><br />
l'OSI :<br />
<a href="http://www.opensource.org">http://www.opensource.org(...)</a><br />
<br />
le mail en français devrait pas trop tarder à se retrouver dans les archives de la ML :<br />
<a href="http://www.mail-archive.com/discuss@fr.openoffice.org/">http://www.mail-archive.com/discuss@fr.openoffice.org/(...)</a><div><a href="https://linuxfr.org/users/mjules/journaux/sun-retire-la-sissl-ooo-uniquement-lgpl.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/45822/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/mjules/journaux/sun-retire-la-sissl-ooo-uniquement-lgpl#comments">ouvrir dans le navigateur</a>
</p>
Mjuleshttps://linuxfr.org/nodes/45822/comments.atomtag:linuxfr.org,2005:Diary/57442003-10-01T11:48:07+02:002003-10-01T11:48:07+02:00Bibtex et ses stylesBonjour journal, et ex-futurs lecteurs<br />
<br />
étant en pleine rédaction de ma thèse, je suis confronté à une certaine difficulté quant à la gestion de ma bibliographie.<br />
<br />
La fac m'impose un style à suivre mais je n'arrive pas à modifier les fichier .bst pour qu'ils collent aux directives.<br />
<br />
J'en appelle donc à votre légendaire connaissance pour trouver quelques pistes :<br />
liens vers des styles, vers des tutoriaux complets et bien faits sur les .bst ou toute info.<br />
<br />
juste un détail, La biblio doit être classé par ordre alphabétique.<br />
<br />
Merci et A+<div><a href="https://linuxfr.org/users/mjules/journaux/bibtex-et-ses-styles.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/32476/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/mjules/journaux/bibtex-et-ses-styles#comments">ouvrir dans le navigateur</a>
</p>
Mjuleshttps://linuxfr.org/nodes/32476/comments.atom