X Entretien avec Martin Peres, développeur Nouveau

Posté par (page perso) . Édité par Davy Defaud, Martin Peres, Nÿco, baud123 et patrick_g. Modéré par Xavier Claude. Licence CC by-sa
91
25
oct.
2012
X

Martin Peres (alias mupuf) n’est pas exactement un inconnu sur LinuxFr.org, puisque son nom a déjà été mentionné lors de la sortie des versions 2.6.37 et 3.3 du noyau, pour son travail sur le projet Nouveau, dont il est l’un des développeurs, ou encore très récemment dans un journal sur la conception sécurisée des serveurs graphiques (X, Wayland).

En creusant un peu, je me suis aperçu que Martin était même actif sur LinuxFr.org, où il a déjà rédigé des dépêches.

Alors que le travail de Martin sur Nouveau sera à nouveau mentionné dans la dépêche à venir sur la prochaine version 3.7 du noyau Linux, le moment me semblait adéquat pour une demande d’entretien qu’il a gentiment acceptée.

Précisons que vous pouvez également suivre Martin via son blogue, sa page recherche ou son compte Google+.

Martin, pourrais‐tu te présenter rapidement ?

J’ai 24 ans, je suis actuellement doctorant au LaBRI sur les problématiques de la gestion d’énergie et de la sécurité dans les réseaux sans fil. Je viens de l’ENSI de Bourges où j’ai reçu le diplôme d’ingénieur Sécurité des systèmes ubiquitaires.

LinuxFr.org a plusieurs fois cité ton nom dans les commits de Nouveau. Pourrais‐tu expliquer comment tu t’es retrouvé à travailler sur Nouveau et ce que tu y fais ?

Comme beaucoup de développeurs X.Org, j’ai commencé à m’intéresser à la pile graphique parce qu’elle ne fonctionnait pas pour moi. Dans mon cas, mon problème venait de Fglrx qui ne gérait pas mon ATI Radeon Xpress 200M, en 2007.

C’est à ce moment que j’ai commencé à m’intéresser aux pilotes graphiques et que j’ai commencé à tester les pilotes libres (radeon).

À mon entrée à l’ENSI de Bourges, la région Centre a offert des ordinateurs ThinkPad à tous les étudiants. Ne voulant pas revivre l’enfer que j’avais connu avec Fglrx, j’ai été déçu de voir qu’ils contenaient une carte graphique NVIDIA. Heureusement, j’ai été soulagé de voir que le pilote propriétaire marchait correctement. Cependant, je m’étais pris de passion pour les pilotes libres, et je suis passé sur Nouveau assez rapidement pour avoir le KMS et tester son niveau de prise en charge.

Après quelques mois, j’ai commencé à me plaindre de corruptions graphiques dans KDE, ce qui m’a poussé à contacter la communauté de développeurs et à essayer de résoudre le problème par moi‐même. Je n’ai pas réussi, mais le CTO de PathScale m’a repéré et m’a proposé de travailler sur PSCNV, un fork de Nouveau visant à proposer le support d’un GPGPU (comme CUDA ou OpenCL) particulier appelé ENZO. Mon travail était de rajouter la prise en charge du pilote dans libdrm de façon à fournir une accélération 2D et 3D. J’ai réussi à avoir glxgears, mais certaines corruptions inexpliquées ont contraint un autre développeur à prendre le relais et ré‐écrire totalement mon code. Deuxième échec, mais faut pas se décourager. :)

On m’a ensuite proposé d’implémenter la gestion d’énergie qui avait un peu de documentation disponible. C’est à ce moment que j’ai décidé de travailler directement sur Nouveau, puis de rétro‐porter mes changements dans PSCNV quand ils seraient prêts. Une première version suffisante pour analyser le VBIOS, lire la température et changer les fréquences de ma nv86 était prête en 15 jours. C’était en septembre 2010, quelques heures avant mon départ pour l’XDS 2010 à Toulouse. Premier succès !

Cependant, ce travail était instable et très dépendant de mon matériel. Depuis cette date, je passe mon temps libre à étudier le matériel (ingénierie inverse), à faire des tests de stabilité durant les changements de fréquence et à implémenter mes découvertes.

Ce travail est de longue haleine. Par exemple, j’ai programmé la première version de la gestion automatique du ventilateur du processeur graphique durant l’été 2011, et ce n’est que maintenant, après que ce travail a été ré‐écrit plusieurs fois, qu’il est enfin prêt à entrer dans le noyau [N. D. L. R. : c’est prévu pour la version 3.7 du noyau Linux].

Cela dit, mon travail ne se limite pas à l’ingénierie inverse et à l’écriture de code. J’essaye de tenir à jour la communauté en participant à des conférences ou par l’écriture d’articles. Je travaille également à attirer plus de développeurs sur le projet Nouveau. Par exemple, cet été, j’ai été le mentor de 2 étudiants pour le X.org Endless Vacation of Code — ou EVoC – (équivalent du Google Summer of Code – ou GSoC). Seulement un des deux étudiants à réussi à aller jusqu’à la fin de son projet. Cet étudiant a travaillé sur l’amélioration de PDAEMON (sorte de RTOS dans les cartes récentes) de façon à pouvoir demander à la carte d’exécuter un script simple. L’application naturelle pour cette fonctionnalité est le changement de fréquence — reclocking — de la mémoire qui doit respecter des contraintes temporelles fortes pour ne pas gêner l’utilisateur. Pour plus d’informations, vous pouvez lire son blogue.

Si je comprends bien, il ne faut pas avoir peur de l’échec et persévérer ?

Exactement ! Une fonctionnalité est terminée quand elle n’a plus de possibilité de ne pas marcher. Il ne faut pas se laisser décourager et persister, jusqu’à ce que tout marche.

À propos de Linux 3.7, tu as proposé des patches relatifs à la gestion du ventilateur. Peux‐tu nous en dire plus ?

La gestion de la température a toujours été un problème dans Nouveau. Sur l’ensemble des cartes gérées par Nouveau, il y a 4 façons de lire la température et 5 façons de changer la vitesse du ventilateur.

Jusqu’à Linux 3.7, seule la lecture de la température sur certaines nv50+ était implémentée correctement. Avec Linux 3.7, la lecture de la température devrait être correcte sur toutes les cartes à l’exception de celles qui utilisent une sonde de température externe. La gestion de ces sondes a aussi été améliorée dans Linux 3.7, et Nouveau devrait charger le pilote hwmon associé à cette sonde.

Cependant, en raison d’une limitation de l’interface de hwmon qui expose la température des sondes externes, Nouveau ne peut pas accéder à la température. Seul l’utilisateur le peut. Nous avons discuté et proposé plusieurs correctifs aux mainteneurs de hwmon pour standardiser l’interface et la rendre accessible depuis le noyau. La dernière tentative faite par Lucas Stach n’ayant pas eu de réponse, nous avons perdu espoir et nous étudions la possibilité de reprogrammer les pilotes nous‐même, pour toutes les sondes utilisées par les constructeurs de carte Nvidia. Il semblerait cependant que nous ne soyons pas les seuls à demander cette interface. Peut‐être viendra‐t‐elle dans une version future de Linux ? Ce n’est pas étonnant car, sans cette interface, il est impossible pour les pilotes de réagir à des évènements tels que la sur‐température.

