Jump to content

[Résolu] gutsy - ati - compiz et c'est la cata...


tyrann27

Recommended Posts

ALors voilà, depuis la mise à jour vers gutsy, je ne peux plus utiliser compiz-fusion :pleure:

Description matérielle :

Portable avec une ati 9700 mobility (donc un R350 c'est bien ça ?)

Cas testés :

- driver libre + AiGLX --> foirage, il veut pas démarrer compiz.

- driver libre + XGL --> foirage, X plante tout simplement.

- driver fglrx par paquet + AiGLX --> tout le monde sait que c'est pas possible :craint:

- driver fglrx par paquet+ XGL --> compiz démarre mais XGL s'amuse à taper mon proco à 100%, lorsque je me mets dans une zone de saisie Fx j'ai droit à une lettre par seconde 1/2 environ.

D'après glxinfo, j'ai le direct rendering (sauf avec XGL).

Avec fglrxinfo, ma carte est bien installée.

Donc c'est un peu la cata...

En plus quand compiz démarre j'ai jamais les bordures de fenetre ! (mais ça je vais chercher sur la doc...)

Donc voilà, un coup de patte ne serait pas de refus ^_^

Merci d'avance

Link to post
Share on other sites
ALors voilà, depuis la mise à jour vers gutsy, je ne peux plus utiliser compiz-fusion :francais:

Description matérielle :

Portable avec une ati 9700 mobility (donc un R350 c'est bien ça ?)

Cas testés :

- driver libre + AiGLX --> foirage, il veut pas démarrer compiz.

- driver libre + XGL --> foirage, X plante tout simplement.

- driver fglrx par paquet + AiGLX --> tout le monde sait que c'est pas possible :keskidit:

- driver fglrx par paquet+ XGL --> compiz démarre mais XGL s'amuse à taper mon proco à 100%, lorsque je me mets dans une zone de saisie Fx j'ai droit à une lettre par seconde 1/2 environ.

D'après glxinfo, j'ai le direct rendering (sauf avec XGL).

Avec fglrxinfo, ma carte est bien installée.

Donc c'est un peu la cata...

En plus quand compiz démarre j'ai jamais les bordures de fenetre ! (mais ça je vais chercher sur la doc...)

Donc voilà, un coup de patte ne serait pas de refus ^_^

Merci d'avance

J'ai eu ce souci (Radeon Mobility X700 + fglrx + XGL) en essayant d'installer les drivers 8.41 (au lieu des 8.37 dans les dépôts) via un tutorial sur le net (qui en faisait un .deb). J'ai réussi à récupérer le coup et ça remarche.

Mais sinon, j'ai juste deux choses à faire (à partir d'une installation fraîche) et ça marche out-of-the-box: installer xserver-xgl dans synaptic, et dire oui pour les drivers vidéo propriétaires dans le restricted-modules. J'ajoute la ligne pour le Powerplay dans mon xorg.conf et quand je relance ma session, tout tourne.

Donc, je ne saurais pas trop t'aider, si ça ne marche pas aussi simplement pour toi. :pastaper:

Link to post
Share on other sites

Par defaut la CG pas bien installé, l'interface en anglais, et dans adept on me propose de migrer vers la 7.10 alors que je viens de l'installer ^^

J'avais deja eu ce probleme en installant la 7.04 avec le live cd, là pareil, il existe une version non live cd ?

edit : ai trouvé la version alternate, mais apres le boot, ecran noir, pfff

Link to post
Share on other sites

Hum...

Je tente sous gnome et paf ça fonctionne :francais:

Donc comme sous xfce4 compiz se lance mais que j'ai pas les décorations de fenetre, je supose que c'est gtk-window-decorator qui merdouille ?

EDIT: c'est normal que mon cpu soit bouffé à 50% constamment pas XGL ????????

EDIT2: à la maison ça fait le meme... 50 à 60% du proco mangé par XGL :(

Niveau autonomie pour le laptop c'est pas le top hein !

Link to post
Share on other sites
Hum...

Je tente sous gnome et paf ça fonctionne :transpi:

Donc comme sous xfce4 compiz se lance mais que j'ai pas les décorations de fenetre, je supose que c'est gtk-window-decorator qui merdouille ?

EDIT: c'est normal que mon cpu soit bouffé à 50% constamment pas XGL ????????

EDIT2: à la maison ça fait le meme... 50 à 60% du proco mangé par XGL :(

Niveau autonomie pour le laptop c'est pas le top hein !

Non, ce n'est pas normal... J'utilise aussi sur un portable, et même si ça consomme trop pour une bonne autonomie, ça ne pompe pas non plus 50% de mon CPU. Je tiens environ 1h30 avec XGL-compiz contre 2h sans (2h30-3h sous XP :fume: ).

Link to post
Share on other sites

Mmmmmh...

En fait le problème ne se situe pas sur l'autonomie parce que ça je m'en fous je suis sur secteur tout le temps au taf. Ce qui m'embete c'est que mon cpu (centrino) est tout le temps à 1.6 (donc au max) et donc il chauffe plus et donc le ventilo tourne sans arret et avec tout ce que ça entraine...

Bref je suis revenu sans compiz pour l'instant avec xfce4.

Petite expérience sur mon desktop :

Je trouve du plus bel effet de mettre le plugin cube gears (les engrenages qui tournent au milieu du cube) et d'augmenter la transparence du cube sans rotation. Autrement dit, je vois les gears qui tournent à travers mon bureau !

Bref... Mon cpu amd qui est sur "on-demand" est à 2.2 sans arret. Je retire la transparence et il redescend à 1.8...

Que dois-je en conclure ?

Je commence à devenir fou avec toutes ces histoires de consommation cpu et accélération graphique blablabla.

Qu'est-ce qui est juste ? Est-ce que mon cpu est censé être influencé par l'option mentionnée plus haut ou alors c'est mon gpu qui devrait tout faire et j'ai encore un problème quelconque ?

Link to post
Share on other sites

Ça dépend comment c'est fait, mais à priori faire tourner un truc 3D comme ça, déjà ça va empêcher que le CPU se mette en sommeil.

Dans ton cas si tu t'en fout de la batterie c'est pas vraiment grave (dans le cas contraire le mieux c'est de tout désactiver, mettre un kernel notics et installer powertop pour régler le reste).

Ici normalement ça devrait prendre autant qu'une application 3D équivalente, c'est à dire

1) faire tourner des roues dans un cube à 60fps : presque rien

2) afficher une texture en 1280x800 (ou quelle que soit la résolution de ton écran) par dessus avec de la transparence... et ça c'est clairement moins facile!

En fonction de la technologie utilisée (TFP ou pas, Xgl ou pas...), ça peut utiliser du CPU ou du GPU. En général, plus il y a d'effets plus ça va consommer, surtout quand ils sont animés!

Link to post
Share on other sites
  • 2 weeks later...

Ben.......

Pour le moment sur mon desktop c'est fglrx des dépots + XGL et ça tourne sans *trop* de soucis. Si on ne compte bien sur pas la consommation de CPU excessive :sm:

Sur mon laptop c'est autre chose...

J'ai fait une réinstall toute fraiche parce que j'avais un peu trop bidouillé et pas envie de me prendre la tete.

Donc je viens justement d'essayer de réinstaller les proprios du site ati mais comme la dernière fois, impossible de le faire fonctionner, je me prends toujours un mesa avec fglrxinfo...

Donc je vais sur le site d'amd, je fouille et Ô que vois-je ? tout plein de mobility supportée, sauf la mienne :yes: une 9700

Donc je suis revenu à XFCE normal tout simple et en fait tu viens de me donner envie de réessayer avec XGL, pitet que ça bouffera plus autant...

A tout de suite :smack:

EDIT :

Bon je laisse tomber j'en ai marre... J'installe XGl, mon clavier passe en qwerty et pas moyen de le remettre. Je n'ai plus de bordure de fenetre meme si j'installe emerald.

Bref ça m'énerve >_<

Link to post
Share on other sites
  • 2 weeks later...

Donc, pour repartir sur ce qu'on disait dans le bar :

driver libre + XGL --> foirage, X plante tout simplement

... ça, a priori, ce n'est pas très étonnant... de toute façon, ton but semble être de vouloir se débarasser de xgl...

driver libre + AiGLX --> foirage, il veut pas démarrer compiz.

Là, faudrait nous en dire plus sur comment tu t'y es pris...

Un truc à noter, ceci dit: j'ai vu plusieurs fois des PC sur lesquels était installé fglrx, et où on n'arrivait pas à avoir le dri par le driver libre... en fait, fglrx foutait le zouc dans des symlinks vers des libs utiles au driver libre (pour y coller les siennes... c'te cochonnerie)... soit on se tape le nettoyage à la mimine (faut aimer la chirurgie en plein charnier de champ de bataille), soit on purge tout ce qui a trait à xgl et fglrx, puis on force la réinstallation de X.org (en entier, ou juste le core), puis on peut repartir sur des bases saines...

Désolé de commencer par t'annoncer cette mesure contraignante (si tu veux pouvoir repartir sur xgl, sauvegarde ce dont tu pourrais avoir besoin avant d'essayer d'utiliser le driver libre proprement), mais j'ai vraiment vu trop de choses bizarres avec fglrx...

Sinon, kernel binaire de ta distro ou compilé toi-même (pour les home-made, ne pas oublier d'y compiler l'agpgart de ta mobo, et la partie kernel du driver libre... si kernel binaire, tout devrait y être)?

Après, bah, fais péter ton corg.conf, et éventuellement, si ça se passe vraiment mal, le /var/log/Xorg.log.0 (son écriture n'est généralement, et heureusement, pas synchrone: il faut terminer la session de X.org pour qu'il soit mis à jour), ainsi qu'un "lsmod|grep radeon", "glxinfo|grep direct" et "glxinfo|grep vendor"... et on pourra voir ce qui bloque...

Link to post
Share on other sites

Bon j'ai mis à jour le titre du topic vu qu'effectivement je veux me débarasser d'XGL !

Effectivement j'ai joué avec fglrx comme tu as pu le lire...

J'ai un kernel binaire.

J'ai pas peur de mettre les mains dans le cambouis donc pour ça ya pas de soucis...

Je viens de réinstaller en purge tous les paquets xserver-xorg* installés

J'ai dpkg-reconfigure mon xserver-xorg et j'ai mis en place le driver ati.

Je reviens exactement au meme soucis qu'avant.

Alors dans mon xorg.conf :

tyrann@tyrann:~$ cat /etc/X11/xorg.conf
# xorg.conf (xorg X Window System server configuration file)
#
# This file was generated by dexconf, the Debian X Configuration tool, using
# values from the debconf database.
#
# Edit this file with caution, and see the xorg.conf manual page.
# (Type "man xorg.conf" at the shell prompt.)
#
# This file is automatically updated on xserver-xorg package upgrades *only*
# if it has not been modified since the last upgrade of the xserver-xorg
# package.
#
# If you have edited this file but would like it to be automatically updated
# again, run the following command:
#   sudo dpkg-reconfigure -phigh xserver-xorg

Section "Files"
EndSection

Section "InputDevice"
	Identifier	  "Generic Keyboard"
	Driver		  "kbd"
	Option		  "CoreKeyboard"
	Option		  "XkbRules"	  "xorg"
	Option		  "XkbModel"	  "pc105"
	Option		  "XkbLayout"	 "be"
EndSection

Section "InputDevice"
	Identifier	  "Configured Mouse"
	Driver		  "mouse"
	Option		  "CorePointer"
	Option		  "Device"				"/dev/input/mice"
	Option		  "Protocol"			  "ExplorerPS/2"
	Option		  "ZAxisMapping"		  "4 5"
EndSection

Section "InputDevice"
	Identifier	  "Synaptics Touchpad"
	Driver		  "synaptics"
	Option		  "SendCoreEvents"		"true"
	Option		  "Device"				"/dev/psaux"
	Option		  "Protocol"			  "auto-dev"
	Option		  "HorizEdgeScroll"	   "0"
EndSection

Section "InputDevice"
	Driver		  "wacom"
	Identifier	  "stylus"
	Option		  "Device"		"/dev/input/wacom"
	Option		  "Type"		  "stylus"
	Option		  "ForceDevice"   "ISDV4"		 # Tablet PC ONLY
EndSection

Section "InputDevice"
	Driver		  "wacom"
	Identifier	  "eraser"
	Option		  "Device"		"/dev/input/wacom"
	Option		  "Type"		  "eraser"
	Option		  "ForceDevice"   "ISDV4"		 # Tablet PC ONLY
EndSection

Section "InputDevice"
	Driver		  "wacom"
	Identifier	  "cursor"
	Option		  "Device"		"/dev/input/wacom"
	Option		  "Type"		  "cursor"
	Option		  "ForceDevice"   "ISDV4"		 # Tablet PC ONLY
EndSection

Section "Device"
	Identifier	  "ATI Technologies Inc RV350 [Mobility Radeon 9700 M10]"
	Driver		  "ati"
	BusID		   "PCI:1:0:0"
EndSection

Section "Monitor"
	Identifier	  "Écran générique"
	Option		  "DPMS"
	HorizSync	   28-50
	VertRefresh	 43-75
EndSection

Section "Screen"
	Identifier	  "Default Screen"
	Device		  "ATI Technologies Inc RV350 [Mobility Radeon 9700 M10]"
	Monitor		 "Écran générique"
	DefaultDepth	24
	SubSection "Display"
			Modes		   "1400x1050"
	EndSubSection
EndSection

Section "ServerLayout"
	Identifier	  "Default Layout"
	Screen		  "Default Screen"
	InputDevice	 "Generic Keyboard"
	InputDevice	 "Configured Mouse"

# Uncomment if you have a wacom tablet
#	   InputDevice	 "stylus"		"SendCoreEvents"
#	   InputDevice	 "cursor"		"SendCoreEvents"
#	   InputDevice	 "eraser"		"SendCoreEvents"
	InputDevice	 "Synaptics Touchpad"
EndSection

Je vérifie si le module radeon est chargé et ce n'est pas le cas... Donc je le charge:

tyrann@tyrann:~$ lsmod | grep radeon
tyrann@tyrann:~$ sudo modprobe radeon
WARNING: Error inserting drm (/lib/modules/2.6.22-14-generic/kernel/drivers/char/drm/drm.ko): Cannot allocate memory
FATAL: Error inserting radeon (/lib/modules/2.6.22-14-generic/kernel/drivers/char/drm/radeon.ko): Unknown symbol in module, or unknown parameter (see dmesg)
tyrann@tyrann:~$

Je pense que le soucis est là...

donc un p'tit dmesg

[ 2005.192000] radeon: Unknown symbol drm_open
[ 2005.192000] radeon: Unknown symbol drm_fasync
[ 2005.192000] radeon: Unknown symbol drm_poll
[ 2005.192000] radeon: Unknown symbol drm_get_resource_len
[ 2005.192000] radeon: Unknown symbol drm_core_get_reg_ofs
[ 2005.192000] radeon: Unknown symbol drm_irq_uninstall
[ 2005.192000] radeon: Unknown symbol drm_ioctl
[ 2005.192000] radeon: Unknown symbol drm_exit
[ 2005.192000] radeon: Unknown symbol drm_debug
[ 2005.192000] radeon: Unknown symbol drm_core_ioremapfree
[ 2005.192000] radeon: Unknown symbol drm_core_get_map_ofs
[ 2005.192000] radeon: Unknown symbol drm_init
[ 2005.192000] radeon: Unknown symbol drm_addmap
[ 2005.192000] radeon: Unknown symbol drm_get_resource_start
[ 2005.192000] radeon: Unknown symbol drm_vbl_send_signals
[ 2005.192000] radeon: Unknown symbol drm_ati_pcigart_init
[ 2005.192000] radeon: Unknown symbol drm_core_ioremap
[ 2005.192000] radeon: Unknown symbol drm_mmap
[ 2005.192000] radeon: Unknown symbol drm_order
[ 2005.192000] radeon: Unknown symbol drm_ati_pcigart_cleanup
[ 2005.192000] radeon: Unknown symbol drm_core_reclaim_buffers
[ 2005.192000] radeon: Unknown symbol drm_release

et enfin

tyrann@tyrann:~$ glxinfo | grep vendor
Xlib:  extension "XFree86-DRI" missing on display ":0.0".
server glx vendor string: SGI
client glx vendor string: ATI
OpenGL vendor string: Mesa project: www.mesa3d.org
tyrann@tyrann:~$

Voilà j'espère que c'est suffisant !

Ah oui encore une chose...

Je ne t'ai pas collé tout le log de Xorg mais dedans j'ai une ligne (EE) AIGLX: Screen 0 is not DRI capable

Voilà et merci de ton aide :transpi:

Link to post
Share on other sites

Bon, en effet, si le module pour dri ne se charge pas, et qu'il empêche celui pour radeon de se charger (puisque ce dernier ne trouve pas les fonctions du module dri qui n'est pas chargé), ça bloque... par contre, ça explique au moins pourquoi tes logs te disent que l'écran n'est pas capable de faire du dri... à ce stade, tout ce qu'il peut te rester, c'est mesa (tout en logiciel), ipso facto incompatible avec la notion de dri...

Ceci dit, quelque chose me chiffonne:

tyrann@tyrann:~$ glxinfo | grep vendor

Xlib: extension "XFree86-DRI" missing on display ":0.0".

server glx vendor string: SGI

client glx vendor string: ATI

OpenGL vendor string: Mesa project: www.mesa3d.org

tyrann@tyrann:~$

... ça, c'est tout sauf normal... surtout la ligne "client glx vendor string: ATI"... ça sent les restes de fglrx à plein nez

Normalement, tu devrais plutôt avoir :

~$glxinfo|grep vendor

server glx vendor string: SGI

client glx vendor string: SGI

OpenGL vendor string: DRI R300 Project

"ATI" à la place de "SGI" est caractéristique de fglrx (quant tu vois le nom de la marque en majuscules, ça vient de chez eux pour ainsi dire à coup sûr)...

Donc, quelques questions: tes manips, tu les as bien faites en tty, ie hors X.org (sous un truc avec gdm, le plus direct étant encore de faire un "/etc/init.d/gdm stop")? Auquel cas, avant de les faire, tu as bien déchargé fglrx ("modprobe -r") et tout ce qui était spécifique au GPU?

Ca peut venir de là... pour passer d'un driver à un autre radicalement différent, il se peut qu'il y ait besoin de réinitialiser le BIOS du GPU: ça se fait à chaque reboot, ou en tirant partir de l'extension int0, quoique cette dernière étape marche parfois aléatoirement (sacrée litote: je considère ça comme du pur mambo-jambo qui peut, avec une barette de RAM cramée et des cartes wifi usb, se targuer d'être l'une des rares choses à avoir fait hard-locker l'une de mes machines), surtout quand on traite à la fois avec le blob et le driver libre...

... dans ce cas, tu peux commencer par essayer un reboot (voire un arrêt, suivi d'un redémarrage): bien que ce ne soit pas tellement l'habitude de la maison, ça forcera au moins le GPU à repasser par son BIOS... et refaire la reinstallation de xorg au besoin... à tout hasard, si tu n'as pas rebooté, un "lsmod|grep fglrx" donne quoi (et tant qu'on y est, j'élargis ma question à un "lsmod" tout court... vu qu'ostensiblement, quelque chose empêche le kernel d'avoir un accès au bus qui contient le périphérique à driser, il est probable que ce soit quelque chose de déjà chargé)?

Tu peux aussi vérifier que tu as bien le paquet "libgl1-mesa-dri" (voire le réinstaller aussi... bien qu'il devrait venir avec le X.org de base)... et tu devrais aussi rajouter

Section "DRI"

Mode 0666

EndSection

dans ton xorg.conf...

... bien que ça ne devrait pas empêcher de charger les modules à la mimine avant de lancer X.org, si ces choses manquent, dri ne fonctionnera pas...

En outre, bien que, normalement, ce qui est nécessaire sera chargé automatiquement, il n'est jamais du luxe de mettre une section module dans le xorg.conf, du genre :

Section "Module"

Load "i2c"

Load "bitmap"

Load "ddc"

Load "dri"

Load "extmod"

Load "freetype"

Load "glx"

Load "int10"

Load "vbe"

EndSection

Sinon, pour le log de X.org, c'est quand même bien pratique pour débuguer... si tu le postes ici, tu peux utiliser des blockquote... sinon, tu peux le mettre sur pastebin...

Link to post
Share on other sites

Bon... ça progresse... ce n'est pas la première fois que je vois qu'il manque la libgl1 sur ta distro et ça confirme donc que l'installer est une chose à y faire pour faire marcher dri (je ne m'étendrai pas plus sur la question... :chinois: ... c'est un choix un peu surprenant, mais après tout... à moins que ce ne soit les scripts d'installation des blobs qui foutent le zouc, auquel cas, c'est plutôt "goretto")...

On n'est visiblement pas loin (dri se charge, permettant au module radeon de se charger... au passage, d'ailleurs, rien de bizarre au "dmesg"?), mais il y a encore le :

client glx vendor string: ATI

qui me perturbe... pourtant, c'est bien la bonne extension ("DRI R300 Project") qui renvoie les commandes au bon serveur ("SGI")... mais il semble toujours que ce soit les fonctions opengl du blob qui servent à traiter les demandes des clients OpenGL ("ATI"... yukkk!... grossss! ... buuuhh!)...

En gros, les clients opengl veulent parler au GPU, mais doivent passer par des mots qu'on leur impose... il leur est alors imposé de parler en "fglrx", à une extension de X.org qui parle en "radeon" (libre), qui elle-même parle au serveur en "radeon"... forcément, ça coince: personne ne comprend ce que disent les applications opengl...

Comment t'y es tu pris, pour la réinstallation de X.org? En cherchant dans mes MP, j'ai retrouvé des échanges où j'avais aidé TOM_KILLERz à résoudre le même genre de problème (sur une Debian)... ce qui s'était soldé par TOM_KILLERz qui avait réussi à faire disparaître le "ATI" persistant (c'était exactement le même problème... passage de fglrx au driver radeon, et pas de dri, avec le "ATI" persistant dans le rôle du fournisseur d'instructions opengl) en faisant :

apt-get install --reinstall xserver-xorg xserver-xorg-core

Ce ne sera pas une nouvelle pour toi que je déteste fglrx (ce sont les blobs, que je hais, avant tout... pas de chichi: je les mets tous à la même enseigne, quelles que soient leurs performances), et ce n'est pas pour rien: ce truc est une vrai plaie quand on veut s'en débarasser... sur Gentoo, il y a bien "eselect" qui est merveilleux (en faisant, par exemple, "eselect opengl set ati", ça remet les choses en ordre tout seul), mais sous les Debian-like, je n'ai rien trouvé d'aussi simple... dpkg-reconfigure ne remet pas toujours les choses en leur état: le plus simple est de forcer une réinstall (et d'une distrib à l'autre, d'une version de X.org a l'autre, d'une version du blob à l'autre, les paquets qu'il faut réinstaller peuvent varier un peu... notamment, j'ai déjà dû forcer la réinstallation d'un kernel ou d'autres mignonneries)...

... je pense vraiment que le plus probable est que le problème vient d'un fglrx qui s'incruste alors qu'on avait dit "pas de baskets"...

Bon, après au sujet des logs... déjà, ils sont très intéressants, pour moi, du moins :transpi:, puisqu'en ce moment, je n'ai vraiment pas le temps de tester X.org, alors que j'aime pourtant beaucoup ça (j'en suis encore à la 7.2 de Debian Testing... en ce moment, je tripe plus sur la manière dont je vais prochainement me débarasser de mes WRT par quelque chose de beaucoup plus costaud... et ça me bouffe le peu de temps que j'ai)... ostensiblement, tu as un X.org 7.3, avec le support du dernier Xrandr (vraiment hâte de tester ce que ça donne au niveau du multi-écran... en espérant que le dri multi-PCIe pour faire du joli tri-écran accéléré ait commencé à être stabilisé... en ce qui me concerne, ça fait un an et demi que j'attends l'unification du multi-écran pour faciliter le multi-PCIe... donc, nécessairement, ça m'intéresse)...

... ça m'étonne un peu, pas pour le X.org 7.3, mais parce que j'en étais resté sur l'idée que le driver radeon était l'un des seuls à ne pas être passé à Xrandr, et qu'il faudrait attendre la 7.4 pour ça (bien que je savais que c'était possible via le CVS)... ou alors, c'est un driver du CVS, dans ta distro :byebye: ?

