Reprise du message précédent :
c'est cool merci pour m'avoir un peu plus eclairci le fonctionnement de linux, mais parmis tous ces noms (ddx, dri, exa, uxa, mesa, ...) il y en a pas qui sont obselete ou doublon par rapport au driver proprio nvidia ?
quel changement auront ils dans l'avenir ? vu qu'ils sont entrain de revoir les cpu et gpu
petite derniere, j'ai mon xorg.conf de vide, et mon ordi marche sans probleme apparant, est ce que jdois le remplir ou jpeux faire sans ?

si je ne me trompe pas les pilotes nvidia n'utilise pas l'architecture standard, donc pas de DRI, pas d'UXA vu que ce n'est qu'Intel, EXA je ne sais pas par contre.
 
Et sinon tu peux faire sans.

les pilotes nvidia accélèrent l'extension RENDER mais n'utilisent pas EXA de même pour l'accélération 3D.
 
Dans tous les cas, c'est une cuisine interne aux pilotes et ils n'utilisent pas les outils du serveur X

ca veut dire que les driver nvidia a ses propres outils pour communiquer avec le serveur X ?
Si oui, ca serait genial pour la communauté, s'ils etaient libéré ?

 
pas vraiment ses propres outils, plutôt ses propres fonctions d'accélération à lui (un peu comme UXA pour les pilotes intel).

 
Les performances sont excellentes, le blob tourne même sur un noyau très récent et/ou fortement patché (-rt)
 
C'est vraiment dommage qu'ils ne soient pas libérés

Topic sympa et d'utilité publique
 
Perso, je tourne sans xorg.conf sur un portable HP, tout fonctionne nickel (après avoir mis un .fdi pour la prise en charge correcte du touchpad). Néanmoins, j'ai un léger problème avec les souris que je branche en externe dessus.
Avec une MX510, aucun problème tout va bien. Avec la MX700, "molette vers le haut" déclenche un évènement qui defile l'élément sélectionné jusqu'en bas. Je ne comprend pas pourquoi, j'ai pas l'impression que ça le faisait avant. Comment résoudre le problème, sans pour autant remettre un xorg.conf ?

petit ajout sur les modelines

Une petite question à propos de "XFree86 DRI Extension" et les constructeurs ne fournissant pas de modules DRI (eg: NVidia) :

 
Attention, il ne s'agit pas du DRI module spécifique à votre carte graphique, mais de cette extension : http://cgit.freedesktop.org/xorg/x [...] free86/dri .
 
Donc la question est : si NVidia ne fournit pas de module DRI, comment est géré le déplacement de fenetres 3D pour ces drivers ? Les recouvrements de fenetre en direct rendering ?

Bonjour
 
J'ai un driver de dalle tactile (a la con) qui ne se configure pas dans Xorg, mais doit se lancer en tant que service "APRES" que xorg soit lancé. Malheureusement, le pilotage de la dalle ne fonctionne pas, malgré le lancement après le serveur X.
 
voici comment je procède :  
 

 
Si j'exécute ce script, cela ne fonctionne pas (bizarrement ca fonctionne sur mandriva 2008 mais pas sur ubuntu 8.04, et je suis sur ubuntu 8.04).
Si par contre, je fais ca :
 

 
puis dans le xterm ca :  
 

 
cela fonctionne.
 
Bien entendu, le service est tellement mal programmé que l'appel /usr/local/Gentouch_S/GT_service stop ne fonctionne pas, ou plutot si, le pilotage ne fonctionne plus mais le process (et donc le port série) reste ouvert.  
 
Je n'ai pas le choix, je dois utiliser ce matériel ( ) et je n'ai que pour documentation un README plus court que l'explication que je viens de vous donner.
 
Je cherche donc un moyen plus propre que le premier script que j'ai écrit ci-dessus pour démarrer des applications après que X soit démarré (j'ai essayé de configurer un .xinitrc et .xserverrc en mettant xclock dedans pour tester, mais rien ne se lance).
 
Je vous remercie de votre aide    

Le problème de ton script c'est que ta seconde commande n'est executée qu'une fois que la première est terminée, c'est à dire quand X se termine
 
Met ton service dans ton .xinitrc ou .Xsession (me souvient jamais de la différence ), et n'oublie surtout pas de lancer une appli (à priori un WM) après sinon X va se fermer aussitot.
 
