Bug 2859 - Flickering or blanking on DVI output of Radeon 9200/9250
Summary: Flickering or blanking on DVI output of Radeon 9200/9250
Status: RESOLVED INVALID
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/Radeon (show other bugs)
Version: git
Hardware: x86 (IA32) All
: high normal
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
: 1620 2657 2887 2935 3275 7478 (view as bug list)
Depends on: 4656
Blocks:
  Show dependency treegraph
 
Reported: 2005-03-30 01:48 UTC by Tomas Lindén
Modified: 2010-02-16 15:17 UTC (History)
20 users (show)

See Also:
i915 platform:
i915 features:


Attachments
My xorg.conf file (2.91 KB, text/plain)
2005-03-30 01:52 UTC, Tomas Lindén
no flags Details
The Xserver log file. (44.92 KB, text/plain)
2005-03-30 01:55 UTC, Tomas Lindén
no flags Details
The output from lspci -vv. (6.69 KB, text/plain)
2005-03-30 01:57 UTC, Tomas Lindén
no flags Details
The striped desktop in 1400x1050 DVI mode, when setting Option Panelsize (319.77 KB, image/jpeg)
2005-04-03 23:38 UTC, Tomas Lindén
no flags Details
The rightshifted DVI 1280x1024 desktop when setting Option Panelsize (299.74 KB, image/jpeg)
2005-04-03 23:39 UTC, Tomas Lindén
no flags Details
The right shifted DVI 800x600 desktop when setting Option PanelSize (313.61 KB, image/jpeg)
2005-04-03 23:41 UTC, Tomas Lindén
no flags Details
My configuration file for Accelerated-X (725 bytes, text/plain)
2005-04-29 05:16 UTC, Tomas Lindén
no flags Details
Xorg.0.log.screenblank (46.73 KB, text/plain)
2006-04-14 12:34 UTC, Brian Beardall
no flags Details
may not fix everyone's problems but works for me (1.37 KB, patch)
2006-12-08 16:06 UTC, Roland Scheidegger
no flags Details | Splinter Review
print out the tmds table (495 bytes, patch)
2007-01-18 05:27 UTC, Roland Scheidegger
no flags Details | Splinter Review
Radeon driver without bios tables rev. 4, x86-32 (313.34 KB, application/octet-stream)
2007-02-22 16:36 UTC, Nuri Jawad
no flags Details
Xorg.0.log, Fedora8, xf86-video-ati-6.9.0 (51.64 KB, text/plain)
2008-07-07 09:00 UTC, Mike
no flags Details
Modeline ignored (51.40 KB, text/plain)
2008-07-10 05:46 UTC, Mike
no flags Details
Modeline ignored (1.02 KB, text/plain)
2008-07-10 05:46 UTC, Mike
no flags Details

Description Tomas Lindén 2005-03-30 01:48:57 UTC
I have an Eizo Flexscan L885 1600x1200 pixel TFT display with DVI-input:
  http://www.eizo.com/support/discontinued/lcd/l885.asp
connected to an ASUS Radeon 9200 SE/TD 128 AGP display card with DVI-output:
  http://usa.asus.com/products/vga/r9200se-td/overview.htm
The graphics card sits on a dual 500 MHz PIII ASUS P2B-DS motherboard 
with 256 MB RAM.

I have the following problems with the radeon driver on this card:
  The DVI-output blanks randomly in all resolutions which makes it unusable.
  The xv driver shows output only over the DVI signal, which is unusable
    because of the random blanking and no output on the analog signal.
  Getting any DVI ouput at all required the usage of the option
    Option      "MonitorLayout" "TMDS, CRT"
  Getting a 1600x1200 mode DVI output required in addition the option
    Option      "PanelSize" "1600x1200"
  but this breaks the drawing of the following resolutions
    1400x1050, 1280x1024 and 800x600

In the following the problems are described in more detail.

The Fedora Core 3 display configurator command
  system-config-display
gives ouput only on the analog output. Nothing is seen on the
DVI-output, during the X11 configuration.

The configuration file thus created will show output only on the analog ouput.

By adding 
  Option      "MonitorLayout" "TMDS, CRT"
to xorg.conf by hand and editing the refresh rates to be compatible 
with my monitor in digital mode, I could get a signal on the DVI-output as
well in the modes "1400x1050" "1280x1024" "1024x768" "800x600" and "640x480".

With this option I cannot get any 1600x1200 mode DVI ouput, which is the
native mode of my TFT display. With this option the resolution 1400x1050
blanks the screen for a short time once or several times with random
intervals.

The DVI modes "1400x1050" "1280x1024" "1024x768" "800x600" and "640x480"
are drawn correctly on the screen without any artefacts.

Using xine with the default xv driver gives output only on the DVI
signal.

Using the xshm driver with xine gives both analog and DVI output.

Adding this
  Option      "PanelSize" "1600x1200"
to xorg.conf I can finally get a 1600x1200 DVI output on my screen, but
the problem with random blanking makes this mode unusable. 

In addition to the problem that the xv driver only gives output on the
dvi-signal, the following new problems appear with drawing the modes
that are smaller than my TFT-panels native resolution:

           1600x1200 blanks
           1400x1050 blanks, horizontal stripes at left and right side
           1280x1024 blanks, displaced to right
           1024x768  blanks
            800x600  blanks, displaced to right
            640x480  blanks

Changing the resolution on the fly with xrandr gives strange striped
borders on the left and right side of the display in 1400x1050.
Switching to 1280x1024 and 800x600 the right part of the desktop is
actually shown on the left edge of the display. Switching to 1024x768
and 640x480 works as expected. 

This bug has previously been filed on 
  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=143872
in a slightly different wording.

Bug 
  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=142932
seems similar to the one that I see, but I have the random blanks even
without touching the mouse.

Best regards,                      Tomas Lindén
Comment 1 Tomas Lindén 2005-03-30 01:52:46 UTC
Created attachment 2256 [details]
My xorg.conf file
Comment 2 Tomas Lindén 2005-03-30 01:55:10 UTC
Created attachment 2257 [details]
The Xserver log file.
Comment 3 Tomas Lindén 2005-03-30 01:57:48 UTC
Created attachment 2258 [details]
The output from lspci -vv.
Comment 4 Alex Deucher 2005-03-31 08:46:21 UTC
try changing the "displaypriority" option.  See the radeon man page for more. 
Another thing to try is setting up a custom modeline with a vrefresh less than
60; like 50 or 55.
Comment 5 Tomas Lindén 2005-04-01 02:11:50 UTC
I tried using
  Option      "DisplayPriority" "BIOS"
and
  Option      "DisplayPriority" "HIGH"
instead of the default value "AUTO", but this did not solve the blanking 
problem, the xv problem nor the problem with showing the DVI modes 1400x1050,
1280x102 and 800x600 properly.

According the manual for My Eizo FlexScan L885 display the Vertical Scanning 
frequency in DVI mode is limited to the range 59-61 Hz.

The manual also says concerning Digital Input that "Only the following 
resolutions with frequency can be displayed on this model"
Resolution Frequency Dot Clock     Remarks
...
1600x1200  60 Hz     162 MHz (max) VESA

For this reason I don't think that it makes sense to try a lower frequency like 
50 or 55 Hz.

Bug 1129 seems similar to the one that I'm seening and it concerns also the same 
ASUS card that I have:
  https://bugs.freedesktop.org/show_bug.cgi?id=1129
Comment 6 Tomas Lindén 2005-04-03 23:38:38 UTC
Created attachment 2306 [details]
The striped desktop in 1400x1050 DVI mode, when setting Option Panelsize
Comment 7 Tomas Lindén 2005-04-03 23:39:44 UTC
Created attachment 2307 [details]
The rightshifted DVI 1280x1024 desktop when setting Option Panelsize
Comment 8 Tomas Lindén 2005-04-03 23:41:01 UTC
Created attachment 2308 [details]
The right shifted DVI 800x600 desktop when setting Option PanelSize
Comment 9 Tomas Lindén 2005-04-11 04:44:23 UTC
The following bugs might be related to the problems described here

DVI screem flickering problem
https://bugs.freedesktop.org/show_bug.cgi?id=1724
https://bugs.freedesktop.org/show_bug.cgi?id=2674
https://bugs.freedesktop.org/show_bug.cgi?id=2887

Xv driver problem
https://bugs.freedesktop.org/show_bug.cgi?id=2759
Comment 10 Tomas Lindén 2005-04-22 02:16:48 UTC
The DVI screen flickering problem occurs for me even when there is no mouse
activity or significant screen changes. However it does get _MUCH MORE_
frequent if there is lots of screen updates like when watching a video
sequence in full screen with xine and the Xv driver, so the problem is
also somehow related to the load on the graphics card.
Comment 11 Alex Deucher 2005-04-22 06:02:04 UTC
the 9200SE definitely has limited bandwidth due to their lower memory bandwidth.
  Have you tried running your vrefresh at 50 Hz?  You may need a custom
