Interface graphique fonctionnelle : encore un effort pour l'open source

Posté par . Modéré par Mouns.
Tags : aucun
0
8
juil.
2008
Serveurs d'affichage
Mes premiers pas avec Linux remontent à ma période d'étudiant (sur une idée de mon copain Laurent) en 1998. Il s'agissait d'installer une Red Hat afin de faire du développement Web. Malheureusement pour nous, son vieux PC de l'époque (et surtout son lecteur de CD pas-standard-pas-IDE) n'avait jamais voulu reconnaître le CD qui était dans le lecteur. Nous nous étions donc résigné à nous tourner vers un IIS sous Windows 98.

C'est au cours de l'année que je réussis à démarrer une Slackware 3.0 (fournie par mon copain Christophe, salut Christophe !) qui m'amenait à un shell en mode texte. Ici, pas de graphique, juste du texte.

Ce n'est que 6 mois plus tard que je fis connaissance de mon mentor Linuxien (salut Baptiste !). Non content d'installer mon Linux en dual-boot avec Windows - à l'époque, ça restait quand même indispensable pour mes études - je configurais également mon serveur X sur une RedHat 5.2. J'avais d'ailleurs tellement bien oeuvré pour faire fonctionner tout ceci que j'avais fait une démonstration dans un amphi lors d'une install party avec configuration d'une Matrox G200 en mode 2D 16 millions de couleurs en lieu et place du mode 16 couleurs.

Avec le recul, on prend mieux la mesure des progrès qui ont été fait. Aujourd'hui, toute distribution est au moins en mesure de démarrer le serveur X et de proposer une interface graphique fonctionnelle. Néanmoins, cette situation n'est pas encore parfaite et certains points sont toujours en cours d'amélioration.
Xorg/XFree86

Il est impossible de parler d'interface graphique sous Linux sans évoquer le serveur Xorg. Ce projet trouve son origine dans un conflit au sein des équipes de XFree86 pour un changement de licence. Changement qui fut également très mal accueilli par les différents acteurs du libre[1].
Il faut avouer que la situation était de toute façon bloquée : refus des contributions externes, conflits de personnes, manque de modularité du projet, etc.
Ce fork a donc relancé une situation qui se dégradait et où l'effort d'intégration des distributions devenait de plus en plus important. En effet, auparavant, le projet était géré sous la forme d'un seul gros bloc : une simple mise à jour de pilote impliquait une attente de release complète, souvent de plusieurs mois. Autre inconvénient, le serveur X venait accompagné d'utilitaires d'un autre temps dont la plupart des distributions modernes n'avait plus besoin : des xterm, xeyes, xedit, xcalc ou autre xclock.

