Ma vie rêvée

Aller au contenu | Aller au menu | Aller à la recherche

vendredi 2 janvier 2009

Bonne année

Tout est dans le titre :D

lundi 1 septembre 2008

Mise à jour du blog

Ce matin, je me suis dit que tant qu'à changer d'hébergeur, autant en profiter pour changer d'autres trucs ;). J'ai donc mis à jour ce blog vers dotclear 2. Normalement, il ne devrait pas trop y avoir de casse, sauf pour les fils RSS et commentaires auxquels il faut se réinscrire, le format ayant totalement changé.

N'hésitez pas à me laisser un commentaire si vous constatez un problème.

dimanche 31 août 2008

Changement d'adresse

Suite à un comportement très bizarre de mon hébergeur (pages persos free.fr), j'ai du me résoudre à déplacer ce blog. La nouvelle adresse est donc http://mjules.littleboboy.net/carnet.
Je vous invite à mettre à jour vos marques-pages et abonnements RSS/atom. Il y a une redirection vers le nouveau site mais il n'y a aucune garantie qu'elle persiste dans le temps :).

En attendant, un grand merci à mon nouvel hébergeur qui m'a gentiment fait une place ici :).

mercredi 21 novembre 2007

Mise à jour sur ma Logitech MX1000 sous GNU/linux (avec Xorg)

En 2006, j'avais écrit un petit tutorial sur la façon de gérer les nombreux boutons de ma MX1000 sous Xorg (GNU/linux), depuis, ça a un peu évolué et ça s'est encore simplifié :

  • Vous pouvez oublier les règles udev, elles ne sont plus nécessaires (voire même elles sont moins pratiques)
  • La conséquence, c'est que la section InputDevice de xorg.conf change un peu et devient :
    Section "InputDevice"
            Identifier      "MX1000"
            Driver          "evdev"
            Option          "Name"      "Logitech USB Receiver"
            Option          "CorePointer"
    EndSection
    
    En clair, la souris est appelée par son nom et pas par son periphérique, il est possible bien que peu probable qu'il y ait des conflits de nom, dans ce cas, vous pourriez utiliser l'option Phys ou Device pour désigner la souris, voir le man d'evdev pour plus d'info.
  • pas de changement pour le reste de la configuration (qui reste à adapter à votre cas).

Cette conf est bien évidemment utilisable moyennant quelques modifications avec d'autres souris boutonneuses (MX700, MX400 etc).

P.S. : ceci doit fonctionner depuis xorg 7.0 mais je n'ai pas testé, utilisant un Xorg 7.2

dimanche 16 septembre 2007

La critique littéraire du jour

Ces derniers temps, j'avais envie de lire un peu de fantaisie et pas trop envie de chercher un nouvel auteur. Je me suis donc lancé dans la lecture du cycle des Rêveurs (Le réveils des anciens Dieux, La dame d'atout, Les Gorges de cristal, La folie des dieux) de David et Leigh Eddings. Ayant découvert et apprécié ces auteurs avec la rédemption d'Althalus, j'avais ensuite dévoré la Belgariade, la Mallorée et les préquelles. Bref, je m'attendais à passer un bon moment.

