Pinaraf a écrit 3674 commentaires

Au fait, j'ai testé Xgl dernièrement sur ma machine. Autant il est vrai que les effets 3D sont fluides (à condition de ne pas être en train de compiler qqc à côté ! ;-) ) et que les fenêtres sont rafraichies immédiatement (plus de trainées quand on déplace une fenêtre comme sous un serveur X classique).
C'est d'un lourd cette incompréhension...

Je te suggère une expérience : prenons une application Java qui consomme comme Netbeans. Prenons Java 5 et Java 6 (http://mustang.dev.java.net). C'est propriétaire hélas, mais j'ai pas mieux comme éléments pour le test (application égale, toolkits quasiment égaux à un détail : la version). Lance netbeans avec Java5. Ouvre la fenêtre à propos par exemple. Déplace là... Ho une traînée énorme...
Maintenant, lance netbeans avec Java 6. Ouvre la fenêtre à propos, déplace là... Mais... où est la traînée ? Ben y'en a plus (ou de quelques pixels seulement). Les traînées, ce n'est pas du à X, c'est du aux applications ! Il suffirait d'un système de double-buffering dans Qt3 pour que toutes les applications Qt3 arrêtent de faire des traînées (Qt4.1 a ça par défaut il me semble, java6 mustang l'a et donc supprime les traînées car il est assez rapide pour redessiner). Pareil pour Gtk.

Vous me direz : oui mais Xgl il est super fort et moderne et tout et tout, et il arrive à éviter les traînées. Bon, déjà Xgl ça fait plus d'un an qu'il existe. Il a eu un coup de punch tant marketing que fonctionnel grâce à novell. Ensuite, Xgl n'apporte rien niveau graphique qui ne soit pas faisable avec un serveur X classique, utilisant aiglx par exemple. Sans aiglx, les performances sont moindres, mais ça reste faisable. Dans Looking Glass, les fenêtres "woobly" nous pourrions les avoir depuis deux ans bientôt... Mais personne n'y a pensé, ou personne n'a eu le temps, ou personne n'a proposé de les coder. Et on n'utilise pas Xgl ni aiglx. On utilise Composite et cie, tout comme compiz utilise composite et cie + un petit truc dans la libGL supporté par aiglx ou Xgl. Ce petit truc d'ailleurs, Looking Glass devrait l'utiliser prochainement.
Maintenant, reprenons nos chères traînées avec netbeans sur Java5. Il existe une possibilité pour les supprimer : utiliser Composite. C'est l'une des possibilités d'un composite manager. Avec kompmgr activé, je n'ai plus aucune traînée sur aucune application.

Bref, reconnaissons les mérites des uns et des autres, sans exagération !
Merci à Xgl de proposer une implémentation originale d'un serveur X, en utilisant l'OpenGL pour tout dessiner. Merci d'implémenter *texture_from_pixmap.
Mais merci à aiglx d'implémenter *texture_from_pixmap pour X.org. Et merci, merci à X.org d'avoir intégré dans la version 6.8 l'extension Composite. C'est un geste courageux car même si l'extension était alors très bugguée, cela a probablement encouragé le développement de nombreux outils liés.

Un conseil :désactive l'IPoT...
sur http://www.mesa3d.org, la dernière nouvelle que je vois date de février 2006 !
Et mesa bouge pas mal, avec notamment les recherches concernant l'accélération et le rendu off-screen.

Je pense qu'il en faudrait un extrêmement bien écrit, très modulaire et tout capable d'utiliser Qt/KDE OU Gtk/Gnome, ou deux : un pour KDE, un pour Gnome. Il y a tellement de technologies chez KDE pour l'intégration... DCOP par exemple : ça serait vraiment un plus d'avoir un client qui supporte DCOP, afin de pouvoir, depuis n'importe quelle application ou script, accéder facilement aux informations...

Ceci dit, je comprends tout à fait la crainte des artistes devant cette proposition de taxe forfaitaire qui légaliserait le piratage.
Il est légal, aujourd'hui en France, de télécharger de la musique sur Internet. Ce qui est illégal, c'est le partage, la diffusion. Cette taxe, si mes souvenirs sont bons, ne vise pas la légalisation de cette diffusion.

Si tu parles de la campagne "Téléchargez nous légalement", Renaud a déjà expliqué à plusieurs reprises s'être fait embobiné, qu'il était en plus en dépression à cette époque là et donc qu'il n'en avait rien à foutre. Tu devrais retrouver ça sur le HLM des fans de Renaud, dans le forum (que Renaud fréquente (ou a fréquenté ?)).
Si tu parles de la pétition récente sur la licence globale, j'ai demandé sans réponse pour l'instant vu qu'apparemment il vient plus sur le forum. Mais cette pétition me gêne : 10000 signatures en deux mois ça me semble trop gros. Ça fait 5000 par mois, soit 166 par jour !

Et pendant ce temps là, que fait milou ?

Xgl (peut marcher)/marche au dessus d'un serveur X normal. Il n'y a donc pas besoin de mettre à jour les pilotes. Toute carte et tout pilote supportant la 3D seront à priori capables de faire tourner Xgl (sauf bugs des pilotes bien sûr)

La OpenSuse 10.1 devrait l'avoir en paquet optionnel, ou dans un dépôt supplémentaire. La 10.2 l'aura de base. De même je pense pour pas mal de distributions grand public qui ne pourront s'en priver (ubuntu par exemple)

Il n'est pas du tout à jour dans dapper : c'est toujours le même que dans breezy.

Le support de Composite avec les pilotes intel sera mieux quand X.org 7.1 sera là : le patch pour qu'ils supportent EXA n'est pas intégré dans X.org 6.9/7.0, donc à moins que ta distrib ne personnalise son X.org et ajoute des patchs comme ça ...

http://xorg.freedesktop.org/wiki/ExaStatus

Encore faut-il que les pilotes supportent DKMS !
Ce n'est pas automagique apparemment.

Il faut dire que le support de XVideo et de l'OpenGL avec Composite (et un *ompmgr qui tourne bien sûr) n'est pas une mince affaire, rien que d'un point de vue "logique".
Dans le cas d'OpenGL, la carte graphique se charge de calculer et d'effectuer le rendu d'une scène (je suis pas très au point sur le vocabulaire 3D, mais bon le principe est compréhensible). Lorsqu'on fait du rendu direct (Direct Rendering), l'affichage est fait par la carte graphique, il n'y a pas un nouveau passage par X qui se charge alors d'afficher une image. En effet, ce passage coûte cher.
Le principe pour avoir des fenêtres transparentes, c'est que les fenêtres sont affichées "off-screen", dans des images, pour ensuite être modifiées et affichées.
Il faudrait donc que la carte graphique effectue le rendu de l'application OpenGL dans une texture ou une image, et il faudrait ensuite afficher cette image après modification... Bref c'est très lourd, et on perd énormément en performances, rendant donc le tout inutile.

La seule solution actuellement, c'est de couper le *ompmgr lorsqu'on souhaite lancer une application OpenGL. Si on utilise KDE et kompmgr, il suffit d'exécuter la commande dcop kwin KWinInterface stopKompmgr

Je sais pas pour vous, mais moi je trouve ça vraiment pas très joli.
Et si on l'adaptait à toutes les sauces en plus, ça serait sûrement pas plaisant à voir (je vois mal un logo de KDE ou gnome entouré de ce machin)

Je vois pas non plus l'intérêt d'une standardisation des sigles des associations francophones : l'homogénéité pour les sigles n'apporte rien, et n'est pas une nécessité.

C'est un avis purement personnel hein.

Malheureusement, toutes les cartes avec un chipset r300 ne fonctionnent pas encore (et à mon plus grand regret, les radeon X700 ne sont pas accélérées...)
De plus, le support d'EXA pour les cartes à chipset r300 est encore assez limité : pas d'accélération de Render notamment...
Mais on peut espérer que X.org 7.1 aura un support bien meilleur de ces cartes :)

J'ai d'autres critiques vis-à-vis des pilotes nVidia. Notamment le fait qu'ils se foutent complètement de la façon dont sont faits les pilotes X habituels.
Par exemple les pilotes nVidia sont les seuls que je connaisse à ne pas passer par DRI. Un truc désagréable semble en découler : si le module noyau n'est pas là, X ne se lancera pas. Super pour les newbies.
Ce genre d'horreurs n'arrivent pas avec les pilotes ATI propriétaires, ni avec les pilotes libres.

D'autres points à ne pas oublier :
1- Support d'autres architectures matérielles. Je ne pense pas que nVidia compilera un jour son pilote pour PowerPC par exemple.
2- Support de nouveaux noyaux. Si quelqu'un veut utiliser le noyau 2.7 quand il sort mais qu'il y a des incompatibilités avec le pilote nVidia, alors il y aura deux choix : pas de 3D, ou pas de noyau 2.7... Ce qui est très agréable.

Rappel : c'est nVidia qui développe le pilote libre actuellement...
Cf http://cvs.freedesktop.org/xorg/driver/xf86-video-nv/ChangeL(...)
Résultat faut pas espérer le voir supporter l'accélération 3D rapidement ...

Avec quels pilotes autres que les pilotes nVidia arrivez vous à accélérer l'OpenGL avec Composite activé ??
Ça m'intéresse énormément.
Pour info, pour les pilotes nVidia il faut activer l'option AllowGLXWithComposite afin d'avoir cette accélération.

Je pense que seules les cartes graphiques ATI peuvent te suffire.
Par contre, aucun pilote autre que les pilotes propriétaires de nVidia ne permet d'accélérer l'OpenGL avec Composite activé.

Donc pour les cartes graphiques ATI, toutes les radeon <= 9200 sont supportées pleinement par le pilote libre, avec en bonus un support complet d'EXA dans X.org 6.9/7.0 (c'est-à-dire Render accéléré, soit Composite utilisable avec les *ompmgr actuels...).
Les ATI radeon > 9200 ont un pilote libre en cours de développement, qui ne supporte malheureusement pas pour la 3D toutes les cartes (ma radeon X700 n'est pas supportée pour la 3D par exemple). Néanmoins ce pilote s'améliore continuellement, et je pense que d'ici 1 an il marchera parfaitement.
Par contre, toutes les cartes graphiques nVidia ont des pilotes propriétaires uniquement, le pilote libre étant quasiment fermé d'après certains (il fait de la magie sur des registres de la carte sans explication). D'ailleurs, il faut noter la man½uvre tactique de nVidia qui consiste à ne plus supporter les Geforce < 3 et les TNT dans les derniers pilotes propriétaires (probablement afin de forcer un renouvellement du parc)

Sinon y'a la "méthode" utilisée en XSLT. En XSLT y'a un if mais pas de else. Donc une solution :
<xsl:choose>
<xsl:when test="condition1">
Cas 1
</xsl:when>
<xsl:when test="condition2">
Cas 2
</xsl:when>
<xsl:otherwise>
Sinon
</xsl:otherwise>
</xsl:choose>

J'ai du coder ce week end une application web avec mod_python, et j'ai trouvé ça vraiment agréable à utiliser, simple et rapide.
Je me demande pourquoi personne n'en parle. L'écriture de templates est très simple avec PSP (Python Server Page).

Bof, le dossier .kde me semble assez bien rangé encore.
.kde/
- Autostart/ : des liens/fichiers .desktop/scripts/exécutables qui seront lancés au lancement de KDE
- cache-*/, tmp-*/ et socket-*/ : des dossiers pour les cache, fichiers temporaires et socket
- share/
- - applnk/ : contient des liens qui sont ajoutés au menu K et propres à l'utilisateur
- - apps/ : contient les fichiers des applications qui ne sont pas liés à la configuration. Exemple : les journaux de discussion sur IRC/Jabber, la base de données d'amaroK...
- - config/ : contient les fichiers de configuration des applications, au format "ini". Certaines applications utilisent plusieurs fichiers car elles sont séparées en plusieurs "composants" (exemple : kdevelop).
- - locale/ : je sais pas là...il est vide ce dossier
- - mimelnk/ : les associations de fichiers que l'utilisateur a modifié
- - services/ : les services propres à l'utilisateur. Exemple : des mots clés de recherche personnalisés (alt+f2 => "gg:test" recherche test sur google. On peut facilement ajouter d'autres mots clés que google)
- - servicetypes/ : contient des composants, actions de konqueror.. propres à un utilisateur

