[compiz] écran blanc avec pilote vesa (résolu)

[farvardin]

bonjour,

je suis en train de réaliser un livecd à base d'archlinux. J'ai installé le pilote vesa par défaut, parce que si on laisse xorg se débrouiller, on se retrouve parfois avec un bureau de 640x480...

J'avais lu sur un forum que vesa ne supportait pas les effets de composition, pourtant xcompmgr fonctionne très bien (transparence, ombres), glxgear est relativement rapide, et glxinfo m'indique que le direct rendering est supporté. Néanmoins en démarrant fusion-icon, j'ai un écran blanc. Je me retrouve dans le cas de figure évoqué ici :

http://forums.archlinux.fr/viewtopic.ph ... mpiz+blanc

le cube fonctionne, est même relativement fluide, mais il reste blanc. Avec fusion-icon -n, je vois que indirect rendering est automatiquement sélectionné, et qu'on ne peut le changer.

D'ailleurs j'ai essayé de remplacer vesa par "nv", et il m'est dit que le module nv n'existe pas ! C'est pourtant un noyau générique, ce pilote devrait être présent non ? (edit: j'ai trouvé que cela se trouvait dans xf86-video-nv dorénavant)

Est-ce qu'il y a une solution quand même pour le mode vesa ?

[farvardin]

finalement j'ai retiré le xorg.conf et rajouté un script pour l'activer en cas de mauvaise configuration par défaut. Sur quelques ordinateurs que j'ai testé, la configuration automatique n'est pas mauvaise du tout, et avec xf86-video-nv, xf86-video-ati et xf86-video-intel, je pense que l'on couvre la plupart des machines récentes. Est-ce qu'il existe d'autres cartes populaires ?

Quoi qu'il en soit, avec cette configuration automatique, compiz fonctionne maintenant très bien.

