interlacing broken in gutsy on radeon/ati open source driver

[laga]

Binary package hint: xserver-xorg-video-ati

Hello,

I'm using a Radeon 9250PCI with a home-made cable to drive my TV over its SCART port. Of course, I need a interlaced modeline to get proper output, like the following:

> Modeline "768x576" 14.774 768 784 848 944 576 581 586 626 interlace +hsync +vsync composite

However, I had to find out that it doesn't work well in Gutsy. The first half of the screen is shown fine, then there's a horizontal black bar and then the first half of the screen is shown again in the lower half of my TV set. I can tell that it's divided in the middle because I see half of the mouse pointer which is usually placed in the middle of the screen.

In order to narrow down the issue a bit, I downloaded the source for xserver-xorg-video-ati for Feisty. After compiling and installing it, X worked flawlessly on my TV. I'd guess that something was broken between xserver-xorg-video-ati-6.6.3 and xserver-xorg-video-ati-6.7.193.

Do you have any idea what would be the cause of that problem? If not, I'll have to use git-bisect to find out which commit introduced this problem.

BTW: I am *not* using the TV out of that card, my cable is connected to the VGA header. DVI-I at 1680x1050 still works fine.

[laga (laga)]

In case it matters: I'm on amd64. Here's the output of lspci:

04:01.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 PRO] (rev 01) (prog-if 00 [VGA])
        Subsystem: PC Partner Limited Unknown device 0250
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 32 (2000ns min), Cache Line Size: 32 bytes
        Interrupt: pin A routed to IRQ 19
        Region 0: Memory at d0000000 (32-bit, prefetchable) [size=128M]
        Region 1: I/O ports at a000 [size=256]
        Region 2: Memory at e3000000 (32-bit, non-prefetchable) [size=64K]
        [virtual] Expansion ROM at e2000000 [disabled] [size=128K]
        Capabilities: <access denied>

04:01.1 Display controller: ATI Technologies Inc RV280 [Radeon 9200 PRO] (Secondary) (rev 01)
        Subsystem: PC Partner Limited Unknown device 0251
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 32 (2000ns min), Cache Line Size: 32 bytes
        Region 0: Memory at d8000000 (32-bit, prefetchable) [size=128M]
        Region 1: Memory at e3010000 (32-bit, non-prefetchable) [size=64K]
        Capabilities: <access denied>

The rest of the system is a Core 2 Duo on Intel 945P chipset.

[Timo Aaltonen (tjaalton)]

You should try the tv-out, since it's supported now at least on some radeons.. Also, could you attach your Xorg.0.log and xorg.conf, so we'd see what mode it is trying to use.

[laga (laga)]

Here's Xorg.1.log with the broken driver.

[laga (laga)]

Here's my xorg.conf. It contains two screens, the affected screen is called "tv".

BTW, I don't *want* to use the tv-out because its quality is likely to be inferior. Unless you want me to test it for you, which I can do.

[laga (laga)]

Would it help if I isolated the faulty commit using git-bisect?

[Sébastien Valette (sebastien-valette)]

Hi,

same issue form me...
moreover, tvout is not working (connection not detected, but detected correctly with vesa driver)

[laga (laga)]

Setting from incomplete to invalid:
* i provided all requested information
* Sébastien Valette has the same issue

[laga (laga)]

Hello,

I'm using my PAL modeline to drive my TV directly over the VGA connector. When upgrading from Ubuntu Feisty to Ubuntu gutsy, this stopped working for me. The first half of the screen is shown fine, then there's a horizontal black bar and then the first half of the screen is shown again in the lower half of my TV set. I can tell that it's divided in the middle because I see half of the mouse pointer which is usually placed in the middle of the screen.

When I downgraded from xserver-xorg-video-ati-6.7.193 to xserver-xorg-video-ati-6.6.3, it started to work again. In an attempt to narrow down the cause, I got xf86-video-ati from git. I have 82 revisions left for testing, but I'll provide my interim results here:

Commit 2618cf2aa8ed76411b943eb90c95869814c2f151 from May still works
Commit 0abce69f0d826a7ca1a41d963cd4730b6e01c145 from April is broken

I didn't use git-bisect for that because I'd keep hitting revisions which wouldn't compile properly or exhibited other problems.

So, if anyone has a fix or knows which revisions might be interesting, I'd appreciate any input. If not, I'll give git-bisect another try tomorrow (with my narrowed-down set of revisions this time).

Thanks,

Michael

[laga (laga)]