Bref, .kde est très rangé.
Et le système de configuration de KDE, KConfig, ne permet pas de cacher des entrées. KConfigEditor est ton ami pour l'édition des options d'ailleurs : http://extragear.kde.org/apps/kconfigeditor/
Au passage : kconfigeditor supporte aussi gconf

1- Ce n'est pas une base de registre immonde qui contient des informations sur tout le système. Ça ne concerne que des applications, les fichiers de config de X par exemple restant hors de ce machin
2- C'est bien plus évolué que la base de registre. Le système de transaction est proche d'une base de données par exemple.
3- Il existe un éditeur en mode texte pour cette base.
4- Il s'agit toujours de KConfig. On a donc toujours une description des différentes clés et valeurs possibles pour ces clés.
5- Comme tu l'as dis, il sera possible de choisir entre un stockage dans un classique fichier "ini" et cette base de données. Il faut tout de même noter que les performances des fichiers .ini sont catastrophiques par rapport à cette base.
6- Cette base sera utilisée par samba4. C'est d'ailleurs les développeurs de samba qui l'ont crée. Donc les performances sont (seront) très bonnes, et cela devra obligatoirement être stable et fiable vu l'envergure du projet Samba4 et la dépendance à cette base pour certains fonctionnalités

Moi j'ai eu un clavier PS2 qui a cramé, en emportant apparemment le port avec.
Résultat j'ai du m'acheter un clavier USB, qui merdoyait pas mal sur tout sauf DOS. J'ai alors flashé le BIOS, et en rebootant, le port PS2 remarchait ...

Pour plus d'info sur les puces SiS/XGI voir http://www.winischhofer.at/linuxsispart1.shtml . En gros si c'est une puce SiS34x ça devrait marcher, pour les autres nada.
Donc il est nada :p (une SiS315 je crois)
Sous Windows le top du top de chez XGI se fait torpiller par l'entrée de gamme de NVidia/ATI et sur les puces intégrées c'est pire.
Et en plus il a le pire !

Comment peuvent-ils vendre ça ? C'est si bon marché ?

Sis ?
Je passe sur le fait que ça soit pourri tout ça, mais y'a un pote qui a des problèmes : sa carte sis n'est pas supportée en 3D, même par un driver proprio ? Ce driver là pourrait marcher ?