... sinon, le code du support de la sortie TV a visiblement aussi été intégré (une vraie bénédiction qui m'évitera d'investir dans un scaler hors de prix pour mon vieux et brave Panasonic 72cm qui a pris place dans le tri-écran de mon bureau :byebye: )....

Mais, du coup, ces logs-là, ils me sont un peu moins familiers, car je n'en ai pas encore vu d'aussi récents... aussi m'est-il un peu difficile de repérer ce qui pourrait y être étrange (vu le nombre de nouveautés, et tout ce qui a changé)...

Bon, il y a toujours des choses comme :

(II) RADEON(0): Render acceleration unsupported on Radeon 9500/9700 and newer.

(II) RADEON(0): Render acceleration disabled

... mais ça, ça y est depuis des éons, et ça ne veut rien dire de plus que le support des 9200 est presque complet, et celui des autres, expérimental, puisqu'issu du reverse-engineering... ça le fait aussi chez moi, et ça ne m'empêche pas d'avoir l'accélération... à la limite; il serait explicitement fait mention d'un autre type de carte (du genre X300m, qui sont en fait souvent des X1xxx maquillées), là, oui, d'accord, ce serait un problème... mais le "9500/9700 and newer" ne souligne rien de plus que le caractère reverse-engineeré, et pas l'absence d'accélération comme suggéré (faudrait d'ailleurs qu'ils pensent à changer keurs logs... ou qu'on bugreporte pour les changer)...

Il y a bien aussi des warnings sur DDC2, mais je pense que c'est plutôt quelque chose dû à la présence de Xrandr 1.2...

Bref, j'insiste, mais je pense que le problème est qu'il reste encore des choses de fglrx quelque part... et puis, franchement, il n'y a pas de raison... on a l'air d'avoir sensiblement le même genre de machine (IPW2200, d'après ton lsmod, et 9700m... la mienne est un centrino 1.7GHz...)... à la limite, j'ai peut-être juste un écran un peu plus grand (1920x1200, en 17" wide)... si ça marche sur mon laptop, avec le même GPU et une résolution plus grande, il n'y a pas de raison que ça ne marche pas sur le tien...