modeline.  I think the windows drivers default to a lower refresh on the DVI
port on the SE cards.  Does the card work properly in windows?  The failure rate
on cheap 9200SE's seems somewhat higher than other radeons.
Comment 12 Tomas Lindén 2005-04-22 14:37:27 UTC
(In reply to comment #11)
> the 9200SE definitely has limited bandwidth due to their lower memory 
bandwidth.

I don't think this is bandwidth related problem because the analog output over 
the VGA cable works fine in 1600x1200 mode. This card is supposed to support a 
maximum display size of 2048x1536, so DVI 1600x1200 should not be a problem.

>   Have you tried running your vrefresh at 50 Hz?  You may need a custom
> modeline.  

The URL to my monitor 
  http://www.eizo.com/support/discontinued/lcd/l885.asp
says that the vertical refresh rate for DVI-signals is 59-61 Hz (For VGA text 
modes the range is 69-71 Hz). The same information is given in the display 
manual and I have confirmed by the local Eizo support that 1600x1200 DVI only 
runs with a vertical refresh rate of 60 Hz.

The distorted DVI-modes that I have shown screen shots of suggest to me that 
there is some kind of timing problem in the Radeon driver for this card.

> I think the windows drivers default to a lower refresh on the DVI
> port on the SE cards.  Does the card work properly in windows?  

I don't have windows on this machine and no space on the harddrive to install
Windows just for testing.

ASUSTEK supplies a Windows driver for this card, but I don't know if this is a 
relabeled ATI driver.

> The failure rate
> on cheap 9200SE's seems somewhat higher than other radeons.

I would have bougth a 9200 card, but I could not find any left in the local 
retail shops. The 9200 and 9200SE has all the features that I want supported in  
principle by the Radeon driver which is why I bought the card in the first 
place. Since I don't do gaming I did not go for a more expensive card with more 
3D-performance.

What do you mean by the failure rate in this context?
Comment 13 Alex Deucher 2005-04-23 16:34:44 UTC
(In reply to comment #12)
> (In reply to comment #11)
> > the 9200SE definitely has limited bandwidth due to their lower memory 
> bandwidth.
> 
> I don't think this is bandwidth related problem because the analog output over 
> the VGA cable works fine in 1600x1200 mode. This card is supposed to support a 
> maximum display size of 2048x1536, so DVI 1600x1200 should not be a problem.
> 
> >   Have you tried running your vrefresh at 50 Hz?  You may need a custom
> > modeline.  
> 
> The URL to my monitor 
>   http://www.eizo.com/support/discontinued/lcd/l885.asp
> says that the vertical refresh rate for DVI-signals is 59-61 Hz (For VGA text 
> modes the range is 69-71 Hz). The same information is given in the display 
> manual and I have confirmed by the local Eizo support that 1600x1200 DVI only 
> runs with a vertical refresh rate of 60 Hz.
> 
> The distorted DVI-modes that I have shown screen shots of suggest to me that 
> there is some kind of timing problem in the Radeon driver for this card.

Unless their is some weirdness for the SE cards, I've never had a problem with
DVI on my non-SE card.  Problems with SE cards and DVI seem pretty common.  One
of the things that other users have reported as helping is running the DVI on SE
cards at a lower refresh rate like 50 or 55 Hz.

> 
> > I think the windows drivers default to a lower refresh on the DVI
> > port on the SE cards.  Does the card work properly in windows?  
> 
> I don't have windows on this machine and no space on the harddrive to install
> Windows just for testing.
> 
> ASUSTEK supplies a Windows driver for this card, but I don't know if this is a 
> relabeled ATI driver.

Shouldn't really matter, ati's drivers will handle the card too.

> 
> > The failure rate
> > on cheap 9200SE's seems somewhat higher than other radeons.
> 
> I would have bougth a 9200 card, but I could not find any left in the local 
> retail shops. The 9200 and 9200SE has all the features that I want supported in  
> principle by the Radeon driver which is why I bought the card in the first 
> place. Since I don't do gaming I did not go for a more expensive card with more 
> 3D-performance.
> 
> What do you mean by the failure rate in this context?

Quite a few people have not been able to get the DVI port to work properly on SE
cards in both windows and Xorg.
Comment 14 Tomas Lindén 2005-04-28 06:08:07 UTC
I tried using the vesa driver on my Fedore Core 3 machine to see if
that driver also exhibits the random blanking of the DVI signal. Unfortunately I
could not get any large resolution DVI modes, but only
  1024x768x16
and
  1024x768x24
worked. I could not see any blanking on the screen with this driver in
these modes. Watching a short film sequence with xine required the use of
  -V Xshm
to get a signal DVI- and VGA-signal, but also this did not induce any
flickering. 

I repeated the same exercise using Knopppix 3.8.1 (kernel 2.6.11,
XFree86 4.3.0.1) with the following drivers and modes
  frambuffer 1024x768x16
  vesa        800x600x16
  vesa        800x600x24
Also in none of these cases did I see random blanking of the screen.

Even when not using
  Option      "PanelSize" "1600x1200"
at least the DVI mode 1400x1050x24 exhibits the blanking problem with
the radeon driver on my Fedora Core 3 machine.

It seems that 
  Option      "PanelSize" "1600x1200"
makes the blanking problem significantly worse, because with this option
the blanking occurs for also for the DVI modes 1280x1024, 1024x768, 800x600
and 640x480.

To debug my DVI problems I have my FlexScan L885 monitor connected to
both the DVI- and the VGA-cable of my Radeon 9200SE card. This has the
side effect that the radeon driver activates a MergedFB mode with the
default value of Clone. The statement on the radeon man page that
connecting two monitors will by default enable the MergedFB mode would
deserve to be written with bold text in my opinion. I tried using
  Option "MergedFB" "off"
to see if this could solve at least some problems for me.
but this did not solve the blanking problem in DVI mode 1600x1200.
Also if I don't use
  Option "PanelSize" "1600x1200"
then the DVI mode 1400x1050 still blanks randomly.

However now it seems that with 
  Option "MergedFB" "off"
that the Xv driver gives output both on the DVI and the VGA cables, so
at least this problem is now solved.

I also tried the combination
        Option      "MergedFB" "off"
        Option      "MonitorLayout" "TMDS, NONE"
        Option      "PanelSize" "1600x1200"
but I still get the flickering problem.



TO SUMMARIZE MY REMAINING PROBLEMS:

To get any DVI output with the radeon driver I need to use
          Option      "MonitorLayout" "TMDS, CRT"
but already this option makes for random blanking at least in the
1400x1050 DVI mode. To enable the DVI mode 1600x1200 I need to use
        Option      "PanelSize" "1600x1200"
but this makes the random blanking occur even more often. 

What does the usage of these options do that the radeon driver does not
do by default?
Comment 15 Alex Deucher 2005-04-28 07:15:27 UTC
(In reply to comment #14)
> 
> TO SUMMARIZE MY REMAINING PROBLEMS:
> 
> To get any DVI output with the radeon driver I need to use
>           Option      "MonitorLayout" "TMDS, CRT"
> but already this option makes for random blanking at least in the
> 1400x1050 DVI mode. To enable the DVI mode 1600x1200 I need to use
>         Option      "PanelSize" "1600x1200"
> but this makes the random blanking occur even more often. 
> 
> What does the usage of these options do that the radeon driver does not
> do by default?
> 

The radeon driver attempts to detect the way your card is wired up and what
monitors are connected by default, sometimes however certain oems do weird
things with the bios or the the card layout which makes the auto-detection stuff
problematic.  these options allow you to override what's detected.  all radeons
except the original r100 have 2 display controllers (crtcs).
The "monitorlayout" option forces the monitor type connected to each crtc. so
setting "TMDS, CRT" forces both outputs on and sets crtc1's monitor type to TMDS
(which is the signaling used for DVI) and sets crtc2's monitor type to CRT
(regular old 15-pin vga style connection).  "Panelsize" is really for forcing
the laptop LCD panel to a spcific size if the driver cannot detect it by
default.  I don't recall off hand how it interacts with the TMDS path.  Mergedfb
enables or disables the use of both crtcs on a shared framebuffer.  by default
this is enabled in Clone mode (both crtcs point at the same part of the
framebuffer).  Clone mode is enabled by default so that each output can have
separate timings and you don't accidently cook one monitor if you try and run a
mode supported by one head and not the other.  However, the radeon only has one
video overlay, and it can only be sourced to one crtc or the other at one time,
so you can only use Xv on one head at a time.  there is an xv attribute you can
set to switch the overlay head in clone mode.  dualhead modes will automatically
switch. with mergedfb off, crtc1 drives both displays so the the overlay shows
on both.
Comment 16 Tomas Lindén 2005-04-29 05:14:39 UTC
I installed the demo version of Accelerated-X on my Fedora Core 3 machine to see 
if the blanking problem would show up with this server also.
It turned out that with Accelerated-X the DVI modes blanks even more ofthen than 
if I only use the the X.org server with the radeon driver.
The flickering occurs at least for 24 bit 1600x1200, 1280x1024 and 1024x768 
modes. I tried also using options MTRR off, AGP1X and RenderExtensions NO, but 
none of these options had any effect on the random blanking. I installed xsvc-3.
0-54c.i386.rpm and Summit_DX-Platinum-2.2-20.i386.rpm and used the driver for 
the Radeon 9200 chipset.
Comment 17 Tomas Lindén 2005-04-29 05:16:01 UTC
Created attachment 2591 [details]
My configuration file for Accelerated-X
Comment 18 Alex Deucher 2005-04-29 07:19:17 UTC
(In reply to comment #16)
> I installed the demo version of Accelerated-X on my Fedora Core 3 machine to see 
> if the blanking problem would show up with this server also.
> It turned out that with Accelerated-X the DVI modes blanks even more ofthen than 
> if I only use the the X.org server with the radeon driver.
> The flickering occurs at least for 24 bit 1600x1200, 1280x1024 and 1024x768 
> modes. I tried also using options MTRR off, AGP1X and RenderExtensions NO, but 
> none of these options had any effect on the random blanking. I installed xsvc-3.
> 0-54c.i386.rpm and Summit_DX-Platinum-2.2-20.i386.rpm and used the driver for 
> the Radeon 9200 chipset.
> 

Sounds like it may be bad hardware.
Comment 19 John Stebbins 2005-05-22 16:36:58 UTC
Adding my $0.02.  The following is a bug report I had posted on redhats
bugzilla.  So references bug numbers are redhat bugzilla bug numbers.

Note that I found a work-around that works for me.  So I thought others 
might have an interest in this report.
========================================================================== 
I just upgraded to xorg-x11-6.8.2-1.FC3.13.x86_64 this morning and am
now experiencing exactly the same behavior.  I have a very similar
setup.

Shuttle SN85G4-V2 motherboard
Ati radeon 9200se
Samsung SyncMaster 213T LCD
Monitor connected to DVI output

What's a little odd is that previously I was running
xorg-x11-6.8.1-12.FC3.21.x86_64 and this problem was NOT
occuring.  Yet this is the version that this bug was
originally posted for.

I see the screen blink out then back, even when there is no
appearent activity (no mouse movement etc.).

Note that I have also been experiencing the problem noted in
bug 123511 (screen blinks while doing GL). So after reading the
note on this bug above, I disabled DRI (commented out loading
dri module in xorg.conf).

After disabling DRI, both problems have improved.  I have not
yet had an instance of the screen blanking out.

Comment 20 John Stebbins 2005-05-22 16:41:10 UTC
Oops, forgot to mention that the original redhat bugzilla number
for this report is 142932.

Link:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=142932
Comment 21 Tomas Lindén 2005-05-24 05:51:00 UTC
I disabled DRI in my xorg.conf. It seemed to improve the flickering problem, 
but unfortunately it is not a complete workaround for me.
I still have the flickering problem, but
it took half an hour for the first blanking to occur. With DRI enabled it 
usually occurs within a few minutes or so. It seems that after an hour or so the 
blanking occurs more and more frequently and returns to the rate seen with DRI 
enabled. This is of the order of 3-4 blankings / minute so it still makes the 
DVI-connection unusable in practice after one hour or so.

Using xine to watch a movie sequence does not seem to increase the rate of 
blanking events with DRI turned off as it does with DRI enabled.
Comment 22 FreeDesktop Bugzilla Database Corruption Fix User 2005-06-16 22:24:56 UTC
I would like to add that I have seen this random screen blanking problem as
well, and I think the details in my situation may be informative.  First, it has
been a long-standing  infrequent problem on a PCI Radeon 7000/VE with a DVI
1280x1024 DFP, but I don't have any further information about that.

More interestingly, I recently started having this problem on my AGP Radeon
7000/VE with DVI 1600x1200 DFP when I simultaneously upgraded from Fedora Core 3
to Fedora Core 4 and from an Athlon XP to an Athlon 64.  The symptoms were that
the DFP would only be autodetected as 1280x1024, and that with PanelSize
1600x1200 the image would be frequently blanked, unusably so.

What I wanted to report is that I was able to fix the panel size detection
problem with my DFP, and that this also fixed the blanking problem.  To get my
panel size correctly detected, I had to modify RADEONUpdatePanelSize() in
xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c.  That function loops
over the various DDC modes of the monitor, but when considering the detailed
timings table, it seems to only look at the first mode bigger than the current
mode, due to the line "if (info->DotClock) continue;"  Since the native
resolution of my monitor is listed second in its DDC detailed timings, this line
was preventing it from ever being detected.  Removing the line allowed
radeon_driver to correctly detect the size of my panel, and as a side effect
fixed my blanking problem.

If this information is useful, I'm happy to provide more details, just let me
know what you would like to know. 
Comment 23 Tomas Lindén 2005-06-17 08:02:17 UTC
Your modification sounds interesting. Could you please post a diff between the 
original code and your modifications?

Comment 24 FreeDesktop Bugzilla Database Corruption Fix User 2005-06-20 09:50:24 UTC
Created attachment 2929 [details] [review]
Implement cairo_ps_surface_set_dpi()

Without this patch, radeon_driver.c stops scanning the detailed DDC modes as
soon as it finds one mode "better" than the current mode.  As my 1600x1200 DFP
lists a 1280x1024 mode before its native resolution, without this patch its
panel size is incorrectly determined to be 1280x1024.  With this patch, the
panel is correctly determined to be 1600x1200.

As a side effect, using this patch for 1600x1200, rather than forcing 1600x1200
via the PanelSize option, resolves for me the random blanking problem at
1600x1200 resolution.  Presumably this is because the Modeline from the DDC
differ from that X automatically generates??
Comment 25 Ulrich Gemkow 2005-09-08 11:11:48 UTC
> 
> Sounds like it may be bad hardware.
> 

Please let me add some more observations:

In short: In the past weeks we tried to switch to DVI (after buying some
LC-Displays :-) and found the same problem with different cards (older ones and
new ones) in different peculiarity. Using some of the cards with windows did
not show the problem.

We bought (in serveral steps) about 35 radeon cards in different configurations
with different chips: 7000, 9200SE, 9550, 9250, 9550SE from different producers
(ACER, HIS, Sapphire, ...). The different cards result simply from what could
be delivered by the suppliers. All cards are without fan (the reason we want to
use them).

We  use different displays (EIZO, NEC) with different resolution (mostly
1600x1200 but also 1280x1024). We currently use Xorg 6.8.2 bute the problem
is the same with XFree86

Our oberservations are:

- Many (but not all) cards show the "screen-off" problem more or less often,
  some cards never show the problem, some ones per day and some are not usable
  because they flicker with an interval of some seconds,

- The problem is not dependant on the used radeon-chip, all chips show the
  problem. There is no coherence between how often the problem happens and
  the chip used,

- We tested some (but not all) cards with the windows drivers. In the time we
  tested (which is shorter than the time we used the cards with Xorg) the
  problem did not (never) occur.

- The problem often gets worse with the time the card is used. But some (also
  rather old) cards never show the problem,

- We found some changes in how often the flicker occurs when changing the
  AGP access time in the BIOS-Mainboard (where this is possible)

- The cards have no problem with analog output (besides the bad quality which
  most of the cards show), only DVI is affected.

So my preliminary conclusions from these observations are:

- The problem seems to be caused by a hardware design flaw which is immanent in
  all 2D-radeon-chips. Something in the chips seems to work at its limit
  which shifts with usage time.

- BUT the driver seems to have a chance to handle the problem - or the cards
  would not work with windows.

Our hardware guru says that there is a good possibility that the problem is
also present when using analog output but is not user-visible then because the
analog monitor simply would ignore i.e. sync flickers while a digital monitor
would go out-of-sync and show the flicker.

When trying to conclude:

- It seems we have "tested" a significant number of "simple" radeon-chips to
  conclude that these have a problem with DVI which could not simply explained
  by hardware defects - it is a flaw in hardware and/or a inadequate handling
  in software.

- With incrasing number of users using DVI with these silent cards the
  problem will become more visible and more annoying for the community.
  
Is there any chance to find a solution? Can we help to debug/test this? We had
to switch back to VGA for most of our seats which is not really a good
solution.

Thanks for your efforts and listening
Comment 26 Alex Deucher 2005-09-08 11:59:13 UTC
(In reply to comment #23)
> Is there any chance to find a solution? Can we help to debug/test this? We had
> to switch back to VGA for most of our seats which is not really a good
> solution.
> 

Does adjusting the refresh rate down (try 50 or 55 Hz) help?  You might also try
the displaypriority option.  If none of that helps, I'm not sure what else to do
until someone can track down exactly what the problem is or ati can provide
information about it.  Unforunately none of my radeon cards exhibit the problem.
Do they work properly with ati's fglrx binary driver?  If so, you might try
dumping and comparing the registers between xorg and fglrx to see if you can dig
out the differences.

Comment 27 Tomas Lindén 2005-09-09 02:13:59 UTC
> - We found some changes in how often the flicker occurs when changing the
>   AGP access time in the BIOS-Mainboard (where this is possible)

Some of the Radeon chips are also used on PCI-cards for either very old computer 
s without an AGP bus or for dual graphics cards setups. On one of my home 
computers I use a Sappphire Radeon 9200SE PCI card with a Dell UltraSharp 1703FP 
in DVI mode 1280x1024 without any problems at all. 

Has there been any reports about this flickering problem with PCI-cards?

Would it be useful if I made a registerdump (how?) from my Sapphire Radeon 
9200SE PCI card and compared it with my problematic ASUSTEK Radeon 9200SE AGP 
card?
Comment 28 T. Hood 2005-09-23 06:41:32 UTC
(In reply to comment #15)
> all radeons
> except the original r100 have 2 display controllers (crtcs).

I am confused.  I have a ThinkPad T30 which reportedly has a Radeon 7500 which
reportedly has an R100 chipset.  I am able to use mergedfb (laptop LCD panel,
external VGA monitor).  Does this mean that the T30 actually has two crtcs?
Comment 29 Alex Deucher 2005-09-23 06:49:04 UTC
(In reply to comment #26)
> (In reply to comment #15)
> > all radeons
> > except the original r100 have 2 display controllers (crtcs).
> 
> I am confused.  I have a ThinkPad T30 which reportedly has a Radeon 7500 which
> reportedly has an R100 chipset.  I am able to use mergedfb (laptop LCD panel,
> external VGA monitor).  Does this mean that the T30 actually has two crtcs?


the 7500 is actually an rv200 which is a variant of the r100 core.  the original
radeon 7200 (plain r100) is the only one with 1 crtc.  If your chip didn't have
two crtcs you wouldn't be able to use dualhead.
Comment 30 T. Hood 2005-09-23 08:39:25 UTC
*** Bug 2887 has been marked as a duplicate of this bug. ***
Comment 31 T. Hood 2005-09-23 09:21:13 UTC
*** Bug 2674 has been marked as a duplicate of this bug. ***
Comment 32 T. Hood 2005-09-23 10:01:54 UTC
*** Bug 3275 has been marked as a duplicate of this bug. ***
Comment 33 T. Hood 2005-09-23 10:20:08 UTC
I wouldn't be surprised if this were related to #1129.
Comment 34 Alex Deucher 2005-09-23 11:45:06 UTC
(In reply to comment #31)
> I wouldn't be surprised if this were related to #1129.

For those of you having problems with DVI, try the modelines with reduced
blanking intervals as per this web page (from bug 1129):

http://suif.stanford.edu/~csapuntz/rv280-linux-dvi.html
Comment 35 T. Hood 2005-09-26 02:57:16 UTC
*** Bug 2657 has been marked as a duplicate of this bug. ***
Comment 36 T. Hood 2005-09-26 02:58:38 UTC
*** Bug 1620 has been marked as a duplicate of this bug. ***
Comment 37 Andreas Schultz 2005-09-28 02:03:16 UTC
(In reply to comment #32)
> For those of you having problems with DVI, try the modelines with reduced
> blanking intervals as per this web page (from bug 1129):
> 
> http://suif.stanford.edu/~csapuntz/rv280-linux-dvi.html

Tried it, didn't work. I fact i even switched to ATI's fglrx driver and compared
the timing reported by a) its Modeline in the log and b) the information from
the monitor. The AIT drivers uses the default VESA timing as reported by DDC and
DOES NOT show the flickering problem.

Andreas
Comment 38 Ulrich Gemkow 2005-09-28 05:03:31 UTC
One small "datapoint", no idea whether this helps: 
 
Beginning in line 6090 of radeon_driver.c (current CVS) there is a 
section which looks like a workaround for a similiar problem. The 
workaround reduces interaction with the PLL because the author 
worried about lock problems for PLL-registers. 
 
Unfortunately removing the "if" around this section (so the section 
is executed also on non-mobility-usage) doesnt solve the problem. 
 
Comment 39 Tomas Lindén 2005-09-28 11:34:08 UTC
I run Fedora Core 3 with automatic updates using yum on the computer
which exhibits the DVI-flickering problem. On September 17th yum updated
X.org to version 
  xorg-x11.i386 6.8.2-1.FC3.45
I was curious to see if this particular update would change anything for
me, so I rebooted my machine on Monday September 19th. To my delight the
DVI flickering problem was significantly reduced by this update, but
unfortunately it is not completly eliminated.

There was another X.org update on September 21st, to version
  xorg-x11.i386 6.8.2-1.FC3.45.1
so I rebooted my machine again. From Monday 19th to Friday 23rd of
September I noticed one flickering event during normal usage and two
when I was locking my screen and xscreensaver faded out the display. On
Monday the 26th I noticed two more flickering events.

Previously the DVI signal flickered so much that it was totally unusable,
but now it is doing it less than once / day, so the improvement is great
and the DVI-output is finally usable.

The update 
  xorg-x11.i386 6.8.2-1.FC3.45
which was the first update to significantly improve my DVI problem
contains among another things a fix to a very old bug in X where the
X-server accesses directly the PCI config registers instead of going
trough the Linux kernel in a safe way. Unfortunately this update created
some new problems on many machines, one them being my other computer
with a Radeon 9200SE PCI card where this X update just hangs with a
completely black screen. Reading this bug description suggests to me
that the DVI flickering problem could be due to the problem of the
X-server accessing the PCI config registers directly
  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168750
Could it be that the remining infrequent flickering events that I see
are due to some part of the X server code that still accesses the PCI
config registers in an unsafe way?
Comment 40 Alex Deucher 2005-09-28 11:51:04 UTC
(In reply to comment #37)
<snip>
>   https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168750
> Could it be that the remining infrequent flickering events that I see
> are due to some part of the X server code that still accesses the PCI
> config registers in an unsafe way?
> 

I strongly suspect it's a problem with the mode being sent to the monitor;
between what the port and the monitor support.  The PCI regs shouldn't have
anything to do with this.
Comment 41 Tomas Lindén 2005-09-28 13:18:02 UTC
In reply to comment 38

> I strongly suspect it's a problem with the mode being sent to the monitor;
> between what the port and the monitor support.  The PCI regs shouldn't have
> anything to do with this.

Was there any bugfixes related to this then in the update
  xorg-x11.i386 6.8.2-1.FC3.45 ?
Comment 42 Mike A. Harris 2005-09-28 14:08:00 UTC
(In reply to comment #37)
> I run Fedora Core 3 with automatic updates using yum on the computer
> which exhibits the DVI-flickering problem. On September 17th yum updated
> X.org to version 
>   xorg-x11.i386 6.8.2-1.FC3.45
> I was curious to see if this particular update would change anything for
> me, so I rebooted my machine on Monday September 19th. To my delight the
> DVI flickering problem was significantly reduced by this update, but
> unfortunately it is not completly eliminated.
> 
> There was another X.org update on September 21st, to version
>   xorg-x11.i386 6.8.2-1.FC3.45.1
> so I rebooted my machine again. From Monday 19th to Friday 23rd of
> September I noticed one flickering event during normal usage and two
> when I was locking my screen and xscreensaver faded out the display. On
> Monday the 26th I noticed two more flickering events.
> 
> Previously the DVI signal flickered so much that it was totally unusable,
> but now it is doing it less than once / day, so the improvement is great
> and the DVI-output is finally usable.
> 
> The update 
>   xorg-x11.i386 6.8.2-1.FC3.45
> which was the first update to significantly improve my DVI problem
> contains among another things a fix to a very old bug in X where the
> X-server accesses directly the PCI config registers instead of going
> trough the Linux kernel in a safe way. Unfortunately this update created
> some new problems on many machines, one them being my other computer
> with a Radeon 9200SE PCI card where this X update just hangs with a
> completely black screen. Reading this bug description suggests to me
> that the DVI flickering problem could be due to the problem of the
> X-server accessing the PCI config registers directly
>   https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168750

The bug you reference is concerning the PCI config access patch, but
is not a bug about problems on Radeon 9200SE PCI.

It is important IMHO to consider the problem you are having as a separate
unrelated problem, and diagnose it to the real problem rather than make
premature conclusions.

The problem may or may not turn out to be triggered by the pci-config
changes.  One thing to try, is to try the latest rpm rebuilt with the
pci-config patch disabled, and if the problem goes away, file a new
bug report in Red Hat bugzilla completely detailing the problem, the
testing you've done, and attaching your X server log and config file.


> Could it be that the remining infrequent flickering events that I see
> are due to some part of the X server code that still accesses the PCI
> config registers in an unsafe way?

The pci-config registers are accessed via the kernel now, which is the
_only_ safe way.  The regressions this has caused in the X server are
not due to the new pci-config changes being wrong or unsafe.  The
regressions are actually bugs that have always been in the X server,
but the codepaths were never hit before.

What we have discovered, is that video BIOSes access registers
outside of PCI config space, but end up using the X server's
pciReadByte which was doing a long read and masking off the wanted
byte.  That had side effect of reading multiple bytes on the hardware,
and if those registers have side effects that trigger the hardware
in some way when read, bad random things can happen.

Our newer patch fixes the X server PCI code so that in these cases
byte reads are used instead of masked long reads.

It is entirely possible that there are other bugs in the X server
code that the pci-config changes have unearthed which were never
hit before, as the code paths were never exercized, or were never
used the way they are now.

So, just to clarify things, the pci-config patches are not "unsafe",
but their presence definitely has uncovered dormant bugs elsewhere
in the X server that were never hit before, and there may yet be
other dormant bugs to find.

May or may not be causing this issue.  More diagnosis is needed to
conclude anything.

xorg-x11-6.8.2-37.FC4.49.2 is the current FC4 release
xorg-x11-6.8.2-1.FC3.45.2 is the current FC3 release


Try adding to the ServerFlags section of your xorg.conf

    Option "PCIOsConfig"

Reboot the machine to force a full hardware reset.  Test X, and see if
there is any change, and make note of it.  Then replace the above option
with each of the following one at a time and do the same:

    Option "PciProbe1"

Then:
    Option "PciProbe2"

Be sure to reboot each time.  After doing these 3 tests, update the bug
report to indicate if anything at all changed in each test.  Also, attach
the X server log file to the report as a file attachment (not cut and paste),
for each of the 3 above tests.

This will help determine if the pci-config patch has unearthed other dormant
bugs in the X server code.

Thanks in advance.
Comment 43 Ulrich Gemkow 2005-10-01 03:47:12 UTC
(In reply to comment #38)
> I strongly suspect it's a problem with the mode being sent to the monitor;
> between what the port and the monitor support.  The PCI regs shouldn't have
> anything to do with this.
> 

I can confirm that using the clock reduction method described in
http://suif.stanford.edu/~csapuntz/rv280-linux-dvi.html from Bug 1129
solves the problem for all cards we tested - even for a card which was
completely unusable before.

It remains the problem that the current radeon server does not accept
Modelines when using digital displays so reducing the clock requires
patching the driver source.

I will file a separate bug report on this.

Thanks for all hints.
Comment 44 Johannes Erdfelt 2005-10-14 21:42:05 UTC
I had the same problem with a Sapphire 9250 and a Dell 2000FP with 1600x1200
mode not displaying anything (with the 2000FP going into power save mode).

The "fix" described at http://suif.stanford.edu/~csapuntz/rv280-linux-dvi.html
mostly fixed the problem. Most of the time the display was fine, but sometimes I
would get the weird couple of second blanking.

I ended up creating a new modeline with even an further reduced blanking
interval, bringing the clock down to 125.97MHz. This seems to be working even
better, but I have to admit, I don't know if it's a good idea to drop it even
further. I'm not familiar enough with DVI and LCD monitor technology to know
what a safe minimum is.

I don't know what this means for a better general solution, but hopefully it'll
help someone.
Comment 45 Ulrich Gemkow 2005-10-15 02:14:56 UTC
(In reply to comment #42)  
> I ended up creating a new modeline with even an further reduced blanking  
> interval, bringing the clock down to 125.97MHz. This seems to be working even  
> better, but I have to admit, I don't know if it's a good idea to drop it even  
> further. I'm not familiar enough with DVI and LCD monitor technology to know  
> what a safe minimum is.    
  
Besides further reducing the blanking time, on some of our displays (mostly  
NEC, IBM) we also reduced the refresh rate to 50Hz without problems. Other  
displays (EIZO) have trouble with such a low rate (some accepted 57Hz).  
This further reduced the clock rate.  
  
After testing this for two weeks now, we found that reducing the clock rate  
reduced the problem but did not completely solve it - the effect still   
shows up with a very low rate (on some displays only one flicker per day). 
  
So the "correct" solution is in my opinion still missing or there  
is a serious design flaw in _all_ radeon chip (we currently use about 
40 cards, a dozen different models from different vendors with 6 different 
radeon-chip-typs).  
  
What I still cannot understand is that about one third of our cards  
_never_ had any problems, they did not flicker even one time (as far as  
we observed it) - we can even increase the clock to any (reasonable)  
value and they do not flicker. These "good" cards use different chips- 
models and come from different vendors. 
  
Is there any chance that ATI comments on this or gives some help?  
  
Comment 46 Benjamin Herrenschmidt 2005-10-24 22:27:24 UTC
Ok, there seem to be different problems here... let's see if we can sort it out.

- First of all, can you build the current CVS HEAD or at least RC1 and test from
that ? That will make things easier and make sure you have all the recent fixes.

- Your server log file that you attached. Was it taken with only that flat panel
connected (DVI input) or the analog input connected to a monitor as well ? The
DDC information seem to show an analog connector, so either you have a monitor
that lies (it happens quite often) or something is wrong in the driver. Also,
please also send the log without the PanelSize option.

- What connectors does your card physically have ? A DVI and a VGA ? Two DVIs ?

- At the beginning of radeon_driver.c, there is a table called
default_tmds_plls. It contains that line:

    {{13000, 0x400f4}, {15000, 0x400f7}, {0xffffffff, 0x400f7/*0x40111*/}, {0,
0}},	/*CHIP_FAMILY_RV280*/

Can you try changing it to:

    {{13000, 0x400f4}, {15000, 0x400f7}, {0xffffffff, 0x40111}, {0, 0}},
/*CHIP_FAMILY_RV280*/

And if it doesn't make a difference, to:

    {{13000, 0xb00f4}, {15000, 0xb00f7}, {0xffffffff, 0xb0111}, {0, 0}},
/*CHIP_FAMILY_RV280*/

Tell me if it fixes your panel randomly "blanking" and that sort of things.

 - Regardless of the above setup (or rather, going back to the initial values),
edit radeon_bios.c, and look near the end of the file, in function
RADEONGetTMDSInfoFromBIOS(), there is this blob:

	    /* revision 4 has some problem as it appears in RV280, 
	       comment it off for now, use default instead */ 
	    /*    

This is then followed by a bunch of code that is commented out. Can you remove
the commenting-out (that is actually -enable- this code) and tell me if it makes
any difference ? In fact, it would be nice if you could add a printf to this
function (Use X's ErrorF() which works just like printf) that tells what value
you get for RADEON_BIOS8(tmp) (3, 4, something else ?)

Thanks,
Ben.
Comment 47 Ulrich Gemkow 2005-12-02 08:32:18 UTC
Hello Ben, 
 
(In reply to comment #44) 
> Ok, there seem to be different problems here... let's see if we can sort it 
out. 
>  
 
I am not sure, to which of the different reporters your comments and 
suggestions were directed  - I did not upload a server log, our displays 
are connected through DVI for sure. So I thoughtyour questions were 
directed to another poster. 
 
If this is wrong - I would be happy to test any suggestion which may 
help to isolate this problem.  
 
At least for us reducing the blanking time by patching the driver 
solves this problem (random blanking) mostly. I added bug 4656 to 
open a way for other users to easily follow the same way without 
patching the driver. 
 
But please correct me if I understand something wrong. 
 
Comment 48 Benjamin Herrenschmidt 2005-12-02 09:17:21 UTC
My comment applies to everybody here. I think those digital output instabilities
(flicker) are related to incorrect TMDS_PLL_* values, thus please try the
various things I suggested and let us know.

Comment 49 Andreas Herrmann 2006-01-07 09:39:55 UTC
Stumbled over this bugzilla when searching for a fix for "random screen
blanking" using a RV280 [Radeon 9200 PRO] with an Eizo FlexScan L885 with DVI.

I am running xorg-x11-6.8.2-r6 on Gentoo with the radeon driver.

Regarding comment 44:
I have just tried out 5 new compiled radeon drivers.
I changed the values in default_tmds_pll for CHIP_FAMILY_RV280 and
combined this with the proposed activation of commented out code
in drivers_bios.c (Thus ending up with 5 new versions)

All tests failed, i.e. blanking of the screen was equal to the unchanged
xorg-x11-6.8.2-r6 radeon driver.

BTW, the blanking occurs randomly "from time to time" - although I am
still able to work with the system but "it nerves".
And it might sound odd, but screen blanking occurs also with high probability
using firefox and walking through the bookmarks menu.

Next I'll try the patch/fix addressed in comments 41 and 42.
Comment 50 Andreas Herrmann 2006-01-07 10:33:48 UTC
Patched radeon_driver.c and changed mode line as described on
Constantine Sapuntzakis' web side.

Could not provoke any screen blanking by walking my firefox bookmarks
menu -- which was a quite reliable test so far. Furthermore up to
now no random screen blanking occurred with the patched radeon
version. Hence I assume that the blanking problem is solved for me.

AFAIK, Constantine Sapuntzakis' patch allows that radeon_drv.o will
accept modlines for DVI output. But it comments out significant code
in the radeon driver.
The question is:
Is there already a similar fix (enabling modelines for DVI) officially
available for xorg-x11? If yes, in which version will this fix
be integrated?

I ask because I don't feel like patching the radeon driver everytime
I update the x11-xorg version on my Gentoo system.

BTW, let me know if you need assistence (testing) in solving this
problem without the "modeline-patch". I'll see what I can do.
Comment 51 jtd 2006-01-26 11:04:23 UTC
I have very bad DVI (1280x1024@75) flickering problems with a 
Radeon7000/VE PCI, too. Using xorg 6.8, those could be almost completely 
removed by disabling the dri module. Since  6.9, nothing (disabling dri, 
Display Priority, Refresh rate, ...) helped. 

I almost have to use 75 Hz refresh rate because otherwise, my second monitor 
(CRT) gets a distorted signal, fonts are "wobbly". Seems to be some kind 
of interference problem. But at 60Hz, the DVI problems persist...

Flickering is worst using Firefox (pages with SVG make my monitor blank 
out completely for several seconds), OpenOffice and Nautilus. Just using 
xfce / terminals / mplayer / xscreensaver does very, very rarely lead to 
blanking.

Opening http://code.google.com/webstats/2005-12/pages.html in Firefox 1.5 causes
the image to shift left and right, most likely resulting in a blank display. The
same applies to clicking on items in the tree view of nautilus, but it's not as
bad as the page using SVG...


- X Window System Version 6.9.0 (Debian 6.9.0.dfsg.1-3 20060110012652 David
Nusinow <dnusinow@debian.org>)
- DualHead configuration with xinerama disabled
Comment 52 Brian Beardall 2006-04-14 12:31:30 UTC
I am having blanking on my Radeon 9250 cards. I have tested four Radeon cards
against this bug, and I have only been able to cause the blanking when playing a
opengl game. I am using the CVS Head for the xserver, and CVS for the radeon
driver, as well as for the DRI module also. These are the cards that I tested as
well as the result:

Radeon 7000VE : PASS, No screen blanking.
Radeon 9000 : PASS, No screen blanking.
Radeon 9250 128bit RAM, 256 MEG : FAIL, Screen was blanking when playing
trigger, and other games. The eventual outcome if I kept playing while the
screen was blanking was system lockup. If I quit the game the screen for the
root window was clean.
Radeon 9250 64bit RAM, 128 MEG : FAIL, Screen was blanking when playing trigger,
and other games. The eventual outcome was system lockup. If I quit the game
before lockup had occured the root X window had artifacts that were randomly
showing up on the root window.

After reading through this bug report there seems to be a little confusion as to
what this bug is. To me this bug is having the screen displaying something to
having nothing displayed for a second or forever. Now having read the bug report
it seems that all users that have the 9200 are experiencing the same bug. Those
that are using a video card other than the 9200/9250 are experiencing another
bug/bugs. To me there seems to be some sort of errata with the RV280 because of
the numerous reports in this report.

I have used the two 9250 Cards for months using the VGA output. I experienced no
screen blanking with the VGA out. All of the cads pass using the VGA output.
Comment 53 Brian Beardall 2006-04-14 12:34:38 UTC
Created attachment 5305 [details]
Xorg.0.log.screenblank

This is the Xorg log while using the Radeon 9250 128 bit RAM and 256 Meg. This
log is after the the screen had been blanking in the game trigger.
Comment 54 Brian Beardall 2006-04-14 14:30:46 UTC
I uncommented the code that retrieves the TMDS information from the video bios
in radeon_bios.c, and that fixed the screen blanking for me. I will be adding
the comments in a couple of days to retrieve the RADEON_BIOS8 values. I have
only tested on one of the Radeon 9250's, but I will be testing the other one
with the same modification and sprinkling ErrorF()'s to read values. Thanks
Benjamin for the suggestion.
Comment 55 Brian Beardall 2006-04-15 13:06:32 UTC
I was looking at the code, and I don't know why I would want to get the value of
RADEON_BIOS8(tmp), and write it to X log file with ErrorF's. The section of code
that was commented out required that that variable be 4, and so since that does
fix the flickering/blanking problem I don't know why I want to put in printf's.
I would like some more insight to this.
Comment 56 Brian Beardall 2006-04-16 06:00:12 UTC
uncommenting the else if (RADEON_BIOS8(tmp) == 4) { } in radeon_bios.c fixed the
screen flickering/blanking for both of my Radeon 9250 cards. Do you need more
information?
Comment 57 Brian Beardall 2006-05-03 14:03:48 UTC
I changed the default_tmds_plls for the RV280 to this: 
{{13000, 0x400f4}, {15000, 0x400f7}, {0xffffffff, 0x40111}, {0, 0}},
/*CHIP_FAMILY_RV280*/
This fixed the random flickering for me also. I am running the driver from CVS
head. It would be nice to see something submitted into CVS to fix this bug.
Comment 58 Benjamin Herrenschmidt 2006-05-03 14:10:40 UTC
I think we need to uncomment the BIOS thing, I'll look into this. Regarding the
default value in the table, it's unclear ... it may break currently working setups. 
Comment 59 Alex Deucher 2006-05-10 09:06:17 UTC
*** Bug 2935 has been marked as a duplicate of this bug. ***
Comment 60 Adam Jackson 2006-05-16 23:30:52 UTC
This isn't critical enough to block the 7.1 release, moving out to 7.2.

benh, I'd appreciate a status update when you get a moment.
Comment 61 Alex Deucher 2006-05-17 00:33:36 UTC
(In reply to comment #58)
> This isn't critical enough to block the 7.1 release, moving out to 7.2.
> 
> benh, I'd appreciate a status update when you get a moment.

the RV280 TMDS PLL fixes are already be in cvs.
Comment 62 Wayne Whitney 2006-07-08 13:21:18 UTC
Hello, 

I'm also having the radeon 1600x1200 DVI flickering problem, but the details are
a bit different from most of the other respondents.  I'm using an old "Radeon
RV100 QY [Radeon 7000/VE] rev 0" PCI card in an x86_64 machine.  FC5
development's xorg-x11-drv-ati-6.6.1-4.x86_64 reports that the DFP table
revision is 3, so the issue with table revision 4 does not apply to this card. 
The problem I'm seeing is a regression: it was absent under FC4 (x.org 6.8.2)
but started when I updated to FC5.  Option DisplayPriority has no effect, while
using a reduced blanking interval modeline (possible without patching the radeon
driver using Option IgnoreEDID) significantly reduces the problem without
eliminating it completely.

Any suggestions on how to proceed with troubleshooting this regression?  

Thanks, Wayne
Comment 63 Simon Morgan 2006-07-17 05:26:55 UTC
*** Bug 7478 has been marked as a duplicate of this bug. ***
Comment 64 Tomas Lindén 2006-09-29 05:35:40 UTC
I had once more a look on my DVI problem. Presently I'm running Fedora Core
5 with X.org 7.0 and the latest Fedora updates.

To debug my DVI-problems I have both the DVI- and the VGA-input
connected to the my Eizo FlexScan L885 panel.

To get DVI-output from my Asus Radeon 9200SE card I have to use the
following option in my xorg.conf file
  Option      "MonitorLayout" "TMDS"

This will only give DVI-output on resolutions lower that 1600x1200.
The 1600x1200 resolution shows only on the VGA-connector with a modeline of
Modeline "1600x1200@60Hz@75kHz"   162.00   1600 1664 1856 2160   1200 1201 1204
1250 +hsync +vsync
This seems to be the modeline reported by my Eizo L885 panel and should be 
within the specifications of the panel.

To have the DVI mode 1600x1200 visible on my Eizo L885 panel I have to
use the following option in my xorg.conf file
  Option      "PanelSize" "1600x1200"
This gives me the same modeline
1600x1200@60@75kHz"   162.00   1600 1664 1856 2160   1200 1201 1204 1250
but now the image will randomly blank over the DVI-connector.

The radeon man page says about the PanelSize
  "If you have a panel with timings different from that of a standard
  VESA mode, you have to provide this information through the Modeline."
Inspired by the comments #31 and #32 and the experience in 
comments #41, #48 and #60 I also tried a Modeline with reduced blanking
timing, but without patching radeon_driver.c.

My first try with the line
"1600x1200@60.01@75.67"   154.98   1600 1632 2016 2048   1200 1224 1236 1261
was an improvement, but the flickering was still there, so I went to

Modeline "1600x1200@60" 132.0 1600 1648 1712 1820 1200 1202 1205 1207
seems to have solved the random blanking problem for me, because it
has not flickered even once during three hours of testing.
I will run like this for some days to really see if the blanking
problem has been solved by this.

I still would like to know why my ASUS Radeon 9200SE card cannot output 
a 1600x1200 DVI-signal without these two options? 
    Option      "MonitorLayout" "TMDS"
    Option      "PanelSize" "1600x1200"

Using 
  Option      "PanelSize" "1600x1200"
has two side effects.

If one wants to temporarily switch to a lower screen resolution using
xrandr, then some of the lower resolutions are shifted towards one edge
of the display, as in the screenshots I have posted in the beginning of
this bug report and some resoultions are garbled with stripes at the
edges in addition to that.

The other side effect of "PanelSize" "1600x1200" is that the graphics
card constantly outputs a 1600x1200 mode to the panel and the lower
resolutions asked for with xrandr are scaled internally up to the output
resolution of 1600x1200 by the graphics card. I guess this is the
typical behaviour that one has on a laptop screen. Without the option
"PanelSize" "1600x1200", the lower resolutions asked for with xrandr
really switch output mode of the graphics card, so that the scaling to
the panels native 1600x1200 resolution is done by the panel itself.



Summary:
  A modeline with reduced blanking can help some flickering problems,
  but the problem can remain in some cases, comments #42 and #43.
  It seems that my blanking problem can also be solved by this.

  In comment #35 it is reported that reduced blanking did not help, so 
  this could be another problem?

  In comment #23 it has been noted that the AGP access time can affect
  the blanking problem if it can be changed on the MB.

  Disabling DRI in comment #19 and #49 has improved things with older
  X.org releases, but not anymore with recent X.org releases.

  Changes in radeon_driver.c and radeon_bios.c suggested in comment #44
  did not solve my problem, nor the problem in comment #47,
  but in comments #54 and #55 it is reported that this solved the problem.

  Is it true also for other users of Radeon cards that the options
    Option      "MonitorLayout" "TMDS"
    Option      "PanelSize" "1600x1200"
  are needed to enable DVI-output of 1600x1200?
Comment 65 moof 2006-11-24 01:46:18 UTC
To add fuel to the fire: I've seen this problem on both NetBSD and Ubuntu with
x.org, whereas this does not occur with XFree 4.x.

What seems to happen is that if a large amount of data - particularly towards
the top of the screen - gets redrawn, the frequency of the signal (as shown by
my LCDs' status HUD) goes down by a few KHz and then goes back up. For whatever
reason, the frequency seems to be a bit low - e.g. tell it to use 75khz, and
when DDC is enabled it only uses 72. (Without DDC it's around 73.)

As with others, disabling DRI and some accel options improves things.
Comment 66 Roland Scheidegger 2006-12-08 16:06:52 UTC
Created attachment 8023 [details] [review]
may not fix everyone's problems but works for me

not sure if this actually helps with this bug, I've some feeling it might only
fix a more recent regression. However, without it I can't get tmds resolutions
with pixel clocks between roughly 90Mhz and exactly 155Mhz (where another set
of tmds parameter values gets used) at all. The reason being that some tmds
values (in particular TMDS_TRANSMITTER_CNTL) which the driver only is supposed
to change some bits end up unitialized (0), which seems to work only with some
luck... I did not see any random blanking though, it either worked or the
monitor didn't sync at all.
Note there might be a more elegant solution to this, for exactly this problem a
simple INREG certainly would do, but I didn't check if other functions called
in ModeInit could suffer from similar issues.
Comment 67 Tom Horsley 2006-12-08 16:52:39 UTC
I should probably add my own "fix" to this problem. For me, I was able to get
my display to be absolutely rock solid if I forced it to run with a reduced
blanking modeline that was slightly less than 60HZ. This was not easy, but
comparing the X server source code to the errors I got along the way eventually
let me pick a path through the code that did what I wanted. Full story
here: http://home.att.net/~Tom.Horsley/easy-linux.html

Now that the VESA spreadsheet algorithm is included in the server source
code, it would sure be nice if there was a new way to specify modeline info
added where all I had to tell it was width, height, refresh rate, and optional
flags (like reduced blanking).
Comment 68 Nuri Jawad 2007-01-12 17:39:51 UTC
Using a Samsung 213T with a Radeon 9200SE connected via DVI at 1600x1200x60
here. System is a P4 Northwood on i875, HT disabled, Debian unstable, stock
kernel 2.6.18.2.
I had occasional blanking and interference/noise especially when moving the
mouse pointer over an image in GIMP, but also during any operations in
OpenOffice that caused large redraws.
Tonight I tested with a Radeon 7000 PCI, same problem except the interference
was even more pronounced. Changing modelines, reduced blanking etc. didn't help
at all. 

What fixed it right while X was running was loading the Radeon DRM kernel
module. It seems to do some kind of initialization that's otherwise missing. It
can be unloaded again immediately, the effect will stay. Display is rock stable now.
Comment 69 Ulrich Gemkow 2007-01-14 01:25:56 UTC
We had the blanking problem with about 40 cards when using Fedora
Core 3 (which is xorg 6.8.2 based). We solved the issue with the
reduced blanking (rb) method described above. We used rb modelines
after patching the driver to accept them.

Now we switched to Fedora Core 6, which uses xf86-video-ati rel
6.6.3. The blanking reappeared and even with the rb method (after
patching the driver) the problem remained.

For a few of our workstation we were able to reduce the problem by
lowering the refresh rate below 60 Hz, but not all displays accept
this.

We also tried the latest git of xf86-video-ati with no success.

So the current driver behaves worse in this respect than older
releases. This is a regression against the 6.8.3 release.

Is there any help or can anyone describe what could possibly lead to
this worse behaviour?
Comment 70 Nuri Jawad 2007-01-15 13:44:42 UTC
(In reply to comment #67)
> Is there any help or can anyone describe what could possibly lead to
> this worse behaviour?

Did you try to use the DRM module? What I forgot to write; I had no problems at
all with older X versions, this appeared only a few months ago after upgrading
to the latest Xorg from Debian Unstable. I had never needed reduced blanking, on
the contrary I used a modeline with 170 MHz pixel clock at 1600x1200 for years
with this screen and card.
I'm using OpenOffice.org all day right currently and I haven't had a single
issue since "modprobe radeon".
Comment 71 Ulrich Gemkow 2007-01-17 13:40:53 UTC
(In reply to comment #68)
> (In reply to comment #67)
> Did you try to use the DRM module? 

Thanks for you reply. No, I did not tried yet - I have found another solution
(see next comment). I will check the DRM module next. Thanks again...
Comment 72 Ulrich Gemkow 2007-01-17 13:58:47 UTC
Sorry to reply to myself in response to comment #67 (my last post):

In git-commit 2b0cdd9448a24ea067b0d78f319b99c1041df2e0 of module
xf86-video-ati a change was committed which enabled the retrieving
the tmds-pll-config-values from the BIOS. The same commit also changed
the default tmds-pll-init-values.

When disabling the BIOS-sequence, our blanking problem disappeared
(mostly) and we got the former (better) behaviour back. So it seems,
getting the info from the BIOS is not fully reliable (at least for our
cards). I left the changed default tmds-pll-init-values as defined in
the commit mentioned above.

I am more than willing to help in debugging this problem (we have
a rather big "testbed") but need some hints what the tmds-init-values
mean and how the BIOS sequence is expected to work.

Thanks to the author of comment #44 which gave the important hint.
Comment 73 Brian Beardall 2007-01-17 14:02:10 UTC
It isn't as simple as it sounds. What is needed is the bios, and r250 chip
revision for the graphics card. There may have been a bug in some of the early
revisions.
Comment 74 Ulrich Gemkow 2007-01-17 14:25:10 UTC
(In reply to comment #71)
> It isn't as simple as it sounds. What is needed is the bios, and r250 chip
> revision for the graphics card. There may have been a bug in some of the early
> revisions.

Please be sure, that I do not believe that its simple (there are
72 comments for this bug :-). I can only add our observation and
share our experience.

Most of our cards are RV 280 (not 250) and some of them were
bought a few weeks ago (we buy them because they need no fan), so
probably are not an early revision. I checked they have the
table version 4, so the BIOS sequence is used for them (when
enabled). We have about 45 cards and about 2/3 of them (bought
from different vendors at different times) have problems when
the BIOS sequence is enabled. Whatever that means for other
owners of such cards...
Comment 75 Roland Scheidegger 2007-01-18 05:27:46 UTC
Created attachment 8437 [details] [review]
print out the tmds table

(In reply to comment #70)
> Sorry to reply to myself in response to comment #67 (my last post):
> 
> In git-commit 2b0cdd9448a24ea067b0d78f319b99c1041df2e0 of module
> xf86-video-ati a change was committed which enabled the retrieving
> the tmds-pll-config-values from the BIOS. The same commit also changed
> the default tmds-pll-init-values.
> 
> When disabling the BIOS-sequence, our blanking problem disappeared
> (mostly) and we got the former (better) behaviour back. So it seems,
> getting the info from the BIOS is not fully reliable (at least for our
> cards). I left the changed default tmds-pll-init-values as defined in
> the commit mentioned above.
> 
> I am more than willing to help in debugging this problem (we have
> a rather big "testbed") but need some hints what the tmds-init-values
> mean and how the BIOS sequence is expected to work.
Could you print out the table (the values as retrieved from the bios) using the
attached patch?
Basically, the tmds init values are "magic numbers" used to program the tmds
pll, it seems different values are optimal for different pixel clocks.
Actually, I had a problem with those values too, though the bios-supplied ones
and the default ones were identical for me, but the monitor would switch off in
a very short time if some 3d activity was on. Turns out it works just well if I
used the values intended for a very slightly higher pixel clock (155Mhz and
higher, whereas the actual pixel clock was 154Mhz). In any case, fglrx had the
same problem. I suspect the values need to differ depending on the external
components of a card, if someone wouldn't use reference layout, but that's just
a guess.
Comment 76 Nuri Jawad 2007-01-18 10:57:34 UTC
(In reply to comment #71)

> There may have been a bug in some of the early
> revisions.

I have the same problem with an RV280 and a VE (Radeon 7000 PCI), completely
different cards.

(In reply to comment #73)

> Basically, the tmds init values are "magic numbers" used to program the tmds
> pll, it seems different values are optimal for different pixel clocks.

If this is by any means relevant, how come that I had no problem ever with any
pixel clock values in XFree86 and older Xorg versions? And that I also have no
problems at all now after building and loading the DRM module (which is a ~1
minute task so I wonder why you didn't just do it).
Comment 77 Roland Scheidegger 2007-01-18 14:54:31 UTC
(In reply to comment #74)
> > Basically, the tmds init values are "magic numbers" used to program the tmds
> > pll, it seems different values are optimal for different pixel clocks.
> 
> If this is by any means relevant, how come that I had no problem ever with any
> pixel clock values in XFree86 and older Xorg versions? And that I also have no
> problems at all now after building and loading the DRM module (which is a ~1
> minute task so I wonder why you didn't just do it).
Not all people here might suffer from the same issue actually, just the same
symptoms. One issue seems to be display buffer underflow, which I suspect is
what you got since enabling the dri/drm (and thus using cp accel instead of
mmio) changes timing/latency considerably. It would actually be possible to
detect such underflows so we'd know if that actually was the problem in a
specific case. Obviously, some people do not suffer from that (otherwise
changing the tmds_pll values wouldn't make any difference), and enabling dri
will not make any difference there (unless the driver has some really bad bug
and programs the tmds registers differently depending on that). I can't talk for
the others but I certainly had the drm module loaded (well I mentioned running
3d apps...), though not everyone can do that (not supported with all OS).
Comment 78 Nuri Jawad 2007-01-19 09:58:12 UTC
(In reply to comment #75)
> One issue seems to be display buffer underflow, which I suspect is
> what you got since enabling the dri/drm (and thus using cp accel instead of
> mmio) 

Point taken, should have read up more on this. Comment #40 about the different
code paths explains it.
What's odd though is a problem with buffer underruns showing itself in "analog
looking" interference and the screen position moving by 1 or 2 pixels, instead
of just plain blanking. That would mean buffer underruns can cause TMDS
signalling problems?
Comment 79 Tom Horsley 2007-01-19 18:16:51 UTC
I can add some anecdotes for what they are worth: I have a Sapphire X700 PCI
express (identified by X as RV410 chipset). I had once in a blue moon flickering
problems in Fedora Core 5 with xorg 7.0, which changed to a couple of times a
second with Fedora Core 6 and xorg 7.1. I got the flickering to stop by
(painfully) forcing X to use a refresh rate lower than 60HZ. Comment #65
points to the details on my solution.

However, the problem is not isolated to linux. I have Windows XP on this same
machine, and in every version of Catalyst I've installed, I see occasional
flickering just like X had (only not as frequent on XP).

Weirdly, the flickering seems to be related to the actual contents of the
screen. The mostly light purplish-blue screen that XP uses at login has never
flickered. I changed my screen background from the default green fields
and hills to a solid purplish-blue about like the login, and the flickering
doesn't happen anymore till I run some app that paints something it doesn't
like. The worst I've seen is adobe photoshop. When it came up initially in
full screen with the sorta tan colored background it uses, it took forever to
see enough of the cursor between blinking on and off to drag a corner down
so it didn't fill the whole screen and get the flickering to stop. Even after
the flickering mostly stopped, pulling down a menu in photoshop would almost
always trigger an instant flicker attack which would go away just as instantly
when I hit ESC to close the menu.

I'm pretty sure I remember it being somewhat screen content sensitive in X
as well till I found my refresh rate solution, but I don't remember anything
under X that was as dramatic or reproducable as photoshop under windows.
Comment 80 Ulrich Gemkow 2007-01-21 05:10:14 UTC
(In reply to comment #73)
> Created an attachment (id=8437) [edit]
> print out the tmds table
> Could you print out the table (the values as retrieved from the bios) using 
the
> attached patch?

I used the following patch the print the table values
(so I skipped the modification of the actual values, only printing
the BIOS values)

@@ -576,8 +576,11 @@
                n = RADEON_BIOS8(tmp + 5) + 1;
                if (n > 4) n = 4;
                for (i=0; i<n; i++) {
-                   info->tmds_pll[i].value = RADEON_BIOS32(tmp+stride+0x08);
-                   info->tmds_pll[i].freq = RADEON_BIOS16(tmp+stride+0x10);
+       /*          info->tmds_pll[i].value = RADEON_BIOS32(tmp+stride+0x08); 
*/
+       /*          info->tmds_pll[i].freq = RADEON_BIOS16(tmp+stride+0x10); */
+                   xf86DrvMsg(pScrn->scrnIndex, X_INFO,
+                      "tmds entry %d value 0x%x freq %d\n",
+                       i, RADEON_BIOS32(tmp+stride+0x08), RADEON_BIOS16
(tmp+stride+0x10));
                    if (i == 0) stride += 10;
                    else stride += 6;
                }

and got for about 25 cards the same result:

(II) RADEON(0): PLL parameters: rf=2700 rd=12 min=20000 max=40000; xclk=20000
(II) RADEON(0): DFP table revision: 4
(II) RADEON(0): tmds entry 0 value 0x1fa0191 freq 15500
(II) RADEON(0): tmds entry 1 value 0x1fa0191 freq 20000
(II) RADEON(0): tmds entry 2 value 0x4e20000c freq 0

Hope this helps. Please let me know when I can give more info
Comment 81 Roland Scheidegger 2007-01-21 11:46:06 UTC
(In reply to comment #78)
> I used the following patch the print the table values
> (so I skipped the modification of the actual values, only printing
> the BIOS values)
Ah sorry for that. I missed that the patch actually was for table rev. 3 only
and not for 4.

> and got for about 25 cards the same result:
> 
> (II) RADEON(0): PLL parameters: rf=2700 rd=12 min=20000 max=40000; xclk=20000
> (II) RADEON(0): DFP table revision: 4
> (II) RADEON(0): tmds entry 0 value 0x1fa0191 freq 15500
> (II) RADEON(0): tmds entry 1 value 0x1fa0191 freq 20000
> (II) RADEON(0): tmds entry 2 value 0x4e20000c freq 0
> 
> Hope this helps. Please let me know when I can give more info
These values strongly suggest that indeed the decoding of dfp table rev. 4 is
incorrect. entry 2 is clearly garbage, though shouldn't matter, as entry 1 is
good for up to 200Mhz (which is already higher than the 165Mhz official limit of
tmds). But even the first two entries seem very fishy to me, as they are very
different to the default rv280 values (see the default_tmds_pll table). It
_could_ be different due to a different chip revision or different card
reference design, but even then it wouldn't really make sense to include two
identical entries in the bios.


Comment 82 Benjamin Herrenschmidt 2007-01-21 13:11:30 UTC
Looks like a broken BIOS indeed. The initial code drop from ATI just ignored
tables version 4, though when I ask Hui why, he said he had problem with
pre-production cards, but would expect production ones to work. I suppose OEMs
screwed up as usual...

Not sure what best to do here... not using the tables version 4 will break other
people with perfectly good tables. Maybe we can find a way to sanity check them...
Comment 83 Nuri Jawad 2007-02-22 16:36:53 UTC
Created attachment 8821 [details]
Radeon driver without bios tables rev. 4, x86-32
Comment 84 Daniel Stone 2007-02-27 01:26:01 UTC
Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Comment 85 Tomas Lindén 2007-03-12 01:24:18 UTC
I'm presently running with reduced blanking on my ASUS Radeon 9200 SE/TD card as described in comment #62 since September last year. 
  xvidtune -show
  "1600x1200"   132.00   1600 1648 1712 1820   1200 1202 1205 1207
With this setting the blanking occurs of the order of once every week or once every second week in ordinary desktop usage. 

If I run GoogleEarth then the flickering frequency increases to a few times per minute. So the problem is not solved completly by using reduced blanking and it can be worsened by increased activity on the graphics card.

Now I run Fedora Core 6 with kernel 2.6.18-1.2869.fc6 and X Window System Version 7.1.1.

I tested also a Connect3D Radeon 9200 C3D-6028 in my machine, but I had even more problems with it than with my Asus card. There was more flickering and I could not reduce it to the present level as with the Asus card using reduced blanking. The largest stable display size that I could achieve was 640x480 over the DVI cable. Using reduced modelines sometimes resulted in videomodes reported to be in error by my monitor. I had the warnings
  pixel clock 79 Mhz flashed in red
  pixel clock 170,6 Mhz flashed in red
by my Eizo L885 monitor.

I also tested a Sapphire Radeon 9200SE PCI card. I could see the flickering
problem on it too, but less frequently. Getting the resolution 1600x1200 over
DVI did not require the options MonitorLayout and PanelSize in the xorg.conf
file,
so this card is much better in this respect, but the performance is not so good because it is a PCI card.
Comment 86 Adam Jackson 2007-04-08 13:36:12 UTC
Move to 7.3 tracker.
Comment 87 moof 2007-05-19 21:10:17 UTC
I'd be happy to snail-mail one of the affected cards to whomever, if that'd help things along.
Comment 88 Tormod Volden 2007-05-30 15:52:08 UTC
Maybe it's late and I don't read the code correctly, but it seems like the "revision 4" code appears twice at the end of the current radeon_bios.c, once uncommented and once commented. Why is that?
Comment 89 Alex Deucher 2007-06-13 06:16:57 UTC
Some bioses may have bogus tmds pll data.  We may want to add some verification or fall back to the default values in certain cases.  An option to ignore the bios values may be worthwhile too.
Comment 90 Andreas Herrmann 2007-07-23 22:14:16 UTC
Short update wrt flickering problem of my radeon card.
(VGA compatible controller [0300]: ATI Technologies Inc RV280 [Radeon 9200
 PRO] [1002:5960] (rev 01))

I reported the problem begining of last year.
I tried almost all fixes/workarounds found here and elsewhere but finally
had to stick to the analog output to avoid flickering on an
Eizo FlexScan L885.

Meanwhile I have another screen. It is an Eizo FlexScan S2000.

(1) On the new screen I can use the Radeon 9200 with DVI w/o any flickering!

(2) Furthermore I have another Gfx card
 (VGA compatible controller [0300]:
 ATI Technologies Inc RV370 5B60 [Radeon X300 (PCIE)] [1002:5b60])
 It works perfectly with DVI on the older L885.
 (even w/o reduced blanking modeline or such)

In fact I run each card with dual screen using both monitors w/o problems.
The only thing that is not working is the combination of Radeon9200+DVI+FlexScan\
L885.

This makes me think that just certain hardware combinations suck.
It's not the radeon card not just the monitor that caused that flickering.
This is dissatisfying but I don't care anymore ...

And I think that certain monitors (e.g. Samsung 204B and Eizo L885) are
less tolerant to the signal quality on the DVI input.

Comment 91 Alex Deucher 2007-08-29 18:17:45 UTC
I believe this should be fixed in ati git master or the ati 6.7.x releases.  The driver uses the edid modes directly, and there is even the option to toggle the which tmds pll table to use via an output attribute.  Beyond that, I don't think there's much more we can do.  My flakey boards are all working fine now with ati git master.
Comment 92 Eric Anholt 2007-09-04 17:09:09 UTC
Clearing blocker status.  Other release managers have deemed it non-blocker for their releases, and I agree that it doesn't appear common and severe enough for this status.
Comment 93 Tom Horsley 2007-11-16 18:44:12 UTC
Well, I have Fedora 8 now with xorg-x11-drv-ati-6.7.195-3.fc8 and 6.7
don't fix my flickering problem :-).

Works fine when I boot up, but if I let the dpms stuff turn off the
monitor, when it turns back on it starts to flicker on and off
and eventually either completely loses the signal or gets a signal
out of range.

I had previously worked around this by providing my own mode line
to operate as slightly less than 60HZ, but with the new an improved
version of X it is looking quite difficult to get it to acknowledge that
I even specified a ModeLine at all.
Comment 94 Tom Horsley 2007-12-08 20:41:29 UTC
DOH! Despite the other folks who chimed in here with apparently identical
problems, I have finally discovered that the problem for me resides, not
in the radeon card or driver, but in the DVI2 input of my monitor. If I
use DVI1, the problems disappears.
Comment 95 Tomas Lindén 2008-04-28 04:46:01 UTC
The flickering problem became tolearable (about a flickering event once a week or so) after I configured a modeline with reduced blanking as described in Comment #64. I changed the the stock DVI cable that came with my Eizo FlexScan L885 to a Dual link DVI cable. This fixed the remaining flickering problem for me.

Changing cables is probably worth doing for everyone with DVI flickering problems.

I have now a new PC with a Nvidia graphics card and the old PC with the Radeon card is taken out of usage, so from my point of view this bug could be closed, but apparently there are many others with remaining flickering problems.
Comment 96 moof 2008-04-28 06:37:16 UTC
(In reply to comment #95)
> The flickering problem became tolearable (about a flickering event once a week
> or so) after I configured a modeline with reduced blanking as described in
> Comment #64. I changed the the stock DVI cable that came with my Eizo FlexScan
> L885 to a Dual link DVI cable. This fixed the remaining flickering problem for
> me.

FWIW, I've been using a dual-link DVI-D cable all along; my monitor wouldn't work without it. I still had the flickering/blanking issues.
Comment 97 Mike 2008-07-07 02:33:23 UTC
Three year old bug. I'm not alone :)

My setup is:
Fedora 8, xorg-x11-drv-ati-6.8.0-4.fc8

[01:00.0 0300: 1002:5961 (rev 01)] 01:00.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200] (rev 01)
[01:00.1 0380: 1002:5941 (rev 01)] 01:00.1 Display controller: ATI Technologies Inc RV280 [Radeon 9200] (Secondary) (rev 01)

monitor:
Manufacturer: IBM  Model: 686e (IBM L170p)

How to reproduce:
1. in kde console (konsole) make 2 tabs
2. fill one tab with lots of text
3. second tab is empty
4. do a fast switching between these tabs

now screen starts to jump horizontally :(
sometimes lcd goes blank for 1-2 second

without user input screen in rock steady

Looks like on screen update somehow refresh rates changes (?).
Most people see this as lcd switch-off.

My xorg.conf is default (almost empty):
<=====================
# Xorg configuration created by system-config-display

Section "ServerLayout"
        Identifier     "single head configuration"
        Screen      0  "Screen0" 0 0
        InputDevice    "Keyboard0" "CoreKeyboard"
EndSection

Section "InputDevice"
        Identifier  "Keyboard0"
        Driver      "kbd"
        Option      "XkbModel" "pc105"
        Option      "XkbLayout" "pl"
EndSection

Section "Device"
        Identifier  "Videocard0"
        Driver      "radeon"
#       Option "DisplayPriority" "HIGH"
#       Option "DefaultTMDSPLL" "true"
EndSection

Section "Screen"
        Identifier "Screen0"
        Device     "Videocard0"
        DefaultDepth     24
        SubSection "Display"
                Viewport   0 0
                Depth     24
        EndSubSection
EndSection
=====================>

There are no modeline lines.

These options won't help at all:
       Option "DisplayPriority" "HIGH"
       Option "DefaultTMDSPLL" "true"


What could I do to help fixing this issue?
Comment 98 Alex Deucher 2008-07-07 07:34:40 UTC
(In reply to comment #97)
> 
> These options won't help at all:
>        Option "DisplayPriority" "HIGH"
>        Option "DefaultTMDSPLL" "true"
> 
> 
> What could I do to help fixing this issue?
> 

Does the following option help?
Option "DisplayPriority" "BIOS"
reboot after changing this option to ensure you are using the bios initialized values.

Can you try the ati 6.9.0 release or git master?
Comment 99 Mike 2008-07-07 08:48:30 UTC
> does the following option help?
> Option "DisplayPriority" "BIOS"
> reboot after changing this option to ensure you are using the
> bios initialized values.

changed, power off - no effect

> Can you try the ati 6.9.0 release or git master?

tested this one:
http://xorg.freedesktop.org/archive/individual/driver/xf86-video-ati-6.9.0.tar.bz2
With or without 'Option "DisplayPriority" "BIOS"'... no change :(
Comment 100 Alex Deucher 2008-07-07 08:50:16 UTC
Can you attach your xorg log?
Comment 101 Mike 2008-07-07 09:00:41 UTC
Created attachment 17563 [details]
Xorg.0.log, Fedora8, xf86-video-ati-6.9.0
Comment 102 Alex Deucher 2008-07-09 10:57:23 UTC
(In reply to comment #101)
> Created an attachment (id=17563) [details]
> Xorg.0.log, Fedora8, xf86-video-ati-6.9.0
> 

Can you try any of the other 1280x1024 modes and see if they work any better, you should have at least 4:

(II) RADEON(0): Modeline "1280x1024"x60.0  108.00  1280 1328 1440 1688  1024 1025 1028 1066 +hsync +vsync (64.0 kHz)
(II) RADEON(0): Modeline "1280x1024"x75.0  135.00  1280 1296 1440 1688  1024 1025 1028 1066 +hsync +vsync (80.0 kHz)
(II) RADEON(0): Modeline "1280x1024"x71.9  133.00  1280 1368 1504 1728  1024 1027 1034 1070 -hsync +vsync (77.0 kHz)
(II) RADEON(0): Modeline "1280x1024"x59.9  109.00  1280 1368 1496 1712  1024 1027 1034 1063 -hsync +vsync (63.7 kHz)

Another option would be to try a cvt mode or a reduced refresh rate.  Do either of the following modes help?

Modeline "1280x1024R"   90.75  1280 1328 1360 1440  1024 1027 1034 1054 +hsync -vsync
Modeline "1280x1024_55.00_rb"  83.00  1280 1328 1360 1440  1024 1027 1034 1051  +HSync -Vsync
Modeline "1280x1024_60.00_rb"  91.00  1280 1328 1360 1440  1024 1027 1034 1054  +HSync -Vsync
Modeline "1280x1024_58.00_rb"  87.75  1280 1328 1360 1440  1024 1027 1034 1053  +HSync -Vsync
Comment 103 Mike 2008-07-10 05:46:19 UTC
Created attachment 17616 [details]
Modeline ignored
Comment 104 Mike 2008-07-10 05:46:38 UTC
Created attachment 17617 [details]
Modeline ignored
Comment 105 Mike 2008-07-10 05:48:35 UTC
Grabbing ModeLines from Xorg.log and setting them in xorg.conf won't work at all.
They are ignored. Modified config and logfile attached.

There is mode override in 'configure kdesktop / display'. But 'Apply settings on KDE startup' is off.
If I set 1024x768 in xorg.conf and press ctrl+alt+backspace monitor switches to that res.

Did I miss something?


Lucky I can change modes (and vsync) by xrandr tool.
1280x1024@60Hz - default, screen jumps only on user input,
1280x1024@72Hz - screen jumps without user input, sometimes stops,
1280x1024@75Hz - screen jumps all the time.

Underclocking video output might "solve" problem.
Is it a proper soltion?
Comment 106 Alex Deucher 2008-07-10 07:35:30 UTC
(In reply to comment #105)
> Grabbing ModeLines from Xorg.log and setting them in xorg.conf won't work at
> all.
> They are ignored. Modified config and logfile attached.

I think that was a bug in xserver 1.3.0.  xserver 1.3.0 also had a bug where it would reverse the sync polarity on modes from the edid.  you might want to check if your xserver has been patched.

> 
> There is mode override in 'configure kdesktop / display'. But 'Apply settings
> on KDE startup' is off.
> If I set 1024x768 in xorg.conf and press ctrl+alt+backspace monitor switches to
> that res.
> 
> Did I miss something?
> 

you can also add modelines on the fly with xrandr.  for example:
xrandr --newmode "1280x1024R"   90.75  1280 1328 1360 1440  1024 1027 1034 1054 +hsync -vsync
xrandr --addmode VGA-0 "1280x1024R"
xrandr --output VGA-0 --mode "1280x1024R"

> 
> Lucky I can change modes (and vsync) by xrandr tool.
> 1280x1024@60Hz - default, screen jumps only on user input,
> 1280x1024@72Hz - screen jumps without user input, sometimes stops,
> 1280x1024@75Hz - screen jumps all the time.

you might also try the 1280x1024@59.9Hz

> 
> Underclocking video output might "solve" problem.
> Is it a proper soltion?
> 

It depends.  lots of LCD monitors are very picky about the signal they like.  the wrong combination of dividers, even though it produces the proper dotclock can make some monitors unhappy.  As such some video cards need to produce a slightly different signal to make them happy in some circumstances.
Comment 107 Mike 2008-07-10 09:08:46 UTC
> Can you try any of the other 1280x1024 modes and see if they work
> any better, you should have at least 4:
> 
> (II) RADEON(0): Modeline "1280x1024"x60.0  108.00  1280 1328 1440 1688  1024
> 1025 1028 1066 +hsync +vsync (64.0 kHz)

same as xrandr: 1280x1024@60Hz - default, screen jumps only on user input,

> (II) RADEON(0): Modeline "1280x1024"x75.0  135.00  1280 1296 1440 1688  1024
> 1025 1028 1066 +hsync +vsync (80.0 kHz)

same as xrandr: 1280x1024@75Hz - screen jumps all the time.

> (II) RADEON(0): Modeline "1280x1024"x71.9  133.00  1280 1368 1504 1728  1024
> 1027 1034 1070 -hsync +vsync (77.0 kHz)

same as xrandr: 1280x1024@72Hz - screen jumps without user input, sometimes stops,

> (II) RADEON(0): Modeline "1280x1024"x59.9  109.00  1280 1368 1496 1712  1024
> 1027 1034 1063 -hsync +vsync (63.7 kHz)

same as xrandr: 1280x1024@60Hz - default, screen jumps only on user input,



> Another option would be to try a cvt mode or a reduced refresh rate.
> Do either of the following modes help?
> 
> Modeline "1280x1024R"   90.75  1280 1328 1360 1440  1024 1027 1034 1054 +hsync
> -vsync
> Modeline "1280x1024_55.00_rb"  83.00  1280 1328 1360 1440  1024 1027 1034 1051 
> +HSync -Vsync
> Modeline "1280x1024_60.00_rb"  91.00  1280 1328 1360 1440  1024 1027 1034 1054 
> +HSync -Vsync
> Modeline "1280x1024_58.00_rb"  87.75  1280 1328 1360 1440  1024 1027 1034 1053 
> +HSync -Vsync

All of them works fine!


>> Grabbing ModeLines from Xorg.log and setting them in xorg.conf won't work
>> at all.
>> They are ignored. Modified config and logfile attached.
> I think that was a bug in xserver 1.3.0.
> xserver 1.3.0 also had a bug where it would reverse the sync polarity
> on modes from the edid.
> you might want to check if your xserver has been patched.

Could You please point to these commits in xserver tree?
That would be very helpfull.
Comment 108 Mike 2008-07-11 07:41:35 UTC
> > Modeline "1280x1024R"   90.75  1280 1328 1360 1440  1024 1027 1034 1054
> > +hsync -vsync
> 
> All of them works fine!

Update.

I'm using above Modeline.
Blanks aren't gone. They are just less frequent.

I think I'll choose cheap solution:
https://bugzilla.redhat.com/show_bug.cgi?id=389041#c2
Comment 109 Alex Deucher 2008-12-02 23:26:04 UTC
Are there still issues with ati from git master?
Comment 110 Pawel 2008-12-29 16:36:50 UTC
Hello!

I have the same problem on my desktop.
Ubuntu version is Interpid - 8.10

I don't know what to do to slove this problem.


regards
Pawel
Comment 111 Alex Muntada 2008-12-30 14:10:07 UTC
My DVI problems with radeon driver were solved by adding Option "MacModel" "mini" in xorg.conf; please see: http://bugs.freedesktop.org/show_bug.cgi?id=12525#c13

However, let me know if I can help with this bug.
Comment 112 Dmitry Morozhnikov 2009-01-25 12:44:17 UTC
(In reply to comment #109)
> Are there still issues with ati from git master?

I'm not yet sure what this is the same problem, but i see flickering and (infrequent) blanking with git version from 01/13/2009 on my

02:00.0 VGA compatible controller: ATI Technologies Inc RV515 PRO [Radeon X1300/X1550 Series]

Seems what "xrandr --rate 60" help. Not sure yet what this removes problem completely for me.
Comment 113 Alex Deucher 2010-02-16 15:17:00 UTC
The original bug was fixed bug since then this bug has turned into a mess.  Closing.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.