Sinon si tu utilises gdm/kdm, le plus propre est certainement de lancer le service via ton WM (gnome ou KDE).

j'ai oublié le & quand j'ai tapé mon script    
 
Effectivement, j'ai un .Xsession mais je ne l'avais pas testé. Je vais donc essayer.
 
Je n'ai pas de gdm/kdm, donc je suis obligé de le faire à la main.

Un truc m'intrigue depuis que j'ai lu l'annonce pour la prochaine version d'ubuntu (celle planifiée pour la fin de l'année).
 
On peut y lire :
 

 
C'est la même HAL que vers laquelle xorg a migré sa détection matérielle depuis moins d'un an qui est déjà en train de passer aux oubliettes ?

C'est le même HAL mais cependant je ne comprends pas dans ce message que HAL passe aux oubliettes, c'est simplement pour la gestion de l'énergie ou des touches particulières des ordinateurs portables que HAL n'est plus (pour le moins) directement utilisé.

 
Oui. Mais c'est surtout l'implémentation qui passe aux oubliettes, le design et les principes restent pratiquement les mêmes (itération de périphs sur les bus, évènements hard, etc.)
 
Amha, c'est une bonne chose. Depuis le temps qu'on demandait la mort de cette aberration pour diverses raisons...

Merci pour vos lumière
 
Ce qui me "préoccupe", c'est ce que ça implique pour l'utilisateur. Hier, on se farcissait xorg.conf, aujourd'hui on se tape des .fdi (qui, à mon goût, sont bien pires que xorg.conf dés qu'il faut y toucher), et demain ?

 
Sans connaitre plus que ça le pilote nvidia, je présume qu'il communique par le biais de l'extension/API en question, sans utiliser le reste du DRI.
 
