Archive for January, 2009

Fixing tearing with Intel video

Wednesday, January 7th, 2009

The single most irritating thing that happened on the Aspire One since I switched over to Debian (mine came preinstalled with windows xp) is the tearing when watching video. Googling for solutions or hints as to why it happens led me to numerous sites that suggested using driconf. But these people all use compiz and whatnot but I enjoy my desktop in plain old stuck-in-the-90s mode.

Finally I struck gold at Seems that the intel driver has changed to always have a textured video overlay, and this is the culprit of the tearing.

Having a look with xvinfo gave me the information needed.

knirch@aspireone:~$ xvinfo
X-Video Extension version 2.2
screen #0
  Adaptor #0: "Intel(R) Textured Video"
    number of ports: 16
    port base: 91
    operations supported: PutImage 
    supported visuals:
      depth 24, visualID 0x23
        bits per pixel: 12
        number of planes: 3
        type: YUV (planar)
  Adaptor #1: "Intel(R) Video Overlay"
    number of ports: 1
    port base: 107
    operations supported: PutImage 
    supported visuals:
      depth 24, visualID 0x23

Choosing the port of the second adaptor Adaptor #1: “Intel(R) Video Overlay” made the tearing go away.

In mplayer just add vo=xv:port=107 to ~/.mplayer/config (or /etc/mplayer/mplayer.conf for system wide) fixes the tearing. The port number might be different on your system, so check with xvinfo first.

In VLC enable advanced options/expert mode and change Video>Output modules>XVideo>XVideo Adaptor number to 1

According to 2.5.1 and release notes of xf86-video-intel the order of the adaptors can be changed, so mplayer and VLC will use the untextured overlay by default.

Maxim Levitsky (1):
Add an option to make the overlay be the first XV adaptor.

There’s also been hinting that DRI2 will solve the tearing in the 2.5.0 release notes.

Item (4) was the main thing we missed this time (Nanhai has been working flat out to get MPEG2 offload working so we didn’t get a chance to try different approaches for vblank sync’ing). I think the real fix here will be DRI2, which should allow us to run compositing managers in DRI mode, with real vblank sync’ing for all their drawing.