Journal Bug de rendu video (xv) lors d'une migration du driver xorg-i810 vers xorg-intel

Posté par (page perso) .
Tags : aucun
7
29
avr.
2009
Contexte : migration de debian etch vers lenny, chip graphique 945GM (GMA950).

Je parle de debian, mais c'est transposable à d'autres distribs, le problème rencontré est lié au nouveau pilote xorg-intel.

En bref : le rendu de video accéléré par XV fait apparaître des bugs d'affichage sur la video ressemblant à un problème de Vsync : de temps en temps une ligne horizontale de décalage balaye l'image de haut en bas (il me semble qu'on parle de "tearing" en anglais).

Comme j'ai cherché pas mal de temps l'origine et la solution de ce bug, je vous fais un petit journal, si ça peut être utile à quelqu'un...

Sur etch, le pilote video utilisé était xorg-video-i810 1.7.2, et le rendu video par défaut de XV utilisait l'overlay qui fonctionnait nickel par défaut avec vlc ou mplayer. Sur lenny, le pilote xorg-video-i810 n'existe plus bien sûr au profit du nouveau pilote xorg-intel (2.3.2).


Après recherches, le bug vient du fait que le pilote xorg-intel n'utilise plus par défaut les "fonctions overlay" du GMA950 mais des 'textured video' et que ces dernières ne me semblent pas encore top-moumoutes (au moins sur la version 2.3.2). Plus par défaut les "fonctions overlay", c'est-à-dire que XV présente désormais 2 sorties, la première (donc utilisée par défaut), la 'textured video', la seconde la 'Video Overlay'. Ci-dessous un extrait de la sortie de xvinfo :

X-Video Extension version 2.2
screen #0
Adaptor #0: "Intel(R) Textured Video"
number of ports: 16
port base: 116
operations supported: PutImage
[...]
number of attributes: 2
"XV_BRIGHTNESS" (range -128 to 127)
client settable attribute
client gettable attribute (current value is 0)
"XV_CONTRAST" (range 0 to 255)
client settable attribute
client gettable attribute (current value is 0)
maximum XvImage size: 1920 x 1088
Number of image formats: 5
[...]
Adaptor #1: "Intel(R) Video Overlay"
number of ports: 1
port base: 132
operations supported: PutImage
[...]
number of attributes: 12
[...]


On voit donc les deux sorties (Adaptor #0 et Adaptor #1) avec certaines caractéristiques en faveur de la 'Textured Video' (16 ports contre 1 seul pour le 'Video Overlay') et d'autres en faveur de la 'Video Overlay' (12 attributs contre 2 pour la 'Textured Video').
Quoi qu'il en soit, le bug de vsync est bien remonté sur le bugtrack de xorg-intel [https://bugs.freedesktop.org/show_bug.cgi?id=19635]. Il semble qu'il ait été corrigé sur la version 2.7.0 mais pour l'heure je suis en 2.3.2... Pas grâve, on a des solutions de contournement pour demander à ses players préférés (en ce qui me concerne vlc et mplayer) d'utiliser l'adapter #1 au lieu du #0 par défaut :
- pour mplayer, il faut lui donner le numéro du port XV à utiliser, donc cf la sortie de xvinfo, dans mon cas pour le video overlay, c'est le port 132 (il n'y en a qu'un) et appeler mplayer comme suit : mplayer -vo xv:port=132 ou ajouter vo=xv:port=132 à votre fichier ~/.mplayer/config .
- pour vlc, Divers -> Préférences -> Video -> Modules de sortie -> XVideo -> Numéro de l'adaptateur de XVideo, mettre 1 au lieu de -1.


Pour être complet, je mets aussi un extrait de mon xorg.conf (alors que par défaut il est désormais quasi vide, tout devant être "autodétecté" au démarrage de X...). J'ai en effet rencontré 2 autres problèmes avec le pilote xorg-intel (mais dont la solution fut plus facile pour moi à trouver), à savoir :
- le serveur X démarrait par défaut en 1024x768 alors que je suis en 1680x1050... en fait le pilote me détectait un écran "LVDS" principale en 1024x768, en plus du TMDS (HDMI). Or je n'ai qu'un écran en HDMI... La release note indique que cela peut arriver aussi pour un écran VGA fictif... Solution bourrine, forcer le mode "1680x1050" dans la section Screen. Solution élégante : créer une section Monitor, Identifier "LVDS" et mettre Option Disable true. Cela doit faire gagner un peu de mémoire vue qu'on n'a plus à gérer un écran qui n'existe pas...
- Rendu 2D médiocre (particulièrement visible dans le rafraichissement de mes terminaux urxvt lors de changements de bureaux) et crashs (certes peu fréquents, mais quand même...) complet de X (écran gris brouillé ou gribouillé ;-) ). Contourné en basculant sur l'ancien module d'accélération XAA (Option "AccelMethod" "XAA").



Section "Device"
Identifier "Configured Video Device"
Driver "intel"
Option "AccelMethod" "XAA"
#Option "PageFlip" "true"
Option "TripleBuffer" "true"
EndSection

Section "Monitor"
Identifier "Configured Monitor"
EndSection

Section "Monitor"
Identifier "LVDS"
#Option "Ignore" "true"
Option "Disable" "true"
EndSection

Section "Monitor"
Identifier "TMDS-1"
Option "PreferredMode" "1680x1050"
EndSection


Section "Screen"
Identifier "Default Screen"
Monitor "Configured Monitor"
SubSection "Display"
Depth 24
##Modes "1680x1050"
EndSubSection

EndSection
  • # Bugtracker

    Posté par . Évalué à -10.

    Après avoir fait office de bookmarker, si les journaux DLFP font maintenant office de bugtrackers…
    • [^] # Re: Bugtracker

      Posté par . Évalué à 9.

      Faut p'tet pas pousser : il expose un problème certes, mais aussi sa solution.

      c'est pas ploum qui pose ses questions de newbies en essayant de faire une dépêche parce que c'est plus visité que les forums :-)
  • # Cassage en cours...

    Posté par (page perso) . Évalué à 3.

    Il semble qu'intel modifie grandement son driver dernièrement : le 2.8 n'aura plus de support de XAA,EXA, DRI1

    cf:http://www.phoronix.com/scan.php?page=news_item&px=NzIzN(...)

    S'il y a un problème, il y a une solution; s'il n'y a pas de solution, c'est qu'il n'y a pas de problème.

    • [^] # Re: Cassage en cours...

      Posté par . Évalué à 2.

      Donc un pilote intel stable, avec la 3D pour un petit nexuiz c'est pas pour tout de suite :-(
      • [^] # Re: Cassage en cours...

        Posté par . Évalué à 4.

        En même temps cela va leur mettre la pression pour finir UXA, GEM, DRI2 et tout le merdier autour et plus d'excuse à ne pas le faire :)
  • # Voila donc la solution...

    Posté par . Évalué à 1.

    J'ai le même problème sous ubuntu mais je ne l'avais pas résolu. merci a toi.
  • # Merci

    Posté par (page perso) . Évalué à 3.

    Hello,

    j'ai modifié mon fichier xorg.conf en pompant sur le tien ! J'obtiens des résultats d'affichage en 1680x1050 bien plus rapides qu'avant sur ma Debian Lenny installée sur une EeeBox: le temps d'affichage des pages via firefox iceweasel est complètement réduit et Xorg me prend beaucoup moins de ressources instantanées (passage 80% d'utilisation CPU lors de l'affichage d'une page HTML chargée à 40% max).

    Donc merci beaucoup...

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.