Après, tout il fait lui aussi du rendu direct.
 

 
+1, hal est pas trop mauvais aujourd'hui mais ça reste quand même le prototype, avec toutes les erreurs associées.
 

 
Pour l'instant, il n'y a pas de remplaçant bien déterminé pour tout ce dont a besoin X ( voir ce thread : http://lists.freedesktop.org/archi [...] 45561.html ). Donc pour un temps, hal va encore rester là.

Une bonne présentation en français sur X et tout ce qui va avec par Matthieu Herbb, un des dev de Xorg :
http://www.toulibre.org/pub/2009-0 [...] tation.pdf

http://www.toulibre.org/pub/2009-0 [...] ique-x.ogv

Vous le savez, le serveur 1.6 a apporté pas mal d'amélioration notamment dans l'architecture d'accélération 2D EXA. Je me suis amusé à refaire un benchmark qui évalue la vitesse de rendu des glyphes (les caractères grosso-modo). Ce point était un des problèmes d'EXA et a beaucoup bénéficié d'un patch en particulier qui a été intégré dans le 1.6 :
http://blog.fishsoup.net/2008/04/2 [...] he-pixmap/

la config est la mienne (cf profil) avec le serveur 1.4.1 (avant) et le 1.6.1 (après), dans les 2 cas, le pilotes est Nouveau (pilote libre pour les cartes graphiques Nvidia). 10 et 24px, c'est la taille des caractères.

Le résultat est assez éloquent (gardez tout de même à l'esprit que c'est un benchmark, donc qu'on met en évidence un comportement donné).

tu as benchmarké ça avec quoi ?

cf plus haut

j'accède pas à ce lien

Ouch, presque 500%

Tiens c'est marrant, à Xserver équivalent, le serveur trace plus vite les caractères de taille 24px que 10px  

Edit: si je lis bien le graphe...

je lis la même chose

 
le programme de bench :
http://fishsoup.net/misc/glyph-cache-benchmark.py

en fait il n'accède pas au lien a priori.

 
ok, je fail bien comme il faut là  

C'est un bench graphique, mais il m'a l'air d'avantage dépendant du CPU que de la carte graphique.

 
gnéee ?

Les chiffres que j'obtiens varient proportionnellement à la fréquence du CPU (bridée avec cpufreq).
 
@3.2Ghz
 
10 :                                                                                                                                                          
1: [220793.69620201105, 204569.58244815498, 205853.51668542926]                                                                                              
1: [210649.18777893859, 199729.35633737006, 212075.25517694699]
5: [498140.48898167477, 525936.00128527742, 468232.68299915403]
10: [771897.30195127055, 658943.48783975351, 810344.68608573813]
30: [2345098.8767464156, 2399988.877824828, 2318781.2975772195]
80: [5027057.7103596805, 5020100.7721312745, 5006861.1765766488]
24 :
1: [184484.28379520093, 176050.840754715, 192239.57162878601]
1: [181162.15695766962, 185257.19743710782, 179315.88136521255]
5: [347547.15046389605, 359132.11747581128, 365706.5796691819]
10: [681223.25513525179, 674239.02182949835, 694121.91901256703]
30: [2013993.4751428955, 2073493.1195229434, 2024208.6655328288]
80: [5153193.9599387608, 5172455.3866806151, 5137580.094825658]
 
 
@2.13Ghz
 
10 :
1: [118152.979388755, 169301.6950007726, 226192.0541575838]
1: [205783.55512875615, 224354.38184072776, 205263.70378640102]
5: [483465.82641654875, 493468.69534845243, 527161.13112579403]
10: [774168.53534008644, 813371.35163715819, 811395.89418586495]
30: [2184374.8263167208, 2374316.333209503, 2310413.2179952883]
80: [3297754.8192120441, 3214320.3083974849, 3338205.3681652737]
24 :
1: [191422.67017894657, 204226.86882084198, 197249.78414876724]
1: [133299.6488849133, 194726.38970262688, 200921.33366998762]
5: [289415.99311703554, 331453.35694194405, 376031.12073011004]
10: [708972.59036621894, 707754.4490272298, 714748.45366863732]
30: [2150712.5844935197, 2158248.9939819821, 2080643.6638468092]
80: [3220821.2589320042, 3382127.6587702506, 3262434.0926325652]
 
Du coup, je me demande si ce bench est représentatif de l'avancée du driver/xorg ou plus simplement bridé par divers facteurs extérieurs pas forcément comparables d'une machine à l'autre.
 
PS: les résultats bruts sont sans valeur, c'est avec le pilote nvidia proprio.

 
les 2 mesures sont faites avec la même machine, la même CG, et le même pilote.
 
C'est un peu normal que les mesures varient avec la vitesse du CPU, c'est lui qui envoie les instructions à la carte.

Justement. Si ça varie proportionnellement parce que "c'est le CPU qui envoie les instructions à la carte", ça sous entend qu'il n'y a pas suffisamment de puissance CPU pour alimenter la carte. Dés lors, on pourrait imaginer que l'optimisation n'est pas de 500% mais de 1000% pour peu que le CPU soit capable de suivre.
Je pense qu'en bridant la fréquence GPU sous la limite de saturation du CPU, on peut arriver à un résultat plus représentatif de la partie graphique.

 
Ben le benchmark ne cherche pas à évaluer la partie graphique, il donne juste une indication sur l'amélioration de la vitesse de rendu des polices avec un patch en particulier. Que ce soit par amélioration de l'utilisation du CPU ou du GPU n'a pas un intérêt fou. Ici, c'est le résultat qu'on met en évidence.

un petit article intéressant sur le un xorg lancé en utilisateur sans privilège :
http://lwn.net/Articles/341033/

J'ai un petit problème avec X. Je tourne avec un portable que j'utilise tantôt sur l'écran intégré, tantôt sur une station d'accueil avec un 22". Lorsque je l'utilise en autonome, pas de pb, quand je le met sur la station d'accueil, X démarre en 1024*768, et je suis obligé d'aller dans la conf de mon DE (KDE en l'occurence) pour repasser en 1680*1050. Je tourne sous Arch avec les drivers Intel pour le chip X3100 intégré au portable, le tout sous HAL/DBUS et sans xorg.conf.
A noter que la détection auto de la résolution d'écran sur l'externe a fonctionné pendant un temps et que je ne sais pas exactement quand est-ce que ça s'est mis à dérailler.  
 
Merci d'avance.

Le serveur X 1.7 est bientôt en vue, et donc Xorg 7.5 également. L'arbre principal des sources est figé pour le moment et devrait être branché sous peu \o/

https://linuxfr.org/2009/10/14/26025.html
 
un article sur la version 1.7 du serveur X ainsi que quelques nouvelles sur Xorg en général dont notamment une rapide explication du nouveau modèle de développement.

http://lwn.net/Articles/355821/
 
et un autre en anglais plus détaillé sur le nouveau processus.

Toujours le même problème avec xorg 1.7 et les drivers Intel 2.9

 
tu as rapporté le bug à ta distros ou à intel ?