Link to post
Share on other sites

Mon laptop est un Acer travelmate 8003LMI et moi c'est du 15" en 1400x1050.

Donc effectivement ça devrait fonctionner !

Je viens de réinstaller une fois de plus xserver-xorg et xserver-xorg-core avec --purge en plus.

Rien à faire, rien ne change...

Je ne vois rien qui cloche dans le dmesg...

Par contre pour le reste de ce que tu dis avec xrandr DDC2 et tout le tralala, je suis largué :D

Bref je ne trouve pas...

Je vais chercher sur gueugueule pour mon problème de vendor...

Si t'as encore des tests à me faire faire, je suis preneur :byebye:

EDIT : bon il me restait encore une bidouille... J'avais oublié de virer fglrx dans /etc/modules

Ceci n'ayant pas changé l'état actuel mais bon :chinois:

EDIT2 : Je viens également de tester en rajoutant ceci dans mon xorg.conf

Section "Extensions"

Option "RENDER" "Enable"

Option "Composite" "Enable"

EndSection

Mais c'est pire, X démarre en low graphics mode et d'après le log il charge vesa :-/

Link to post
Share on other sites

Sinon, en googlant vite fait, j'ai trouvé ça...

... ils confirment bien que fglrx remplace des libs opengl, et conseillent de faire:

apt-get install --reinstall libgl1-mesa-glx libgl1-mesa-dri

... en tout cas, il est à peu près sûr que le problème se situe quelque part dans les libs OpenGL, vu que ce sont celles de fglrx qui continuent d'être utilisées par les applis OpenGL...

Sinon, xrandr, c'est la "nouvelle" extension de X.org pour gérer les écrans: branchage à chaud, multi-écran, ... c'est censé unifier un peu la manière de faire les choses... et ddc2 est un module pour dialoguer avec les écrans au sujet de leurs résolutions et cie...

Et pour les extensions "RENDER" et "Composite", je n'en ai jamais eu besoin... de toute façon, avant de commencer à utiliser des optimisations sur le serveur, il faut en premier lieu s'assurer qu'il fonctionne en utilisant les bonnes choses... et donc se débarrasser du "ATI" dans glxinfo...

Link to post
Share on other sites

\o/

\o/

\o/

\o/

Youhouuuuuuuuuuuuuuuuuuuuuuuuuu

\o/

\o/

Ca marche ! ! !

Rhaaaaaa il restait une saloperie de fglrx avec j'ai refait un purge du driver xorg, réinstallé les libGL1 et maintenant ça fonctionne !

Super, un grand merci Aefron :up::transpi::craint:

Tant qu'on y est, aurais-tu quelques conseils pour le tweak de mon xorg ?