La gestion du ventilateur est encore plus kafkaïenne. En premier, la gestion automatique peut être prise en charge par le noyau, la carte elle‐même ou par une sonde externe. Dans tous les cas, la vitesse du ventilateur est contrôlée par modulation de largeur d’impulsion (PWM). Cette modulation peut être générée par le noyau en basculant périodiquement une GPIO de la carte définie par le VBIOS (mode TOGGLE), par un contrôleur PWM interne à la carte (mode PWM) ou par la sonde externe.

Avec Linux 3.7, la gestion du mode PWM devrait être terminée pour les familles nv40 et nv50. Les familles nvc0+ gérant la vitesse du ventilateur automatiquement, vous ne pourrez la changer sur ces cartes pour l’instant. La gestion automatique du ventilateur sur les cartes plus vieilles a été écrite, mais a été finalisée trop tard pour rentrer dans Linux 3.7. Je travaille donc à l’améliorer ainsi qu’à ajouter le gestion de la sur‐température. Je finaliserai ensuite mon implémentation de la gestion automatique de la température pour les cartes nvc0+. Le travail initial est déjà disponible.

Avec un peu de chance, tout ça finira dans Linux 3.8, et je n’aurai plus à faire chauffer mes cartes jusqu’à 130 °C avec un sèche‐cheveux pour travailler. :)

Qui sont les développeurs à l’œuvre sur Nouveau, et comment décidez‐vous de ce qui entre dans les branches officielles et ce qui reste dans vos arbres personnels ?

Nouveau est majoritairement composé d’étudiants, à l’exception de Ben Skeggs de chez Red Hat et de Maarten Lankhorst.

Ben Skeggs (alias darktama) est le mainteneur du pilote DDX xf86-video-nouveau et de la partie DRM (pilote nouveau dans le noyau). Il est aussi le principal contributeur de Nouveau et opère majoritairement dans le noyau.

On trouve ensuite Christoph Bumiller (alias calim), étudiant, en tant que mainteneur et unique développeur des pilotes Mesa nv50 et c0. Il est aussi un des principaux rétro‐ingénieur de la partie 3D. Il a aussi passé une bonne partie de son temps à maintenir et améliorer le support de Direct3D dans Nouveau. Cependant, cette fonctionnalité lui a finalement juste permis de déboguer les extensions OpenGL non gérées par Gallium, lorsque celui‐ci était bloqué à OpenGL 2.1. Il était en effet bien plus facile de gérer Direct3D 10/11 qu’OpenGL 3.0. À ma connaissance, seule la version Windows du banc d’essai Heaven de Unigine fonctionne en conjonction avec une version modifiée de Wine. La gestion de Direct3D a récemment été désactivée par défaut, car elle n’est plus maintenue et boguée. Christoph considère que ce state tracker est une occasion manquée, car il aurait démontré la flexibilité de Gallium3D. Espérons que la gestion de Direct3D deviendra plus prioritaire lorsque la prise en charge d’OpenGL sera plus complète et mieux éprouvée.

La majorité de l’ingénierie inverse est effectuée par Marcin Kościelnicki (alias mwk), étudiant, qui s’est d’ailleurs interdit d’écrire le moindre bout de code dans Nouveau depuis quelques années. Sa contribution étant l’écriture d’outils annexes à Nouveau et l’écriture de documentation. Il a par exemple rétro‐ingénieré la plupart des jeux d’instructions des processeurs développés par NVIDIA (Falcon/FµC, VµC et ctxprogs), puis écrit un (dés)assembleur pour faciliter la rétro‐ingénierie des codes existants ou l’écriture de nos propres versions. Pour un petit aperçu, vous pouvez consulter son (hautement addictif) blogue [NDLR : chacun se fera son opinion en fonction de son niveau ;-)]. Le fruit de son travail est disponible sur GitHub, projet envytools. Il n’est cependant pas seul à travailler sur ce dépôt, j’essaye d’aider autant que possible en créant de nouveaux outils suivant mes besoins, ou en complétant les documentations au fur et à mesure que je découvre des fonctionnalités dans le matériel. Il est généralement le dépôt le plus ouvert de Nouveau.

Maarten Lankhorst (alias mlankhorst) vient de se faire embaucher par Canonical pour maintenir les pilotes graphiques pour les versions LTS. Il s’est d’abord fait connaître par son travail sur Wine avant de contribuer sur le décodage vidéo matériel dans Nouveau. Il travaille actuellement à améliorer la prise en charge d’Optimus entre Intel et Nouveau, dans le cadre de son nouvel emploi. Pour en savoir plus, vous pouvez visionner la vidéo de sa présentation au XDC 2012. Vous pouvez le suivre sur Google+.

Concernant la gestion d’énergie, je travaille en partie avec Roy Spliet (alias RSpliet), étudiant, qui a majoritairement rétro‐ingénieré la gestion des timings et qui m’a inspiré un outil pour nous aider dans cette tache (nvamemtimings). La majorité de notre travail est disponible sur Gitorious, Linux Nouveau PM.

Francisco Jerez (alias curro) est un contributeur de longue date. Il a notamment écrit le code pour la gestion des modes d’affichage — modesetting — sur les nv40, mais aussi l’implémentation initiale d’OpenCL dans Nouveau, dans le cadre d’un EVoC. Un travail de nettoyage de code est encore nécessaire, mais la prise en charge est en bonne voie.

Marcin Slusarz (alias joi) est un contributeur qui se limite généralement à la correction de bogues, et qui le fait très bien.

Lucas Stach (alias lynxeye) est majoritairement connu dans Nouveau pour ses patches dans le défunt driver Mesa nv40, qui a été remplacé par Ben Skeggs lors de la ré‐écriture de libdrm. Il travaille maintenant majoritairement sur le portage de Tegra sur l’architecture DRM. Ce travail est fait de concert avec l’équipe de développeurs de chez NVIDIA et d’autres contributeurs externes. Vous pouvez suivre son travail sur Google+.

Il y a bien sûr plusieurs autres développeurs, mais je pense que la majorité des gens qui ont contribué du code récemment sont là.

Quant au choix de ce qui rentre dans les branches officielles ou pas, ça dépend énormément de quelle partie on touche. Pour le noyau, il faut soumettre ses patches à Ben Skeggs, qui doit les accepter. Le niveau de qualité de code demandé est très élevé, et l’on doit généralement prouver que ce qu’on fait est bon. C’est pour cette raison que mes patches sur la gestion d’énergie sont majoritairement dans mon arbre. Ils ne sont acceptés qu’après avoir fait l’objet d’une étude exhaustive du matériel, ainsi que lorsque l’architecture logicielle proposée est totalement cohérente. En moyenne, je produis entre 5 et 10 versions d’une fonctionnalité avant de la voir acceptée.

Durant toute la phase de développement, nous parlons de notre travail sur le canal IRC, de façon à avoir des retours d’autres développeurs. Ben Skeggs propose ensuite ses patches à Dave Airlie, le mainteneur de DRM, qui envoie à son tour les patches DRM à Linus Torvalds.

Je ne peux pas trop parler de Mesa, mais il semblerait qu’il faille simplement envoyer les patches à la liste de diffusion dri-devel, et le mainteneur du code modifié donne son avis et récupère le code assez rapidement. Cependant, pour toute fonctionnalité un peu grosse, il semblerait bon d’en discuter en premier avec Christoph Bumiller.

Tu mentionnes OpenCL, Optimus et la gestion d’énergie, faut‐il s’attendre à d’autres surprises ?