(mais j'ai toujours pas ma réponse pour le mode vesa)

[tuxce]

vesa, 3D, y a pas un truc qui te choque là ?

[farvardin]

à la base, oui, tout à fait.

Mais justement, rien qu'avec le pilote vesa j'arrive à avoir du direct rendering, glxgear tourne bien vite, et le cube de compiz fonctionne correctement, en 3D donc, à part que la zone du bureau est blanche.

J'en arrive donc à la conclusion que vesa peut malgré tout faire du 3D, contre toute attente.

[tuxce]

regarde bien si c'est bien vesa qui est lancé (dans le /var/log/Xorg.*.log) parce que ça m'étonnerait que l'extension glx soit chargé pour ce pilote.

[Cactus]

finalement j'ai retiré le xorg.conf et rajouté un script pour l'activer en cas de mauvaise configuration par défaut. Sur quelques ordinateurs que j'ai testé, la configuration automatique n'est pas mauvaise du tout, et avec xf86-video-nv, xf86-video-ati et xf86-video-intel, je pense que l'on couvre la plupart des machines récentes. Est-ce qu'il existe d'autres cartes populaires ?

Quoi qu'il en soit, avec cette configuration automatique, compiz fonctionne maintenant très bien.

(mais j'ai toujours pas ma réponse pour le mode vesa)

Je rajouterais le pilote mga (Matrox) et openchrome (cartes SiS).
Ensuite, je serais curieux de voir ton script, car hwd choisis toujours les pilotes proprios, et je préfèrerais les libres.
Ca se modifie peut-être, mais j'ai pas eu le temps de creuser... en plus, j'ai prêté ma clé pour dépanner ma voisine.
Pour le moment, ce sont des modif à coup de sed (fglrx --> ati, nvidia --> nv, etc...), mais bon, c'est pas top comme solution.

[farvardin]

et pourtant, j'ai l'impression que c'est bien du vesa :

(II) Reloading /usr/lib/xorg/modules//libint10.so
(II) VESA(0): initializing int10
(II) VESA(0): Primary V_BIOS segment is: 0xc000
(II) VESA(0): VESA BIOS detected
(II) VESA(0): VESA VBE Version 3.0
(II) VESA(0): VESA VBE Total Mem: 8000 kB
(II) VESA(0): VESA VBE OEM: Intel(r)845G/845GL/845GE/845GV Graphics Chip Accelerated VGA BIOS
(II) VESA(0): VESA VBE OEM Software Rev: 1.0
(II) VESA(0): VESA VBE OEM Vendor: Intel Corporation
(II) VESA(0): VESA VBE OEM Product: Intel(r)845G/845GL/845GE/845GV Graphics Controller
(II) VESA(0): VESA VBE OEM Product Rev: Hardware Version 0.0
(II) VESA(0): virtual address = 0xb7294000,
physical address = 0xd0000000, size = 8192000
(II) VESA(0): Setting up VESA Mode 0x117 (1024x768)
(==) VESA(0): Default visual is TrueColor
(==) VESA(0): Backing store disabled
(**) Option "dpms" "true"
(**) VESA(0): DPMS enabled
(==) RandR enabled
(II) Initializing built-in extension MIT-SHM
(II) Initializing built-in extension XInputExtension
(II) Initializing built-in extension XTEST
(II) Initializing built-in extension XKEYBOARD
(II) Initializing built-in extension XC-APPGROUP
(II) Initializing built-in extension SECURITY
(II) Initializing built-in extension XINERAMA
(II) Initializing built-in extension XFIXES
(II) Initializing built-in extension RENDER
(II) Initializing built-in extension RANDR
(II) Initializing built-in extension COMPOSITE
(II) Initializing built-in extension DAMAGE
(II) Initializing built-in extension XEVIE
(II) AIGLX: Screen 0 is not DRI capable
(II) AIGLX: Loaded and initialized /usr/lib/xorg/modules/dri/swrast_dri.so
(II) GLX: Initialized DRISWRAST GL provider for screen 0
(II) config/hal: Adding input device Logitech USB RECEIVER
(II) LoadModule: "evdev"

le log complet se trouve ici : http://pastebin.archlinux.fr/326716

Je n'ai rien modifié dans le script de configuration de Larch. De toute façon, il n'y aura que des pilotes graphiques libres, vu que je n'ai pas installé les pilotes propriétaires (en plus je n'ai pas la place, et ce n'est pas le but de ce livecd)

Je pense qu'une préversion du livecd sera prête bientôt.

[gyo]

et pourtant, j'ai l'impression que c'est bien du vesa :

(II) Reloading /usr/lib/xorg/modules//libint10.so
(II) VESA(0): initializing int10
[…]
(II) AIGLX: Screen 0 is not DRI capable
(II) AIGLX: Loaded and initialized /usr/lib/xorg/modules/dri/swrast_dri.so
(II) GLX: Initialized DRISWRAST GL provider for screen 0

Tiens tiens intéressant.

swrast is basically a mesa 3D driver that uses the mesa sw rasterization methods exclusively. It looks and loads just like a real hw 3D driver only it's sw only. GLcore was not. The change allows us to have a common interface for loading 3D drivers in the X server and provides us with a sw only 3D driver that provides a nice base for a new hw 3D driver in that you can slowly replace the sw routines with the hw ones.

Traduction approximative :

swrast est en gros un pilote mesa qui utilise exclusivement des méthodes de « rasterization » logicielle. Ça ressemble et se charge comme un vrai pilote 3D matériel sauf que c’est uniquement logiciel. GLcore ne l’était pas. La différence est que cela nous permet d’avoir une interface commune pour charger des pilotes 3D au niveau du serveur X et fournit un pilote 3D logiciel qui permet d’avoir une base pour un nouveau plilote 3D matériel en ce sens que vous pouvez remplacer les routines logicielles par celles matérielles.

[farvardin]

bien trouvé Gyo !

Effectivement, on dirait que c'est un palliatif à un vrai pilote pour la carte. Comme je l'avais essayé sur une machine puissante, c'est sans doute pour cela que les performances n'étaient pas mal.

On va dire que la question est résolue en ce cas. Et je vais rajouter les suggestions de Cactus pour les pilotes.