Merci :keskidit:

Link to post
Share on other sites

Et un radeonien libre de plus :craint:

Pour les optimisations, ça tient du mambo-jambo le plus complet... apparemment, le X.org 7.3 autoconfigure X.org tant que possible en essayant d'optimiser les choses... bon, on sait tous que l'auto-optimisation a ses limites...

... plus concrètement, fait un tour du côté du "man radeon"... les options auxquelles je pense en premier sont AGPFastWrite, ColorTiling, EnablePageFlip et AccelMethod (en EXA)... voire DynamicClocks... mais, n'utilisant guère de 3D sur mon PC (va falloir que je m'y mette... pour des graphes octaves... mais FVWM n'étant pas composité, je ne suis pas pressé d'optimiser la 3D), je n'ai pas d'exemple de configuration bien optimisée, là, maintenant... d'autant que d'une carte à l'autre, d'une version de X.org à l'autre, ça peut pas mal changer...

... autrement, il y a aussi driconf, qui peut pas mal aider, et donner accès à des réglages intéressants...

En tâtonnant, tu verras bien ce dont tu as besoin... si ça plante ou que ça marche moins vite, faut pas le mettre :keskidit: ... plus sérieusement, en général, les réglages par défaut des devs fonctionnent déjà pas mal...

En tout cas... encore une belle démonstration que fglrx est une saloperie ingérable :transpi:

Link to post
Share on other sites

Ah tu parles que c'est ingérable !

Si tu scrolles vers le haut en direction du post de tuXXX, tu verras que juste au dessus je ralais (à juste titre) d'une consommation excédente du CPU !

C'était bien ce foutu XGL (nécessaire avec fglrx, rappelons-le :ouioui:) qui le foutait à 100%

Ici je tourne sur mon laptop avec compiz + kiba-dock et je garde mes 600 voire 800Mhz :mdr2:

Niquel :pciwin:

Et au passage, j'ai fait la meme méthode pour mon desktop (muni d'une 9600XT) et byebye les problèmes de consommation :yes:

Bref, je suis très content et te remercie grandement pour ton aide :transpi:

De plus, je pense que cela va aider notre ami GoobY13 qui souffrait du meme problème que moi (voir plus haut) et qui pourra dès lors suivre les memes manip pour régler son problème !

EDIT : niveau performances, précisons-le, c'est un tantinet plus rapide pour moi étant donné l'absence de XGL le consommateur de ressources !

Néanmoins, peut-etre que fglrx avec AiGLX fonctionnera mieux mais maintenant que j'ai gouté à ce que j'ai, je veux plus changer !

Link to post
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...