Dur à dire. On travaille sur plusieurs choses en parallèle, et nul ne sait quand une fonctionnalité sera prête. Ben a mentionné la gestion du SLI, mais je n’ai aucune information là‐dessus et je doute que ce soit une priorité.

As‐tu d’autres projets relatifs à Linux ou au Libre en général ?

Oui, j’essaye d’être actif autant que possible sur deux autres sujets : la sécurité et le développement embarqué.

Concernant la sécurité, j’ai commencé à étudier ce domaine à l’ENSI de Bourges. J’ai très tôt contribué à la recherche effectuée par l’équipe SDS (Sécurité des systèmes distribués) en participant au projet de l’ANR (Agence Nationale pour la Recherche) Système d’Exploitation Cloisonné & Sécurisé pour l’Internaute (SEC & SI). La solution proposée était à base de Gentoo Hardened, PIGA et PIGA-SYSTRANS pour contrôler les interactions venant de l’utilisateur. J’étais en charge du développement de cette dernière couche. J’ai par la suite continué à me soucier de la sécurité des données utilisateur, ce qui a abouti à une présentation au XDC 2012 à propos de la sécurité dans la pile graphique. Dans le cadre de mon doctorat, je donne également des cours de sécurité des systèmes d’information et de sécurité matérielle à l’ENSEIRB, dans la filière Télécom, option Systèmes et Réseaux Communiquants (RSC).

Concernant l’embarqué et l’électronique, je suis membre du hackerspace de Bordeaux, appelé LaBX. Je suis aussi mainteneur et développeur d’un EDI libre alternatif pour les Arduinos. Cet EDI se différencie de l’EDI officiel par le fait qu’il est totalement écrit en C++/Qt, contrairement à l’EDI officiel qui est en Java. Vous pouvez avoir plus d’informations sur le site officiel.

Les deux dernières questions ont essentiellement pour but de mettre de l’animation dans les commentaires : quels distribution et environnement graphique utilises‐tu ?

Je suis un Archer (Arch Linux) depuis 2008, grâce à un ami de DUT. J’aime particulièrement l’aspect communautaire, la facilité d’écriture de paquets et la politique de publication continue (rolling release).

Pour le bureau graphique, je suis sous KDE depuis la version 4.3. J’aime beaucoup Plasma, KWin, Kile, Kate, Kcalc et Okteta. J’espère juste que la communauté KDE va arrêter d’ajouter des fonctionnalités et testera mieux ses composants principaux avant chaque publication. Il semblerait que ce soit la direction prise actuellement par KDE. Wait and see! ;)

Arch Linux étant récemment passé sous systemd par défaut, que penses‐tu de systemd ? Et Wayland ? Ce sont deux sujets bouillants auprès de nos lecteurs…

Je n’ai personnellement aucun problème avec systemd. Celui‐ci est encore jeune, mais il fait bien son travail. J’aime le concept du chargement dynamique des daemons nécessaires, et j’adore le fait qu’il soit devenu facile d’utiliser de nouvelles fonctionnalités de Linux, telles que le file system namespace ! L’amélioration du temps de démarrage, ainsi que la facilité d’audit de celui‐ci sont les cerises sur le gâteau. :)

Quant à Wayland, je suis extrêmement enthousiaste. Celui‐ci va permettre de résoudre les problèmes de sécurité de X, mais aussi des problèmes de performance. Un autre avantage de Wayland est qu’il est beaucoup plus facile à comprendre que l’architecture de X. Cette simplification devrait rendre possible l’arrivée de nouveaux types de compositeurs aussi innovant que l’était Compiz en son temps. Voici un petit aperçu de ce qui est à venir.

Merci pour cet entretien et tes contributions.