(In reply to comment #0)

> Commit 2618cf2aa8ed76411b943eb90c95869814c2f151 from May still works
> Commit 0abce69f0d826a7ca1a41d963cd4730b6e01c145 from April is broken

Sorry, I got that backwards.

0abce69f0d826a7ca1a41d963cd4730b6e01c145 is working
2618cf2aa8ed76411b943eb90c95869814c2f151 is broken

Also, I filed a bug in Ubuntu a few days ago: https://bugs.launchpad.net/xorg-server/+bug/144322

[laga (laga)]

Since I've verified that the problem occurs upstream as well, I'll file a bug with upstream to get this resolved more quickly.

[laga (laga)]

Hi again,

> I didn't use git-bisect for that because I'd keep hitting revisions which
> wouldn't compile properly or exhibited other problems.

I tried to narrow down the problem further, but I've been unable to do so. git-bisect will give me revisions which won't compile. If i pick revisions at random, they will either lock up my box when I start X or do other weird stuff.

So, I'm afraid I need some help. If anyone has a a hint how I can debug this further or if a developer is looking at this, please let me know. I'm willing to test revsions and patches, but I cannot do so without help.

FYI, this problems also shows up with a X300: http://www.gossamer-threads.com/lists/mythtv/users/294492#294492

Regards,

Michael

[laga (laga)]

*** Bug 12727 has been marked as a duplicate of this bug. ***

[Jose Bernardo (bernardo-bandos)]

Ok, I am also seeing the same problem, with a TV-Scart cable, on a Radeon X300 in a Advent DHE-500 media centre PC. I worked around it last night by using a modeline designed for adapters that couldn't do interlace:
Modeline "STB Vel128" 14.16 680 728 792 904 264 280 296 313 +hsync +vsync Composite

As for svideo out, I can't get any signal out of it, and I've tried everything these last three days.

[Jose Bernardo (bernardo-bandos)]

I'm the X300 owner, and I am indeed seeing the same bug, the screen split in half with the top copied to the bottom and the vblank in the middle. I am also using a VGA->SCART cable to connect my X300 to a analog 16:9 PAL tv.
I can get a image on the tv if I remove the "interlace" keyword, and choose a progressive modeline with half the scanlines of my interlaced scanline.

[agd5f (agd5f)]

Does disabling tiling fix it?

Option "ColorTiling" "FALSE"

[laga (laga)]

No, disabling Colortiles doesn't work for me. Although it clearly says that it's disabled in Xorg.1.log:

(**) RADEON(0): Option "NoAccel" "true"
(**) RADEON(0): Option "SWcursor" "on"
(**) RADEON(0): Option "IgnoreEDID" "true"
(**) RADEON(0): Option "ForceMinDotClock" "12MHz"
(**) RADEON(0): Option "ColorTiling" "false"
(**) RADEON(0): Option "RenderAccel" "false"
(**) RADEON(0): Option "VGAAccess" "false"
(**) RADEON(0): Option "DRI" "false"

I still have the same problem. For this test, I used xserver-xorg-video-ati from Ubuntu in 1:6.7.195-1ubuntu2 because I don't expect GIT HEAD to show much difference.

[agd5f (agd5f)]

can you use radeontool to dump the regs as set by the old driver and the new driver using this version of radeontool:
http://cgit.freedesktop.org/~airlied/radeontool/

radeontool regmatch '*'

and attach both dumps.

[laga (laga)]

Created an attachment (id=11991)
registerdump when using the broken driver

[laga (laga)]

Created an attachment (id=11992)
regdump using the working driver

[laga (laga)]

Done!

[agd5f (agd5f)]

Can you also attach your xorg log from the old working driver? Also, which connector are you using for the interlaced output?

[agd5f (agd5f)]

Can you try again with the latest ati git? I think this should be fixed.

[laga (laga)]

Alex,

> Can you try again with the latest ati git? I think this should be fixed.

Sorry for not getting back to you earlier. Using latest git, the X server just crashes. I'll attach my Xorg.log in a minute. I've also tried your commits from 15th of this month and that's also crashing.

[laga (laga)]

Created an attachment (id=12100)
Xorg log of crash using latest git

[laga (laga)]

Let me know if you need a proper backtrace using gdb.

Do you still need a xorg.log using the working driver?

[agd5f (agd5f)]

(In reply to comment #15)
> Let me know if you need a proper backtrace using gdb.
>
> Do you still need a xorg.log using the working driver?
>

yes on both. thanks.

[laga (laga)]

Created an attachment (id=12109)
gdb backtrace for segfault with latest git

I hope this backtrace is OK, I don't know a lot about these things. (The first time I tried getting one my box froze, worked the second time. phew.)

[laga (laga)]

Created an attachment (id=12111)
Xorg.1.log of working driver, rev 0abce69f0d826a7ca1a41d963cd4730b6e01c145

Here's the missing log file. Let me know if you need anything else.

Thanks for working on this, btw.

[agd5f (agd5f)]

(In reply to comment #17)
> Created an attachment (id=12109) [details]
> gdb backtrace for segfault with latest git
>
> I hope this backtrace is OK, I don't know a lot about these things. (The first
> time I tried getting one my box froze, worked the second time. phew.)
>

Can you try again with tiling disabled?

Option "ColorTiling" "FALSE"

[agd5f (agd5f)]

(In reply to comment #17)
> Created an attachment (id=12109) [details]
> gdb backtrace for segfault with latest git

this crash should be fixed now.

[laga (laga)]

I've just tried with latest git.

* with color tiling disabled, it is still broken (same behavior as before)
* with color tiling enabled, the screen is split in half like before, but there are horizontal black lines trhoughout the picture, maybe a few pixels high. Judging from the noise, my TV set doesnt really like that :)

[laga (laga)]

Created an attachment (id=12119)
regdump using latest git rev a9306b7986467c0794c91625ad2ece597b718462

Here's a register dump just in case you need it. Xorg log is coming...

[laga (laga)]

Created an attachment (id=12120)
Xorg log using latest git rev a9306b7986467c0794c91625ad2ece597b718462

[laga (laga)]

*** Bug 13057 has been marked as a duplicate of this bug. ***

[laga (laga)]

Hi Alex,

since Gutsy has been released in the meantime, more people are getting bitten
by this bug (eg #13057), is there anything we can do to help getting this
fixed?

Regards,

Michael

[mirak (mirak-mirak)]

hello, I posted that dupe bug, I am happy to see this issue is already worked on, I have it since 2 weeks but didn't had time to report, and couldn't find on google anything about that. I use a radeon 9600pro.

by the way I might be off topic but I am taking the occasion to ask here if anyone manage to use this PAL modelines to obtain a valid display on the framebuffer, I mean on the non X display in console.
I see something on the output, but the image appear only on half of the screen is not stable at all, scrolling up and down very fast. It's the same on Windows XP login.
I tried things using radeonfb and /etc/fbdev.conf but it was worse nothing appeared on the screen.

Also a bit of topic too but I guess you noticed as well, composite option in the modeline have no effect on the fglrx driver.

I am interested you point me a place whith discussions about this VGA -> PAL issues.

bye.

(In reply to comment #25)
> Hi Alex,
>
> since Gutsy has been released in the meantime, more people are getting bitten
> by this bug (eg #13057), is there anything we can do to help getting this
> fixed?
>
> Regards,
>
> Michael
>

[mirak (mirak-mirak)]

hello, I have also this problem, I posted on bugzilla and luckily they said there was already a dupe bug, yours. I couldn't find other info on google before.

[mirak (mirak-mirak)]

by the way I might be off topic but I am taking the occasion to ask here if anyone manage to use this PAL modelines to obtain a valid display on the framebuffer, I mean on the non X display in console.
I see something on the output, but the image appear only on half of the screen is not stable at all, scrolling up and down very fast. It's the same on Windows XP login.
I tried things using radeonfb and /etc/fbdev.conf but it was worse nothing appeared on the screen.

I use a Radeon 9600 pro

Also a bit of topic too but I guess you noticed as well, composite option in the modeline have no effect on the fglrx driver.

I am interested you point me a place whith discussions about this VGA -> PAL issues.

bye.

[S-j-newbury (s-j-newbury)]

Same problem here. I notice that radeon_modes.c has changed significantly, is the interlace flag still being picked up from the mode line so that V_INTERLACE gets set?

[S-j-newbury (s-j-newbury)]

Sorry, I meant mode->Flags gets V_INTERLACE set.

[S-j-newbury (s-j-newbury)]

Has anyone tried using xrandr --newmode <modeline> to add the interlaced modeline. I was going to try it but I'm working remotely and the X server just locked up the box! :-(

[DualIP (adrian-bacon)]

Like the topic starter, I ran into same problem trying to get RGB output from VGA connector in PAL timings (15625Hz horizontal 50Hz vertical interlaced):

When this error occurs, my CRT OSD displays 100Hz as the vertical frequency (should be 50)! Also, hooking up an oscilloscope to VGA Vertical output confirms this 100Hz frequency.

I think I can explain the screen as described by topic starter: The black horizontal border in the middle of the screen is just the extra Vsync pulse. After this extra Vsync pulse the vertical counters are reset, and the top half of the screen is repeated in lower half.

I used fedora7 to play around with modelines to use them later in Geexbox, but discovered these settings don't work in Geexbox:

My setup:
Modeline "PAL" 14.625 768 786 855 936 576 580 585 625 interlace -hsync -vsync
VGA cards tested: Radeon 7000 series:
GigaByte GV-R7064T Rev 1.0 64MB
Gecube GC-R7000L Rev 1.3 64MB

---Working config:
Fedora7 using
Module ati: version = 6.7.196

-Not working version:
Geexbox mediaplayer dev 12252007 having X support.
Module ati: version = 6.6.3

btw: Using the radeon instead of ati driver in xorg.conf device section doesn't help. This still loads the ATI driver.

Seems to me the code is lacking a divide by 2 somewhere.....

[laga (laga)]

@ DualIP

Wow, that's interesting. Are you sure that 6.7.196 is working for you while 6.6.3 is not working? Because it's 6.6.3 that works here while newer releases break..

[DualIP (adrian-bacon)]

oops.....
Re-read text 2 times before posting but didn't notice I swapped version numbers
Should be:

---Working config:
Fedora7 using
Module ati: version = 6.6.3

-Not working version:
Geexbox mediaplayer dev 12252007 having X support.
Module ati: version = 6.7.196

[mirak (mirak-mirak)]

using an older ati radeon module of xorg works for me, until it will break if the gap between versions is to big

[laga (laga)]

(In reply to comment #29)
> Has anyone tried using xrandr --newmode <modeline> to add the interlaced
> modeline. I was going to try it but I'm working remotely and the X server just
> locked up the box! :-(
>

No, I haven't tried it yet.

However, I have installed the latest git as of today to see if the issue is still there. Yes, screen is still garbled :/ This time however, I don't get the same screen two times as described above. It's even more garbled, now I see the upper third of the screen three times.

Any ETA on a fix? I know you guys are busy, I just want to know when I should start nagging again :)

Do you need any additional logs? SSH access to my box?

[DualIP (adrian-bacon)]

Workaround to get interlaced PAL output using 6.7.196

At latest geexbox developer version , xorg has DRI stuff included and I no longer managed to compile 6.6.3 in it:-(
However, I stumbled on a workaround:
1) Start Xorg using PAL interlaced setting. RGB output is like reported bug
2) use
xrandr -display :0.0 -s 1
to switch to different (also PAL interlaced) setting. Now RGB output is OK !
Even switching back to startup config using xrandr -display :0.0 -s 0 , PAL output is valid!

I have these lines in my xorg.conf
HorizSync 15-16
VertRefresh 49-51
Modeline "PALWS" 24.75 1280 1321 1437 1584 576 580 585 625 -hsync -vsync interlace
Modeline "PAL" 22.50 1152 1195 1301 1440 576 580 583 625 -hsync -vsync interlace

Intention of these 2 PAL modelines: My vga to scart convertor uses vertical sync length (note 585 and 583 in Vertical part of modeline) to switch the scart 16:9 pin.

[laga (laga)]

Wow.

You're right, it works! Do you think you could post your workaround in the Xorg bug tracker as well?

[DualIP (adrian-bacon)]

Like the topic starter, I ran into same problem trying to get RGB output from VGA connector in PAL timings (15625Hz horizontal 50Hz vertical interlaced):

When this error occurs, my CRT OSD displays 100Hz as the vertical frequency (should be 50)! Also, hooking up an oscilloscope to VGA Vertical output confirms this 100Hz frequency.

I think I can explain the screen as described by topic starter: The black horizontal border in the middle of the screen is just the extra Vsync pulse. After this extra Vsync pulse the vertical counters are reset, and the top half of the screen is repeated in lower half.

====>>>Workaround to get interlaced PAL output using 6.7.196
At latest geexbox developer version , xorg has DRI stuff included and I no longer managed to compile 6.6.3 in it:-(
However, I stumbled on a workaround:
1) Start Xorg using PAL interlaced setting. RGB output is like reported bug
2) use
xrandr -display :0.0 -s 1
to switch to different (also PAL interlaced) setting. Now RGB output is OK !
Even switching back to startup config using xrandr -display :0.0 -s 0 , PAL output is valid!

I have these lines in my xorg.conf
HorizSync 15-16
VertRefresh 49-51
Modeline "PALWS" 24.75 1280 1321 1437 1584 576 580 585 625 -hsync -vsync interlace
Modeline "PAL" 22.50 1152 1195 1301 1440 576 580 583 625 -hsync -vsync interlace

Intention of these 2 PAL modelines: My vga to scart convertor uses vertical sync length (note 585 and 583 in Vertical part of modeline) to switch the scart 16:9 pin.

[laga (laga)]

This problem still exists in Ubuntu hardy.

ii xserver-xorg-video-ati 1:6.8.0-1 X.Org X server -- ATI display driver

The xrandr workaround works, though.

[Freedesktopbugz (freedesktopbugz)]

Just to note this is affecting my Radeon X550 after upgrading to Fedora 8
xorg-x11-drv-ati.x86_64-6.8.0-1.fc8
this has worked fine from fedora5 to fedora7

I'm using VGA->SCART to a PAL TV on the VGA port (port 0) nothing connected to DVI or STV ports (1 and 2)

What is actually being displayed is the odd scanrows from the top half of the screen double-scanned then a thick black + thin white vsync pulse in the centre of the screen followed by the even scanlines from the top half of the screen double-scanned.

The top half of the screen though shown twice, is not shrunken in height.

I confirmed the double-scanning by setting a special wallpaper which consists of (G)reen/(M)agenta/(B)lack pixels as follows

BBBBBBBBBBBBBBBBMMMMMMMMMMMMMMMMM
GGGGGGGGGGGGGGGGBBBBBBBBBBBBBBBBB
BBBBBBBBBBBBBBBBMMMMMMMMMMMMMMMMM
GGGGGGGGGGGGGGGGBBBBBBBBBBBBBBBBB

normally this gives a horrid interlaced flicker, but I used it previously to demonstrate that interlace is working properly.

With 6.8.0 the top half of the display shows as pure

BBBBBBBBBBBBBBBBBMMMMMMMMMMMMMMMM
BBBBBBBBBBBBBBBBBMMMMMMMMMMMMMMMM

and the bottom has as pure

GGGGGGGGGGGGGGGGGGBBBBBBBBBBBBBBB
GGGGGGGGGGGGGGGGGGBBBBBBBBBBBBBBB

I can't get any joy using the xrandr trick as suggested above

[Freedesktopbugz (freedesktopbugz)]

Previous version that worked for me was
xorg-x11-drv-ati-6.6.3-4.fc7.x86_64.rpm

[Freedesktopbugz (freedesktopbugz)]

Created an attachment (id=15187)
Fix for radeon interlace modes

You'll be interested to know I've written a patch to fix this, by doubling the values of the vtotal/vdisplay/vsyncstart CRTC registers when in interlaced modes, the same should probably be done for CRTC2 registers.

I've just reported this via Fedora's bugzilla as my patch applies to the Fedora source after their other patches, hopefully it'll find its way upstream from there, or you can tweak the patch to apply it for other distros, I've attached it here for reference

https://bugzilla.redhat.com/show_bug.cgi?id=437700

[Andy (andy-redhat-bugs)]

Description of problem:

After upgrading from F7 to F8 my 50Hz PAL RGB interlace mode was broken (similar
problems also noted in ubuntu bugzilla and xorg bugzilla) the actual output was
the even rows of top half of the screen, followed a spurious vsync pulse halfway
down the screen, followed by the even rows of the top half of the screen.

Version-Release number of selected component (if applicable):

xorg-x11-drv-ati-6.8.0-1.fc8

How reproducible:

100%

After if some delving into the CRTC register values I decided to try doubling
the vertical values, this seems to work nicely, I've made it conditional on the
interlace flag, probably similar fix needed for CRTC2.

[Andy (andy-redhat-bugs)]

Created attachment 298199
Fix CRTC vtotal/vdisplay/vsyncstart registers for interlace

[Andy Burns (fedora-adslpipe)]

FYI I've just submitted a patch to fix this issue to Fedora's bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=437700

[agd5f (agd5f)]

(In reply to comment #34)
> Created an attachment (id=15187) [details]
> Fix for radeon interlace modes
>
> You'll be interested to know I've written a patch to fix this, by doubling the
> values of the vtotal/vdisplay/vsyncstart CRTC registers when in interlaced
> modes, the same should probably be done for CRTC2 registers.

I've just tested interlaced modes with the ati driver currently in git on several cards (RV280, RV350, RS690) and it works perfectly as is. Can you verify that you are still having a problem with the ati driver currently in git? Note that there are still issues with tiling when using multiple crtcs, but that is being sorted out now.

[Freedesktopbugz (freedesktopbugz)]

(In reply to comment #35)

> I've just tested interlaced modes with the ati driver currently in git on
> several cards (RV280, RV350, RS690) and it works perfectly as is. Can you
> verify that you are still having a problem with the ati driver currently in
> git?

I'll see if I can figure out git, and try to build from there, have to confess my main interest is in distro released versions.

> Note that there are still issues with tiling when using multiple crtcs,
> but that is being sorted out now.

Multi-crtc problems wouldn't show up on this machine, the only output is a TV.

[laga (laga)]

Andy,

thanks a lot for your patch. I've adapted it for the xserver-xorg-video-ati 6.8.0 package in Ubuntu and it works for me. I'm attaching the diff here.

[DualIP (adrian-bacon)]

I'm glad finally a coder looks into this, and patched code surfaces.
Although the recent posted patch will work for most users, imho it's not a proper patch.

Over here I didn't use git,but applied the patch to 6.8.0 source.
On my radeon7000 setup, the patch works fine when starting xorg into this mode:
Modeline "PALWS" 24.75 1280 1321 1437 1584 576 580 585 625 -hsync -vsync interlace
However I do have an additional PAL modeline in xorg.conf:
Modeline "PAL" 22.50 1152 1195 1301 1440 576 580 583 625 -hsync -vsync interlace
Using xrandr to switch from using the 1st modeline to 2nd gives wrong PAL output! The screen OSD reads 15k-below30Hz, where it should shoud 15k-50Hz. This mode suggest Vregisters are set to twice required value

It seems to me that somewhere a bug is introduced after V6.6.3, that somehow halves the Vregister settings on interlace mode.
On my radeon 7000, this bug only shows up when starting an interlaced mode, not after switching from an interlaced mode to another interlaced mode.
(that was my workaround, start interlaced, then jump to another interlaced mode)

"Hey, this pipe line is leaking half of the oil!"
"Then start pumping twice as much to get the required output."
Obvious that'll give required output , but (as environmentalists will agree) isn't the way to fix it ;-)

[Freedesktopbugz (freedesktopbugz)]

(In reply to comment #35)

> I've just tested interlaced modes with the ati driver currently in git on
> several cards (RV280, RV350, RS690) and it works perfectly as is. Can you
> verify that you are still having a problem with the ati driver currently in
> git?

Just checked out the ATI driver sources with git-clone from
git://anongit.freedesktop.org/git/xorg/driver/xf86-video-ati

Ran autogen and make, killed X server, copied over the newly built driver and re-started X server.

I can confirm the same issue exists that I originally had.

Will attach config and log files.

[Freedesktopbugz (freedesktopbugz)]

Created an attachment (id=15295)
xorg.conf

[Freedesktopbugz (freedesktopbugz)]

Created an attachment (id=15296)
Log file from git 19-MAR-2008

[agd5f (agd5f)]

(In reply to comment #38)
> (In reply to comment #35)
> I can confirm the same issue exists that I originally had.

Perhaps it's just an issue with PAL modes you are using. Is there any chance you can try an interlaced mode (like 1024x768i) on a monitor? Those modes work fine on all my cards, but I don't have a TV to test you PAL modes on. Perhaps forcing a lower min clock would help?

[Freedesktopbugz (freedesktopbugz)]

(In reply to comment #41)

> you can try an interlaced mode (like 1024x768i) on a monitor?

Connected a CRT and used the "industry standard" modeline

ModeLine "1024x768" 44.9 1024 1032 1208 1264 768 768 776 817 +hsync +vsync Interlace

Unfortunately, the output is not correct.

Only the top half of the screen is displayed, stretched to fill the whole screen, the individual scanlines are quite widely separated, the monitor seems able to lock on to the "double frequency" sync pulse better than the TV, as you'd expect from a multisync device I suppose, so there isn't a black sync bar visible on screen.

Monitor OSD reports frequencies as horizontal 35kHz, vertical 174Hz

> I don't have a TV to test you PAL modes on. Perhaps
> forcing a lower min clock would help?

The 13MHz clock has worked with all previous drivers for more than 2 years, but I will certainly try forcing it even lower.

Config/Log files required for the 1024x768i test?

[Freedesktopbugz (freedesktopbugz)]

With my "vertical * 2" patch I get a proper picture on the CRT monitor using 1024x768i modeline, however the monitor OSD reports 87Hz vertical frequency.

I tried a "vertical * 4" version of my patch, to see if the monitor OSD would show the expected 43.5Hz but the monitor refused to show any picture.

[Freedesktopbugz (freedesktopbugz)]

(In reply to comment #43)

> the monitor OSD reports 87Hz vertical frequency.

OK realised that the OSD must be displaying the field rate, rather than the frame rate so those numbers are OK.

[Freedesktopbugz (freedesktopbugz)]

(In reply to comment #41)

> Perhaps it's just an issue with PAL modes you are using.

I think all the people reporting this issue are using PAL modelines.

> Perhaps forcing a lower min clock would help?

Tried using 12.0MHz (which I beleive is the lowest the drive will allow) unfortunately no difference.

[DualIP (adrian-bacon)]

I'm glad finally a coder looks into this, and patched code surfaces.
Although the recent posted patch will work for most users, imho it's not a proper patch.

Over here I didn't use git,but applied the patch to 6.8.0 source.
On my radeon7000 setup, the patch works fine when starting xorg into this mode:
Modeline "PALWS" 24.75 1280 1321 1437 1584 576 580 585 625 -hsync -vsync interlace
However I do have an additional PAL modeline in xorg.conf:
Modeline "PAL" 22.50 1152 1195 1301 1440 576 580 583 625 -hsync -vsync interlace
Using xrandr to switch from using the 1st modeline to 2nd gives wrong PAL output! The screen OSD reads 15k-below30Hz, where it should shoud 15k-50Hz. This mode suggest Vregisters are set to twice required value

It seems to me that somewhere a bug is introduced after V6.6.3, that somehow halves the Vregister settings on interlace mode.
On my radeon 7000, this bug only shows up when starting an interlaced mode, not after switching from an interlaced mode to another interlaced mode.
(that was my workaround, start interlaced, then jump to another interlaced mode)

"Hey, this pipe line is leaking half of the oil!"
"Then start pumping twice as much to get the required output."
Obvious that'll give required output , but (as environmentalists will agree) isn't the way to fix it ;-)

[DualIP (dualip-redhat-bugs)]

I'm glad finally a coder looks into this, and patched code surfaces.
Although the recent posted patch will work for most users, imho it's not a
proper patch.

Over here I didn't use git,but applied the patch to 6.8.0 source.
On my radeon7000 setup, the patch works fine when starting xorg into this mode:
Modeline "PALWS" 24.75 1280 1321 1437 1584 576 580 585 625 -hsync -vsync
interlace
However I do have an additional PAL modeline in xorg.conf:
Modeline "PAL" 22.50 1152 1195 1301 1440 576 580 583 625 -hsync -vsync interlace
Using xrandr to switch from using the 1st modeline to 2nd gives wrong PAL
output! The screen OSD reads 15k-below30Hz, where it should shoud 15k-50Hz.
This mode suggest Vregisters are set to twice required value

It seems to me that somewhere a bug is introduced after V6.6.3, that somehow
halves the Vregister settings on interlace mode.
On my radeon 7000, this bug only shows up when starting an interlaced mode, not
after switching from an interlaced mode to another interlaced mode.
(that was my workaround, start interlaced, then jump to another interlaced mode)

"Hey, this pipe line is leaking half of the oil!"
"Then start pumping twice as much to get the required output."
Obvious that'll give required output , but (as environmentalists will agree)
isn't the way to fix it ;-)

[Andy (andy-redhat-bugs)]

(In reply to comment #2)

> imho it's not a proper patch.

Heh, I won't disagree with you :-)

I needed a fix that works for me, and I thought others might benefit, someone
who knows the driver might fix it in a far better way.

[Freedesktopbugz (freedesktopbugz)]

I realised I hadn't done any non-interlaced tests, in the case of my TV it doesn't support non-interlaced modes, but I have the CRT monitor available, so I tried 640x480 mode with it, this works fine (with and without my patch, and as expected fails to produce a valid display if I make my patch *NOT* unconditional instead of checking for V_INTERLACE)

It seems to me from looking at the register dumps by Michael Haas and from debug prints I put into the driver that *something* has halved the values of vertical registers for interlaced modes, presumably this is happening when the mode values are calculated (or adjusted) rather than (at the stage I inserted my hack) when they are poked into CRTC registers.

I tried a git bisect, but rapidly ran back to versions of the driver that the X server refused to load (version compatibility with my server or drm module?)

Also I've looked "by eye" at the diffs between 0abce69f0d826a7ca1a41d963cd4730b6e01c145
and
2618cf2aa8ed76411b943eb90c95869814c2f151
but the "merge and fix conflicts" in
76670f665ebec7cdf40a04bf9379cb3ad4417507
are a bit too much for me to follow manually, so much other development has happened since that change, makes it difficult to follow code that has been split into other files.

Perhaps this problem only affects certain cards, any clue how I can proceed further?

[S-j-newbury (s-j-newbury)]

Andy, since the new randr code went in the current driver uses completely different code paths for modesetting, a bisect is only of limited usefulness due to this. I don't believe the new code was properly tested for the interlaced (initial mode) case we need. You need to look at what the old (working) code did when initialising interlaced modes and ensure the current code does the same. I did have a look myself previously but couldn't see what was missing. I'll have another look, as you say it's probably in the timings calcs...

[S-j-newbury (s-j-newbury)]

OK. It's obviously: xf86SetModeCrtc(adjusted_mode, INTERLACE_HALVE_V) not getting called in every case it should. It seems to get called unconditionally in the i810 driver...

[Freedesktopbugz (freedesktopbugz)]

(In reply to comment #48)

> OK. It's obviously: xf86SetModeCrtc(adjusted_mode, INTERLACE_HALVE_V) not
> getting called in every case it should.

Sounds likely, but rather it's being called when it shouldn't be, I'll have to pull down some old git trees for comparison.

Still doesn't explain why Alex sees interlace modes with a standard monitor work and I don't (without re-doubling the verticals).

[S-j-newbury (s-j-newbury)]

Perhaps it's only not working if the initial start-up mode is interlace? I'm unable to test at the moment since I'm having trouble building the xserver...

[agd5f (agd5f)]

(In reply to comment #50)
> Perhaps it's only not working if the initial start-up mode is interlace? I'm
> unable to test at the moment since I'm having trouble building the xserver...
>

I'm able to add modes and switch between interlaced/non-interlaced on the fly via xrandr.

[S-j-newbury (s-j-newbury)]

So I guess the question is how does the code path differ between randr and startup. Perhaps the bug is related to where initial mode stucts get filled in, particularly where the xorg.conf modelines get added rather than mode programming itself?

[Freedesktopbugz (freedesktopbugz)]

(In reply to comment #51)

> I'm able to add modes and switch between interlaced/non-interlaced on the fly
> via xrandr.

I set my default mode to 800x600 non-interlaced and started X, then did

xrandr --newmode 720x576 13.88 720 741 814 888 576 580 587 625 +hsync +vsync interlace composite

xrandr --addmode VGA-0 720x576

It seems OK at this stage, xrandr lists the new mode, but when I do

xrandr --output VGA-0 --mode 720x576

it crashes my whole machine (the display does change to black), I'll see if I can get any sensible crashdump out of a serial console.

[PreyingMantis (andrew-diver)]

I've got the same problem trying to display on a PAL CRT television using a VGA-> SCART lead.

mobo: Albatron KI690-AM2 with onboard RS690G chipset (Radeon Xpress 1250)
OS: OpenSuSE 10.3 with 2.6.24 kernel for x86_64
X server 7.2.0
xorg.conf: Driver "radeon" # version 6.8.0 built from git repository as of Apr 1st 2008 (commit fc9af578...1b0e)
                 Modeline "768x576i" 14.76 768 824 888 944 576 581 586 625 -hsync -vsync interlace

When I try the xrandr switch the black vsync gap disappears so I get full screen, but the y-coords are wrong (- looks like the X mouse events are generated as y-mouse co-ord x 2) and only a fraction (top left corner) of my desktop is visible.
The patch has no effect on my setup - presumably legacy_crtc.c not used for my card... does anyone have any clues as to a work-around until this bug is fixed properly ? I had a quick look but didn't spot the same code to what was changed in the legacy_crtc.c patch...

I also tried the 'radeonhd' v1.1.0 driver, but looks like it won't support interlace yet...

Thanks
Mantis

[cyrillic (t-dekker)]

Hi, is anyone still looking into this?
I have the same problem, and while xrandr does the job, it should be working from the start...
I was looking at how the radeon module initializes, and i wonder if perhaps RADEONCrtcFindClosestMode() doesn't honour the interlace flag. All the commits between the working and non-working version seem pretty harmless, but something must have been changed :(

[Freedesktopbugz (freedesktopbugz)]

(In reply to comment #54)

> Hi, is anyone still looking into this?

Not had chance to look for a while, my "hacky patch" works for me, but is clearly not an acceptable solution.

> I have the same problem, and while xrandr does the job, it should be working
> from the start...

I never got an interlaced mode running with xrandr, can you give me the exact steps you used to do that? what mode did you start X in? did you just switch to an interlaced mode pre-defined in your xorg.conf? or did you define a new mode with xrandr and then switch to it?

> All the commits
> between the working and non-working version seem pretty harmless, but something
> must have been changed :(

Yep, but I rapidly got lost in them, doesn't help that my TV is the only monitor on this machine, hardly makes it convenient for editing/viewing large chunks of source code ...

[cyrillic (t-dekker)]

I have two working modes on my Radeon 7200 (R100):

ModeLine "720x576PAL" 15.125 720 770 842 968 576 579 607 625 Composite Interlace
Modeline "720x540PAL" 15.101 720 770 842 968 540 565 570 624 Composite Interlace

Additionally I define the virtual size, but i'm not really sure if it makes a difference:

Section "Screen"
  SubSection "Display"
    Virtual 720 576

$ export DISPLAY=":0.0"
$ xrandr -s 1
$ xrandr -s 0

And that's what i need to get a normal picture...

I'm thinking of using your patch, but an upstream fix would be very welcome :)

[Bryce Harrington (bryce)]

In reading the comments and the upstream bug reports, it doesn't sound like there's a consensus about taking the patch upstream, so I'm going to hold off on pulling it into Ubuntu. Alex Deucher is having trouble reproducing the issue, and also see https://bugs.freedesktop.org/show_bug.cgi?id=12626#c37. Setting back to incomplete for now.

[Mike-pieper-family (mike-pieper-family)]

Hello,

I can confirm that this bug still exists in todays git.

I'm using an interlaced mode. As output a TV is connected via SCART.
I see the picture doubled with a black line in the middle. The picture is streatched 2 times, i.e. I see two times the first quarter of the picture.
Horizontally the picture is correct.

My hardware is a Gigabyte Mobo with a X1250 IGP.

It would be great if someone could try to fix this. The patch above doesn't work for me.

Thanks
Mike

[agd5f (agd5f)]

(In reply to comment #57)
>
> My hardware is a Gigabyte Mobo with a X1250 IGP.

I just fixed some issues with interlaced and avivo cards in git. So the x1250 should work fine now with ati from git master. As to pre-avivo chips, unfortunately, I cannot reproduce any problems with with interlaced modes here.

[cyrillic (t-dekker)]

I think vsync is calculated wrong when an interlaced modeline is read, since xrandr sets it correctly. Anything i can do to help you?

> As to pre-avivo chips,
> unfortunately, I cannot reproduce any problems with with interlaced modes here.

[Mike-pieper-family (mike-pieper-family)]

Created an attachment (id=17820)
Picture of X1250 with interlaced mode showing VDR.

[Mike-pieper-family (mike-pieper-family)]

Created an attachment (id=17821)
Picture of X1250 with interlaced mode showing plain X screen.

[Mike-pieper-family (mike-pieper-family)]

(In reply to comment #58)

Sorry but the latest git shows exactly the same behavior like before. I've attached two screenshots showing the problem.

[Mike-pieper-family (mike-pieper-family)]

With this patch I get on my hardware (X1250 IGP) at least the same behavior like the others, i.e. after switching resolution with xrandr I have a correct picture:

diff --git a/src/atombios_crtc.c b/src/atombios_crtc.c
index 70650e1..18885e6 100644
--- a/src/atombios_crtc.c
+++ b/src/atombios_crtc.c
@@ -493,7 +493,7 @@ atombios_crtc_mode_set(xf86CrtcPtr crtc,
        OUTREG(AVIVO_D1GRPH_X_END + radeon_crtc->crtc_offset, x + mode->HDisplay);
        OUTREG(AVIVO_D1GRPH_Y_END + radeon_crtc->crtc_offset, y + mode->VDisplay);
        OUTREG(AVIVO_D1GRPH_PITCH + radeon_crtc->crtc_offset,
- crtc->scrn->displayWidth);
+ crtc->scrn->displayWidth << ((adjusted_mode->Flags & V_INTERLACE)?1:0));
        OUTREG(AVIVO_D1GRPH_ENABLE + radeon_crtc->crtc_offset, 1);

        OUTREG(AVIVO_D1MODE_DESKTOP_HEIGHT + radeon_crtc->crtc_offset,

[Mike-pieper-family (mike-pieper-family)]

(In reply to comment #63)
This patch is not quite correct. Now I can see the whole picture, but I can see only every second line. That means that the lines are doubled by the hardware (like doublescan) and by doubling the pitch in the patch I skip every second line.

I played around with the line:
src/atombios_crtc.c:655
OUTREG(AVIVO_D1MODE_DATA_FORMAT + radeon_crtc->crtc_offset,
                   AVIVO_D1MODE_INTERLEAVE_EN);

It makes no difference if the AVIVO_D1MODE_INTERLEAVE_EN bit is set or not.

[agd5f (agd5f)]

How are you adding the interlaced mode? Is it part of the edid from your monitor or a modeline or added at runtime using xrandr? As has been noted, I suspect the xserver may be mangling interlaced modes. Can you attach your xorg log?

[Mike-pieper-family (mike-pieper-family)]

Created an attachment (id=17827)
Xorg.log for Interlaced mode with two xrandr -s x calls

This is the Xorg.log when starting the X-server in interlaced mode. Short after starting I switch the resolution with xrandr -s 1 ; xrandr -s 0.

[Mike-pieper-family (mike-pieper-family)]

Created an attachment (id=17828)
xorg.conf for X1250 igp with interlaced mode.

This is the xorg.conf. The interlaced mode is defined by myself. The same timing works with fglrx. radeonhd doesn't like this mode at all.
Only difference to fglrx is that I had to change sync polarity (+hsync -> -hsync ...)

[Bryce Harrington (bryce)]

Could someone test this against Intrepid and see if the situation is any better with the newer -ati driver?

[Brian Murray (brian-murray)]

Thanks for taking the time to report this bug and helping to make Ubuntu better. In the development cycle for Intrepid there have been some vast improvements in the open source ati video driver and we could use your help testing them. Could you please download the latest Alpha CD image of Intrepid and test this particular bug just using the Live CD? You can find the latest image at http://www.ubuntu.com/testing . Your testing can help make Ubuntu and the open source ati driver even better! Thanks in advance.

[Bryce Harrington (bryce)]

We're closing this bug since it is has been some time with no response from the original reporter. However, if the issue still exists please feel free to reopen with the requested information. Also, if you could, please test against the latest development version of Ubuntu, since this confirms the bug is one we may be able to pass upstream for help.

[Bryce Harrington (bryce)]

Actually I see some fairly recent activity on the upstreamed bug; leaving it open.

[Jose Bernardo (bernardo-bandos)]

I apologize for the long time since my last report, but I can no longer test if this bug is fixed - I replaced the Radeon with a NVidia 7200 some time ago, and finally the TV broke down and I bought a LCD. So I no longer have the original parts to test it.

[Arvidb (arvidb)]

I've had similar problems getting VGA->Scart (PAL RGB) to work.

I have found one and only one way of getting a picture on my TV: add a PAL compatible mode in xorg.conf (not with xrandr), but make sure X starts with a non-interlaced mode on the VGA output (e.g. the automatically added 1024x768@60Hz VESA mode). This gives me an un-synced scrolling picture on the TV.

Then use xrandr to change to the PAL mode added in xorg.conf.

Any other procedure (starting X with the PAL mode set from the beginning or adding the mode with xrandr) just gives me a black screen (with sync if the mode I set is PAL compatible, without sync otherwise, but always just black). And the TV seems to display whatever it is sent even if it cannot sync to the signal, so it is probably sent a black picture by the graphics card.

When it works, the mouse pointer is shown in the wrong position on the TV: at half the y position compared to the correct position. (I.e. if I want to click something at the bottom of the TV screen I have to position the mouse pointer in the middle of the TV screen.) The mouse pointer is not visible in "black mode".

Using "X Window System Version 1.3.0" and xf86-video-ati-6.9.0 (or ati-git-080929; same result).

[cyrillic (t-dekker)]

I opt to commit Andy's fix to git. Nobody new is going to come up with a proper fix for these old drivers. At least this makes it work for a few, and it has no drawbacks. If it breaks again in a future Xorg version we have a better chance of bisecting the real problem. This also prevents users with a similar problem but a different bug from diluting this report and never find help themselves.

[Naez (krister-atdot)]

I have exactly the same problem, using Ubuntu 8.04 and the opensource Radeon driver. I have banged my head against this problem many many hours. changing cables and such. I have not yet tried the xrandr workaround as stated here, but I will do that later today.

Is the version of xserver-xorg-video-ati updated in the newest version of Ubuntu?

[Naez (krister-atdot)]

Yes, I can confirm that if I have 2 working modelines (tested in powerstrip) and I switch between them using
xrandr -display :0.0 -s 1 and xrandr -display :0.0 -s 0 alternately, I can see that initially I get the bug, but after switching I get both modes working fine. Could this be remedied in the newer 6.9 Version available in 8.10 ?

[Rvanderstelt (rvanderstelt)]

While checking why the mode->CrtcV values are halve of what they should be (like they were in version 6.6.3) I came across the following comment in the function xf86InitialCheckModeForDriver (file hw/common/xf86Mode.c):

/*
 * NOTE: We (ab)use the mode->Crtc* values here to store timing
 * information for the calculation of Hsync and Vrefresh. Before
 * these values are calculated the driver is given the opportunity
 * to either set these HSync and VRefresh itself or modify the timing
 * values.
 * The difference to the final calculation is small but imortand:
 * here we pass the flag INTERLACE_HALVE_V regardless if the driver
 * sets it or not. This way our calculation of VRefresh has the same
 * effect as if we do if (flags & V_INTERLACE) refresh *= 2.0
 * This dual use of the mode->Crtc* values will certainly create
 * confusion and is bad software design. However since it's part of
 * the driver API it's hard to change.
 */

In version 6.6.3 the function RADEONPreInitModes (file src/radeon_driver.c) calls xf86SetCrtcForModes which in turn calls xf86SetModeCrtc for each mode with adjustFlag 0.

However in version 6.9.0 the new function radeon_mode_fixup (file src/radeon_output.c) only recalculates the mode->Crtc* values for a few specific conditions.
Namely when MonType is MT_LCD or MT_DFP and the display resolution is smaller then the panel resolution (and rmx_type is not RMX_OFF and either IS_AVIVO_VARIANT or radeon_crtc_id == 0 is true).

This means that at least for CRT monitors the CrtcV* values are left halve from what they should be.

To fix this I placed a call to xf86SetModeCrtc with adjustFlag 0 at the start of the radeon_mode_fixup function. But I'm not sure whether this is correct for all radeon cards because as I gather from the previous comments that this problem only seems to show up on older cards (I have a R350).

Note that the function radeon_mode_fixup contains two calls to xf86SetModeCrtc with the INTERLACE_HALVE_V flag. But after the call the Crtc* values are recalculated (without adjusting for interlacing or double scanning). However the values CrtcVBlankStart, CrtcVBlankEnd, CrtcHBlankStart and CrtcHBlankEnd are left untouched.

The problem with the pointer image placed to high is caused by the halving of the y coordinate in the function radeon_crtc_set_cursor_position when the V_INTERLACE flags is set. This wasn't done in version 6.6.3.
Removing it fixes the problem.

Note that the y coordinate is doubled when the V_DBLSCAN flag is set. This matched the doubling of the CrtcV values in xf86SetModeCrtc. But the y coordinate is not multiplied with mode->VScan.

Also note the corrected values in the 'adjusted_mode' don't seem to be propagated to the various copies of the mode in the xserver data structures.
The adjusted_mode is just dropped at the end of the xf86CrtcSetMode function.
So when the function RADEONDisplayVideo (radeon_video.c) uses crtc->mode.CrtcVDisplay it gets the halved valued.

Unfortunately this is not the cause of xv corruption I am experiencing on the second head (it is not related to interlacing).

Attached a patch.

[Rvanderstelt (rvanderstelt)]

Created an attachment (id=20529)
Proposed patch to fix split screen and wrong pointer image placement

[Freedesktopbugz (freedesktopbugz)]

(In reply to comment #70)

> While checking why the mode->CrtcV values are halve of what they should be
> (like they were in version 6.6.3) I came across the following comment in the
> function xf86InitialCheckModeForDriver

That looks like a much better attempt to stop the problem happening, rather than my approach of fixing it after it has happened, I'm no longer using my VGA->SCART cable, having upgraded to HDMI and switched from Radeon PCIe to a motherboard with Intel video onboard.

[cyrillic (t-dekker)]

You are a hero! This fixes the resolution and the mouse pointer. Even on my older card which uses the legacy part of the driver.

I concern this bug closed \o/

[Naez (krister-atdot)]

Additional information:

The mousepointer does not move to the bottom part of the screen, but the X-Y coordinates seems to work... this means that I can not really see where the mouse points, unless I can see some part of the desktop highlight, indicating that it is there where the action will be :) So - this is bugging me quite a bit now. Switching to the fglrx driver seems not to be an option either, as it is indicated that it ignores the "forcemindotclock" directive needed to render the output to my SCART connected TV.

[agd5f (agd5f)]

pushed thanks!
065938617c0feab17f4274a5350de02a692ba065

[Naez (krister-atdot)]

Sweet. Will upgrade to Ubuntu 8.10 (as the 6.9.0 git won't compile on my 8.04)and try this on my arcade system tonight. I have the exact same probs with the driver as it is today. Let you know the result....

[Bug (bug-redhat-bugs)]

This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 8 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

[Andy (andy-redhat-bugs)]

(In reply to comment #4)

> Fedora 8 is nearing its end of life.

I believe a different patch for this has now been accepted upstream, I have switched from Radeon/VGA to Intel/HDMI so no longer relevant for me, hopefully the new fix will be picked up and benefit others.

[Naez (krister-atdot)]

This fix solved my problem. Thanks.

[Bryce Harrington (bryce)]

Fixed, according to upstream comment.

[Bug (bug-redhat-bugs)]

This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 9 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

[Bug (bug-redhat-bugs)]

Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

[DualIP (adrian-bacon)]

afaik, the bug causing this problem is found and a patch made it into newer ATI radeon driver
http://bugs.freedesktop.org/show_bug.cgi?id=12626#c70