Et bien, c'est raté ! Le moment, et les bouquins. Autant être clair, pas la peine de dépenser votre argent dans ce cycle, il ne vaut pas grand chose. L'histoire aurait pu être intéressante mais on se lasse très vite des X narrations de la même scène par des points de vues différents, du développement/remplissage sur 3 chapitres de la vie d'un personnage secondaire (et il y a beaucoup de personnages secondaires...) qui n'apporte absolument rien à l'histoire, un Deus ex Machina qui pulvérise la cohérence de l'histoire dès le tome 2 et rend la fin absolument minable, j'ai pourtant une tolérance au TGCM (Ta Gueule C'est Magique) assez élevée ; sans compter une traduction très moyenne et mal relue (erreur dans les noms, fautes d'orthographes etc).

Bref, j'ai beau être bon public, je ne peux que vous déconseiller ces livres. Ne vous fiez pas aux auteurs, ils ont écrit de très bons livres mais ceux là n'en font vraiment pas partie.

dimanche 2 septembre 2007

Bridage Orange et pages perso free ?

Depuis que je suis chez Orange, j'ai remarqué que le téléchargement de fichiers depuis les pages perso de free est lent.

Plus exactement, il semble limité aux alentours de 30ko/sec. Après quelques investigations voilà ce que j'ai pu constater :

  • Cette limite ne semble exister qu'en voie descendante, je mets à jour ce site à 75ko/sec sans aucun problème.
  • Elle ne semble toucher que les pages perso de free (toutes les pages persos, pas juste celle-ci), le serveur test ( http://test-debit.free.fr/ ) n'est pas impacté, les ftp de proxad ne le sont pas non plus, les dedibox non plus. Le débit étant tout à fait correct avec ces derniers.
  • Je ne constate ça que depuis Orange, pas de problèmes depuis le réseau neuf, et je n'en n'avais pas avec télé2 (qui utilise le même réseau)
  • Quelques tests avec un ami également chez Orange mais géographiquement assez loin montre les mêmes résultats
  • Le résultat n'est pas dépendant du moment des tests

Bref, il me semble bien qu'il y a effectivement une limitation mis en place dans le cas présent. La question maintenant est qui bride qui ? Est ce Orange qui limite l'accès vers les pages persos free (rétorsion commerciale ?) ou est ce free qui limite l'accès depuis les abonnées Orange. Honnêtement, la première possibilité me parait la plus probable, la deuxième n'ayant qu'un intérêt limité pour free.

Si vous avez des informations plus précises ou un avis sur la question, je suis preneur, n'hésitez donc pas à « lâcher vos com' ! ».

lundi 30 juillet 2007

Petite visite au zoo

Le zoo d'Amiens est plein de surprise, je ne m'attendais pas à y trouver ce petit animal, que j'ai plutôt tendance à utiliser pour naviguer sur internet :

un joli petit panda roux

mercredi 23 mai 2007

De retour

Enfin de retour après une longue absence due à mon déménagement et à l'incapacité de certains opérateurs ADSL à me reconnecter. Normalement, je vous en dirai plus très bientôt.

jeudi 29 mars 2007

Science et foi, la nuance

Une image amusante sur la différence fondamentale entre la science et la foi. (source HFR)

2 schémas explicitant la différence entre la science et la foi

lundi 12 mars 2007

Vote électronique, pour moi, c'est non

Deux grandes élections approchant, je me devais de parler un peu de ce problème qu'est le vote électronique.

Le vote électronique est un problème car il interdit toute vérification au préalable de la machine (est elle conforme, est elle bien « vide » de tous bulletins ?) et par la suite interdit tout recomptage des bulletins.
En effet, si il est simple de voir dans une urne transparente son bulletin tomber, il est ardu pour ne pas dire impossible d'être certains que son vote a été comptabilisé par la machine.

Bref, on ajoute des possibilités de fraudes (à grande échelle et très simplement, qui peut vérifier le programme des machines dans chaque bureau de vote ?) sans aucunement limiter les fraudes existantes (les faux électeurs ne seront pas plus facilement démasqués). Pour ma part, je fais mien des mots d'autres et j'appelle ça un recul démocratique.

Vous n'êtes bien sur pas obligé de me croire sur parole et je vous invite à lire les liens suivants :

Le site de padawan qui nous alerte depuis 2004

Ordinateur de vote.org (anciennement recul-democratique.org) mine d'information sur le sujet même si le site n'est pas très beau

Lettre ouverte à André Santini, député-maire d'Issy-les-moulineaux

Et enfin, la pétition pour le maintien du vote papier :

Pétition pour le maintien du vote papier

dimanche 3 décembre 2006

Ce qui me manque sous GNU/linux

Il y a de ça deux ans, j'avais écrit un billet répertoriant ce qui manquait et portant le même titre : ce qui me manque sous GNU/linux. 2 ans ce sont écoulés, il est temps de faire le bilan et de reprendre les points que j'avais alors évoqué.

  • Un lecteur flash libre. J'avais évoqué swfdec et gplflash à ce moment là. Si swfdec continue son chemin depuis, gplflash est mort. En effet, les développeurs ont préféré rejoindre le projet gnash, soutenu également par le FSF, qui partait sur de meilleures bases. Actuellement, la deuxième version alpha a été publiée, le lecteur seul semble fonctionner pas trop mal, le plugin fait planter mon navigateur mais c'est probablement parce que c'est une version beta vu qu'il fonctionne pas trop mal avec FF 1.5. A tester et à suivre, le développement est rapide.
  • Une machine virtuelle java libre. Beaucoup de développement dans cette partie :-). Le projet GNU classpath atteint presque 100% de compatibilité pour java 1.4 et plus de 95% pour java 1.5 (java5). On est donc presque parfait du côté des projets libres et, cerise sur le gateau, Sun a récemment annoncé que la version 7 de java serait publiée sous licence GNU/GPL. Bref, du tout bon.
  • Des pilotes libres pour ma carte graphique. Le projet Opengraphics avance toujours doucement, les premiers prototypes de la carte de démonsrtation (destinée à la recherche) sont arrivés ces derniers temps. Intel a, de son côté, confirmé le développement de pilotes libres pour ses puces graphiques. ATI et Nvidia, restent quand à eux sur des pilotes propriétaires et refusent toujours de donner des spécifications. Heureusement, un peu d'espoir vient du projet r300 pour ATI et du projet Nouveau pour Nvidia. Ces 2 projets visent à écrire des pilotes libres et complets pour les cartes de ces constructeurs, R300 est plus ancien et est déjà utilisable ; nouveau en est à ses débuts mais évolue vite.
  • Un équivalent à Acrobat pour manipuler des PDF. De ce côté, rien de vraiment nouveau, je n'ai toujours pas trouvé la perle rare et je n'ai pas connaissance de projets de ce type..

AU final, en 2 ans, pas mal de choses ont évolué et même si ce n'est pas encore parfait, l'avenir ne s'annonce pas si mal que ça.

jeudi 16 novembre 2006

Comment marche X11/xorg et toute la clique ? 6° partie (et fin)

Plan général

  1. Les bases, le rendu 2D
  2. Le rendu 3D direct
  3. Le rendu 3D indirect
  4. Composite et XGL
  5. AIGLX
  6. Suite et fin (ou comment ne plus avoir d'idée pour le titre)

Préambule

Cet article est basé sur ce que je comprend du fonctionnement de X11. Il est loin d'être parfait et comporte peut-être des erreurs. si c'est le cas, j'apprécierais qu'on me les signale pour pouvoir améliorer le tout.

Qu'est ce qu'il reste à dire ?

Plus grand chose en fait, nous avons vu à peu près les grands principes de fonctionnement de X11 et des dernières technologies développées autour. Il y a seulement 1 an, beaucoup de monde râlait et pestait contre Xorg et sa gestion antédiluvienne des fenêtres par rapport à des OS comme MacOS X ou même XP.
1 an plus tard, on peut dire sans trop de complexe que La couche graphique X11 n'a pas grand chose a envier aux derniers développements des OS propriétaires. Il reste encore beaucoup à faire et à inventer pour amener le plein potentiel de ces technologies mais elles sont là et elles marchent.

Il reste néanmoins quelques problèmes à régler :

  • Pour rester sur le fonctionnement de X11, à l'exception d'XGL qui ne remporte pas les suffrages, beaucoup de choses sont encore gérées par la partie 2D de la carte graphique avec les limitations que l'on connait. Cela devrait néanmoins se régler grace à des initiatives comme Glucose qui permet d'accélérer le rendu grâce à la partie 3D (il utilise une partie du code de XGL pour modifier le serveur X existant).
  • Plus généralement, et c'est je pense, le plus gros problème avec les nouvelles technologies de X11, tout cela repose sur l'utilisation intensive de la partie 3D. Ce qui confine de fait à l'utilisation des pilotes propriétaires d'ATI ou de NVIDIA avec tout les problèmes que cela pose (obsolescence obligatoire du matériel, failles de sécurité masquées, impossibilité d'évolution tant que le pilote n'est pas mis à jour au bon vouloir de la société, etc). Néanmoins, des solutions existent ou se rapprochent même si elles ne sont pas parfaites : les pilotes Intel (2D et 3D, puces intégrées) sont libres et même si les cartes ne sont pas des foudres de guerres, elles sont suffisantes pour beaucoup ; les cartes ATI jusqu'au x800 disposent d'un pilote 3D libre qui marche pas trop mal et ne devraient plus trop tarder à être disponible par défaut (les cartes < radeon 9200 en on déjà un); l'espoir pour les cartes nvidia repose sur le projet Nouveau qui avance relativement bien ; à plus long terme, c'est le projet Opengraphics qui vise à développer une carte graphique complètement ouverte.

Le mot de la fin

J'espère que ça vous (les lecteurs) a plus, que ça vous a un peu éclairé et que je n'ai pas dit trop de bêtises (je ne pense pas mais sait on jamais).
Quant à moi, j'ai bien aimé Inkscape, c'est vraiment sympa à utiliser, surtout la dernière version que je trouve nettement plus ergonomique que la précédente.

Bibliographie

mercredi 15 novembre 2006

Comment marche X11/xorg et toute la clique ? 5° partie, AIGLX

Plan général

  1. Les bases, le rendu 2D
  2. Le rendu 3D direct
  3. Le rendu 3D indirect
  4. Composite et XGL
  5. AIGLX
  6. Suite et fin (ou comment ne plus avoir d'idée pour le titre)

Préambule

Cet article est basé sur ce que je comprend du fonctionnement de X11. Il est loin d'être parfait et comporte peut-être des erreurs. si c'est le cas, j'apprécierais qu'on me les signale pour pouvoir améliorer le tout.

AIGLX

dans l'article précédent, nous avons aperçu le fonctionnement de XGL qui est l'une des solutions proposée pour accélerer le rendu en utilisant la partie 3D de la carte graphique. A peu près au même moment, RedHat a développé une autre solution pour cette problématique, AIGLX, acronyme qui signifie Accélérated Indirect GL X.

Schéma de principe :
Principe de AIGLX

AIGLX est basé sur un principe complètement différent de XGL. Plutôt que de réinventer un serveur X, les développeurs ont préféré modifier celui existant pour lui permettre d'accélérer certaines opérations particulières à l'aide de la partie 3D de la carte graphique.
Ici, le gestionnaire de composition va s'adresser à la libGL en lui envoyant une instruction spéciale : GL_EXT_texture_from_pixmap. La libGL va alors transmettre cette instruction et ce qui va avec au serveur X par le biais de l'extension GLX. Le serveur X, quant à lui, va relayer le tout vers la partie 3D de la carte graphique.
On est donc bien en face d'un rendu 3D indirect qui passe par le serveur X, la différence avec le rendu indirect "classique" c'est que maintenant, celui-ci est accéléré par la carte 3D et profite de sa puissance.
La gestion de la composition implique certes des aller-retours entre le gestionnaire de composition et le serveur X mais quelques optimisations du protocole permettent d'éviter que cela surcharge trop le système : les manipulations avant le rendu sont effectuées par le serveur X sur ordre du gestionnaire de composition, ainsi, seule les informations de manipulations sont à transmettre, les données ne sont transmises qu'une seule foi.

Les avantages de ce modèles, c'est que le rendu direct est toujours possible pour les applications qui le demandent. L'autre avantage, c'est que d'après la théorie, la transparence réseau est toujours là y compris lorsque l'on utilise la composition.
Le défaut, c'est que contrairement à XGL, ici seule certaines opérations sont accélérées, le reste des opérations continue à utiliser le schéma 2D classique.

Au contraire de XGL, le développement d'AIGLX s'est fait de manière totalement ouverte et AIGLX a été inclu dans Xorg 7.1.

Bibliographie

dimanche 12 novembre 2006

Comment marche X11/xorg et toute la clique ? 4° partie, composite et XGL

Plan général

  1. Les bases, le rendu 2D
  2. Le rendu 3D direct
  3. Le rendu 3D indirect
  4. Composite et XGL
  5. AIGLX
  6. Suite et fin (ou comment ne plus avoir d'idée pour le titre)

Préambule

Cet article est basé sur ce que je comprend du fonctionnement de X11. Il est loin d'être parfait et comporte peut-être des erreurs. si c'est le cas, j'apprécierais qu'on me les signale pour pouvoir améliorer le tout.

Où en est t'on ?

Dans les billets précédents, on a vu comment Xorg se débrouillait pour afficher des choses sur l'écran en 2D et en 3D. Ça fonctionne très bien mais ce mode de fonctionnement comporte des limitations qui rendent difficile l'évolution de l'affichage. En particulier, avec ce mode de fonctionnement, il est très complexe de faire des choses comme des ombres derrières les fenêtres, ou tout bonnement des fenêtres transparentes. C'est pourquoi le protocole X11 a été encore étendu avec l'extension Composite. Celle-ci va permettre de modifier le comportement du rendu. En effet, au lieu que le serveur envoie directement les informations sur chaque fenêtre à la carte graphique ; celles-ci sont envoyées dans un espace de la mémoire où elles peuvent être ensuite manipulées par un gestionnaire de composition avant que le résultat soit rendu par la carte graphique.
L'énorme avantage, c'est qu'avec cette méthode, il devient très simple de faire, par exemple, une fenêtre réellement transparente. Le gestionnaire de composition possédant toutes les infos pour celà (il sait exactement quelle fenêtre est au dessus de quelle autres etc).
L'énorme inconvénient, c'est que ça nécessite beaucoup de puissance graphique et donc, pour pouvoir faire ça sans que l'affichage rame atrocement, il faut de l'accélération par la carte graphique.

Cette accélération est disponible avec la partie 2D de la carte via les extensions XAA ou plus récemment EXA. Néanmoins, l'accélération 2D pose quelques problèmes qui rendent son utilisation peu intéressante :

  • XAA était difficile à implémenter dans les pilotes et n'accélérait que peu de fonctions 2D
  • EXA est plus simple à implémenter mais il ne l'est toujours pas dans un grand nombre de pilotes
  • la partie 2D des cartes graphiques se réduit de plus en plus au profit de la partie 3D
  • la partie 2D des cartes graphiques est nettement moins performante que la partie 3D

Bref, la conclusion s'imposait d'elle même, il fallait trouver un moyen d'accélerer tout ça en utilisant la partie 3D de la carte graphique.
2 solutions ont alors été développées qui répondent à cette problématique : XGL par Novell/Suse et AIGLX par Fedora/RedHat.

XGL

XGL a été la première solution présentée par Novell au tout début de l'année 2006. Son développement a fait l'objet de quelques critiques, en effet, il a principalement été réalisé de manière non-ouverte. Les craintes quand a la fermeture du projet ou du code ont depuis été levées.

Le schéma de principe :

Fonctionnement de XGL

Le schéma ci-dessus présente XGL dans son implémentation Xglx, c'est à dire utilisant 2 serveurs X. Il existe une autre implémentation, Xegl, encore à l'état de projet, qui se baserait sur les EGL, des bibliothèques openGL censées parler directement à la carte graphique.

Comme on le voit sur le schéma, Xgl va donc jouer un double rôle, il est simultanément un client X pour les applications et un serveur X utilisant openGL. Au démarrage, Il va dialoguer avec libGL (et donc le serveur X sous-jacent) et obtenir un rendu 3D direct. Ainsi, toutes les opérations du serveur XGL sont susceptibles d'être accélérées par la carte graphique et en particulier par sa partie 3D. En particulier, toutes les opérations d'un gestionnaire de composition (compiz, beryl par exemple) seront accélérées du moment que celui-ci utilise openGL.

Cela fonctionne très bien mais à quand même quelques défauts relativement gênant : comme pour tout rendu direct, on dit au revoir à la transparence réseau ; la nécessité d'avoir 2 serveurs X tournant simultanément augmente la mémoire occupée ainsi que la complexité du système ; enfin, et c'est le plus gênant, il est impossible pour les autres applications 3D (les jeux par exemple) d'obtenir un rendu direct vers la carte graphique. Elles n'obtiennent au mieux qu'un rendu indirect par le serveur XGL, ce qui pose un problème de performance.

Les 2 derniers problèmes sont liés à l'implémentation Xglx et devrait disparaitre avec Xegl. Mais cette dernière n'est encore que théorique.

Bibliographie

vendredi 10 novembre 2006

Comment marche X11/xorg et toute la clique ? 3° partie, le rendu 3D indirect

Plan général

  1. Les bases, le rendu 2D
  2. Le rendu 3D direct
  3. Le rendu 3D indirect
  4. Composite et XGL
  5. AIGLX
  6. Suite et fin (ou comment ne plus avoir d'idée pour le titre)

Préambule

Cet article est basé sur ce que je comprend du fonctionnement de X11. Il est loin d'être parfait et comporte peut-être des erreurs. si c'est le cas, j'apprécierais qu'on me les signale pour pouvoir améliorer le tout.

Résumé des épisodes précédents

Dans les articles précédents, nous avons parlé du rendu 2D et d'une des méthode de rendu 3D, le rendu direct qui nécessite un accès direct à la carte graphique. Aujourd'hui nous allons parler de l'autre méthode utilisée pour le rendu 3D, le rendu indirect.

Le rendu 3D indirect

Le schéma qui va bien :

Rendu 3D/OpenGL indirect

Comme on peut le voir, le rendu 3D indirect est un peu différent. Il fait intervenir une extension du protocole X11 appelée GLX, c'est elle qui va permettre au serveur X de gérer les commandes openGL.

Reprenons donc le cheminement. Une application 3D programmée en openGL va donc s'adresser à la libGL, celle-ci pour une raison ou un autre ne peut pas ouvrir un accès direct à la carte et elle va alors s'adresser à l'extension GLX au niveau du client X. Les commandes openGL vont alors transiter comme les commandes classiques 2D entre le client et le serveur X. Enfin, le serveur X va réaliser l'opération de rendu et envoyer les infos à la carte graphique pour qu'elle affiche ce qu'il faut à l'écran.

On voit donc ici que le rendu final est effectué au niveau du serveur X et pas directement par la carte graphique, d'où le nom de rendu indirect.
Ceci va avoir quelques avantages : on retrouve la transparence réseau, les commandes passant par le chemin classique de X. L'autre avantage, c'est qu'on ne dépend que de la libGL (qui est intriquée avec GLX) pour interpréter les commandes openGL et non d'une implémentation matérielle d'openGL dans la carte graphique.
A l'opposée, le rendu indirect a un énorme défaut, c'est qu'avec les serveurs X inférieurs à Xorg 7.1, le rendu est intégralement effectué au niveau du serveur par le processeur central de la machine. Et le CPU, il aime pas du tout ça parce qu'il n'est pas fait pour. Résultat, c'est effroyablement lent (facilement d'un facteur 20 par rapport au rendu direct).

Bibliographie

  • Mesa 3D, le projet qui fournit la bibliothèque libGL
  • GLX (page de wikipedia)

jeudi 9 novembre 2006

Comment marche X11/xorg et toute la clique ? 2° partie, le rendu 3D direct

Plan général

  1. Les bases, le rendu 2D
  2. Le rendu 3D direct
  3. Le rendu 3D indirect
  4. Composite et XGL
  5. AIGLX
  6. Suite et fin (ou comment ne plus avoir d'idée pour le titre)

Préambule

Cet article est basé sur ce que je comprend du fonctionnement de X11. Il est loin d'être parfait et comporte peut-être des erreurs. si c'est le cas, j'apprécierais qu'on me les signale pour pouvoir améliorer le tout.

De quoi on va causer

Nous avons vu dans la première partie, l'architecture client/serveur du système X11. Evidemment, il n'a pas échappé à votre oeil de lynx que le schéma ne mentionnait que la 2D et ne faisait qu'une vague référence à la 3D. C'est tout à fait normal, au moment où X11 a été inventé (vers 1984), la 3D n'était pas particulièrement développé et l'architecture n'en a pas forcément tenu compte d'emblée.
Heureusement pour nous, cette lacune a été comblée depuis et X peut maintenant gérer la 3D. C'est ce que nous allons voir maintenant (tout au moins une partie).

Comment ça marche donc ?

Avec X, la gestion de la 3D au niveau des applications repose sur une API (interface de programmation) assez connue nommée OpenGL. Cette API offre aux application un ensemble de fonctions qui permettent de dessiner en 3D (Direct3D fait de même sous MS-Windows).
Sous GNU/linux (et les autres), c'est le projet Mesa3D qui implémente OpenGL et founis la bibliothèque qui va bien aux applications, la libGL.

A ce stade, on est encore au niveau de l'application et pas encore de la carte graphique, et le problème, c'est que celle-ci ne comprend pas directement l'OpenGL. On va donc avoir forcément une transformation quelque part. C'est ce qu'on appellera le rendu 3D et suivant la méthode il pourra être direct ou indirect.

Le rendu direct

Rendu 3D/OpenGL direct

Il est représenté dans le schéma ci-dessus. Dans le rendu direct, l'application 3D va s'adresser à la libGL pour son affichage. La libGL va alors communiquer directement avec le serveur X, demander et obtenir l'autorisation d'accéder à la partie 3D de la carte graphique.
Une fois le droit d'accès donné, la libGL va convertir les commandes OpenGL en commandes compréhensibles par la carte et les envoyer directement à la carte 3D. Ces 2 dernières étapes mettent en jeu le pilote 3D lequel est fortement intriqué avec la libGL.

Dit comme ça, on voit pas trop l'intérêt ; mais en réalité, celà signifie que le traitement 3D est directement effectué par la carte (d'où son nom ;-) ), aucun passage par le serveur X et donc nettement moins de traitement au niveau du CPU. On a donc une accélération 3D complète de l'application.

L'inconvénient majeur de cette méthode, c'est qu'il faut dire au revoir à la transparence réseau, en effet, l'application accède à la libGL au niveau client X et cette dernière accède directement au matériel ; il est donc impossible d'avoir de l'affichage déporté avec cette méthode.

Pendant ce temps là, les applis non-3D continuent bien sur à utiliser le rendu 2D classique que nous avons déjà vu.

mercredi 8 novembre 2006

Comment marche X11/xorg et toute la clique ? Généralités, protocole X11, rendu 2D

Plan général

  1. Les bases, le rendu 2D
  2. Le rendu 3D direct
  3. Le rendu 3D indirect
  4. Composite et XGL
  5. AIGLX
  6. Suite et fin (ou comment ne plus avoir d'idée pour le titre)

Il y a des moments où on a pas envie de faire des trucs constructifs (i.e. mes sujets pour l'exam de chimie par exemple). hier, Je me suis donc mis à tester inkscape. Et histoire de pas faire ça dans le vide et de me clarifier certains points, j'ai donc décidé de schématiser le fonctionnement de X11.

Préambule

Cet article est basé sur ce que je comprend du fonctionnement de X11. Il est loin d'être parfait et comporte peut-être des erreurs. si c'est le cas, j'apprécierais qu'on me les signale pour pouvoir améliorer le tout.

Le début de la fin

Pour ceux qui ne le sauraient pas, X11 est le protocole qui est implémenté par xorg, le truc qui s'occupe de faire un bel affichage graphique sous les différents *nix modernes (linux, et BSD surtout). Son fonctionnement est un peu compliqué et je vais donc vous le détailler dans un schéma réalisé avec inkscape (cliquer pour la version plus grande, le svg est dispos sur demande).

X11 en rendu 2D

Explication de texte

X11 fonctionne sur le modèle client/serveur, on a donc d'un côté le client X (la xlib ou plus récemment, xcb) qui parle aux applications et au serveur X et d'un autre côté, le serveur X qui parle au matériel et au client X.

Suivons un peu le cheminement de tout ça. Imaginons que je vienne d'ouvrir openoffice writer et que je veuille taper du texte. La fenêtre d'openoffice est affichée sur mon écran par ma carte graphique. Celle-ci a reçu les infos du serveur X qui s'est adressé à sa partie 2D par le biais du pilote DDX.
J'appuie sur une touche (A). Le serveur X reçoit l'information comme quoi j'ai tapé sur la touche A, il va alors transmettre cette information au client X, celui-ci va alors la faire parvenir à openoffice.
Openoffice réagit et commande alors l'affichage de la lettre A sur la partie qu'elle destine à l'écriture. Elle envoie alors cette information au client X qui la transmet au serveur X. Le serveur X reçoit la commande et la converti en une commande compréhensible par la carte graphique grâce à son pilote.
La carte graphique trace la lettre et l'affiche sur l'écran.

C'est vrai que dit comme ça, ça peut sembler un peu usine à gaz. Mais il y a quand même un énorme avantage dans cette organisation ; le client et le serveur n'ont absolument pas besoin d'être sur la même machine ! En conséquence, il devient très simple d'avoir une machine puissante qui ne comporte que le client X (le serveur d'application) et une ou plusieurs machine peu puissante qui ne possède que le serveur X (le client d'application) et utilisent les applications sur le serveur d'applications. On fait ainsi simplement de l'affichage déporté.

Ce qui manque dans l'explication de texte

Bien sur, ce que j'ai écris au dessus n'est qu'un aperçu du fonctionnement du protocole X11, j'ai passé sous silence les toolkits graphiques qui sont des bibliothèques d'objets qui évitent à chaque application de réinventer la roue pour faire du graphique, j'ai également omis de parler des polices et du rendu côté serveur de celles-ci ainsi que de plein d'autres trucs (les window manager par ex).
Si je suis pas trop feignasse, je devrais d'ici peu palier un peu ces manques en vous parlant du rendu direct, du rendu indirect, de XGL et si j'arrive à comprendre correctement de AIGLX et de Glucose. Avec bien sur quelques schémas à la clé ; parce que inkscape, c'est bien :D

Un peu de biblio

vendredi 20 octobre 2006

Le remplaçant du vendredi

Aujourd'hui présentation d'un soft que j'ai découvert il y a quelques semaines et qui remplace très facilement et très agréablement le vénérable top, utilitaire de visualisation des process tournant sur la machine : htop

Quelques avantages :

  • il est en couleur
  • on peut scroller avec les flèches, verticalement et horizontalement
  • il est possible de masquer les threads noyau ou les threads des programmes ce qui rend l'affichage plus lisible
  • gestion de la souris
  • possibilité de modifier l'affichage de la mémoire, du CPU, etc l'occupation mémoire affichée étant l'occupation réelle (sans les tampons et caches)
  • affichage en liste ou en arbre de process

Bref, un soft que je ne regrette vraiment pas d'avoir installé pour remplacer top

htop dans toute sa splendeur

mercredi 27 septembre 2006

Linux n'est pas prêt pour le desktop

En voilà une phrase qu'on entend périodiquement aussi bien chez les pro-linux que chez les anti. A force, en lisant les moultes démonstrations, on finirait presque par croire que c'est vrai. Il y a juste un petit détail qui me chagrine à chaque fois...

C'est quoi le "desktop" ? Parce que de la réponse à cette question dépend la réalité de l'assertion en titre.

Et c'est là que je suis rarement d'accord avec l'auteur du moment, à chaque fois, il part du principe que le système doit s'installer sans douleur, se configurer quasi-magiquement (pilote et réglages) et ...
Et rien en fait, la plupart du temps, la démonstration s'arrête à ces 2 points et ne parle absolument pas de la suite, l'utilisation.
Mais franchement, quel OS peut se targuer de réussir les 2 points de la démonstration ? windows ? pas vraiment, la configuration par défaut de windows est atroce une fois sur 2 (le 60Hz sur un écran qui supporte le 100 sans broncher, j'ai toujours apprécié) et l'installation est pas vraiment simple (l'obligation d'installer chaque soft un par un est assez énervante, sans compter qu'il faut parfois redémarrer, pourquoi faire d'ailleurs ?) ; linux fait un peu mieux sur l'install, nettement mieux sur la configuration mais pêche dès qu'un pilote n'est pas inclus par défaut, ça a beau être de la mauvaise volonté des constructeur, c'est quand même très agaçant voire bloquant.

Résultat ? pour moi c'est sur, linux (comme windows d'ailleurs) n'est pas près pour ce desktop là.

Maintenant, considérons une autre définition que, pour ma part, je préfère : un desktop, c'est une machine qui permet de réaliser les tâches courantes que je veux réaliser : de la bureautique (texte, tableaux, présentations), du surf, mes mails, ma messagerie instantanée, suivre l'actualité, retoucher quelques images et les imprimer, jouer un peu, faire mes comptes, écouter de la musique, lire des videos ; j'ai à peu près fais le tour.

A l'exception peut-être des jeux commerciaux qui ne sont pas portés sous linux (et encore, il y a une tripotée de jeux natifs, commerciaux ou non), je peux faire tout ça indifféremment avec n'importe quel OS. Et en particulier, puisque c'est le propos qui nous intéresse, je peux faire tout ça sous GNU/linux

Pour finir parce que c'est déjà bien long, Effectivement GNU/linux n'est pas près pour le desktop si on ne considère que sa gestion du matériel (mais franchement, windows ne fait pas beaucoup mieux). Par contre, dès qu'on regarde l'utilisation de tous les jours, là, force est de constater que GNU/linux est déjà sur le desktop. Si il est prêt ou non est pour moi un combat d'arrière-garde.

PS : j'utilise volontairement linux dans la première partie car GNU/linux est rarement employé dans cette situation

PPS : je ne parle pas de MacOS X que je ne connais pas assez

jeudi 24 août 2006

9 - 1 = 8

C'est officiel depuis cet après midi, le dieu romain des enfers ne fait plus partie des grands de ce système.

L'Union Astronomique Internationale a donc décidé, par un vote à main levé, de redéfinir les objets célestes en planètes, planètes naines et petits corps du système solaire.

Pluton, découverte en 1930, n'aura donc même pas eu le temps de faire une révolution complète autour du soleil (248 ans) avant de se retrouver reléguée dans la deuxième catégorie et de disparaitre de la liste des planètes du système solaire (Mercure, Vénus, La Terre, Mars, Jupiter, Saturne, Uranus, Neptune). Neptune devient donc la planète la plus éloigné du soleil, ce qu'elle était déjà temporairement en raison de l'excentricité de l'orbite de Pluton.

la page de wikipedia sur le sujet est déjà à jour.

- page 1 de 3