La première version de ce fork fut donc Xorg X11R6.7.0 (une copie de XFree86 4.4 RC2 - dernière version utilisant l'ancienne licence [2] - suivie très rapidement de la version X11R6.8.0. Cette dernière apportait des fonctionnalités de gestion matériel de l'affichage 2D et notamment le support des transparences, ombrages etc.

Néanmoins, l'un des travaux les plus important de Xorg fut la modularisation du serveur X. Ce travail s'est fait au moment de la sortie simultanée des versions X11R6.9.0 et X11R7.0.0, le premier se basant toujours sur l'ancien système de packaging maison de XFree86, le second étant modularisé à l'aide des outils GNU/autotools.

Pourquoi ce changement fut-il important ? Tout d'abord pour moderniser le système de packaging du serveur X. Mais surtout, il fut le passage du système de développement cathédrale au système de développement du bazar. Le système de développement cathédrale est très long avec une vision du code une fois seulement les changements terminés et de grandes difficultés pour inclure des contributions externes. Tous les logiciels propriétaires fonctionnent sur ce principe et quelques logiciels libres procédant de la même manière comme GCC ou généralement les logiciels opensource portés par une société : Firefox, openoffice.org, MySQL etc. Le système de développement du bazar est très ouvert et très décentralisé avec une acceptation beaucoup plus large des contributions. Un exemple de développement célèbre en mode bazar est Linux.

Un autre avantage de la modularisation de Xorg était la sortie des pilotes qui pouvait se faire de manière complètement décorrélée de la sortie du serveur X. Xorg apportant ainsi plus de souplesse aux équipes en charge du développement des pilotes 3D et autres utilitaires de gestion des fontes du système.

Depuis, les versions se sont enchaînées : X11R7.1, 7.2 et 7.3 chacune avec son lot d'améliorations et de nouveautés : accélération de l'affichage 2D à base d'openGL pour la 7.1, branchement hotplug dans la 7.3. Paradoxalement, l'accélération 2D (sans effet 3D) est toujours en travaux. La version 7.4 devrait améliorer les choses au travers du support de EXA.

À remarquer que depuis la modularisation, la tendance est de parler directement des versions de Xserver, la version 1.5 correspondant par exemple à X11R7.4.

Les problèmes dans le graphique sous GNU/Linux

Globalement, la situation n'est pas parfaite mais - point important - ça marche ! Autre point important, les choses bougent beaucoup en ce moment ! Dans ce qui va suivre, je vais essayer de vous présenter les travaux en cours avec les différents axes d'amélioration.

(presque) Pas de gestion 3D opensource (pour l'instant)

Le support opensource est encore très limité pour la gestion des cartes graphiques sous GNU/Linux. En effet, il y a peu, les principaux acteurs du monde graphiques ne fournissaient qu'une implémentation des pilotes 2D (voir rien du tout) et des implémentations propriétaires de l'accélération 3D OpenGL. En effet :
  • ATI fournit un pilote propriétaire 3D mais pas de pilote 2D libre.
  • Nvidia fournit un binaire fermé mais propose un pilote 2D libre.
  • VIA fournit des pilotes opensource pour une partie de ses cartes mais avec un temps d'attente conséquent, voire aucun support.

Seul Intel jouait jusque là totalement la carte de l'ouverture en sponsorisant le fonctionnement de la fondation Xorg depuis plusieurs années et en employant certains contributeurs importants (notamment Keith Packard).

En quoi est-ce un problème dans la mesure où une solution (propriétaire) existe ? Je vais essayer d'y répondre en soulignant les points suivants :
  • Incompatibilité entre les licences des pilotes et les distributions linux.
  • En cas de problème sur un pilote, vous êtes soumis au bon vouloir du constructeur (Nvidia ne corrige pas un bug de 2004 qui se révèle être une faille de sécurité en octobre 2006 [7]).
  • Le support du matériel n'est pas garanti. Si en plus de ça vous utilisez un PowerPC, vous risquez de vous retrouver bien seul face à vos problèmes.
  • Lorsqu'un pilote propriétaire à des problèmes de sécurité, vous n'avez aucun moyen de corriger le problème.

Enfin notons que ces pilotes sont dans un état très particulier vis à vis de la GPL : en effet, il est interdit par cette licence de lier un logiciel libre (Linux) avec un logiciel propriétaire (pilote 3D). Sachez toutefois qu'ils sont tolérés par les principaux contributeurs du noyau pour des raisons pragmatique. L'interdiction impliquerait l'absence de solution - Linus Torvalds a plusieurs fois exprimé sont opinion à ce sujet - Ce logiciel existe en dehors de Linux. Le pilote a d'ailleurs été porté à partir des pilotes Windows avec lequel il partage une grosse partie du code.

MAIS - bonne nouvelle - tout ceci est train de changer ! Notamment depuis le rachat d'ATI par AMD. AMD a commencé à libérer les spécifications de leurs matériels il y a un peu plus d'un an. On commence donc à voir des pilotes opensource fonctionnels[4]. Du côté de Nvidia, un groupe très organisé de hackers a également commencé un travail de rétro-ingénierie sur les spécifications des cartes Nvidia avec le début d'écriture d'un pilote (projet nouveau[5]). VIA, de son côté, a démarré un site qui devrait servir de portail pour proposer des pilotes libre pour son matériel[6].

Même si tout n'est pas terminé, les choses vont dans le bon sens. Le bon élève de la classe reste Intel qui apporte un support très complet de ses cartes graphiques et qui reste moteur sur les changements à venir.

Améliorer la cohabitation de Linux et Xorg

Comme nous l'avons vu, le support 3D n'est pas parfait mais on peut dire qu'actuellement la situation est globalement satisfaisante. En revanche, un gros problème persiste : le serveur X et le noyau Linux cherchent à dialoguer avec la carte graphique. Ce problème peut-être mis en évidence lors du démarrage de la machine. En effet, le passage de l'écran de démarrage au mode graphique de Xorg entraine un temps d'attente ainsi que des artefacts graphiques. Ceci est dû à la sauvegarde / réinitialisation de la carte graphique entre les deux modes de fonctionnement (noyau vs Xserver).

J'ajouterais qu'en dehors de l'aspect purement esthétique, il faut savoir que le partage de la ressource graphique entre le noyau et le serveur X pose un problème de taille d'un point de vue sécurité et stabilité. Comme le serveur X initialise la carte graphique avec le même niveau de droit que le noyau Linux, il est en mesure de tout casser... Lorsqu'on sait que Xorg est constitué d'environ 2.5 millions de lignes de code, on imagine facilement que la situation peut très facilement déraper.

Des problèmes peuvent également apparaître lors de la mise en veille puisque le noyau est obligé de déléguer certaines opérations au serveur X. En cas de problème lors d'une sortie de veille, l'utilisateur peut obtenir une interface figée et n'aura aucune information.

Des travaux ont néanmoins déjà été menés. Fedora 9 offre par exemple ce support pour les cartes graphiques Intel. A terme, le noyau devrait intégrer les points suivants[3] :
  • Gestion de la mise en veille. Le noyau s'occuperait complètement de la sortie de l'état de veille avant de rendre la main au serveur X.
  • Message d'information en cas de crash. On peut se moquer de l'écran bleu de Windows, il a l'avantage d'informer de l'existence d'un problème...
  • Utilisation d'une interface sans serveur X. Contrairement à ce qu'on pourrait croire, le serveur X n'est pas indispensable pour afficher du graphique sous Linux. Certains type d'applications pourraient très bien se passer de la couche de communication du serveur X (téléphonie, GPS, embarqué etc).
  • Une gestion plus rapide lors d'un passage d'un terminal virtuel à un autre (même si ce n'est pas très parlant, il s'agit en réalité d'accélérer le démarrage du serveur X).

Développements à venir

La prochaine étape restera certainement l'inclusion d'un gestionnaire de mémoire pour les cartes graphiques dans le noyau Linux. Malheureusement, la situation est bloquée puisque le projet TTM (Translation Table Maps) n'a toujours pas été inclus dans la branche officielle. En effet, ce dernier est vu comme trop complexe et inclus trop d'éléments qui n'ont pas de place dans le noyau - du code n'est là que pour l'inclusion de pilote binaire, gestion trop complexe des accès concurrents aux GPU et CPU - et plus grave, les projets opensource des pilotes ATI et Nvidia n'ont toujours pas complètement adopté cette couche d'abstraction.

La question a donc été de savoir s'il n'existe pas un autre projet pouvant se substituer à TTM. Il se trouve qu'Intel avait commencé un projet (GEM pour Graphics Execution Manager [8]) qui devait justement remplir ce rôle. Plutôt que de vouloir trouver une solution unique trop complexe, le pari a été de faire fonctionner correctement un type de carte (Intel) puis d'adapter ce mécanisme aux autres type de carte (ATI et Nvidia).

L'approche a l'avantage de simplifier les choses au démarrage du projet pour son inclusion dans le noyau Linux (moins de code donc moins de remarque à prendre en compte). Mais elle a le désavantage de devoir introduire des changement importants à venir au niveau de l'API. De plus, certains tests préliminaires ont montrés que GEM devait encore s'améliorer pour arriver au niveau de performance de TTM [9].

Pour conclure

Globalement, comme nous avons pu le voir, tout n'est pas prêt et il reste un gros travail à fournir pour arriver à un niveau de finissions comparable à celui de Mac OS X ou au niveau des performances des pilotes propriétaires. D'un autre côté, contrairement à un modèle de développement propriétaire, le monde opensource a le temps de faire ces changements et tout indique que les pièces du puzzle sont en train de se mettre en place tranquillement.

Références
Didier Granjon, co-fondateur de simia.

Aller plus loin

  • # intéressant, une question ...

    Posté par . Évalué à 5.

    Très jolie résumé de l'évolution et de l'état de l'art. Très intéressant.

    Par contre, pourquoi cet article est dans les dépèches ?
    • [^] # Re: intéressant, une question ...

      Posté par . Évalué à 10.

      Ben linux n'est toujours pas prêt pour le desktop donc il serait temps qu'on se "dépêche" ! _o/ \o_ \o/ /o\
      • [^] # Re: intéressant, une question ...

        Posté par . Évalué à 10.

        T'inquiète pas, le plus gros concurrent en face a encore bien plus de retard et pourtant plein de gens l'utilisent.
        • [^] # Re: intéressant, une question ...

          Posté par . Évalué à 1.

          Je vois pas bien ou tu veux en venir...
          C'est la Gnu/Tortue qui dit ça au Lièvre Vista ou le GNU/Lièvre qui dit ça à la Tortue Vista ? Parce que si la course n'a que ces deux options, La Fontaine n'avait pas pensé qu'un Fauve X pouvait bouffer les retardataires...
          Rien ne sert de courir, certes, mais il faut partir à point quand même !
          • [^] # Re: intéressant, une question ...

            Posté par . Évalué à 7.

            bof bof si le Fauve X était pas vendu préinstallé sur une plateforme hardware rigoureusement testée, il ne ferai pas mieux que les 2 autres.
            • [^] # Re: intéressant, une question ...

              Posté par . Évalué à 2.

              tu veux dire quoi ?
              Que si l'interface de Mac OS basculait dans l'Open Source et qu'on l'installait sur du matos de merde, ça serait à chier ? :-)
              • [^] # Re: intéressant, une question ...

                Posté par . Évalué à 10.

                Je pense qu'il veut surement dire que si MacOS X n'était pas disponible que sur le seul matos d'apple, il aurait lui aussi des problèmes de drivers comme nous le connaissons pour Linux et Windows.

                Sous linux, c'est un manque de drivers (pas tous les matériels et périphérique sont supportés).

                Sous windows, ils ont bien souvent de nombreux drivers (car toutes les entreprises développent les drivers pour leurs périphériques) mais la qualité n'est pas au rendez-vous (tout le monde n'a pas les capacités à faire un driver de qualité) et de ce fait, windows plante souvent. Je me souviens d'une citation qui disaient que 80% des plantages de windows sont dus à de mauvais drivers.
              • [^] # Re: intéressant, une question ...

                Posté par . Évalué à 3.

                En tout cas ceux qui ont essayé de le faire tourner sur un Intel compatible (comme moi) pourront te le confirmer que ce n'est pas joyeux. Rien que pour faire fonctionner quartz extrem correctement avec sa carte graphique c'est toute une aventure.
          • [^] # Re: intéressant, une question ...

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

            Je sais pas quel goût ça a la tortue, mais du lièvre à point j'en veux bien !

            ce commentaire est sous licence cc by 4 et précédentes

      • [^] # Re: intéressant, une question ...

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

        Ouuuuuouh !!!
        Excellente \o/

        Tu sors, j'aurais pu la faire... c'est dire le niveau :)

        Sinon, je ne vois en quoi il est génant d'avoir une telle dépêche. C'est très bien, ça rappelle un des aspects de Linux&co : les utilisateurs, qui commencent sans savoir et qui aspirent à s'approprier
        Et il est bon de leurs rappeler l'Histoire et de donner des pistes, de partager des expériences, etc.
        Et puis même pour les "initier", c'est toujours "touchant" :)

        Deux questions qui me viennentt à l'esprit là :
        Est-ce que LinuxFr est lu par un public débutant (comme celui-ci, plus ou moins) ?
        Et si non, est-ce qu'il y a un filtrage des articles "pour non-initié" (est-ce une volonté de l'équipe qui gère le site) ?

        Merci en tout cas !
      • [^] # Re: intéressant, une question ...

        Posté par . Évalué à 5.

        C'est archi faux puisque linux est sur mon desktop depuis 10 ans maintenant. Et je n'ai jamais eu de problème à configurer X. Pourtant j'étais un débutant complet.
        • [^] # Re: intéressant, une question ...

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

          Le pingou il sait faire un click droit propriété pour
          changer la résolution, le nb de couleurs ?, le positionnement
          du bi-écran ...

          Il y a encore beaucoup de taf, pour simplifier l'utilisation.
          Ha si mon oreillette me dis qu'on peut faire CTRL+ALT+SHIF+"+",
          lol ...
          • [^] # Re: intéressant, une question ...

            Posté par . Évalué à 5.

            Avec xrandr 1.2, tout se fait en une ligne de commande : ajout/suppression d'écran, changement de résolution/rafraichissement, placement ... Il "suffit" juste de rajouter une petite GUI à ça, et il me semble que Ubuntu a déjà bien avancé là dessus.
          • [^] # Re: intéressant, une question ...

            Posté par . Évalué à 4.

            Ca existe encore le changement de résolution et de nombre de couleurs ?

            Avec les écrans LCD il n'y a qu'une seule bonne résolution : celle native de l'écran. Et depuis quelques années tout le monde travaille en 23/32 bits de couleurs.

            Quand tout va bien, X règle tout ça automagiquement. Dans le pire des cas il faut faire appel à un spécialiste une et une seule fois pour régler le problème.


            Par contre joker pour le positionnement du bi-écran ;)

            BeOS le faisait il y a 15 ans !

            • [^] # Re: intéressant, une question ...

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

              La profondeur des couleurs peut être importante pour certains jeux Wine (ils veulent 16M sinon ça ne marche pas).
              Et même si les écrans LCD sont très répandus, il n'y a pas que ça.
    • [^] # Re: intéressant, une question ...

      Posté par . Évalué à 9.

      Par contre, pourquoi cet article est dans les dépèches ?

      Parce qu'il est tellement intéressant (comme tu le dis toi-même) et bien écrit qu'il mérite une forte visibilité. Enfin, c'est mon opinion...
      • [^] # Re: intéressant, une question ...

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

        J'appuie avec vigueur, très intéressant pour un néophyte comme moi

        (une petite faute au passage:
        à un niveau de finissions comparable à celui de Mac OS X dans la conclusion, rien de grave )
      • [^] # Re: intéressant, une question ...

        Posté par . Évalué à 4.

        Je suis débutant sous Linux, et j'apprécie ce genre d'articles, c'est clair bien que technique, et ça permet de se faire une idée moins obscure de ce qu'est Linux et des dynamiques, des problèmes, ainsi que des solutions qui émergent.

        Vu que je ne lis quasiment que les dépêches, je suis pour que ce genre d'articles passe dans les dépêches! :)
    • [^] # Re: intéressant, une question ...

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

      Il est en première page. C'est difficilement plus visible !
    • [^] # Re: intéressant, une question ...

      Posté par . Évalué à 4.

      Perso j'ai appris pas mal de choses en lisant l'article. J'ai trouvé celui très intéressant est bien écris. Alors je ne peux dire que merci à LinuxFr de l'avoir mis ici.
  • # modèle de développement

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

    Le système de développement cathédrale est très long avec une vision du code une fois seulement les changements terminés et de grandes difficultés pour inclure des contributions externes. Tous les logiciels propriétaires fonctionnent sur ce principe et quelques logiciels libres procédant de la même manière comme GCC ou généralement les logiciels opensource portés par une société : Firefox, openoffice.org, MySQL etc.

    J'ai l'impression que tu confonds le modèle marketing avec le modèle de développement. Tous les développement propriétaires ne se font pas en "Cathédrale" - Dans ce cas-ci tu parles en fait du modèle de développement "Waterfall" qui est en effet le modèle de développement classique des logiciels propriétaires et des Cathédrales.
    Il existe d'autres méthodologies de développement (je pense à extreme programming et aux autres techniques de développement agile) qui n'ont pas ces restrictions (impossibilité de visualiser le projet avant la fin de gros changements, impossibilité de recevoir des patches) - parce que le but même des ces méthodologies est d'avoir en permanence quelque chose de fonctionnel. Ce qui ne leur empêche évidement pas d'avoir une vue à long terme, même si l'analyse complète de la solution ne se fait qu'au fur et à mesure.
    • [^] # Re: modèle de développement

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

    • [^] # Re: modèle de développement

      Posté par . Évalué à 8.

      J'acquiesce!

      Au vu de l'article, la méthode cathédrale est dépeinte comme peu efficace et lourde.
      Pourtant, si je ne m'abuse, les BSD fonctionnent en cathédrale, et on ne peut quand même pas dire que le développement soit peu efficace et lourd.

      Un deuxième point qui fait des évolutions conjointes du kernel Linux et de Xorg un problème pas si simple, c'est que Xorg est portable, et utilisé sur beaucoup d'autres systèmes. On ne peut pas le rendre dépendant du kernel Linux de quelque façon que ce soit, ou alors il faut que "l'interdépendance" puisse être facilement adaptée à n'importe quelle système.

      En dehors de ça, très bon article.
      • [^] # Re: modèle de développement

        Posté par . Évalué à 6.

        De plus en plus les logiciels libres sont développes pour Linux, et il est de plus en plus difficile de les prter.

        Qu'une équipe de devs ne gère pas le développement sur toutes les archis je le comprends, mais la portabilite devrait etre prise en compte des le debut d'un projet libre.
  • # The Linux developers are selfish dickheads

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

    Bon j'en remet un couche (voir : https://linuxfr.org/~patrick_g/26876.html ) !

    Sérieusement, à lire l'article on croirait qu'il n'existe que linux! Et les *BSD alors? Et le hurd?

    Bon finalement j'hésite entre Syllable et isaac ( http://isaacproject.u-strasbg.fr/li.html ).
  • # PPC _not_ pwned

    Posté par . Évalué à 9.

    Si en plus de ça vous utilisez un PowerPC, vous risquez de vous retrouver bien seul face à vos problèmes.
    Ceux qui veulent faire un tour du coté du projet nouveau [http://nouveau.freedesktop.org/wiki/] trouveront plein de gens qui ont des PPC et du Nvidia \o/
    Et en ce qui concerne les arguments pour avoir des drivers libres, j'utiliserais les même que pour tous les autres logiciels libres : la liberté !

    Voilà, sinon nouveau c'est sympa, mais n'achetez pas de Nvidia (enfin, pas du neuf) c'est un peu contre-productif : http://lwn.net/Articles/269562/ . Ce n'est pas contre le projet nouveau, qui est très bien pour faire sortir les gens qui ont _déjà_ une Nvidia de la merde, mais ça favorise une entreprise qui ne fait rien pour le libre.
    • [^] # Re: PPC _not_ pwned

      Posté par . Évalué à 2.

      Entièrement d'accord en théorie.

      En pratique maintenant, Nvidia c'est quand meme les cartes qui fonctionnent le mieux sous linux et quand on veut des perfs sans se prendre la tete a triturer la conf du noyau / de X pendant des heures, y a pas photo ...
      • [^] # Re: PPC _not_ pwned

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

        Mouais, perso j'ai une ati et mis à part pour la configuration des écrans en mode bureau étendu dès le démarrage de x.org, j'ai rien à touché.

        Pour les perfs, j'ai pas de problème, cela dit je ne joue pas à des jeux conçu pour favoriser le réchauffement climatique. :)

        Non franchement j'ai un usage assez varié pour ce qui est du graphisme, je fais un peu de gimp, de inkscape et scribus, je me met tout doucement à blender et à OpenGL et jusque là j'ai pas eu de soucis.

        Tu as quoi comme utilisation qui te demande de grosses performances en graphisme?
        • [^] # Re: PPC _not_ pwned

          Posté par . Évalué à 3.

          Pour ma part j'ai un jour tenté de jouer à UT2003 avec ma 9700
          (le jeu marche très bien sous windows cela dit)

          Y a quelques mois de cela j'ai tenté d'aider un pote à installer linux avec sa X1300 (pas une carte dernier cri pourtant), rien à faire, le PC freezait toutes les 10min et X plantait quand on lancait une appli 3D (ca marchait avec le driver vesa). Résultat des courses : extension de la partition NTFS par dessus le / ...

          Avec un vilain blob nvidia propriétaire il aurait pu essayer d'utiliser linux au moins ...
          • [^] # Re: PPC _not_ pwned

            Posté par . Évalué à 1.

            Heu, l'ATI de ton pote, tu l'utilisais avec le driver proprio (fglrx) ou le libre ? Parce que critiquer le PC qui freeze à cause d'un driver proprio, je ne comprend pas trop ton argumentation contradictoire ...
            • [^] # Re: PPC _not_ pwned

              Posté par . Évalué à 3.

              D'autant qu'il y a quelques mois (et même encore maintenant), le driver libre pour les X1xxx, il était tout sauf prêt à être utilisé...

              ... en outre, le mode vesa, il y a mieux, mais ça dépanne bien : je connais au moins deux personnes qui s'en servent, pour cause de trop de problèmes avec le(s) driver(s) libre(s), et aussi par refus d'utiliser le blob... [ahemmm] : ils ont des nvidia...

              ... et sinon, UT2003 sur une X800XL à drivers libres (pas essayé sur ma 9600m, vu que j'évite ce genre de trucs qui font chauffer les ordis portables... mais comme elle a tendance à être mieux supporté que les X800, et que je connais quelqu'un qui fait tourner ça sur une 9800... bon, après, ça dépend de la résolution et des détails), chezmoiçamarche© (enfin, quand j'avais testé, ce qui remonte un peu)...

              Perso, je fais peu de 3D (essentiellement : MythTV), mais je fais du multi-écran partout, et depuis longtemps : et je ne suis pas près de prendre autre chose que de l'ATI à driver libres (on verra quand Intel sortira du GPU en cartes à brancher)...
            • [^] # Re: PPC _not_ pwned

              Posté par . Évalué à 1.

              Le driver libre sur du R500 tu oublies, il y a bien radeonhd maintenant mais c'est pas ce que j'appelle un driver fini.

              En l'occurence si tu veux de l'accélération 3D un peu performante à l'heure actuelle avec une ATI, tu utilises comme sur nvidia le driver proprio, même sur les vielles R300 ...

              Nvidia a le mérite de maintenir un driver qui bien que non-libre est à jour, fonctionne (en tout cas de mon experience personnelle, aucun probleme rencontré n'a été insolvable) et qui fournit des perfs équivalentes à celles qu'on pourrait obtenir sous windows

              La situation changera peut être dans quelques années, et je serai parmi les premier à recommander ces cartes là si elles marchent bien, mais d'ici là je vois pas pourquoi s'embêter avec du matèriel peu exploitable.
              • [^] # Re: PPC _not_ pwned

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

                Nvidia maintient que dalle, régulièrement des cartes anciennes sont éjecté de la dernière version de leur drivers proprio. Ce qui prive de bureau 3D et autres bidules pas mal de machines si elles ne sont pas dernier cri. Alors qu'avec un driver libre, c'est l'inverse. On peut utiliser des vieux chipset, ce sont les mieux supporté... J'ai choisi le juste milieu avec une ATI RV 280 et les drivers libres, ça marche au poil, et je ne me retrouverais jamais sans évolutions du driver, contrairement à ma vieille Gforce.
                • [^] # Re: PPC _not_ pwned

                  Posté par . Évalué à 1.

                  Rien ne t'empêche de rester à la dernière version du driver qui supporte ta CG.

                  Et puis j'en suis sûr que dans le noyau tu trouveras bien des drivers pour des cartes tridents, savage ou autre constructeur inconnu pas actualisé depuis des années....
                  • [^] # Re: PPC _not_ pwned

                    Posté par . Évalué à 5.

                    Oui cela marche quand tu utilise un système qui reste figé pendant 10 ans (suivez mon regard). Mais le libre ça marche pas comme ça; et quand il faut attendre 6 mois pour que ton constructeur mette à jour ton drivers pour qu'il fonctionne sur la dernière version de Xorg, tu apprécie ton pilote libre.
                  • [^] # Re: PPC _not_ pwned

                    Posté par . Évalué à 3.

                    Rien ne t'empêche de rester à la dernière version du driver qui supporte ta CG.

                    C'est bien pour ça qu'il dit que NVidia maintient que dale.

                    Est-ce qu'un code de cette taille et fait avant tout pour le grand public pourrait atteindre un degré de stabilité et de sécurité suffisant ? J'ai un doute.

                    Et puis suffisant ça veut dire quoi ? Tant que le code n'est pas complètement prouvé rien ne garanti qu'un hacker va pas trouver une faille dans 2 jours. Et dans ce cas tu es devant un choix très sympa :

                    - tu hérites d'une faille forever et tu peux rien y faire... super.
                    - tu va au magasin acheter une autre CG (et si tu refais la même erreur et que tu rachètes une carte qui ne fonctionne qu'avec du logiciel privateur et en fait tu n'as réglé aucun problème, tu as juste été forcé à dépenser ton argent inutilement)

                    Je ne parle même pas des laptop.

                    Ni du cas où le constructeur arrête de diffuser son pilote et que tu dois réinstaller le système ou celui de ton voisin. Si c'est le tient et que tu es méticuleux, à la limite tu auras une sauvegarde. Si c'est celui de ton voisin et qu'il est bordélique (pas de sauvegarde), tu n'as probablement pas le droit de lui refournir le driver... super (bis)

                    Maintenant si vous êtes des fashions victimes et que vous changez de PC tous les ans, c'est sûr que de toute manière vous prenez pas la tête continuez à acheter du NVidia et à utiliser les drivers privateurs qui vont avec. Les gens doivent garder le droit de s'auto emprisonner :p

                    Les pilotes sont un des pires type en ce qui concerne le risque sur tes libertés dans le cas où il s'agit de logiciel privateur.
                  • [^] # Re: PPC _not_ pwned

                    Posté par . Évalué à 2.

                    Rien ne t'empêche de rester à la dernière version du driver qui supporte ta CG.

                    si, il y a le noyau. A moins de rester sur un kernel antédiluvien, au bout de quelques mois, vouloir garder la dernière version du driver te force à ne plus utiliser le blob noyau, et donc à perdre les performances de ton vieux driver 3D qui marchait... donc soit pas de 3D, soit pas de noyau.
                    • [^] # Re: PPC _not_ pwned

                      Posté par . Évalué à 2.

                      Un noyau antédiluvien c'est un noyau qui a quelques mois ??!?

                      A quoi bon changer de noyeau/serveur X/... si les versions installées rendent le service attendu et sont stables ?

                      BeOS le faisait il y a 15 ans !

                      • [^] # Re: PPC _not_ pwned

                        Posté par . Évalué à 5.

                        Je crois qu'il parlait dans le cas où Nvidia abandonne une carte, t'es obligé de garder le noyau de l'époque de la dernière version du driver. Dans le cas des GeForce2, ça doit faire quelques années ...
                        • [^] # Re: PPC _not_ pwned

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

                          Je confirme. :-/

                          Même si la publication (irrégulière) du driver legacy permet parfois de "regagner" quelques versions du noyau.
                • [^] # Re: PPC _not_ pwned

                  Posté par . Évalué à 4.

                  Nvidia maintient son driver pour les cartes récentes, et effectivement les vielles cartes passent à la trappe.

                  Ca ne sert à rien de m'expliquer l'intérêt d'un driver libre, tu prêches un convaincu, je n'ai jamais évoqué le fait que ca ne servait à rien d'ailleurs.

                  Je maintient quand même que dans les faits quand tu veux une carte 3D récente et performante bien supportée (utilisable) sous linux x86, nvidia reste le meilleur choix.

                  C'est simplement incontestable.
                  • [^] # Re: PPC _not_ pwned

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

                    Oui, certes. Mais c'est le syndrome du "tout jetable". Cette carte récente top moumoute est bien supporté avec les drivers proprios, deux ans plus tard apu drivers proprio, je dois rester avec les anciens. Les nouveaux drivers apportent la techno wwyyzz qui fait ouizzz, et bien je dois racheter une carte alors que l'ancienne serait parfaitement capable de faire wwyyzz qui fait ouizzz si les drivers étaient ouverts... Ce qui n'est pas du tout de l'intérêt de NVidia pour vendre la nouvelle carte qui fait ouizzz.
                  • [^] # Re: PPC _not_ pwned

                    Posté par . Évalué à 2.

                    C'est clair qu'étant un joueur à mes temps libres le constat est simple c'est nvidia.

                    Certe c'est domage que ça ne soit pas libre etc, j'adore le libre vraiment, ça fait >10 ans que j'ai démarré sous linux, mais je sais rester pragmatique et savoir crier sur les drivers ati merdiques ou un téléphone certe libre mais moche, gros, chèr et auquel il manque des fonctionnalités. Bon ensuite si on voit l'achat de ce tél comme une donnation au libre pourquoi pas.

                    Mais pour revenir au driver, certe en étant pas libre personne ne pourra le modifier. Mais bon il ne faut pas se leurrer si tu achètes du nvidia sous linux c'est que tu est joueur, donc faut pas s'étonner que la Geforce 2 mx ne soit plus supporté au bout d'un moment.

                    La question est de savoir est-ce que la dernière version qui supporte la CG est suffisante ? Elle permet de lancer X, même d'avoir des bling bling effets sur les fenêtres, de jouer, le serveur X est stable, perso pour ma part j'ai parfois un plantage de X lorsque je joue.... une fois tout les 6 mois. Certe domage, pourrait-être mieux, mais au vu de ce que les autres proposent je bénis ces drivers.
                  • [^] # Re: PPC _not_ pwned

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

                    La trappe dont vous parlez, c'est le pilote legacy fourni par nVidia, n'est-ce pas ?

                    C'est une trappe qui a un fond, pas un goulp...
              • [^] # Re: PPC _not_ pwned

                Posté par . Évalué à 2.

                Voilà, c'est un peu ce que je reproche aux gens comme toi. D'être opportuniste. Bon, ça ne dérange pas certains, mais moi je n'aime pas trop ça.
                • [^] # Re: PPC _not_ pwned

                  Posté par . Évalué à 1.

                  Relis bien ce que j'ai écris, constates à quel point ta remarque est stupide.
                  A la limite tu peux aussi prendre un dictionnaire pour chercher opportuniste parce que je pense que tu ne saisis pas bien le sens du mot.
                  • [^] # Re: PPC _not_ pwned

                    Posté par . Évalué à 4.

                    Je réagissais surtout à cette phrase :
                    La situation changera peut être dans quelques années, et je serai parmi les premier à recommander ces cartes là si elles marchent bien, mais d'ici là je vois pas pourquoi s'embêter avec du matèriel peu exploitable.
                    Ce que je veux dire, c'est qu'aujourd'hui des développeurs s'évertuent à développer ce qu'ils peuvent avec des constructeurs coopératifs, et toi tu t'en fous parce que ce n'est pas "bleeding edge". Mais quand ils auront fini de galérer, tu n'hésitera pas une seconde à exploiter leur travail. C'est ce que j'appelle de l'opportunisme, même si toi tu appellera sûrement ça de la naïveté et du masochisme de la part de ces devs et des gens qui soutiennent leur travail.
                    • [^] # Re: PPC _not_ pwned

                      Posté par . Évalué à 1.

                      Ouai et tu préconises dont de continuer à galerer pour soutenir les entreprises qui soutienne le libre. Madame michou ou doit lui expliquer comment configurer le framebuffer de son ati, et d'activer 2 3 trucs dans /proc pour que son X se lance ? C'est ça ?

                      L'histoire nous prouve que si des gens libérent du code c'est surtout car ils ont perdu ou sont en train perdre à leur concurrent. Netscape par exemple. Lorsque via décide d'ouvrir ses specs sur ses chips graphique c'est bien car leurs parts de marché global est de 4.62% donc avoir ne serait que 1/20 de la communauté libre qui achète du via pour eux ça représente tout de suite une augmentation des ventes assez conséquente et visible.
                      Nvidia avec ses parts de marché ça le fait rire.

                      Oui je sais que au vu de ce que je viens de dire, la solution serait bouder ces entreprises pour qu'elles s'ouvrent. Potentiel de linux ? 2% dont beaucoup de serveurs et autres, desktop infime.

                      Bref je te laisse faire tes calculs et en tirer tes petites conclusions moi en attendant je vais aller dans le pays merveilleux de mickey mousse courrir tout nu dans un champs de blé, et même que les gens sont gentils et les épis brains de blé me carésseront délicatement les fesses.
                      • [^] # Re: PPC _not_ pwned

                        Posté par . Évalué à 2.

                        Si un linuxien, qui ne représente pas grand chose, choisi de prendre une ATI à la place d'une Nvidia, ça ne changera peut-être pas grand chose pour Nvidia, mais ça changera plus de choses pour ATI. Et à plus long terme, un meilleur support des ATI sous linux.
                        Et on n'a pas besoin d'expliquer quoi que ce soit à madame michu, parce qu'elle ne cherche pas de la 3D dernière technologie, mais un desktop qui marche, et ça c'est fonctionnel "out of the box" pour les ATI et Intel (avec un décalage de 6 mois maxi si tu n'utilises pas une distribution "unstable" pour les cartes super-récentes -- ce qui n'est généralement pas le cas des ordis destinés à mmde michu).

                        En fait, je ne comprend pas le but de ton commentaire. ATI sont des "loosers", et être un "looser" c'est "naze" ? C'est une histoire d'être à la mode, ou un truc comme ça ? Franchement, je ne te comprend pas.
                        • [^] # Re: PPC _not_ pwned

                          Posté par . Évalué à 2.

                          En fait dans le cas ou mme michu se retrouve avec une ATI pas trop vieille, elle se tapera le driver proprio quand son fils en aura marre de jouer a Xbill, c'est ca ou windows et une image de "linux ca marche pas" ...
                          • [^] # Re: PPC _not_ pwned

                            Posté par . Évalué à 4.

                            Madame Michu est moderne, elle joue à la DS pour devenir intelligente et elle a offert à son fils une Wii pour pouvoir tabasser des lapins crétins.

                            C'est dire si chez les Michu on se moque éperdument des drivers 3D pour carte graphique (et puis de toute façon y'a pas de jeux pour linux en vente au magasin)

                            BeOS le faisait il y a 15 ans !

                        • [^] # Re: PPC _not_ pwned

                          Posté par . Évalué à 1.

                          Non c'est d'avoir un truc qui marche bordel.

                          Ah et madame michou si si je t'assure, elle aime bien les trucs 3d. Y a qu'à voir la ou je bosse tout les gens qui me demandent si je peux pas leur installer vista car elles ont vu ça sur le portable d'une amie alors c'est trop bien elle veulent la même chose.

                          Ce ci dit j'ai arrêté d'être gentil. Marre de perdre du temps à faire plaisir au gens pour rien.

                          - Non mais Vista va pas tourner dessus, votre pc est trop ancien. Vous voulez linux ?
                          - Non non je veux Vista <comme tout le monde...> avec les fenêtres toutes jolies la.

                          Donc bon même si elles avaient voulue de linux, franchement je me serait même pas lancé si la CG était ATI. J'aime bien le libre, j'aime à le promouvoir, mais déjà que je fais pas mal d'à côté dans mon boulot pour rendre servir aux gens qui me ramenent en douce leurs machines, je ne vais non plus me tirer une balle dans le pied en leur foutant un linux pour qu'elles viennent me les briser car l'autre sécrétaire son bureau il est plus joli blahblah...

                          M'enfin tu fais comme tu veux, mais la politique de l'autruche est un non sens.

                          CG ati ? Ok passe ton chemin.
                          • [^] # Re: PPC _not_ pwned

                            Posté par . Évalué à 2.

                            Je n'ai jamais dit d'aller installer du linux partout ! Et je suis exactement comme toi, quand je sais qu'un matos est problématique, je préfère ne rien installer et laisser les gens sous windows.

                            Et les mme michu qui veulent des trucs 3D, je pense que c'est une minorité, même si c'est la minorité qui gueule le plus. Raison de plus pour ne pas aller se faire chier.
                        • [^] # Re: PPC _not_ pwned

                          Posté par . Évalué à 0.

                          Franchement après plus de 10 ans de linux, ça ne m'amuse plus du tout de perdre du temps à chercher pourquoi ma CG marche pas. Parfois appuyer sur DA Fucking button et que ça marche... oh putain c'est le pied

                          Ensuite que ati libére ou non le code raf, le driver merde il merde.

                          Et puis certe on peut louer les efforts des mecs du libre qui eux ce font chier à ce que ça marche, et c'est très bien et on les remercie de leur investissement, car moi même je n'aurait ni le temps ni les connaissances. Néanmoins je suis désolé tout comme un logiciel a un statut beta ou alpha qui le place d'emblé pour une catégorie très spécifique d'utilisateurs, les drivers ATI actuellement c'est des alpha, point. Donc exit madame michou.

                          Par contre dans quelques années oui je serait prêt à prendre du ATI.
                          • [^] # Re: PPC _not_ pwned

                            Posté par . Évalué à 2.

                            T'inquiètes, moi aussi je n'aime pas me prendre la tête (parfois) : j'ai passé quelques années sous OSX, et je sais le bonheur que c'est quand tout marche au poil.

                            Maintenant, pour les gens qui veulent s'épanouir dans le libre (c'est à dire : moi, et éventuellement une autre personne des mes connaissances : tu vois, je ne force personne), je préfère faire quelques efforts.

                            Et je ne sais pas pourquoi ATI a si mauvaise réputation pour toi : peut-être est-ce un souvenir des drivers fglrx ? Parce que généralement, c'est soit ça marche nickel, soit ça marche pas du tout.
                            • [^] # Re: PPC _not_ pwned

                              Posté par . Évalué à 4.

                              Ouai bah le souvenir du marche pas du tout, pourtant j'ai bien tout fait bien à l'époque. Je veux dire j'ai 10 ans de linux, j'ai une gentoo, je suis habitué à geeker. J'ai aussi des machines sun que je bidouille, jamais eu de problèmes pour arriver à tout faire marcher au poil. Mais ATI, jamais. Que des merdes et inexplicables. Bref j'ai laissé tombé. Acaht de CG nvidia, puis en une ligne sous gentoo j'ai j'ai installé les drivers, et en modifiant une ligne dans xorg, tout marchait. Bref.
                              • [^] # Re: PPC _not_ pwned

                                Posté par . Évalué à 3.

                                Bah, c'est peut-être parce que j'utilise que des cartes de "vieux", mais les R200 que j'ai utilisées ont toujours marché nickel. Et pas depuis récemment, depuis au moins 4 ans.
                      • [^] # Re: PPC _not_ pwned

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

                        Intel développe un pilote libre pour sa carte graphique et ils sont leader dans leur domaine (les cartes bas de gamme pour portable), donc ce n'est pas toujours vrai.

                        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                        • [^] # Re: PPC _not_ pwned

                          Posté par . Évalué à 1.

                          Le driver intel c'est bien quand ca marche mais c'est pas toujours ca non plus.
                          J'ai un pc qui freez quand X se ferme à chaque fois quelle que soit la distrib, et un qui as le DRI activé mais qui est a peine plus performant que l'acceleration software

                          Tout n'est pas rose
                          • [^] # Re: PPC _not_ pwned

                            Posté par . Évalué à 2.

                            Tout n'est pas rose

                            Dans ce domaine effectivement... nVidia est vert, ATI est rouge et Intel est bleu !
              • [^] # Re: PPC _not_ pwned

                Posté par . Évalué à 2.

                "même sur les vielles R300 ..."
                Si t'as pas besoin de jeux/compiz top moumoute le driver libre marche très bien, j'ai 1000 FPS à glxgears et openarena ne rame pas (et c'était il y a 6 mois) .
            • [^] # Re: PPC _not_ pwned

              Posté par . Évalué à 2.

              Non il l'utilisait proprio et même que c'était sous MS-DOS j'en suis sûr!
      • [^] # Re: PPC _not_ pwned

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

        Ça change vite ces choses-là : sur Phoronix, les Radeon 48xx sont devant les NVIDIA en haute qualité : http://feeds.feedburner.com/~r/Phoronix/~3/325771980/vr.php

        ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

      • [^] # Re: PPC _not_ pwned

        Posté par . Évalué à 3.

        Mhh...... Je voudrais pas dire, mais quelles sont les seuls cartes qui "supportent" pas mal de fonctionnalités "out of the box" ? Celles qui ont un driver libre et dont le constructeur a été coopératif. Même pas besoin d'installer un driver quelconque, il est déjà dedans.
        Quant à triturer X pendant des heures, pour les drivers déjà intégrés upstream, rien à faire, et nouveau m'a permis de faire marcher ma Nvidia en très peu de temps avec pas mal de fonctionnalités (multi-écran dynamique, accélération XV, etc ...). Pas de 3D, certes, mais de toutes façons nous n'avons pas les même objectifs et je ne pense pas qu'on arrivera à se comprendre ...
        • [^] # Re: PPC _not_ pwned

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

          Pas de 3D ? Les cartes Intel fonctionnent out of the box, avec 3D !
          • [^] # Re: PPC _not_ pwned

            Posté par . Évalué à 2.

            Je voulais parler de nouveau pour le "pas de 3D", désolé de la mécompréhension.
        • [^] # Re: PPC _not_ pwned

          Posté par . Évalué à 3.

          J'ai quelques cartes VGA isa dans un coin qui répondent surement à tes critères :)

          Je pense quand même que la majorité des gens qui ont investi 150€ dans une carte graphique se sentiraient un peu frustré si ils n'arrivent pas à lui faire sortir quelques polygones
          • [^] # Re: PPC _not_ pwned

            Posté par . Évalué à 0.

            Oui enfin je ne t'en veux pas que tu n'aies rien compris aux principes du libre (d'ailleurs c'est le principe du libre, de le laisser utiliser même à ceux qui ne le comprennent pas), mais j'ai déjà ce qu'il faut chez moi.
            • [^] # Re: PPC _not_ pwned

              Posté par . Évalué à 0.

              Un peu de pragmatisme et de recul te feraient le plus grand bien.
              Je ne t'en veux pas, moi aussi il y a 10 ans je postais des messages comme ça sur les forums.
              • [^] # Re: PPC _not_ pwned

                Posté par . Évalué à 5.

                C'est dommage de partir sur le postulat que les jeunots deviendront un jour matures. Au vu du succès rencontré par skyblog et ce même auprès d'une population de plus en plus agé, il faut bien se rendre à l'évidence, certains cas sans malheureusement irrécupérables.
              • [^] # Re: PPC _not_ pwned

                Posté par . Évalué à 3.

                Ton "pragmatisme" j'appelle ça de la facilité.

                Quand tu parles des gens qui veulent exploiter les capacités de leur carte graphique, il y a un certain prix pour être libre : y passer un peu de temps, quand on utilise une cart encore supportée expérimentalement. Après, quand on achète du matériel dont on sait très bien à l'avance qu'il ne marchera pas avec du libre, j'estime que c'est aller contre l'élan du libre ; d'autant plus quand on l'utilise avec des drivers proprios sous linux. En fait, je pense que c'est plus le coté "pub" qui me dérange : "achetez du Nvidia pour jouez à vos jeux sous linux, c"est génial". Et aussi parce que quand je parle de linux, je fais souvent un raccourci avec "libre" (honte à moi !).

                Et merci pour le ton condescendant mais ce n'est pas parce qu'on défend le libre tant que faire se peut qu'on est un "petit jeune" du domaine.
                • [^] # Re: PPC _not_ pwned

                  Posté par . Évalué à 1.

                  J'espère seulement que tu es conscient que c'est pas en disant aux gens "si vous voulez de la 3D qui marche prenez une carte obsolete ou pas performante" que tu vas populariser linux.
                  Ca vaut le coup à ton avis de priver les gens d'une expèrience agréable sur un des meilleurs systèmes concus jusqu'à présent à cause d'un pauvre module proprio qui doit représenter 0.01% du code qui tourne et que personne ne voit ?
                  Dans ce cas là utilises plus internet, je suis quasiement sur que tes paquets passent par des programmes de routages fermés.
                  • [^] # Re: PPC _not_ pwned

                    Posté par . Évalué à 2.

                    Voilà, on en fini toujours par le même problème : non, mon but n'est pas de populariser linux. C'est de libérer les gens qui le souhaitent.

                    Et ton "pauvre" module proprio, c'est par là que passe une bonne partie de l'information que tu utilises tous les jours.
                    Et pour Internet, ce n'est pas mon matériel, il ne m'appartient pas, je n'irai donc pas faire de commentaires sur le choix de leurs propriétaires.
                  • [^] # Re: PPC _not_ pwned

                    Posté par . Évalué à 2.

                    Je crois que si je dis à quelqu'un que moins le matériel est cher mieux son PC fonctionnera sous Linux il serait rudement curieux d'essayer Linux !

                    BeOS le faisait il y a 15 ans !

                    • [^] # Re: PPC _not_ pwned

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

                      Pas forcément, notamment pour des joueurs/frimeurs/victimes de la mode..., il peut y avoir une réaction du genre : « Bah, c'est un système d'exploitation pour bouses, donc c'est bas de gamme. »

                      Mais bon, en même temps, j'ai envie de dire, qu'est-ce qu'un joueur victime de la mode irait bien faire sous Linux ? Apprendre à penser par soi-même d'abord, non ?
  • # 32 bits

    Posté par . Évalué à 2.

    Une petite question... Pourquoi Xorg ne supporte pas le 32 bits alors qu'il l'est sous Windows et qu'il y a même écrit "true color" à côté... Cela voudrait-il dire que les couleurs en 24 bits que je vois avec Xorg ne seraient pas vraies ???
    • [^] # Re: 32 bits

      Posté par . Évalué à 10.

      En fait, sous Windows, les 32 bits, c'est 3*8 bits pour la couleur, et 8 bits de canal alpha.
      Donc, que tu aies 24 ou 32 bits, tu as le même nombre de couleurs. Y a juste la transparence est présente ou non.
      • [^] # Re: 32 bits

        Posté par . Évalué à 2.

        Je comprends mais j'ai du mal à comprendre :)...

        Ils sont où les 8 bits du canal alpha vu que Xorg gère la transparence, c'est juste qu'ils ne sont pas spécifiés comme sous Windows mais qu'ils sont bien présents ? Et admettons que je n'en veux pas, comment les désactiver ?

        Pour activer la transparence je connais 2 méthodes soit anciennement l'option RENDER ou maintenant l'option Composite. Pour RENDER je ne sais pas mais Composite ça passe par de l'OpenGL non ? L'utilisation d'OpenGL est-il vraiment nécessaire pour gérer la transparence ? Non, puisque que je peux visualiser mais images PNG par exemple sans avoir Composite activé...

        Enfin bref, comment est gérée la tranparence ? :)

        En revanche, un gros problème persiste : le serveur X et le noyau Linux cherchent à dialoguer avec la carte graphique.

        Sinon, j'attend avec impatience la résolution de ce problème afin d'avoir un joli fondu quand je switch entre les terminaux et l'interface graphique par exemple... Parce que les flashs au démarrage, c'est pas très esthétique comme dit dans l'article...
        • [^] # Re: 32 bits

          Posté par . Évalué à 4.

          je peux visualiser mais images PNG par exemple sans avoir Composite activé...
          Ça n'a pas grand chose à voir. Le PNG transparent, c'est géré par le moteur de rendu du logiciel. Mettons un PNG transparent sur un fond rouge, ben, au final, les pixels sont bien visibles et rouges. Si tu as le même PNG, uniquement transparent, ben, ça dépend des logiciels. Firefox rendra des pixels blancs. Eye of gnome placera un damier gris derrière.
          Bref, en aucun cas, la fenêtre n'envoie des pixels transparents à Xorg (Ça n'a pas trop de sens, sauf à faire des fenêtres avec des trous anti-aliasés -Faut déposer un brevet là-dessus-)
          C'est pour ça qu'en tant que tel, avoir 8 bits de canal alpha, c'est un peu gâcher de la place pour pas grand chose. Sauf, éventuellement à faire de la transparence entre les fenêtres, où là, ça peut être nécessaire.
          • [^] # Re: 32 bits

            Posté par . Évalué à 2.

            Sauf, éventuellement à faire de la transparence entre les fenêtres, où là, ça peut être nécessaire.
            Ce que fait Composite il me semble, puisqu'il utilise 32bits afin de gérer les jolis effets. Quant aux fenêtres transparentes, ça existe déjà, il y avait un thème GTK qui est sorti récemment qui implémentais la transparence de certains widgets.
            De toutes façons, comme tu le dis, 24/32 c'est la même chose, c'est juste la gestion de la transparence qui change.
        • [^] # Re: 32 bits

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

          RENDER est une extension qui permet d'accélérer l'opération de composition (composite).

          Il est tout à fait possible d'accélérer l'opération Composite sans utiliser OpenGL, c'est typiquement ce que fait EXA.

          Et donc on peut avoir des ombres et de la transparence (par exemple) sans openGL.
    • [^] # Re: 32 bits

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

      Autant que je sache, au niveau de l'affichage final, le quatrième octet ne sert à rien. Ça n'a aucun sens, un canal alpha sur l'écran. :-)

      Non, je crois que ces couleurs sur 32 bits sont en fait sur 24, avec 8 bits en plus parce que calculer en 32 bits, c'est plus facile pour nos processeurs.
    • [^] # Re: 32 bits

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

      Toute manière tu auras bien du mal à faire la différence entre des images avec 2^24 et et 2^32 couleurs, étant donnée que ton oeil ne peux percevoir qu'un ensemble limité du spectre lumineux. Cela dit, je crois que tu peux en percevoir un peu plus que 2^24, mais bon c'est à vérifier.
      • [^] # Re: 32 bits

        Posté par . Évalué à 4.

        Il faut préciser quand même : _aucun_ système grand public actuel n'affiche au final plus de 2^24. Le 32bits, c'est pour parler de comment vont être "compostées"/"blendées" les couleurs, qui au final sur l'écran seront en 24bits (enfin, avant l'affichage par le LCD qui va surement encore diminuer la précision).
        • [^] # Re: 32 bits

          Posté par . Évalué à 2.

          De plus, l'oeil humain est limité, je ne suis pas certain qu'on puisse vraiment distinguer plus de 96.000 couleurs voir http://francoisg.ifrance.com/rubriks/trucs/couleurs/couleurs(...)

          Les daltoniens c'est encore moins.
          • [^] # Re: 32 bits

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

            Ouais bof, citer un nombre comme ça sans source, ça vaut rien.

            Et puis avec seulement 256 niveaux de gris, on peut arriver à voir le passage de l'une à l'autre sur de grands à-plats, donc 24 bits c'est pas assez.

            Et enfin, même avec 24 millions de combinaisons, les écrans sont incapable d'afficher tout le gamut perceptible par l'œil, il y aura toujours des couleurs irreproductibles.
  • # je suis trop vieux ?

    Posté par . Évalué à 9.

    [...] le serveur X venait accompagné d'utilitaires d'un autre temps dont la plupart des distributions modernes n'avait plus besoin : des xterm [...]

    Et dire que je travaille avec des xterm à longeur de journée. Je n'ai jamais compris l'interêt des konsole ou gnome-terminal, c'est plus lent, les raccourcis 'classiques' ne fonctionnent plus ... xterm est rapide et ne dépend d'aucun wm ... en fait, xterm c'est indispensable.
    • [^] # Re: je suis trop vieux ?

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

      Yes ! Copaing !

      Vive xterm et fluxbox !
      • [^] # Re: je suis trop vieux ?

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

        Moi, je préfère rxvt (urxvt en fait). Parmi les "xterm" que j'ai essayés (aterm, eterm, kterm, xterm, xfterm, konsole, gnome-terminal, iTerm, Terminal), c'est urxvt que je préfère parce qu'il est raisonnbalement rapide, il a des features qui pétent (genre iso14755, ou les caractères unicode). Le pire état gnome-terminal qui affiche des séquences qu'il n'est pas censé afficher et qui me rattrappe des raccourcis clavier parce qu'il croit savoir mieux que moi ce que je veux faire.
    • [^] # Re: je suis trop vieux ?

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

      Arf, je n'avais pas lu ce passage-là, visiblement. XTerm, pas utile ! Ça ne va pas, non ? :-)
    • [^] # Re: je suis trop vieux ?

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

      en fait, xterm c'est indispensable.

      On peut aussi rajouter dans la liste des "gadgets": xclock, bitmap, xfontsel, xcalc, xcolorsel, et plein d'autres auxquels on ne pense pas toujours. Je vous invite à compléter la liste de ces trucs d'un autre age...

      Par contre, c'est vrai que xeyes ne correspond plus trop aux standards blingbling du troisième millénaire...

      * Ils vendront Usenet^W les boites noires quand on aura fini de les remplir.

    • [^] # Re: je suis trop vieux ?

      Posté par . Évalué à 7.

      En fait non, xterm serait plutot parmi les plus lent :
      http://martin.ankerl.com/2007/09/01/comprehensive-linux-term(...)
      • [^] # Re: je suis trop vieux ?

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

        Je pense que dans ton benchmark (qui est très interressant pour comparer les preformances brutes d'un terminal) il manque un calcul de temps de démarrage.

        Si on veut se servir d'un terminal histoire de lancer 3-4 scripts tout fait. Je pense qu'utiliser xterm est un bon compromis entre performance brute et dépendances/temps de démarrage.

        L'avantage d'utiliser xterm vient aussi par l'habitude, exemple:
        tu veux dépanner un pote, tu n'as pas besoin de t'adapter à son envirronment de bureau tu lance juste xterm (tu est sur qu'il est installé) et tu fait ce que tu veux.

        Ceci dit si tu utilise un environnement qui te procure un terminal plus adapté (ergonomie, consommation mémoire, etc...) utilisons le.
        • [^] # Re: je suis trop vieux ?

          Posté par . Évalué à 3.

          > tu lance juste xterm (tu est sur qu'il est installé)

          # xterm
          # bash: xterm: command not found

          On doit pas utiliser les mêmes distribs.

          --> []
          • [^] # Re: je suis trop vieux ?

            Posté par . Évalué à 3.

            C'est normal, ta distribution veut pas que tu lance une application graphique en tant qu'administrateur .
            ---------> []
      • [^] # Re: je suis trop vieux ?

        Posté par . Évalué à 3.

        En fait on peut faire dire ce qu'on veut à un bench. En l'occurence, celui ci dit que quand il s'agit de faire défiler de grandes quantités de données le plus vite possible, alors gnome-terminal est efficace. Ceci dit, ça dépend des fichiers : ttp://nowwhatthe.blogspot.com/2007/10/konsole-performance.html . Et à côté de ça, pour des opérations bien plus simples et courantes: http://linuxfr.org/~schyzomarijks/12617.html#410615
        Donc voilà, je persiste.
      • [^] # Re: je suis trop vieux ?

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

        M'en fous, c'est le meilleur émulateur de terminal. Quand tu te connectes à une machine qui s'attend à avoir une vraie VT510 en face, tu es content d'avoir XTerm.
    • [^] # xterm vs reste du monde

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

      xterm est rapide à lancer, mais c'est tout. Il n'y a pas de barre de défilement : pratique pour savoir où on en est dans l'historique (SHIFT+page haut/bas permet toujours de relire l'historique). Il n'y pas d'onglet : pratique pour gagner de la place sur le bureau (gnome-terminal conserve le dossier courant quand on ouvre un onglet, malin et pratique). Le rendu des polices est moche (gnome-terminal et konsole c'est des polices TrueType avec anti-aliasing fin).

      On peut *facilement* changer le thème de couleur, changer la taille de la police, le jeu de caractères, la méthode pour notifier les bips, changer la disposition du clavier, etc. On peut facilement configurer la taille de l'historique et en particulier choisir un historique illimité. On peut faire une recherche dans l'historique. Le copier/coller Gnome/KDE fonctionne (clic-droit : coller), différent du clic central.

      Et enfin, le meilleur, on peut se créer des profils. C'est comme comparer fluxbox et KDE. Ok, fluxbox est rapide à se lancer, mais il n'y pas de navigateur web, client de messagerie, ... intégrés au bureau.

      Konsole se lance en une seconde ici. La création d'un onglet est instantanée.
      • [^] # Re: xterm vs reste du monde

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

        xterm a des barres de défilement, mais tu risque de pas les aimer. ;-)

        Le rendu des polices est basé sur Freetype et il supporte donc les polices TrueType avec anti-aliasing (même si pour un terminal, je préfère utiliser une police bien hintée). Il est facile de basculer entre les tailles de police préréglées (shift+plus, shift+moins), moins agréable d'éditer cette liste (enfin bon, c'est rien qu'un fichier de conf). La taille de l'historique se règle en un coup de vi également, même si elle n'est pas vraiment illimitée rien n'empêche de mettre une "grosse" valeur.

        Pour l'encodage et le clavier, c'est moins évident (j'ai moins pratiqué, surtout).

        Et pour le reste, bah non, XTerm n'a pas. Mais on s'en fout, il est très bien comme ça. :-)
      • [^] # Re: xterm vs reste du monde

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

        Le rendu des polices est moche

        Ça dépend des goûts, mais au moins, la police par défaut d'XTerm, elle contient plus de caractères qu'aucune autre.
      • [^] # Re: xterm vs reste du monde

        Posté par . Évalué à 2.

        La feature qui me manque lorsque j'utilise xterm, c'est la surveillance de l'activité/inactivité de konsole. ça m'évite de surveiller mon terminal pour attendre un résultat...

        Mais lorsque j'ai juste besoin d'un terminal pour moins de dix secondes, xterm suffit (et je l'utilise actuellement)
  • # corrections

    Posté par . Évalué à 5.

    Avec une telle dépêche,il serait dommage de laisser quelques perles

    développement du bazard
    d'un autre temps dont la plupart des distributions modernes n'avaient plus besoin :
    à un niveau de finisstions

    Très intéressant en tout cas
    • [^] # Re: corrections

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

      J'ajouterais :

      "Linus Torvald a plusieurs fois exprimé sont opinion à ce sujet"

      "Certains types d'applications pourraient très bien se passer de la couche de communication du serveur X (téléphonie, GPS, embarqué etc)."

      "ce mécanisme aux autres types de carte (ATI et Nvidia)."

      En tout cas, merci pour cette belle dépêche, très intéressante quand on ne suit pas de près le développement de ce projet :)
  • # intro

    Posté par . Évalué à -4.

    on aurait pu se passer de l'intro larmoyante. Gardez ça pour vos skyblogs.
    • [^] # Re: intro

      Posté par . Évalué à -2.

      t'as vraiment un probleme avec les skyblogs toi

      faut arreter la fixette
  • # Merci pour cette dépêche, je rebondis...

    Posté par . Évalué à 5.

    Idée excellente que cette dépêche car je vais enfin pouvoir poser la question qui me taraude depuis que j'uilise Linux (3 ans).

    Est ce que vraiment faire une image de ce qui doit être affiché et l'envoyer via un socket sur un serveur qui lui va l'envoyer à la CG n'est pas un peu obsolète aujourd'hui ?

    Il me semble, merci de me corriger si je me trompe, que cela a été pensé il y a bien longtemps du temps des terminaux déportés.

    Ne gagnerait on pas énormément en performances et en ressources en faisant ce que font Windows et Mac : une couche graphique au plus près du matériel ?

    J'ai osé poster cette idée sur le "brainstorm" Ubuntu, autant dire que je me suis fait pourrir par les intégristes Unixiens de tout poils. Mais je persiste, sans compter tous les aspects où Linux est en retard (gestion à chaud des changements de paramètres, gestion des profils couleurs...).
    • [^] # Re: Merci pour cette dépêche, je rebondis...

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

      Tu a calculé la bande passante des sockets locales ?

      De toute façon ce truc "obsolete" te permet plus de chose et plus facilement que les système "plus près du matériel" donc ce serait stupide de s'en séparer. Surtout que les terminaux X et l'affichage
      déporté d'applications, n'en déplaise a certains c'est toujours très utilisé.

      Ensuite quand on voit les perfs que sont capables de tirer enlightenment sur le système 2D, ou les jeux natif 3D je ne vois pas de raison de changer.

      Les plus gros soucis de perfs et de resources des applications X11 sont plus souvent lié à l'utilisation de N couches de toolkits et autres abstractions qu'au dispositif X11 en lui même
      • [^] # Re: Merci pour cette dépêche, je rebondis...

        Posté par . Évalué à 1.

        Non je n'ai rien calculé.

        Bien évidemment ma remarque ne compte que dans une optique "Linux sur le poste de travail de tout un chacun", et dans cette optique, ça me fait un peu l'impression d'utiliser un bazooka pour écraser une mouche le serveur X.
      • [^] # Re: Merci pour cette dépêche, je rebondis...

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

        Surtout que les terminaux X et l'affichage
        déporté d'applications, n'en déplaise a certains c'est toujours très utilisé.


        Je plussoie vigoureusement. Ici chez moi: deux machines ont un écran et font aussi TX, et derrière j'ai huit autres machines qui servent à des trucs variés. Et quand aux performances, même sur un réseau un peu chargé, ça reste dans la plupart des cas très utilisable. Il faut dire que pour les games, j'ai un SMS, une SNES, une GB et une GC, donc pas de jeux sur les ordinateurs en gros. casser l'architecture client-serveur du X11 serait à la fois un troll bien glauque et une énorme erreur stratégique.

        * Ils vendront Usenet^W les boites noires quand on aura fini de les remplir.

        • [^] # Re: Merci pour cette dépêche, je rebondis...

          Posté par . Évalué à 2.

          D'autant que certains trucs sont prévus pour fonctionner avec un export de l'affichage...

          ... parce que bon... configurer mon Mythbackend sans exporter le clickodrome, soit ça me force à avoir un X.org complet dans un des conteneurs de l'un de mes serveurs (beurrrk), soit à mettre les mains dans une base mysql (beurrrk)...
    • [^] # Re: Merci pour cette dépêche, je rebondis...

      Posté par . Évalué à 2.

      Un avantage de ne pas faire comme Apple et Microsoft, c'est de ne pas être obligé d'installer et d'utiliser un environnement graphique.

      Pour ce qui est des perfs, a moins de de passer son temps a mesurer les FPS, Xorg ne se caractérise pas par une lenteur extravagante.

      Quant à l'architecture client/serveur, même s'il elle date, en quoi est-elle si mauvaise que cela ?
    • [^] # Re: Merci pour cette dépêche, je rebondis...

      Posté par . Évalué à 2.

      J'ajoute que la gestion des profils couleur existe => dispwin
      • [^] # Re: Merci pour cette dépêche, je rebondis...

        Posté par . Évalué à 3.

        Moi aussi j'utilise un truc dans le genre "xcalib" :
        - faut récupérer les sources,
        - faut recompiler,
        - faut que le driver graphique supporte la chose
        - dès qu'on modifie un truc dans le Xorg.conf, faut le redémarrer.

        Bref c'est l'âge de pierre des interfaces, désolé.

        Mais ta remarque "c'est de ne pas être obligé d'installer et d'utiliser un environnement graphique" est très juste et je ne serais pas vraiment surpris que le problème vienne de là : on veut tout faire faire à Linux, du serveur sans interface au poste de travail et fatalement, on se retrouve donc sur le plus petit dénominateur commun à toutes ces utilisations.
        • [^] # Re: Merci pour cette dépêche, je rebondis...

          Posté par . Évalué à 4.

          Moi aussi j'utilise un truc dans le genre "xcalib" :
          - faut récupérer les sources,
          - faut recompiler,

          Effectivement, si c'est pas dans les dépôts de ta distrib... mais bon tu ne doit pas être obligé de le recompiler tout les jours non plus.

          - dès qu'on modifie un truc dans le Xorg.conf, faut le redémarrer.
          J'imagine que cela va changer a moyen terme. Il me semble avoir lu quelques part que l'un des objectif de Xorg était de ne plus dépendre d'un fichier de config et de pourvoir déteminer la config dynamiquement.
          Pour le moment, on payes encore les errances du projet Xfree, mais il y a eu beaucoup d'avancées.

          Bref c'est l'âge de pierre des interfaces, désolé.
          Certes, certaine parti de l'architecture ne sont pas vraiment au top. Mais je le redis : Le projets Xfree a laissé quelques séquelles.
    • [^] # Re: Merci pour cette dépêche, je rebondis...

      Posté par . Évalué à 5.

      Est ce que vraiment faire une image de ce qui doit être affiché et l'envoyer via un socket sur un serveur qui lui va l'envoyer à la CG n'est pas un peu obsolète aujourd'hui ?

      Naaaannn !
      Ca permet de faire des chouettes export display pour faire tourner des applis distantes, éventuellement dans un tunnel ssh, sur ton serveur X local, et ça, c'est bien =)
    • [^] # Re: Merci pour cette dépêche, je rebondis...

      Posté par . Évalué à 10.

      Des gens plus compétents que moi et très impliqués sur le sujet (au hasard, Keith Packard) ont conclu que le problème des sockets était un non-problème avec très peu d'overhead. L'overhead est ailleurs (apparemment, la nature de la XLib, ses appels bloquants et son caching inapproprié seraient davantage problématiques, d'où l'apparition de XCL/XCB). j'ajoute que sur une machine locale, il s'agit de sockets UNIX et que l'extension XSHM permet d'utiliser de la mémoire partagée (donc d'éviter les transfert que tu décris). Même les projets destinés à l'embarqué (comme feu PicoGUI ou les plus actuels Xynth/XFast) utilisent une architecture client/serveur comparable.

      Par contre, j'ai tendance à être pas mal de l'avis de John Smirl (qui critiquait les efforts placés dans EXA dans la mesure où tous les chips actuels ont des capacités 3D, et qui préconisait +/- une couche d'abstraction 100% EGL/OpenGL à la place, surtout que les avancées d'OpenGL (shaders...) permettent d'imaginer des applications inconcevables par le passé, au hasard http://alice.loria.fr/publications/papers/2005/VTM/vtm.pdf ).

      L'architecture de DirectFB 2.0 semble aussi s'orienter vers l'utilisation de backends (comme OpenVG) exploitant davantage l'accélération matérielle http://directfb.org/wiki/index.php/DirectFB_2.0:_Efficient_2(...)
      • [^] # Re: Merci pour cette dépêche, je rebondis...

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

        La plupart des implémentations d'EXA (Radeon et Nouveau au moins, je sais pas pour Intel) sont faites en programmant directement le moteur 3D de la carte. Et si j'ai bien tout compris, ça permet d'éviter d'avoir à lancer toute la machinerie OpenGL pour faire de la 2D.
    • [^] # Re: Merci pour cette dépêche, je rebondis...

      Posté par . Évalué à 2.

      Est ce que vraiment faire une image de ce qui doit être affiché et l'envoyer via un socket sur un serveur qui lui va l'envoyer à la CG n'est pas un peu obsolète aujourd'hui ?

      Ca n'est plus fait comme ça depuis longtemps : xorg utilise la mémoire partagée unix (shm, etc...) pour transmettre les grosses données lorsque c'est possible (Utilisation en local, activation des modules kivonbien, etc).
      • [^] # Re: Merci pour cette dépêche, je rebondis...

        Posté par . Évalué à 2.

        Dans un debat sur OSNews sur le même sujet, un lecteur m'a dit que shm était incompatible avec l'accélération matérielle, ce qui est un probleme..

        J'avoue avoir un peu de mal a comprendre comment ça marcherait un bureau avec une acceleration materielle si le client fait le rendu de l'image..

        J'ai lu que de plus en plus une grosse partie du rendu est faite par le client X (le programme), mais il faudrait que le programme client puisse faire le rendu en utilisant l'acceleration materielle (et idealement directement dans la mémoire de la carte graphique si l'affichage est local) et ensuite passe une reference vers l'image au serveur X qui idéalement utiliserait aussi l'acceleration materielle pour composer ces image dans le rendu final mais
        1) tous les clients et le serveur partageant la carte graphique: ça ne pose pas un probleme? Au départ, les cartes graphique avaient 'un seul maitre' pour l'acceleration 3D il me semble.
        2) j'ai l'impression que si le serveur X compose des 'images' fourni par le client, au niveau rendu des fontes ça risque d'être l'horreur: pas de possibilité de faire de l'anti-aliasing propre tant que tu ne connais pas ton positionement par rapport aux pixels (tant que le DPI des écrans reste assez faible :-( ).

        Ce n'est pas clair tout ça pour moi..
        Je ne comprends pas bien pourquoi on parle d'image fourni par le client: si le client fournissait des vecteur et du texte a la place d'image (ce que fait Cairo il me semble non?), le rendu et la composition étant fait par le serveur, ces problemes la disparaitraient non?
        • [^] # Re: Merci pour cette dépêche, je rebondis...

          Posté par . Évalué à 2.

          [...] il faudrait que le programme client puisse faire le rendu en utilisant l'acceleration materielle (et idealement directement dans la mémoire de la carte graphique si l'affichage est local)

          Si l'affichage est déporté, il n'y a aucun moyen que l'application utilise la carte graphique !
          Maintenant, lorsqu'une application (ou un toolkit graphique) veut utiliser l'accélération matérielle, elle utilise l'api OpenGL en court-circuitant le serveur X. Donc il est impossible d'utiliser openGL en affichage déporté (sauf bidouille, mais cela n'aurait aucun intéret de tt façon).

          et ensuite passe une reference vers l'image au serveur X qui idéalement utiliserait aussi l'acceleration materielle pour composer ces image dans le rendu final
          C'est à peu de choses près ce qu'il se passe actuellement. Lorsque le serveur X est en mode RenderAccel (EXA, XAA,...), il utilse des optimisations implémentées par le pilotes de la CG. On peut aussi utiliser un composeur (?) style compiz qui utilise le contexte OpenGL de la cg.

          1) tous les clients et le serveur partageant la carte graphique: ça ne pose pas un probleme? Au départ, les cartes graphique avaient 'un seul maitre' pour l'acceleration 3D il me semble.
          C'est toujours le cas et ce n'est pas près de changer. C'est la même chose que faire du multi-tâche alors qu'on a qu'un seul CPU: il faut le partager entre les applications en sauvegardant/restaurant leur contexte respectif.

          j'ai l'impression que si le serveur X compose des 'images' fourni par le client, au niveau rendu des fontes ça risque d'être l'horreur: pas de possibilité de faire de l'anti-aliasing propre tant que tu ne connais pas ton positionement par rapport aux pixels (tant que le DPI des écrans reste assez faible :-( ).
          Étant donné que l'on n'a pas encore inventé les pixels quantiques, l'image envoyée par le client sera toujours alignée sur un pixel (logique, non ?). L'AA est fait par le client, s'il veut que sont image puisse être composée, il n'a qu'à y avoir des pixels (semi-)transparents...

          Je ne comprends pas bien pourquoi on parle d'image fourni par le client: si le client fournissait des vecteur et du texte a la place d'image
          Le protocol X permet cela mais ces instructions restent basiques.

          (ce que fait Cairo il me semble non?),
          Non, justement c'est à cairo que l'on demande de dessiner des formes vectorielles dans un pixmap, que l'on envoit ensuite au serveur X. Imagine le temps qu'il faudrait pour redessiner ton écran si à chaque refresh X devait se taper le rendu d'une description vectorielle au lieu d'une faire une bête copie binaire. Ce serait aussi la voie vers une explosion de la complexité du protocol X (il faudra une nouvelle version du protocole à chaque fois que tu voudrais utiliser un nouveau type de flou ?!).

          le rendu et la composition étant fait par le serveur, ces problemes la disparaitraient non?
          À quels problèmes fait tu références ?
          L'avantage de cette architecture c'est que le rendu et la composition sont effectués par ceux qui sont le mieux disposés à le faire. Et avec un compositeur style compiz, on arrive même à masquer la latence engendrée lorque le serveur X demande à une fenêtre de se redessiner.
          • [^] # Re: Merci pour cette dépêche, je rebondis...

            Posté par . Évalué à 3.

            >>Si l'affichage est déporté, il n'y a aucun moyen que l'application utilise la carte graphique !<<

            Aucun moyen dans l'implementation actuelle, pas dans l'absolu:
            -le client pourrait utiliser sa carte graphique pour accelerer un rendu sans l'afficher, recopier l'image en mémoire principale (raisonnable depuis PCI Express pour des rendus complexes) puis l'envoyer au serveur
            -si le client envoyait des vecteurs ou des commandes OpenGL au serveur, le rendu serait fait par le serveur: j'ai bien compris que ce n'est pas le cas a l'heure actuelle, mais 'aucun moyen' n'est pas correcte.

            >>mais cela n'aurait aucun intéret de tt façon<<
            Bin la bande passante utilisée pour envoyer des vecteur ou des commandes OpenGL est tres inferieure a celle utilisée pour envoyer des images donc dans certaines conditions (assez limitée d'accord), cela pourrait être interressant.

            >>Étant donné que l'on n'a pas encore inventé les pixels quantiques, l'image envoyée par le client sera toujours alignée sur un pixel (logique, non ?).<<

            Certes mais si la composition decale l'image d'une quantité non-entiere, le mapping des pixels n'est plus valable non?

            >>Non, justement c'est à cairo que l'on demande de dessiner des formes vectorielles dans un pixmap, que l'on envoit ensuite au serveur X.<<
            Oui j'avais oublié ça, mais ça veut dire que cairo ne peut pas utiliser l'acceleration materielle alors???

            >>Imagine le temps qu'il faudrait pour redessiner ton écran si à chaque refresh X devait se taper le rendu d'une description vectorielle au lieu d'une faire une bête copie binaire.<<
            Bof, le serveur pourrait cacher le rendu je ne vois pas ou est le probleme.

            >>Ce serait aussi la voie vers une explosion de la complexité du protocol X (il faudra une nouvelle version du protocole à chaque fois que tu voudrais utiliser un nouveau type de flou ?!).<<

            C'est effectivement le gros probleme..
            • [^] # Re: Merci pour cette dépêche, je rebondis...

              Posté par . Évalué à 1.

              Aucun moyen dans l'implementation actuelle, pas dans l'absolu:
              -le client pourrait utiliser sa carte graphique pour accelerer un rendu sans l'afficher, recopier l'image en mémoire principale (raisonnable depuis PCI Express pour des rendus complexes) puis l'envoyer au serveur
              -si le client envoyait des vecteurs ou des commandes OpenGL au serveur, le rendu serait fait par le serveur: j'ai bien compris que ce n'est pas le cas a l'heure actuelle, mais 'aucun moyen' n'est pas correcte.


              Merci de me lire correctement, tout est toujours possible mais cela vaut -il réellement la peine ? ;)
              Je te ferais remarquer aussi que la BP des cartes graphiques ne fait qu'augmenter. On ne fait pas qu'envoyer des "commandes vectorielles" à un CG, on y copie aussi des structures et des textures. Si tu parcours les liens donnés dans cet articles, tu te rendras compte que le problème de copier des données dans la cg de manière efficace est primordial. Ajoute y l'over-overheard d'un réseau et c'est à peine si tu peux encore jouer à pong.
              Dans ton idée (rappel, opengl permet de faire du rendu temps-réel, ie affichier le plus d'images possibles par secondes), ce qu'il te faut c'est pas le protocole X mais un protocole de streaming vidéo + un mesa qui permet au client d'utilise une carte graphique.
              Note: le fait d'utiliser un client déporté n'empêche pas le serveur X de faire du composing accéléré (cf. compiz).

              Certes mais si la composition decale l'image d'une quantité non-entiere, le mapping des pixels n'est plus valable non?
              gni !? Comment fais-tu pour décaller une image d'un demi-pixel ? (hint: dépose un brevet, ça a l'air intéressant... (o: )

              mais ça veut dire que cairo ne peut pas utiliser l'acceleration materielle alors???
              Il peut faire comme tout le monde et utiliser OpenGL (comme QT le peut, je pense).

              Bof, le serveur pourrait cacher le rendu je ne vois pas ou est le probleme.
              Oui mais pour des raisons qui me sont inconnues, il ne le fait pas; Compiz le fait. Par contre, X peut cacher des pixmaps à la demande de l'application.
              • [^] # Re: Merci pour cette dépêche, je rebondis...

                Posté par . Évalué à 2.

                Je crois que tu te mélanges un peu les pinceaux quand même : Cairo peut utiliser l'accél matérielle parce que justement il ne fait pas le composting avant de l'envoyer à X ....
                • [^] # Re: Merci pour cette dépêche, je rebondis...

                  Posté par . Évalué à 2.

                  Si j'ai bien compris Cairo est utilisé par le client donc s'il peut utiliser l'accél matérielle et que le compositeur qui lui est coté X serveur utilise l'accel materielle aussi alors ça veut dire que plusieurs processus utilisent tous les deux l'accel materielle, c'est possible?
                  • [^] # Re: Merci pour cette dépêche, je rebondis...

                    Posté par . Évalué à 3.

                    Je ne vois pas de problème à ce que deux applis différentes utilisent "en même temps" l'accel matérielle : en OpenGL on a des contextes, il me semble qu'il y a un équivalent pour EXA/XAA.
          • [^] # Re: Merci pour cette dépêche, je rebondis...

            Posté par . Évalué à 6.

            Donc il est impossible d'utiliser openGL en affichage déporté (sauf bidouille, mais cela n'aurait aucun intéret de tt façon).
            Heuu ... si justement, GLX a été fait pour ça et il est possible d'utiliser de l'OpenGL "déporté".

            Imagine le temps qu'il faudrait pour redessiner ton écran si à chaque refresh X devait se taper le rendu d'une description vectorielle au lieu d'une faire une bête copie binaire.
            Bahh, c'est ce que fait justement OpenGL, et c'est bien plus rapide qu'une "copie binaire" puisque c'est la carte graphique qui s'en occupe ...

            Faire passer de l'OpenGL par le réseau, ce n'est pas "aberrant", car au lieu de faire passer des pixmaps complets, tu fais passer en quelques octets un paquet disant "trace moi telle triangle à telles coordonnées", etc. Plus la scène est compliquée, plus le traffic augmente par contre, donc pour des images "compliquées" il doit y avoir un seuil où passer par des bitmaps est plus avantageux.
            • [^] # Re: Merci pour cette dépêche, je rebondis...

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

              Ahh merci ! j'avais l'impression d'avoir rêvé !

              J'ai fait le test il y a 3 mois entre deux bécanes : d'un coté un thinkpad X22 : pauvre pentium3 et vieille radeon 8mo (huhu), sur lequel j'avais lancé tremulous avec comme DISPLAY une autre bécane, en l'occurence un pc de bureau avec une nvidia gefore6600 : ça marchait !
              Juste un soucis : des ralentissement sensibles lors de changement de scène (typiquement l'arrivée depuis un couloir vide vers une salle de carnage avec du monde et des bâtiments dans tout les sens) qui sont certainement du au fait d'envoi d'infos lourdes commes des textures et autres. Sachant que dans mon test j'étais limité par la carte ethernet 10mb/s du thinkpad, il faudrait refaire le test entre deux bécanes en gigabit !
              Donc oui il y a des trucs où c'est normal que ça ralentisse (transfert de textures et autres) mais la 3D en elle-même est bien accélérée en déporté !

              ce commentaire est sous licence cc by 4 et précédentes

            • [^] # Re: Merci pour cette dépêche, je rebondis...

              Posté par . Évalué à 2.

              Heuu ... si justement, GLX a été fait pour ça et il est possible d'utiliser de l'OpenGL "déporté".
              Ah c'est sympa ça ! merci pour l'info, cela m'apprendra à raconter n'importe quoi.

              Sinon je trouvais cela aberrant dans le cadre d'une utilisation "temps-réel" (jeux) où la latence du réseau doit quand même se faire sentir. Plus les problèmes de chargement de textures évoqués par Thomas D.

              Concercant cairo, celui-ci utilise l'extension Xrender mais rien ne l'empêcherait d'utiliser opengl (evas et qt possèdent ce genre de backend).
  • # 2 objections

    Posté par . Évalué à 2.

    Premièrement, pour les cartes ATI assez anciennes le support dans les drivers libres existe depuis longtemps .
    J'ai pas attendu les derniers mois pour avoir une accélération 3D correcte sur ma Radeon 9550, elle marche sans problème depuis 1 an et avec le driver libre "radeon" .
    Deuxièmement, X.org peut marcher avec le framebuffer de la console, et depuis longtemps puisque c'est possible avec Slackware 8.1 (dans QEMU) .
    Bon d'accord dans ce cas là les performances ne sont pas au rendez vous, et idem pour le confort .
    • [^] # Re: 2 objections

      Posté par . Évalué à 4.

      la radeon 9500/9550 est sortie en 2002, le support 3D dispo en 2007, c'est ma foi fort lent... et quand je compare ce que savait faire ladite carte en 2002 sous windows et en 2007 sous OS libre, il y a quand même quelques différences de performance... (tout dépend ce que l'on appelle "correct")

      le support libre 3D chez ati qui existe depuis longtemps, c'est pour celles d'avant (9000 et plus anciennes encore).
      • [^] # Re: 2 objections

        Posté par . Évalué à 1.

        Quand je disais 1 an c'est parce que j'ai commencé à utiliser Linux sur l'ordi concerné il y a 1 an .
        Mais il y a un an c'était "expérimental", je l'accorde .
  • # les "xtools" plus indispensable ?

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

    Je suis pas d'accord, c'est un des seuls outils que je peux encore lancer en étant sous twm pour arriver à convaincre mon entourage que linux est disponible gratuitement.

    Parce qu'avec tout les effets 3D des bureaux, le fait de pouvoir jouer à mes jeux sous wine de façon plus rapide que sous windows (wow en opengl par exemple), etc. le tout à partir d'un livecd, le novice n'arrive plus à y croire...
    • [^] # Re: les "xtools" plus indispensable ?

      Posté par . Évalué à 1.

      Parce qu'avec tout les effets 3D des bureaux, le fait de pouvoir jouer à mes jeux sous wine de façon plus rapide que sous windows (wow en opengl par exemple), etc. le tout à partir d'un livecd, le novice n'arrive plus à y croire... les effets 3D des bureaux se désactivent

Suivre le flux des commentaires

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