Open source "Radeon" driver: vsync, vblank_mode, tearing and (open)GL

[Meneer Jansen]

You'll need 2.6.35 and mesa and ddx from git to use GL "vsync" with kms.

Thanks for the info. And if you do not use kms? Because if I use kms then TV out (on my PAL TV) has that very severe "combing" effect. That's completely gone when I disable kms (in grub).

[agd5f]

That should be fixed in 2.6.35:

http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=ff3f011cd859072b5d6e64c0b968cff9bfdc0b37

In general, please report bugs in kms so we can fix them as we are trying to transition way from ums.

[Meneer Jansen]

Finally seem to have cracked it. But oh boy did this take a whole lotta testing, cashes and forum hopping! Ever since I bought this GraCa (way, way back in 2003) I never got the darn thing to work properly in Linux. Mostly used it for gaming in Wondows. Now I know why we linuxers have been advising to use NVidia GraCa's for ages.

Many thanks to this forum topic which explains how to install the latest mesa, radeon (etc.) drivers and a supernew kernel (from "git"). The driver stuff and kernel are of versions that are officially not yet available for the distro that I use. And the distro that I use is quite new (Ubuntu 10.04 'The Lucid Lynx' at time of writing.). Things I needed to get GL video working (i.e. XbMC mediacenter, mplayer -vo gl):

• Kernel 2.6.35.
• Now KMS works w/ YV out, so I did not deactivate that anymore (removed the "nomodeset" in /etc/default/grub).
• mesa-glx and mesa-dri 7.9.0.
• drm 2.4.21.
• Xorg 7.5
• And probably some more things that could be updated after adding the xorg-edgers repo/ppa from aforementioned forum topic.

So after "waiting" (read: using NVidia cards) for 7 years I can finally use my Ati card for 3D desktop effects as well as full screen (and overscanned!) video on my TV. No thanks to Ati/AMD by the way. Who said open source was bad for business?

One final remark: somebody here said that 2.6.32 is an "old" kernel. It is, however, the latest avaliable and supported kernel for Ubuntu 10.04. That's not old in my book. It's also a bit of a disappointment that a long term support (LTS) distro uses drivers and a kernel that does noet work very well with a brand of graphics cards that half of the PC users owns. That is: should have worked out of the box by now... But you can't always get what you want.

[Meneer Jansen]

P.S. If drivers or kernel, irq's, vsynch or what ever, ever gets broken again (update??) then I'm gonna kill my computer!

[Meneer Jansen]

Nope. Seems there are some more quirks to this. Now I can't overscan anymore. The picture does not cover the whole TV screen anymore. That is: without KMS the output of the command "xrandr --prop" is:

S-video disconnected (normal left inverted right x axis y axis)
	tv_standard: pal
	tv_vertical_position: 0 (0x00000000)	range:  (-5,5)
	tv_horizontal_position: 0 (0x00000000)	range:  (-5,5)
	tv_horizontal_size: 0 (0x00000000)	range:  (-5,5)
	load_detection: 0 (0x00000000)	range:  (0,1)

Meaning that I can overscan (i.e. set hor/vert position and the hor. size). However if I boot with KMS then these parameters do not appear when I ask for the TV's properties w/ "xrandr --prop". And only with KMS the GL output (vsync) does noet tear or stutter. AAaaaaaaaaaaaaaaaaaaarrrrrrrrrrrggggghhhhhhhhhhh.

How can I fix this and what's the matter w/ xrandr if KMS is activated?

[bridgman]

I believe underscan was recently enabled by default with HDMI outputs and HD timings. There is an xrandr option to turn it off, will see if I can find it...

[bridgman]

Here we go :

http://www.phoronix.com/forums/showpost.php?p=141212&postcount=3

xrandr --output DVI-0 --set underscan off

(adjust for whatever your output is called)

[Meneer Jansen]

Thank you for your reply. But when I use xrandr to see if "underscan" is a property which I can set with "--set" it is not. See output of xrandr --prop w/ KMS enabled:

$ xrandr --prop

Screen 0: minimum 320 x 200, current 1280 x 960, maximum 4096 x 4096
VGA-0 connected 1280x960+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
	load detection: 1 (0x00000001)	range:  (0,1)
   1280x960       60.0*+
   1680x1050      60.0  
   1600x1024      60.2  
   1400x1050      60.0  
   1280x1024      60.0  
   1440x900       59.9  
   1360x768       59.8  
   1152x864       75.0     75.0     70.0     60.0  
   1024x768       85.0     75.0     70.1     60.0  
   832x624        74.6  
   800x600        85.1     72.2     75.0     60.3     56.2  
   848x480        60.0  
   640x480        85.0     72.8     75.0     59.9     59.9  
   720x400        85.0  
   640x400        85.1  
   640x350        85.1  
DVI-0 disconnected (normal left inverted right x axis y axis)
	load detection: 1 (0x00000001)	range:  (0,1)
S-video connected (normal left inverted right x axis y axis)
	tv standard:	pal
		supported: ntsc         pal          pal-m        pal-60      
		           ntsc-j       scart-pal    pal-cn       secam       
	load detection: 1 (0x00000001)	range:  (0,1)
   800x600        59.9 +
   640x480        59.9

And the output for the S-video part of xrandr --prop w/ KMS DISabled:

S-video disconnected (normal left inverted right x axis y axis)
	tv_standard: pal
	tv_vertical_position: 0 (0x00000000)	range:  (-5,5)
	tv_horizontal_position: 0 (0x00000000)	range:  (-5,5)
	tv_horizontal_size: 0 (0x00000000)	range:  (-5,5)
	load_detection: 0 (0x00000000)	range:  (0,1)

Notice that magically some very useful settings appear with which I can set overscan myself. With kms enabled, I seem not to be able to do that. Why?

Since there is no property called "underscan" its no surprise that if I try to set it I get an error:

$ xrandr --output S-video --set underscan off

X Error of failed request:  BadName (named color or font does not exist)
  Major opcode of failed request:  149 (RANDR)
  Minor opcode of failed request:  11 (RRQueryOutputProperty)
  Serial number of failed request:  29
  Current serial number in output stream:  29

[nanonyme]

Wonder if 2.6.35 is recent enough... Seems like the guy got overscan in the other thread from 2.6.35-git2 to 2.6.35-git3. (and no, I don't personally recommend using those; rather use git with 2.6.35 release and then pull from airlied's drm-next or whatever branch on top of it; airlied free to strangle me if I gave the wrong branch )

[xiando]

Wonder if 2.6.35 is recent enough... Seems like the guy got overscan in the other thread from 2.6.35-git2 to 2.6.35-git3. (and no, I don't personally recommend using those; rather use git with 2.6.35 release and then pull from airlied's drm-next or whatever branch on top of it; airlied free to strangle me if I gave the wrong branch )

I am fairly sure 2.6.35 is too old. You must get your hands on the fancy new 2.6.35-git3+ technology to xrandr --output DVI-0 --set underscan off with KMS with r600. Underscan is now enabled by default for this driver and I find this very sad and depressing and I kind of wish those behind this conspiracy would be shot in their heads and barried in shallow graves. Mr. Jansen (Danish person indicated?) is using r300, not r600, but I am fairly sure the KMS underscan changes where forced upon users of both chips at the same time.

It's hard to say what kernel mr Jansen should go ahead and use, I haven't tried the fancy new 2.6.35-git16 yet but a quick glance at http://www.kernel.org/diff/diffview....6.35-git16.bz2 does not indicate that it will not make computers explode.

Anyway, good luck!!1!