Bon, a priori, ya de la demande, donc on va faire un petit topic sur Xorg.
 
 
Qu'est ce que Xorg ?
 
C'est une pile graphique qui implémente le protocole X11 d'affichage.
 
Plus prosaïquement, c'est le machin qui permet d'avoir du graphisme et d'interagir avec un environnement graphique.
 
C'est quoi ce nom à la noix ?
 
Xorg vient de X.org qui est le nom de domaine du consortium X11.
 
Ok, et ya quoi dedans ?
 
Xorg est une collection de différents modules :

• un serveur X qui implémente l'affichage en lui même
• un ensemble de bibliothèque (xlib et xcb) qui décrivent le protocole X11 et permettent aux logiciels ou bibliothèques haut niveau comme gtk,Qt de l'utiliser et donc de parler au serveur X
• des pilotes de sortie, typiquement pour piloter une carte graphique
• des pilotes d'entrée pour gérer clavier/souris/tablette graphique etc
• un certains nombres d'outils pour gérer tout ça

Les versions de tous ces modules sont décorrélées les unes de autres depuis que Xorg est modulaire (v7.0) contrairement à l'ancienne façon de fonctionner qui prévalait avec Xfree86.
 
C'est quoi ton machin Xfree86 ?
 
Xfree86 est une autre implémentation du protocole X11, à la base, il est issu de l'implémentation initiale de X.org. Il a ensuite vécu sa vie et est devenu l'implémentation de référence jusqu'à que des divergences sur la licence provoquent un fork qui est revenu vers les origines : Xorg.
 
c'est tout ?
pour le moment oui, mais j'ai plein de choses qui vont venir, notamment des explications sur différentes technologies que l'on trouve aujourd'hui et qui sont parfois mal comprise : EXA, composite, le DRM, mesa, gallium, RENDER, RandR, MPX etc.
 
Il va juste falloir être un peu patient parce que ça prend du temps à écrire.
 
En attendant, un peu de pub pour une explication de X11 et compagnie :
http://mjules.littleboboy.net/carn [...] -la-clique

Le serveur X

comme son nom l'indique, c'est un serveur d'affichage, il tourne donc sur le poste client. C'est lui qui reçoit les infos des périphériques d'entrées (clavier, souris, tablette, force), les envoie au client, reçoit les requêtes d'affichage du client et envoie le tout aux périphériques de sorties (Carte graphique, tablette braille, machine à café etc).

Le serveur X implémente un certains nombres d'extensions pour réaliser différentes tâches. Quelques exemples :