De rien ! Merci de m’avoir donné la parole.

  • # Félicitations

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

    Bonsoir Martin, je tiens à te féliciter, il est rare de voir de jeunes étudiants Français aussi motivés. J'espère que tu sauras amener avec toi d'autres étudiants pour les développements dans le monde du logiciel libre, surtout avec ce qui se prépare sur Bordeaux en ce moment ! Merci pour tes contributions, qui serviront sur le moyen terme à tous.

    CNRS & UNIX-Experience

    • [^] # Re: Félicitations

      Posté par . Évalué à  9 .

      rare de voir de jeunes étudiants Français aussi motivés.

      c'est quoi ce cliché de merde ? il y a beaucoup d'étudiant Français qui participent à des projets libres.

      • [^] # Re: Félicitations

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

        Mais ce qui est dommage est le manque de visibilité ; non pas dû à leur inexistence, ou à leur manque de talent et d'acharnement, mais à l'accaparement de l'espace médiatique par d'autres sujets infiniment plus intéressants, tels que — en vrac — les tenues des stars, les crises, les nouveaux produits top super-cool, le refrain à la mode, et cætera. Donc merci aussi à l'initiateur de l'entrevue.

        • [^] # Re: Félicitations

          Posté par . Évalué à  10 .

          l'accaparement de l'espace médiatique par d'autres sujets infiniment plus intéressants, tels que — en vrac — les tenues des stars, les crises, les nouveaux produits top super-cool, le refrain à la mode, et cætera.

          Tu as oublié systemd, Unity et Gnome Shell.

          • [^] # Re: Félicitations

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

            Non, c’est bien dans son commentaire:

            les crises

            ou à la limite

            les nouveaux produits top super-cool

            comme ça je m’épargne les foudres de Zenitram.

    • [^] # Re: Félicitations

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

      Merci Loïc. J'avoue ne pas te suivre sur "ce qui se prépare sur Bordeaux". J'ai raté quelque chose ?

    • [^] # Re: Félicitations

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

      C'est pas à Toulouse plutôt ?

      http://www.capitoledulibre.org/2012/

  • # respect

    Posté par . Évalué à  7 . Dernière modification : le 26/10/12 à 06:57

    Respect et bravo.

    une petite dizaine d'étudiant face aux mille ingé nvida, le combat est inégal mais c'est beau quand même :)

    • [^] # Re: respect

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

      Merci, on s'amuse comme on peut ;)

      • [^] # Re: respect

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

        Petit anecdote…

        Un collègue était sous Ubuntu avec une carte Intel, j'ai du récupérer sa machine et du coup il a récupéré une machine de chercheur avec carte Quadro de chez Nvidia.

        Je prend les disques de l'ancien PC, je les mets en place sur la nouvelle machine et je boot (Ubuntu 12.04). Par réflexe (configuration bi écran, je connais mal nouveau, sur mon pc à la maison, quelques bugs graphiques), j'installe le driver NVIDIA.

        Les jours passent et j'apprends que le gars a des freezes sur sa machine plusieurs fois par semaine voir parfois elle plante en lançant X. Je vire le driver NVIDIA histoire de voir si par hasard ca fait la même chose avec Nouveau, je configure le double écran, ca fonctionne… Depuis, la machine ne plante plus!

        Bon, faudrait que je me décide à retester nouveau à la maison :)

        • [^] # Re: respect

          Posté par (page perso) . Évalué à  6 . Dernière modification : le 26/10/12 à 10:28

          Allez pour le coup, je viens de virer les drivers Nvidia sur mon pc au taf (bi écran avec NVIDIA Corporation G84 [Quadro FX 570].

          J'ai un peu flippé d'avoir perdu ma conf KDE quand ca a démarrer en mode clone mais une fois configuré, plasma m'a remis mon bureau de droite en état :)

          Ca fonctionne au poil et j'ai même pu réactiver le module kwin pour le curseur qui saute (faut connaitre KDE pour comprendre) qui avait de gros bug d'affichage avec le dernier driver Nvidia ;)

          Je regarde ce soir si ca corrige aussi les bugs d'affichage que j'ai à la maison avec les vidéos et xv (parfois, pendant 1 seconde, j'ai une image qui s'affiche à l'écran et qui n'a rien à voir avec la vidéo au temps t… Souvent, c'est une scène de y'a 10 minutes dans la vidéo)…

          MERCI!

    • [^] # Re: respect

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

      Bravo pour le boulot que vous faites sur Nouveau

      Le travail de retro-engineering sur des drivers proprio doit être quelque chose de très complexe, et cela m'épate que l'on puisse y arriver !

      • [^] # Re: respect

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

        Le travail de retro-engineering sur des drivers proprio doit être quelque chose de très complexe, et cela m'épate que l'on puisse y arriver !

        C'est pas complexe du tout quand on a les bons outils. Par contre c'est lent et très ennuyeux si on aime pas les challenges ;)

        • [^] # Re: respect

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

          et c'est quoi tes outils ?

          • [^] # Re: respect

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

            et c'est quoi tes outils ?

            Ils sont ouverts. Il y a tout d'abord les mmiotraces qui permettent d'espionner ce qui passe par le port PCIE puis il y a valgrind-mmt qui permet de tracer tous les appels systèmes fait pour une application puis de tracer l'utilisation des buffers graphiques. On a aussi nvafakebios qui permet d'envoyer un bios modifié sur la carte sans flasher la ROM. Pour le reste, je te conseille d'aller voir la liste des programmes que l'on a dans le dépôt envytools.

          • [^] # Re: respect

            Posté par (page perso) . Évalué à  1 . Dernière modification : le 27/10/12 à 12:33

            cf, je pense, la partie de l'entretien sur Marcin Kościelnicki

            edit : grillé

  • # Sécurité dans la pile graphique

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

    J'ai lu ton article il y a quelque temps déjà et c'est vrai que savoir qu'aujourd'hui, fier de notre OS "plus sécurisé que la fenêtre", n'importe quelle appli graphique peut écouter le clavier, y compris lorsque l'on tape son mdp root dans un terminal graphique ou la popup Gnome est traumatisant !

    • [^] # Re: Sécurité dans la pile graphique

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

      Oui, vivement Wayland pour corriger tout ça!

      • [^] # Re: Sécurité dans la pile graphique

        Posté par . Évalué à  1 .

        J'ai un camarade qui m'avait parlé de ce bug sur SunOS (avant Solaris donc) en 1992 à l'ENST où on avait des Sparc, ce qui lui avait permis d'obtenir la plupart des mots de passe des autres étudiants. Du coup, quand il tapait son mot de passe, il activait je ne sais plus quoi pour éviter que les frappes clavier puissent être écoutées par autre chose que le terminal où il tapait.

    • [^] # Re: Sécurité dans la pile graphique

      Posté par . Évalué à  2 .

      Ça veut dire que n'importe quelle application malicieuse (y compris une saloperie en flash ?) peut avoir accès à toutes les entrées clavier et les sorties écran n'importe quand ?

      • [^] # Re: Sécurité dans la pile graphique

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

        Ça veut dire que n'importe quelle application malicieuse (y compris une saloperie en flash ?) peut avoir accès à toutes les entrées clavier et les sorties écran n'importe quand ?

        Rien ne l'empêche dans X et dans le kernel en tout cas. Le seul contrôle existant est trop large.

      • [^] # Re: Sécurité dans la pile graphique

        Posté par . Évalué à  2 . Dernière modification : le 26/10/12 à 14:38

        Non c'es sandboxé. Par contre le jour ou la sandbox se fait trouer… Mais de toute facon à partir du moment ou on peut executer du code sous l'uid de l'utilisateur c'est game over, juste plus ou moins facile .

        Bref utilisez une VM pour browser l'interweb et autre;)

        • [^] # Re: Sécurité dans la pile graphique

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

          Non c'es sandboxé.

          Par qui? Pas par chromium/firefox car Flash peut accéder à VDPAU pour faire de l'accélération vidéo ;)

          • [^] # Re: Sécurité dans la pile graphique

            Posté par . Évalué à  4 .

            C'est Flash qui a accès à X, pas les applis Flash. Elles, elles ne peuvent accéder qu'à ce qu'expose Flash/ActionScript. Les problèmes arrivent quand Flash est troué. C'est le même problème que pour les VM JS des browser.

            Pour que les applis Flash puissent chopper les événements X, elles auraient besoin d'avoir fait tourner un bout de code natif sous l'UID de l'utilisateur pour aller chercher lesdits événement. À partir de la le problème de sécu à déjà eu lieu. Si tu enlèves ça elles feront autrement, elles peuvent faire exactement ce que l'utilisateur peut faire.

            Après il est aussi intéressant de s'intéresser à comment on limite les dégats quand on se fait trouer. Adobe à bossé à sandboxer le processus Flash pour que quand il se fait trouer, l'attaquant ne puisse pas faire grand chose. Ca repose sur un design de type séparation de privilège. La VM tourne avec les droits les plus minimaux possibles, et quand il y a une interaction à faire avec le système elle doit demander à un autre processus qui à gardé les droits de l'utilisateur. Ca c'est dispo que sous Windows AFAIK. Si c'était dispo sous Linux alors là oui, pouvoir écouter les événements clavier serait un problème. Mais sans ca, ca ne sert pas à grand chose.

            • [^] # Re: Sécurité dans la pile graphique

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

              C'est Flash qui a accès à X, pas les applis Flash.

              J'avoue qu'avec le nombre de failles dans ce genre d'applis (Flash, Java), j'ai du mal à faire la différence ;)

              Demander au userspace de faire de la sécurité, c'est se tirer une balle dans le pied. Je préfère l'approche du sandboxing de chrome. Demander au kernel de dropper des privilèges pour toujours!

              • [^] # Re: Sécurité dans la pile graphique

                Posté par . Évalué à  5 .

                J'avoue qu'avec le nombre de failles dans ce genre d'applis (Flash, Java), j'ai du mal à faire la différence ;)

                Le problème c'est qu'on ne comprend plus du tout de quoi on parle si on va part là. Vu la question posée à la base ainsi que son domaine il me semble très important de bien expliquer chaque partie, comment elles interagissent et l'état de l'art actuel.

                Soit dit au passage il est très difficile à trouver pour Linux soit dit en passant. Pour Windows on peut se faire une idée là: https://media.blackhat.com/bh-us-12/Briefings/Sabanal/BH_US_12_Sabanal_Digging_Deep_Slides.pdf

      • [^] # Re: Sécurité dans la pile graphique

        Posté par (page perso) . Évalué à  1 . Dernière modification : le 26/10/12 à 14:44

        J'ai trouvé ceci :

        the isolation between applications is a major issue of the traditional X11 model. It is well known that any application connected to X11 server can listen on arbitrary events.
        Under the Wayland model, the application recieves only mouse and keyboard events only when it has
        focus. The application can't steal events from other application. So this is much improved design.

        http://lists.freedesktop.org/archives/wayland-devel/2012-June/004078.html

        Par contre j'avais lu qu'avec Wayland on pouvait ouvrir une fenêtre(*) transparente faisant tout l'écran qui permettrait d'écouter le clavier ?

        (*) je ne suis pas sûr du terme, désolé je ne maîtrise pas le sujet

        • [^] # Re: Sécurité dans la pile graphique

          Posté par . Évalué à  4 .

          Par contre j'avais lu qu'avec Wayland on pouvait ouvrir une fenêtre(*) transparente faisant tout l'écran qui permettrait d'écouter le clavier ?

          Pas vraiment: avec Wayland (Weston en fait) tu peux effectivement ouvrir une fenêtre transparente qui couvrirait l'écran sans que l'utilisateur sans aperçoive puisque les décorations sont affichées par le programme donc tu n'aurais pas de fenêtre "bizarre" affichées a l'écran, après ça ne sert à rien car il ne suffit pas de recevoir les évènements souris/clavier il faut aussi les rediriger vers les applications "en dessous" autrement tes applications arrêtent de recevoir des évènements et donc de fonctionner, ce qui n'est pas très discret!

          Et il me semble que Wayland/Weston n'a pas la fonctionnalité de redirection des évènements..

          Maintenant comment ça va fonctionner pour les clavier "virtuels" avec Wayland, des applications qui doivent légitimement envoyer des évènements, là j'avoue que je ne sais pas..
          Je vois 2 possibilités: Wayland vérifie que le programme qui envoient des évenements a des privilèges particulier (comment il peut faire ça??) ou bien les claviers virtuels font partie de Weston, mais ça n'est pas souple du tout..

          • [^] # Re: Sécurité dans la pile graphique

            Posté par (page perso) . Évalué à  3 . Dernière modification : le 26/10/12 à 17:17

            Ah ben ça c'est abordé dans la présentation de Martin Peres & Timothe Ravier à XDC2012 dont les slides sont ici (p 20-21) :

            Proposal: a MAC framework

            Mandatory Access Control

            • Control enforced by the system (mostly the kernel);
            • Based on a policy (no unprivileged user control).

            Suggestions

            • Should be implemented as a library to unify access control on every wayland compositors;
            • Should define which applications are allowed to take screenshots/act as virtual keyboards/copy & paste/drag & drop/register global shortcuts. . .
            • Generic model, could look like or be polkit; Integrating SELinux to use policy mecanisms.
  • # 3D

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

    La vidéo de démo de Wayland est très impressionnante, je l'admet… le compositeur pourrait même devenir un jeu vidéo à lui tout seul (je vois bien un mini FPS où l'on pourrait "killer" les programmes au propre comme au figuré, mais je m'égare)

    Concernant nouveau, j'ai bien conscience que la critique est facile et que l'art est difficile, mais quelle sont les raisons qui font que la prise en charge de la 3D progresse si lentement par rapport à celle de la 2D ? Est-ce que nvidia a délibérément compliqué l'électronique pour compliquer le travail de ceux qui voudraient faire de la rétro-ingénierie ?

    Peut-on espérer un support de la 3D dans un futur relativement proche ou doit-on se résoudre à conserver les pilotes propriétaires pour les années à venir ?

    • [^] # Re: 3D

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

      la prise en charge de la 3D progresse si lentement par rapport à celle de la 2D ?

      Ça semble pourtant évident, la 2D est quelque chose de bien plus facile à gérer par une carte graphique et du coup par les pilotes (moins d'instructions, de difficultés, moins besoin de puces pour calculer la 2D facilement par rapport à la 3D, etc.).

      Je ne pense pas que nVidia fasse volontairement de la 3D plus difficile que la 2D à implémenter, naturellement ça l'est.

      • [^] # Re: 3D

        Posté par (page perso) . Évalué à  0 . Dernière modification : le 26/10/12 à 01:44

        D'après ce qu'on peut lire les GPU NVidia sont inutilement complexes (sans doute comme les CPUs x86, obligés de se coltiner l'antériorité)

        comparer :

        NVIDIA doesn't know how to design simple hardware.

        https://plus.google.com/108010086967233476835/posts/iy21rLJfeCk

        et :

        "From a technical point of view, ARM's Mali GPU is the perfect candidate for a reverse engineering project. The hardware is well structured and beautifully simple. The driver stack is equally structured and highly logical. The kernel interface is kept simple and sane. Compared to some of its competitors, the Mali is a thing of beauty. It gives this driver developer the same buzz that the original ATI R500 display engine did when implementing the radeonHD driver."

        Luc Verhaegen does applaud the ARM Mali GPU design as being "clean" since their driver doesn't require any micro-code to be loaded manually nor does it do any register banging from user-space. This does help in the reverse-engineering process.

        http://www.phoronix.com/scan.php?page=article&item=arm_mali_reverse&num=2

        • [^] # Re: 3D

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

          Comme tu le dis, le problème de nVidia vient sans doute du poids historique de ses composants et qu'il ne peut pas permettre de tous remettre à 0 comme le x86 qui est aujourd'hui un truc assez immonde, énergivore et peu efficace par rapport à sa réelle fonctionnalité. Cela explique le succès grandissant de ARM sur mobile, ARM ayant une architecture profitant des innovations techniques pour faire quelque chose de sobre mais puissant ce qui donne un meilleur rendement et une simplification des pilotes derrière.

        • [^] # Re: 3D

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

          NVIDIA doesn't know how to design simple hardware.

          Quand je disais ça, c'était pour la gestion d'énergie qui est compliquée pour pas grand chose. Je travaillais sur la gestion du ventilateur et voir que piloter
          un moteur d'exécution est plus facile qu'un ventilateur, c'était surréaliste.
          À contrario, 95% du design hardware d'NVidia est purement génial. On pousse quelques coups de gueules parfois car on a besoin de souffler un coup mais c'est en général justifié quelques années plus tard quand on comprend mieux les contraintes sur les ingénieurs NVidia. Pour les 5% restant, on a de grosses surprises et on se demande sous quelles drogues étaient les ingénieurs quand ils ont conçu ce matériel!

          Cela dit, la 3D et les contrôleurs mémoire sont la spécialité d'NVidia et je peux vous assurer que ça se ressent dans le matériel! La 3D est relativement simple à implémenter du coté Nouveau maintenant qu'on a les briques de base. Comme je l'ai dit plus haut, ce qui manque maintenant, c'est le support dans Gallium des nouvelles extensions.

          D'après ce qu'on peut lire les GPU NVidia sont inutilement complexes (sans doute comme les CPUs x86, obligés de se coltiner l'antériorité)

          Non, Nvidia ne se coltine pas l'antériorité. Ils ont tout changé pour les Geforce 8 et, à ma connaissance, il n'y a plus rien à changer. Il faut juste rajouter le support des nouvelles instructions. Fermi a changé pas mal de choses, mais pas sur la 3D.

          • [^] # Re: 3D

            Posté par . Évalué à  10 .

            À contrario, 95% du design hardware d'NVidia est purement génial. On pousse quelques coups de gueules parfois car on a besoin de souffler un coup mais c'est en général justifié quelques années plus tard quand on comprend mieux les contraintes sur les ingénieurs NVidia. Pour les 5% restant, on a de grosses surprises et on se demande sous quelles drogues étaient les ingénieurs quand ils ont conçu ce matériel!

            C'est clairement la citation de la semaine. On voit souvent les gens tirer à boulet rouge sur des choses qu'ils ont juste survolées en méprisant les gens et leur travail, alors qu'avec un peu de recul et d'information supplémentaire on comprend le pourquoi. Quand c'est pas beau ou qu'on s'écarte du chemin de moindre résistance, il y a souvent une raison.

        • [^] # Re: 3D

          Posté par . Évalué à  2 .

          Ca peut être un problème de performance?
          Quand tu rajoutes des choses pour amméliorer la perf (par ex les RISC qui sont passés d'instruction 32bit uniquement au 16/32bit), ça complique la programmation..

      • [^] # Re: 3D

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

        Ça semble évident mais ça ne l'est absolument pas !

        Dans le temps il y avait dans les GPU du silicium dédié à un "moteur 2D", qui effectuait certaines opérations 2D. Aujourd'hui, la 2D se fait en général en utilisant le moteur 3D… donc au niveau driver on est pas vraiment sur quelque chose de plus simple.

        • [^] # Re: 3D

          Posté par . Évalué à  0 .

          D'où l'intérêt du projet glamor

          • [^] # Re: 3D

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

            D'où l'intérêt du projet glamor

            Oui et non. Glamor est plus là pour abstraire le driver et utiliser la seule API de programmation commune : OpenGL.

            Luca Stach est plus intéressé par l'écriture d'un State Tracker Gallium pour permettre l'exposition de primitives plus adaptées à l'accélération 2D. Il a présenté son approche à l'XDC2012.

            • [^] # Re: 3D

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

              Il y aussi Cairo-gl que Lucas n'aborde pas ?

              • [^] # Re: 3D

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

                Réexprimer les primitives 2D en commandes 3D au niveau de l'API 3D, ce n'est pas optimal du tout. OpenGL n'a pas été conçu pour la 2D et tu vas forcément perdre pas mal en performance.

                Les primitives 2D sont exprimées en commandes 3D au niveau du GPU, ce qui n'est d'ailleurs pas optimal non plus (mais ça économise du silicium, le nerf de la guerre quand on fabrique des GPU). L'idéal c'est d'adapter l'API 2D à la réalité du backend, pas de la transcrire bêtement en OpenGL.

                C'est pour ca que des projets comme Glamor sont peu intéressants, c'est juste un processus de "migration", mais pas une bonne solution.

                • [^] # Re: 3D

                  Posté par (page perso) . Évalué à  2 . Dernière modification : le 26/10/12 à 16:24

                  Tiens un développeur Nouveau ("inactif" ?) grenoblois :-)

                  Merci pour ce point, tu viens de me faire comprendre en quelques lignes ce que j'avais du mal à réaliser depuis un bout de temps, en assimilant un peu vite OpenGL avec les fonctions 3D des puces graphiques

            • [^] # Re: 3D

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

              Un truc comme Direct-rendering with cairo (cairo-drm)
               ?
              cf http://cworth.org/~cworth/papers/2009-LCA_Carl-Worth_Click-to-Pixel_Graphics-Stack-Tour.pdf (p11)

    • [^] # Re: 3D

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

      La vidéo de démo de Wayland est très impressionnante, je l'admet… le compositeur pourrait même devenir un jeu vidéo à lui tout seul (je vois bien un mini FPS où l'on pourrait "killer" les programmes au propre comme au figuré, mais je m'égare).

      Hey hey, oui. Ça pourrait être marrant. Et pour une fois, les films seraient dépassés par la réalité!

      Concernant nouveau, j'ai bien conscience que la critique est facile et que l'art est difficile, mais quelle sont les raisons qui font que la prise en charge de la 3D progresse si lentement par rapport à celle de la 2D ?

      À vrai dire, je ne comprend pas la question. Le support de la 3D est complet (à l'exception du support d'OpenGL 3.1+) du point de vue Nouveau. Ce qui traîne, c'est l'interface Gallium et l'implémentation de l'architecture nécessaire pour supporter les prochaines versions d'OpenGL. Du coté de Nouveau, on a des problèmes de performance à cause du code non optimal que l'on génère pour les shaders (si quelqu'un veut aider là dessus, il est le bienvenue!) mais surtout à cause du fait qu'on ne gère pas encore bien le changement de fréquence. Du coup, on est bloqué à des fréquences ridiculement basses ce qui limite énormément les performances.
      J'y travaille mais c'est énormément de boulot!

      Peut-on espérer un support de la 3D dans un futur relativement proche ou doit-on se résoudre à conserver les pilotes propriétaires pour les années à venir ?

      Pour les cartes un peu vieilles (geforce 8/9), on devrait pouvoir se passer du blob assez rapidement si l'on a pas besoin énorme en performance. Pour les suivantes, le reclocking est une grosse inconnue.

      • [^] # Re: 3D

        Posté par . Évalué à  2 .

        Hey hey, oui. Ça pourrait être marrant. Et pour une fois, les films seraient dépassés par la réalité!

        Tu n'a jamais vu Tron ? Je te le conseil :)

        Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

        • [^] # Re: 3D

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

          Tu n'a jamais vu Tron ? Je te le conseil :)

          Si si, j'ai vu les deux :) Mais Tron, ça fait une analogie du monde électronique et système dans le monde "physique". Ça montre pas vraiment une interface faite pour l'utilisateur.

          Je pensais plutôt à des trucs à la con comme dans Hackers :D

      • [^] # Re: 3D

        Posté par . Évalué à  2 .

        Du coté de Nouveau, on a des problèmes de performance à cause du code non optimal que l'on génère pour les shaders (si quelqu'un veut aider là dessus, il est le bienvenue!) mais surtout à cause du fait qu'on ne gère pas encore bien le changement de fréquence. Du coup, on est bloqué à des fréquences ridiculement basses ce qui limite énormément les performances.

        Est-ce que ce sont les seules limitations (les shaders et la fréquence) ou bien est-ce qu'il y a des optimisations non triviales en plus de ça ? J'ai une carte radeon (pas nouveau donc mais j'imagine que les problématiques sont similaires) plutôt bien supportée et les performances avec le pilote libre sont faibles par rapport à ce que je peux obtenir sous windows. J'ai aussi lu que les développeurs d'Intel ne veulent pas passer à Gallium entre autres parce qu'ils pensent que ça engendre une perte de performance trop importante (et ils ne veulent pas réécrire leur pilote).

    • [^] # Re: 3D

      Posté par . Évalué à  7 .

      je vois bien un mini FPS où l'on pourrait "killer" les programmes au propre comme au figuré, mais je m'égare

      http://www.cs.unm.edu/~dlchao/flake/doom/chi/chi.html

  • # Kafkaïenne

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

    Dans une des réponses, je lis « Kafakaesque ». Il me semble qu'on dit plutôt « kafkaïenne », en français…

  • # Nouveau : vraiment opérationnel

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

    Sur ma machine principale, toujours en Mageia_1, j'utilise le pilote nvidia mais sur deuxième machine utilisée pour le traitement du son et de la video, j'ai laissé nouveau qui a été automatiquement installé par Mageia_2.
    Vu que tout fonctionne bien, je n'ai pas envie de m'embêter à installer le pilote propriétaire qui le plus souvent refuse de fonctionner après une mise à jour.
    Je viens de tester Mageia_3 version alpha_2 : Nouveau est impeccable, que ce soit pour la vidéo ou pour les effets de bureau de KDE.

    En fin de compte, je suis ravi de réduire le nombre de programmes propriétaires sur ma machine. Maintenant que j'ai pu remplacer Acrobat Reader par Okular et le pilote Nvidia par Nouveau, il ne me reste plus que Flash à éradiquer. Je vais être patient et attendre que HTML5 fasse son œuvre. Mais il faudra vivre encore quelques années avec ce module indispensable si on veut avoir une machine pleinement fonctionnelle.

    Un grand bravo et un grand merci à tous ceux qui on travaillé sur Nouveau.

    • [^] # Re: Nouveau : vraiment opérationnel

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

      Un grand bravo et un grand merci à tous ceux qui on travaillé sur Nouveau.

      Merci de la part de l'équipe de Nouveau. C'est bon d'entendre parler des gens chez qui c'est fonctionnel même si clairement pas grâce à moi (je bosse que sur la gestion d'énergie).

      • [^] # Re: Nouveau : vraiment opérationnel

        Posté par . Évalué à  2 .

        Comme si la gestion de l'énergie ça ne servait à rien, tsss…

        Bravo !

        Yth.

      • [^] # Re: Nouveau : vraiment opérationnel

        Posté par . Évalué à  3 .

        Tu veux entendre des remerciements!!! Ben en voilà!! ;)
        Nouveau marche chez moi sans problème depuis plusieurs années.

        Merci BEAUCOUP!

        • [^] # Re: Nouveau : vraiment opérationnel

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

          idem, la GeForce 7300 de mon laptop ne me pose plus aucun problème depuis que j'ai basculé sur nouveau lors de son entrée officielle dans le kernel. Mais je n'ai aucun besoin particulier en 3D.

      • [^] # Re: Nouveau : vraiment opérationnel

        Posté par . Évalué à  4 .

        Un collègue n'utilise pas Nouveau, car il est impossible de rester dans la pièce tellement la ventilation de sa carte graphique est bruyante. Donc tes avancées devraient au contraire lui être plus qu'utiles !

      • [^] # Re: Nouveau : vraiment opérationnel

        Posté par . Évalué à  2 .

        J'utilise pour ma part nouveau depuis au moins deux ans sur mon (vieux) T61 et sa NVS 140M. Avec gnome-shell ça fonctionne relativement bien, y'a juste des corruptions de textures de temps en temps qui forcent à réinitialiser X.

      • [^] # Re: Nouveau : vraiment opérationnel

        Posté par . Évalué à  4 .

        J'ai adopté nouveau avec fedora 15 si je me souviens bien.
        C'était la première version qui me permettait de jouer à urban terror correctement (et je me suis du coup débarrassé du dernier blob de mon système).
        Je suis tout à fait stupéfait par le fait que les performances du driver nvidia et nouveau soient comparable. Je me souviens d'une époque où il y avait deux ordre de grandeurs d'écart.

        Chapeau ! Il ne manque qu'OpenCL du coup ?

        Please do not feed the trolls

        • [^] # Re: Nouveau : vraiment opérationnel

          Posté par (page perso) . Évalué à  4 . Dernière modification : le 28/10/12 à 16:12

          C'était la première version qui me permettait de jouer à urban terror correctement (et je me suis du coup débarrassé du dernier blob de mon système).

          Sauf qu'aujourd'hui c'est UrbanTerror le blob, depuis qu'ils ont migré d'ioQuake3 vers le SDK propriétaire. /o\

          ce commentaire est sous licence cc by 4

          • [^] # Re: Nouveau : vraiment opérationnel

            Posté par . Évalué à  1 .

            D'ailleurs il me semble que si le moteur est était libre, le mod lui ne l'était pas. Donc c'était effectivement pas le dernier.

            Please do not feed the trolls

  • # Nouveau sur une nvidia 9300MGS (Asus X71SL)

    Posté par . Évalué à  2 . Dernière modification : le 26/10/12 à 12:25

    En regardant la Feature Matrix, je savais que c'était risqué, mais la curiosité l'a emporté.

    (Linux 3.6.3-1 sous Archlinux 64 bits).

    J'ai donc installé nouveau, nouveau-dri, et activé [Option "GLXVBlank" "true"] dans la config de Xorg, ainsi que [options nouveau msi=1] dans /etc/modprobe.d/nouveau.conf, viré le pilote proprio, activé nouveau dans /etc/mkinitcpio.conf et refait mon image initrd, et redémarré en priant. :p

    Résultat :
    - VDPAU ne fonctionne plus (c'était plus ou moins attendu)
    - Une 2D qui plante moins (en tout cas j'ai bien les jeux en 320x200 de DOSBox qui prennent toute la largeur de l'écran en 1440x900 en mode plein écran, alors que le pilote nvidia a décidé de foutre le plein écran de DOSBox en 4:3 dernièrement. Et de ne même plus maximiser le plein-écran si j'utilise output=opengl au lieu de output=surface (une surface SDL) dans la config de dosbox. Juste WTF nvidia ? 1440x900 et 320x200 c'est le même rapport hauteur/largeur!)
    - warsow qui tourne à 1 FPS - même pas le jeu en fait, juste l'écran de présentation de la dernière version qui a un arrière-plan en 3D (là aussi c'était plus ou moins attendu)
    - Pas eu de plantage, si ce n'est un redémarrage qui a bloqué (en même temps j'utilise systemd en plus, j'suis un peu fou)

    Finalement, ça s'est beaucoup mieux passé.

    Rien que pour la 2D qui fonctionne mieux, je suis très tenté le garder (la 3D n'est pas le point fort de cette carte de toute façon). Par contre, VDPAU me sert beaucoup pour les films en HD (qui passent souvent mal sur le Core2Duo T5800…)

    • [^] # Re: Nouveau sur une nvidia 9300MGS (Asus X71SL)

      Posté par . Évalué à  2 .

      j'oubliais dans les paquets installés : libgl, et xf86-video-nouveau

      • [^] # Re: Nouveau sur une nvidia 9300MGS (Asus X71SL)

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

        j'oubliais dans les paquets installés : libgl, et xf86-video-nouveau

        Hey hey, il te manque nouveau-dri pour avoir l'accel 3D. Actuellement, tu utilises ton CPU (swrast ou llvmpipe), donc ça ira pas vite :)

        Pour vérifier, tu peux faire: glxinfo | grep "OpenGL vendor string".

        • [^] # Re: Nouveau sur une nvidia 9300MGS (Asus X71SL)

          Posté par . Évalué à  2 .

          Si si il était bien installé lors de mon test. :)

          De nouveau sous nouveau (heu…) :

          $glxinfo | grep "OpenGL vendor string"
          OpenGL vendor string: nouveau

          En fait, warsow tourne entre 10 et 16 FPS (entre 30 FPS - beaucoup d'action - et 60 FPS - on regarde le sol - pour le pilote nvidia), avec le son qui est très très haché et lent. M'enfin pour un pilote qui est tout nouveau (heu…), c'est très impressionnant ! J'avais aussi absolument aucun bug graphique.

    • [^] # Re: Nouveau sur une nvidia 9300MGS (Asus X71SL)

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

      Du temps d'Ubuntu 12.04, j'utilisais les drivers propriétaires nVidia. Tout était fluide, rien à redire. Lors du passage à la version 12.10, que ce soit sous Unity ou Gnome Shell, tout était lent, hyper poussif, avec X qui se mettait à consommer énormément de CPU. Ça semble correspondre au bug suivant

      https://bugs.launchpad.net/ubuntu/+bug/1067432

      J'ai dégagé les drivers propriétaires pour mettre Nouveau 1.0.2 et, oh joie, j'ai enfin retrouvé ma fluidité d'antan. Et ce, y compris sur les vidéos HD, aussi bien 720p que 1080p, alors que je ne possède pourtant pas du matos dernier cri

      VGA compatible controller: NVIDIA Corporation GT216 (GeForce GT 220) (rev a2)
      Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz

      Un grand merci à l'équipe de Nouveau

  • # Contribuer

    Posté par . Évalué à  10 .

    Bon, comme tout le monde, merci de fournir un truc libre et qui marche bien !

    Histoire de renvoyer l'ascenseur, on est tenté de regarder comment contribuer.

    Tâches à accomplir

    Pour ceux que ça intéresse, il y a une page TODO for newcomers, avec des tâches en documentation / communication, développement et reverse engineering.

    En cherchant dans un vieux message, j'ai retrouvé les liens suivants :

    https://github.com/pathscale/pscnv/wiki/TestingTimings
    http://nouveau.freedesktop.org/wiki/PowerManagementDumps
    https://github.com/pathscale/pscnv/wiki/PM_memory_timings
    https://github.com/pathscale/pscnv/wiki/TestingTimings

    Il n'y a pas de lien direct depuis la page TODO. Parce que les données en question ne sont plus utiles ?

    C'est bien fait, ces pages, parce que ça permet d'essayer seul de voir ce qu'on peut produire, et de contacter l'équipe uniquement si on pense que c'est pertinent.

    Maintenant, si je prends par exemple en reverse dans la page TODO :
    - Improve the current temperature vbios parsing. Possible mentor: mupuf.
    - Find where is the max brightness in the vbios. Possible mentor: mupuf

    Martin, si on veut participer, on doit nécessairement te contacter ? Avec le risque de te faire perdre ton temps si ça se révèle trop compliqué ? (Et donc le risque inverse de ne pas oser déranger de peur de pas suivre derrière.)

    Existe-t-il une page qui explique comment faire ces choses-là ?

    Avancement par famille de cartes

    Un autre truc bien serait d'avoir un état actuel de la connaissance, pour savoir sur quelles cartes les infos sont utiles. Peut-être que ça existe déjà et qu'il manque plus que le lien en page TODO.

    On en a parlé la semaine dernière au L@BX et tu me disais que par exemple, sur la famille nv92, vous aviez (à peu près ?) tout donc je pouvais pas faire grand chose de bien utile.

    Et si ça plante ?

    Par ailleurs, que faire en cas de plantage ? Il m'arrive, bien que très rarement, d'avoir un freeze. A ce moment, là, j'aimerais faire quelque chose pour que ça ne se reproduise pas, ici ou ailleurs. Je ne suis pas certain que ce soit nécessairement lié à X ou à nouveau. Comment savoir si ça peut être le cas (quels indices ?). Quelles sont les infos utiles à remonter quand ça arrive (quels logs ?). Même si c'est plutôt à remonter au bugtracker de la distro, autant donner toutes les bonnes infos.

    En bref, quelque outils pour donner des pistes très simple à celui ou celle qui veut modestement et ponctuellement aider sans nécessairement appartenir à la communauté de contributeurs (et qui sait, une fois qu'on a mis le pied dedans…).

    A plus.

  • # Merci !

    Posté par . Évalué à  3 .

    J'en profite pour remercier chaudement Martin et tous les contributeurs de Nouveau. Habitué des cartes nvidia, j'utilisais les pilotes proprio depuis des années quand un bug m'a forcé à passer temporairement sous Nouveau. C'était il y a deux mois, et je pense que je ne repasserai plus jamais aux pilotes proprio.

    Ma carte chauffe carrément moins, le ventilo est bien mieux géré (j'ai ENFIN un pc silencieux) et la 3d, pour le peu que je m'en sert, fonctionne très bien. Bref que du bonheur.

    Alors bravo et merci !!

    • [^] # Re: Merci !

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

      Ma carte chauffe carrément moins, le ventilo est bien mieux géré (j'ai ENFIN un pc silencieux)

      Oui, effectivement, sur l'ancien pc de mes parents avec le driver nvidia, le ventilo était toujours à fond… Mais bon, c'est la seul machine ou j'ai vu cela…

    • [^] # Re: Merci !

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

      Ma carte chauffe carrément moins, le ventilo est bien mieux géré (j'ai ENFIN un pc silencieux)

      Hmm, on a pas encore de gestion du ventilateur. Je te conseille de regarder la température de ta carte ($ sensors) avant qu'elle ne fasse une combustion spontanée.

      • [^] # Re: Merci !

        Posté par . Évalué à  1 .

        Question bête : sur une carte (une 8800 gt en occurrence) où le ventilo d'origine à été remplacé par un système passif, est-ce-qu'utiliser le pilote nouveau peut être risqué ?

        • [^] # Re: Merci !

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

          Question bête : sur une carte (une 8800 gt en occurrence) où le ventilo d'origine à été remplacé par un système passif, est-ce-qu'utiliser le pilote nouveau peut être risqué ?

          Non, pas du tout risqué ;)

          • [^] # Re: Merci !

            Posté par . Évalué à  4 .

            Je vient de tester, nouveau a fait beaucoup de progrès depuis la dernière fois où j'ai essayé.

            De ce que j'ai testé, le compositing Kwin marche très bien, Doom3, en natif, fonctionne bien ; les perfs sont plus que correctes.
            Par contre, Diablo3, via wine, ne se lance pas (problème de carte qui n'a pas les capacités nécessaire) ; je n'ai pas eu le temps de chercher plus avant, je ferais d'autres essais ce week-end.

            Voila pour mon retour.

      • [^] # Re: Merci !

        Posté par . Évalué à  2 .

        Ok je suis à 70° avec nouveau, soit la même chose que via les drivers proprio + ventilo à fond (au passage nvidiasettings classe cette température dans "attention c'est bientôt limite" mais je n'ai jamais réussi à descendre en dessous, même en dépoussiérant la carte).

        Hmm, on a pas encore de gestion du ventilateur

        Que faut-il en conclure exactement ?

        • [^] # Re: Merci !

          Posté par (page perso) . Évalué à  2 . Dernière modification : le 29/10/12 à 14:18

          que dans Linux 3.7 tu auras la gestion manuelle du ventilo (à l'utilisateur de définir la vitesse de rotation), et plus tard la gestion auto si tout va bien

          • [^] # Re: Merci !

            Posté par . Évalué à  4 .

            Je parlais d'une conclusion opérationnelle et pas d'un enfonçage de porte ouverte, si on me dit "attention avec nouveau tu vas cramer ta carte" j'aimerais bien connaître les cas où il fait bon l'utiliser.

            • [^] # Re: Merci !

              Posté par . Évalué à  4 .

              "les cas où il fait bon l'utiliser. "
              En hiver?

              Perso, le pilote nouveau me va bien:
              _ support de randr
              _ pas de config Xorg à faire (en tout cas sous debian)

              Seul "bémol" impossible d'utiliser 2 cartes branchées en même temps (cela dis, c'est précisé sur le site officiel) et il me semble que les jeux 3D soufrent d'une perf moindre, mais pas testé depuis longtemps avec NVidia et/ou windows.
              Vu le peu de temps ou je joue à des jeux 3D, je préfère le confort d'un WM qui marche à celui de jeux qui carburent (en attendant les deux en simultané peut-être?).
              Et puis tant qu'openMW arrive à fonctionner, donc ça me va.

              En tout cas, merci bien à l'équipe de dev.

Suivre le flux des commentaires

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