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
- [1] X.Org sur wikipedia : http://fr.wikipedia.org/wiki/X.Org
- [2] XFree86 Project License Modification
- [3] (Jesse Barnes) enhancing the kernel's graphics subsystem
- [4] (Michael Larabel) Gaming With The Open-Source R500 Driver
- [5] (B. Rathmann) The state of Nouveau concernant le pilote nouveau
- [6] (Michael Larabel) VIA's Open-Source Efforts A Bluff?
- [7] (Jeremy Andrews) Linux: NVIDIA Binary Graphics Driver Exploit
- [8] (Jonathan Corbet) GEM v. TTM
- [9] (Keith Whitwell) http://lwn.net/Articles/283823/
Aller plus loin
- x.org (7 clics)
- Le projet 'nouveau' (4 clics)
# intéressant, une question ...
Posté par or zax . Évalué à 5.
Par contre, pourquoi cet article est dans les dépèches ?
[^] # Re: intéressant, une question ...
Posté par sirrus . Évalué à 10.
[^] # Re: intéressant, une question ...
Posté par suJeSelS . Évalué à 10.
[^] # Re: intéressant, une question ...
Posté par Anthony F. . Évalué à 1.
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 Psychofox (Mastodon) . Évalué à 7.
[^] # Re: intéressant, une question ...
Posté par moudj . Évalué à 2.
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 cosmocat . Évalué à 10.
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 bob le homard . Évalué à 3.
Même avec Windows Millénium?
[^] # Re: intéressant, une question ...
Posté par suJeSelS . Évalué à 3.
[^] # Re: intéressant, une question ...
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: intéressant, une question ...
Posté par Mickaël Sibelle (site web personnel) . Évalué à 7.
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 Gregory Auzanneau (site web personnel) . Évalué à 4.
Par contre je note que patrick_g se duplique : nous avons maintenant un didier_g.
[^] # Re: intéressant, une question ...
Posté par Émilien Tlapale . Évalué à -1.
[^] # Re: intéressant, une question ...
Posté par or zax . Évalué à -1.
[^] # Re: intéressant, une question ...
Posté par Psychofox (Mastodon) . Évalué à 5.
[^] # Re: intéressant, une question ...
Posté par Old Geek . Évalué à -2.
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 benoar . Évalué à 5.
[^] # Re: intéressant, une question ...
Posté par dinomasque . Évalué à 4.
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 20 ans !
[^] # Re: intéressant, une question ...
Posté par Mildred (site web personnel) . Évalué à 2.
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 meuble2001 . Évalué à 9.
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 Epy . Évalué à 4.
(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 jihele . Évalué à 2.
[^] # Re: intéressant, une question ...
Posté par glattering . Évalué à 4.
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 Pierre Jarillon (site web personnel) . Évalué à 4.
[^] # Re: intéressant, une question ...
Posté par nust . Évalué à 4.
# modèle de développement
Posté par Aris Adamantiadis (site web personnel) . Évalué à 4.
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 Marc Poiroud (site web personnel) . Évalué à -2.
http://www.linux-france.org/article/these/cathedrale-bazar/
[^] # Re: modèle de développement
Posté par Maclag . Évalué à 8.
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 totof2000 . Évalué à 6.
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 psychoslave__ (site web personnel) . Évalué à 2.
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 ).
[^] # Re: The Linux developers are selfish dickheads
Posté par alexissoft . Évalué à 2.
[^] # Re: The Linux developers are selfish dickheads
Posté par Old Geek . Évalué à 0.
ReactOS,
GNU/Hurd ;)
[^] # Re: The Linux developers are selfish dickheads
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
# PPC _not_ pwned
Posté par benoar . Évalué à 9.
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 timid . Évalué à 2.
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 psychoslave__ (site web personnel) . Évalué à 5.
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 timid . Évalué à 3.
(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 benoar . Évalué à 1.
[^] # Re: PPC _not_ pwned
Posté par Aefron . Évalué à 3.
... 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 timid . Évalué à 1.
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 dawar (site web personnel) . Évalué à 3.
[^] # Re: PPC _not_ pwned
Posté par lfmarante . Évalué à 1.
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 benja . Évalué à 5.
[^] # Re: PPC _not_ pwned
Posté par Guillaume Knispel . Évalué à 3.
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 tinodeleste . Évalué à 2.
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 dinomasque . Évalué à 2.
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 20 ans !
[^] # Re: PPC _not_ pwned
Posté par benoar . Évalué à 5.
[^] # Re: PPC _not_ pwned
Posté par Boa Treize (site web personnel) . Évalué à 4.
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 timid . Évalué à 4.
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 dawar (site web personnel) . Évalué à 6.
[^] # Re: PPC _not_ pwned
Posté par lfmarante . Évalué à 2.
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5.
C'est une trappe qui a un fond, pas un goulp...
[^] # Re: PPC _not_ pwned
Posté par benoar . Évalué à 2.
[^] # Re: PPC _not_ pwned
Posté par timid . Évalué à 1.
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 benoar . Évalué à 4.
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 lfmarante . Évalué à 1.
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 benoar . Évalué à 2.
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 timid . Évalué à 2.
[^] # Re: PPC _not_ pwned
Posté par dinomasque . Évalué à 4.
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 20 ans !
[^] # Re: PPC _not_ pwned
Posté par lfmarante . Évalué à 1.
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 benoar . Évalué à 2.
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 lfmarante . Évalué à 0.
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 benoar . Évalué à 2.
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 lfmarante . Évalué à 4.
[^] # Re: PPC _not_ pwned
Posté par benoar . Évalué à 3.
[^] # Re: PPC _not_ pwned
Posté par claudex . Évalué à 4.
« 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 timid . Évalué à 1.
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 meuble2001 . Évalué à 2.
Dans ce domaine effectivement... nVidia est vert, ATI est rouge et Intel est bleu !
[^] # Re: PPC _not_ pwned
Posté par FreeB5D . Évalué à 2.
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 lfmarante . Évalué à 2.
[^] # Re: PPC _not_ pwned
Posté par ʭ ☯ . Évalué à 7.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: PPC _not_ pwned
Posté par benoar . Évalué à 3.
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
[^] # Re: PPC _not_ pwned
Posté par benoar . Évalué à 2.
[^] # Re: PPC _not_ pwned
Posté par timid . Évalué à 3.
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 benoar . Évalué à 0.
[^] # Re: PPC _not_ pwned
Posté par timid . Évalué à 0.
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 lfmarante . Évalué à 5.
[^] # Re: PPC _not_ pwned
Posté par benoar . Évalué à 3.
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 timid . Évalué à 1.
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 benoar . Évalué à 2.
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 dinomasque . Évalué à 2.
BeOS le faisait il y a 20 ans !
[^] # Re: PPC _not_ pwned
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
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 Spack . Évalué à 2.
[^] # Re: 32 bits
Posté par Sarcastic . Évalué à 10.
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 Spack . Évalué à 2.
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 ? :)
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 Sarcastic . Évalué à 4.
Ç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 benoar . Évalué à 2.
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 Mjules (site web personnel) . Évalué à 3.
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 7.
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 psychoslave__ (site web personnel) . Évalué à 1.
[^] # Re: 32 bits
Posté par benoar . Évalué à 4.
[^] # Re: 32 bits
Posté par spark . Évalué à 2.
Les daltoniens c'est encore moins.
[^] # Re: 32 bits
Posté par Boa Treize (site web personnel) . Évalué à 2.
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 left . Évalué à 9.
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 -=[ silmaril ]=- (site web personnel) . Évalué à 3.
Vive xterm et fluxbox !
[^] # Re: je suis trop vieux ?
Posté par 태 (site web personnel) . Évalué à 4.
[^] # Re: je suis trop vieux ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
[^] # Re: je suis trop vieux ?
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 3.
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...
[^] # Re: je suis trop vieux ?
Posté par timid . Évalué à 7.
http://martin.ankerl.com/2007/09/01/comprehensive-linux-term(...)
[^] # Re: je suis trop vieux ?
Posté par Clément David (site web personnel) . Évalué à 3.
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 Jean B . Évalué à 3.
# xterm
# bash: xterm: command not found
On doit pas utiliser les mêmes distribs.
--> []
[^] # Re: je suis trop vieux ?
Posté par FreeB5D . Évalué à 3.
---------> []
[^] # Re: je suis trop vieux ?
Posté par left . Évalué à 3.
Donc voilà, je persiste.
[^] # Re: je suis trop vieux ?
Posté par Boa Treize (site web personnel) . Évalué à 0.
[^] # xterm vs reste du monde
Posté par Victor STINNER (site web personnel) . Évalué à 6.
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 Boa Treize (site web personnel) . Évalué à 5.
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Ç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 Batchyx . Évalué à 2.
Mais lorsque j'ai juste besoin d'un terminal pour moins de dix secondes, xterm suffit (et je l'utilise actuellement)
# corrections
Posté par Bozo_le_clown . Évalué à 5.
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 Rémi PALANCHER (site web personnel) . Évalué à 4.
"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 :)
[^] # Re: corrections
Posté par Bozo_le_clown . Évalué à 5.
De plus, certains tests préliminaires ont montrés
[^] # Re: corrections
Posté par FreeB5D . Évalué à 2.
# intro
Posté par Psychofox (Mastodon) . Évalué à -4.
[^] # Re: intro
Posté par pikapika . Évalué à -2.
faut arreter la fixette
# Merci pour cette dépêche, je rebondis...
Posté par romu . É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 ?
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 -=[ silmaril ]=- (site web personnel) . Évalué à 8.
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 romu . Évalué à 1.
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 Tonton Th (site web personnel, Mastodon) . Évalué à 3.
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.
[^] # Re: Merci pour cette dépêche, je rebondis...
Posté par Aefron . Évalué à 2.
... 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 Padishah . Évalué à 2.
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 Padishah . Évalué à 2.
[^] # Re: Merci pour cette dépêche, je rebondis...
Posté par romu . Évalué à 3.
- 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 Padishah . Évalué à 4.
- 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 Mildred (site web personnel) . Évalué à 2.
[^] # Re: Merci pour cette dépêche, je rebondis...
Posté par gaaaaaAab . Évalué à 5.
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 Frédéric COIFFIER . Évalué à 3.
[^] # Re: Merci pour cette dépêche, je rebondis...
Posté par karteum59 . Évalué à 10.
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 Mjules (site web personnel) . Évalué à 4.
[^] # Re: Merci pour cette dépêche, je rebondis...
Posté par Hank Lords . Évalué à 2.
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 reno . Évalué à 2.
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 benja . Évalué à 2.
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 reno . Évalué à 3.
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 benja . Évalué à 1.
-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 benoar . Évalué à 2.
[^] # Re: Merci pour cette dépêche, je rebondis...
Posté par reno . Évalué à 2.
[^] # Re: Merci pour cette dépêche, je rebondis...
Posté par benoar . Évalué à 3.
[^] # Re: Merci pour cette dépêche, je rebondis...
Posté par benoar . Évalué à 6.
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 Thomas Debesse (site web personnel) . Évalué à 5.
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 benja . Évalué à 2.
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 FreeB5D . Évalué à 2.
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 tinodeleste . Évalué à 4.
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 FreeB5D . Évalué à 1.
Mais il y a un an c'était "expérimental", je l'accorde .
# les "xtools" plus indispensable ?
Posté par s[e]th & h[o]lth (site web personnel) . Évalué à 6.
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 tylhdar . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.