• Xvideo : permet l'accélération de certaines fonctions relatives à la vidéo (redimensionnement, changement d'espace colorimétrique etc)
• Render : implémente et permet l'accélération des opérations de composition via opérateur de Porter&Duff
• RandR (Resize and Rotate) : redimensionnement, rotation à chaud + gestion du multiécran
• GLX qui apporte la compréhension d'OpenGL
• Xinput pour gérer toutes les entrées (molette, touches spéciales, sensibilité d'une tablette graphique)

Il implémente également deux architectures d'accélération des fonctions 2D : XAA et EXA. L'accélération des fonctions 2D consiste à les faire réaliser côté serveur X en envoyant directement les commandes à la carte graphique.

• XAA est la plus ancienne, elle permet d'accélérer des opérations basiques telles que le tracé d'une ligne, remplissage d'un rectangle avec une couleur etc. L'ennui c'est qu'aujourd'hui, ces opérations ne sont quasiment plus utilisées directement et d'autres opérations non accélérés (l'anti aliasing des polices par ex) ont pris leur places. Résultat, XAA n'accélère plus vraiment les bureaux modernes.
• EXA a été inventé pour résoudre les problèmes qui se posaient avec XAA. Cette architecture accélère des opérations plus spécifiques : copie de zones opaques ou transparentes, opérateur de Porter&Duff (i.e. la composition). Ces opérations sont celles utiliseés dans les bureaux modernes (transparence, antialiasing, ombrage etc).

et UXA dans tout ça ? C'est une architecture d'accélération dérivant d'EXA mais spécifique aux cartes Intel sans mémoire spécifique et dépendante du gestionnaire de mémoire GEM.

Les pilotes de cartes graphiques, comment ça marche ?
 
Historiquement, il y a 2 pilotes pour chaque périphérique de sortie (carte graphique généralement).  
 
Un pilote dit DDX (Device Dependent X) qui est généralement fournis avec les distributions de Xorg, il permet de gérer les modes (résolution/fréquence/bi-écran etc), l'accélération de la 2D (EXA/XAA/UXA), l'accélération vidéo (Xv, XvMC etc), et quelques autres trucs.
 
Un pilote dit DRI (Direct Rendering Interface) qui lui gère les fonctions 3D de la carte, il est généralement fournis avec une bibliothèque appelée Mesa
 
Ok, c'est cool mais ça me dit pas comment ça marche tous ces trucs
 
Prenons les choses dans l'ordre alors.
 
le serveur X se lance. Il charge alors le pilote DDX qui va initialiser ou modifier les modes (l'initialisation est de plus en plus réalisée par la partie noyau du pilote, c'est ce qu'on appelle KMS : Kernel Mode Setting) ainsi que l'accélération 2D et vidéo. Si un pilote 3D est disponible, il va le noter et le rendre disponible pour les applications ayant besoin de la 3D.
 
J'ai besoin de 3D !
L'application qui a besoin de 3D exprime ça en utilisant une interface appelée OpenGL. Cette interface est implémentée par la bibliothèque Mesa. L'application va donc s'adresser à Mesa, cette dernière va alors regarder si il y a un pilote 3D en demandant au DDX, si c'est le cas et qu'il supporte la fonction demandée, elle passe la demande au pilote 3D qui va directement traduire ça pour la carte. Si la fonction n'est pas supportée ou que le pilote n'est pas disponible, alors Mesa l'envoie sur le processeur central de la machine pour qu'elle soit tout de même éxécutée.
 
Super ! mais je sais toujours pas ce que vient faire le DRM ici, je croyais que c'était mal les DRM ?
 
le DRM dont on va parler signifie Direct Rendering Manager et non Digital Right Management.
 
Le DRM est une partie du noyau (Linux ou BSD) qui permet de parler directement au GPU de la carte graphique. Il est nécessaire pour éviter qu'un pilote en espace utilisateur fasse n'importe quoi avec cette dernière.  
Accessoirement, il permet d'obtenir des performances à peu près correcte lorsqu'on s'adresse au moteur 3D.
 
initialement, il n'était utilisé que par le DRI mais de plus en plus de DDX l'utilisent pour programmer eux même le moteur 3D vu qu'il n'y a plus de partie 2D dans les puces récentes. Accessoirement, ça permet aussi de faire du transfert direct en mémoire (DMA).
 
Ça me dit toujours pas ce qu'est le « direct rendering » ?
 
J'ai posté un lien dans le premier message du sujet, c'est pas une blague hein
http://mjules.littleboboy.net/carn [...] e-2-partie
 
 
Et le pilote propriétaire nvidia ? Il a pas tout ça lui !
 
Et non, le pilote nvidia utilise un schéma un peu différent mais qui au final revient à peu près au même : un module noyau et un pilote DDX+3D.

déjà vendu encore,

Quelques questions pas si fréquentes que ça

Les modelines, quoi, pourquoi comment ?

Une modeline, c'est une suite de valeur qu'on fourni à l'écran pour qu'il affiche une résolution donnée à une fréquence donnée.

En théorie, le serveur X les génère pour vous à partir des informations données par votre écran. En pratique, si l'écran renvoie n'importe quoi, le serveur X peut s'emmêler les pédales et générer des modelines pour des résolutions/fréquences complètement aberrantes (genre 640x480@0Hz).

Dans ce cas, une solution (en dehors du changement d'écran) est de générer soit même les modelines pour le couple fréquence résolution voulu. Pour cela, 2 outils cvt ou gtf.
gtf (Général Timing Formula) est l'algorithme de génération le plus ancien. Il a été remplacé par cvt (Coordinated Video Timings) depuis maintenant quelques années et est censé apporter quelques bénéfices (cf http://www.uruk.org/~erich/projects/cvt/). J'aurais tendance à vous conseiller d'utiliser plutôt cvt que gtf mais si le premier vous donne de mauvais résultats, vous pouvez toujours tenter l'autre.

Générer une modeline est assez simple.
avec gtf :

avec cvt :

vous n'avez plus ensuite qu'à coller ça dans la partie idoine de votre xorg.conf (cf les tutoriaux sur randr1.2 notamment) et a appeler le mode en question.

Bibliographie
Quelques liens très utiles pour comprendre et configurer le serveur X et ces nouvelles capacités

• Généralités sur la pile graphique par Carl Worth, John Smirl (plus très à jour) et le futur de celle-ci par Keith Packard
• Randr1.2 : le multi-écran
• Input Hotplug : le branchement à chaud des périphériques d'entrée
• un billet qui décrit plutôt bien les différents intervenant dans la gestion des périphériques d'entrée
• EXA : différentes présentation de Carl Worth et Stéphane Marchesin

Non mais c'est quoi ce premier post tout riquiqui ?

Bon ma question, j'ai réglé mon xorg pour prendre en charge la touche caps lock, mais manque de pot, ca m'active aussi le verrou numérique, un peu ennuyant
Une idée pour me mettre enfin sur la voix d'un clavier qui s'utilise comme un vrai clavier ? (un peu chiant de maintenir shift pour taper un paquet de chiffres)

pi prems au passage

Ce serait bien si tu pouvais expliquer comment mesa fonctionne avec xorg/dri/drm ...

 
j'ai mis une explication en 3° post, ça t'éclaire un peu ?

Tiens justement j'ai cherche y'a 2-3 jours comment configurer mieux mon xorg pour le driver xf86-video-ati et un R300.
En effet, j'aimerai bien utiliser le composite de metacity, tout simple, mais lorsque je met le composite, tout va bien... sauf pour le surf, le scrolling est saccade parfois.
Ok, ma resolution est elevee, 1600*1200, mais les effets sont minuscules (metacity) ! J'ai donc cherche de la doc sur les differents options d'acceleration disponibles, pas trouve.
J'avais mis EXA, bizarrement en 2D c'est pas mieux, meme sans composite le scroll sur une page web est saccadee    
 
Donc ma question : quelqu'un aurait un pointeur vers de la doc pour xf86-video-ati, pour la configuration du Xorg (recent ) ?

les pilotes sont tous plutôt bien documentés, man ati devrait te renvoyer des infos.
http://dri.freedesktop.org/wiki/AT [...] 20eaf29566
 
 
Plus généralement, un truc qu'il faut comprendre c'est que bien que beaucoup de choses se retrouvent dans xorg.conf, souvent ça s'appliquent aux pilotes et donc c'est la doc de ces derniers qu'il faut consulter.

DRM, c'est pas Digital Right Management ?

ah si tiens

 
  man radeon renvoie a de la doc    
En fait j'imaginais pas du tout... j'ai meme pas essaye ca    
Merci !

 
Un peu
 
Puisque le direct rendering permet à libgl/mesa d'accéder directement au hardware, est-il possible d'ouvrir un contexte OpenGL (via SDL ou GLUT) sans serveur X, tout en bénéficiant de l'accélération hardware (avec un chip radeon<RV400 ou intel) ?  
Si j'ai bien compris, non, parce que l'implémentation du dialogue OpenGL<->hardware est faite dans les pilotes dri ?!?

Aujourd'hui, c'est complexe (voire impossible ?) parce que les pilotes DRI sont très liés à X. Dans le futur, ce devrait être possible. Si je ne me trompe pas, Gallium3D devrait permettre à la pile 3D de se séparer de X.

Si tu veux être sur, pose ta question sur dri-devel (le chan sur freenode ou la ML), ils pourront te répondre rapidement.

une explication de tout ça en anglais par un des dev de X :
http://people.freedesktop.org/~aja [...] nation.txt

Petite nouvelle, le très attendu Xserver 1.6 est sorti ce jour \o/ :
l'article relatif a cette sortie.

C'est deja change dans le 2.6.29 si tu as du intel ou du amd

Non, Digital Restrictions Management.

Peut-on y passer sans risque ? Faut-il encore modifier son xorf.conf pour y désactiver la prise en charge des périphériques par hal ?

c'est la version présente dans les versions de développement de mandriva,ubuntu et fedora.

Très bonne idée ce topic !
Un (très) petit tuto sur xlib pour toujours se souvenir de l'intérêt de lib de plus haut niveau : http://tronche.com/gui/x/xlib-tutorial/

 
pour AMD, c'est pas upstream, ya que intel, le support KMS d'AMD reste très expérimental actuellement (et il n'y a pas de gestionnaire de mémoire figé pour l'instant, ceci expliquant cela).
 

 
non, il vaut mieux configurer proprement hal pour qu'il gère les périphériques.

Ya encore un intérêt à utiliser la xlib en bas niveau vs xcb ? (modulo les facilités pas encore portées sur xcb)

ah je croyais que le pilote radeon avait ete le 1er a avoir cela sous Fedora.

 
expérimentalement oui, mais rien n'est releasé hors fedora. (Nouveau a également des patches pour KMS qui trainent) En fait, de ce que j'en comprends, tout repose sur un gestionnaire de mémoire, prérequis indispensable pour la gestion des modes dans le noyau. Et pour l'instant, le GEM+TTM, c'est encore en développement.

ok je pensais que radeon avait une interface TTM => GEM en attendant la refonte du code.

C'est le cas mais elle est encore instable à ma connaissance.

Autre soucis, sur mon portable.
Je suis passé récemment sur le driver intel 2.6.0 qui a requis l'installation de xorg 1.6 avec evdev.
J'ai recherché un peu comment configurer cet evdev et ca se passe généralement à coup de fichiers /usr/share/hal/fdi/policy.
Si je tente de copier le fichier  

vers  

Je me prend un reboot de session en boucle à l'ouverture de session (message du style "votre session n'a pas durée 10s..." ).
De plus depuis l'installation de xorg 1.6, l'écrran de connexion (gdm) est en qwerty et après ouverture de session j'ai le verr num d'activé. Pas très pratique sur un clavier de portable.
 
Le touchpad fait aussi le mort et je n'ai pas possibilité d'installer synaptics ou son driver sans désintaller xorg
 
Que faire ? Désactiver evdev dans xorg.conf ?

c'est pas evdev que tu configures via ces fichiers, c'est hal. Lequel par le biais des mécanismes de branchement à chaud envoie au serveur X différents paramètres de configuration (la langue notamment) qui sont ensuite appliqués par le pilote d'entrée, evdev dans le cas présent.

gdm en qwerty, ça signifie que hal envoie un code us.

dans ton fichier   /etc/hal/fdi/policy/10-keymap.fdi tu as essayé de changer us vers fr ?
<merge key="input.xkb.layout" type="string">fr</merge>

tu as quoi dans les logs concernant evdev ou Xorg ?

Sinon, oui, en dernier recours, tu peux désactiver l'utilisation de hal via l'option AutoAddDevices à false.

http://fedoraproject.org/wiki/Feat [...] Experience

pour numlock, aucune idée. Pour synaptic, c'est un problème avec ta distro.

Oui j'ai bien tenté fr dans le keymap.fdi.
Au reboot du portable j'ai retrouvé gdm en fr alors que redémarrage de X ca me donnais us.

Petit problème depuis les derniers Xorg et le support du hotplug : par défaut, les joysticks/joypads, se prennent pour une souris, ça bouge le pointeur.
Si la fonction peut être sympa pour certaines applications, pour jouer, c'est super naze, ça fait tout foirer.
 
Et je n'arrive pas à trouver de solutions satisfaisante ... à part les boulets sur les forums Ubuntu pour qui désactiver le hotplug est la solution.

J'ai une petite question a laquelle je n'ai pas trouve de reponse via quelques recherches : lorsque j'execute une application via ssh (avec forward X) la decoration de la fenetre est OK, mais les boutons sont dessines avec le theme par defaut tout moche, qui s'integre pas du tout.
 
Y'a-t-il une solution pour dire que la decoration devrait etre faite avec le theme gnome ? Ca le fait avec toutes les applis, gnome, qt, kde...

 
 
C'est normal selon moi, tu déportes l'affichage d'une application d'une machine A sur une machine B, mais B et A n'ont pas forcément les mêmes thèmes/skins/etc
 
Si depuis ma debian je ssh -X une ubuntu et que je lance un gnome-terminal d'ubuntu, je ne verrais pas le thème orange propre à Unbuntu (humanity truc jsaisplukoi) vu qu'il n'existe pas sur ma debian (responsable de l'affichage ici). Du coup ça serait pas étonnant qu'il se rabatte sur le thème par défaut.

Oui mais on ne peut pas demander de decorer avec _mon_ theme local ? Ou c'est le serveur X qui decore ? Je pensais que c'etait le decorateur local qui s'en chargeait ...

 
Je ne sais pas, en tout cas le comportement doit être :
1. tenter de charger le thème demandé
2. s'il n'est pas disponible sur la machine locale, on adopte le comportement par défaut
 
Faut sans doute que tu exécutes un truc genre :
    MON_THEME="truc dispo en local" mon_appli
(si évidemment le thème est définissable à la volée en surchargeant une variable d'environnement)

c'est normal : le contenu de la fenêtre est géré par le client X (qui est sur la machine distante, le serveur X il est sur ta machine locale), donc c'est lui qui gère le thème utilisé
la seule solution c'est que tu installes le thème que tu veux sur ta machine distante

Merci a vous deux... spas tres grave, juste dommage ^^