After buying a new monitor (Dell 2209WA, running on 1680x1050@60Hz) I am facing a severe problem when the monitor is connected via DVI: Whenever something happens on the screen (like moving windows, scrolling in the web browser, or output scrolls in a terminal, just to name examples), the monitor turns black for about 2 seconds, then it comes back. Sometimes its kind of harder to trigger, but most times it happens just all the time, rendering it completely useless. VGA works without problems, but is of course no solution.

I thought that the card might be broken but it works using the propietary fglrx driver (I tried 1:9-2-2 from non-free testing). This is also no solution because -it's propietary -the version now in unstable does not support the card anymore -I don't want to use non-free packages.

Then I also tried xserver and radeon driver (1:6.12.2-2) from unstable, with exactly the same result.

The X log for using the fglrx driver is attached.

Any help appreciated, thanks,

Florian

Option "DisplayPriority" "HIGH"
in the device section of your config file fix it?

Alex

Option "DisplayPriority" "HIGH"
in the device section of your config file fix it?

Alex

driver only).

Long version, if it matters: It worked for some minutes after restarting
the xserver after the change. Then, after a reboot, the same behaviour
returned (and will stay from now on). I saw this several times already
before, that after changing something in xorg.conf and restarting the
xserver, it seemed to work, but after (another?) restart it stopped
working again. Anyway, that's not reproducible. Sorry for this fuzzy
information, but it seems worth mentioning...

thanks,

florian

This is probably a hardware limitation of the card.

AFAIK dual-link dvi is needed for modes above 1280x1024 to work reliably
over DVI. Some card - monitor combinations might work but others would
not.

Better cards have higher-rate transmitters that can do modes slightly
larger than 1280x1024 but a 22" screen is likely over-spec for any
single link card so there is no guarantee it will work.

Dual link cards start somewhere in the X1300-X1600 range for Radeons
iirc.

Thanks

Michal

165 Mhz is the single link limit.  With reduced blanking you can run
1920x1200@60Hz.  Most dual link monitors start out around 2560x1600.

Alex

2009/7/22 Alex Deucher <alexdeucher@gmail.com>:

Well, reduced blanking is like overclocking. It might work but it might not.

Either way my experience with Radeon 9250 is that it cannot drive a
22" screen over DVI reliably, and I read in a bug report somewhere
somebody testing about a dozen cards with similar results.

It might be that these older cards actually cannot do full 165 MHz.

Radeon 9600 is a higher model than 9250 but it is about as old as the
9250s, perhaps even older. While it may offer better 3D performance it
might not offer better DVI transmitter than the lower models.

Thanks

Michal

Not exactly.  Lots of monitors (mostly LCDs) require reduced blanking modes.

I can run 1920x1200 reliably on a 9250 here.  I've even run it on a
radeon 7000, so the hardware is capable.  It's more likely a issue
with the pll or watermark setup.  Lots of the higher res LCDs are VERY
picky about the pll dividers.  I would try some alternate mode lines,
e.g., :
Modeline "1680x1050R"  119.00  1680 1728 1760 1840  1050 1053 1059
1080 +hsync -vsync
Modeline "1680x1050_60.00"  147.14  1680 1784 1968 2256  1050 1051
1054 1087  -HSync +Vsync

In the earlier days of the driver, it did not use the modes from the
edid which resulting in the driver not using the specific modes he LCD
monitors required.  Changing that fixed a lot of setups.

The hardware definitely can.

The 9600 also supported up to 165 Mhz as well.

Based on the description, it really sounds like display underflow to
the display controller.  The display controller contends with the 2d
and 3d engine for memory bandwidth.  If the memory controller is not
able to fill the display controller's request fast enough you end up
with the screen blanking due to lack of incoming data.  Another thing
to try is:
Option "ColorTiling" "False"
Option "DisplayPriority" "HIGH"

The second option sets the display controller's memory controller
priority to the max, and the first option disables surface tiling.
The line buffer that feeds the display controllers is scanline based,
however, when tiling is enabled, the hw has to adjust the requests to
deal with the tiling which eats additional bandwidth.

Alex

2009/7/23 Alex Deucher <alexdeucher@gmail.com>:

It's not like it can never works but depending on the card-monitor
pair it may work flawlessly, blank sometimes, fail to wake up from
DPMS sleep states, ...
The solution was to replace these old cards with newer cards where
larger screen is used.

Here it does not even have the WorksWithWindowsᵀᴹ property so the
original ATI drivers fail, too.
Sure, it's not like the X drivers cannot get better than the original
drivers. Some S3Trio3D/2X cards that did not work well in windows
would work with X at higher modes and without glitches.

The results may also vary depending on the memory chips and other
support chips / included features used by the card maker.

For one, if that's a memory bandwidth problem the frequency and bus
width of the memory chips used may affect the issue and different card
models by different manufacturers offer different options.

I am not sure where the TMDS transmitter is already integrated into
the graphics chipset and where it is an option added by the card
manufacturer. In the later case the parts used by the card maker may
also affect the capabilities of the DVI output and cause differences
between  systems.

Thanks

Michal

The tmds controller is integrated into the chips.  However different
oems use different memory types and configuration so that indeed may
be the problem.  An older low end card with slow memory may not be
able to handle the bandwidth for 2d and 3d and a high res screen.
Still, it might be worth trying the modelines and options I suggested.


Alex

Thanks for your comments (and sorry for the late reply)

Now that xorg 1.6.3 migrated to testing, together with a new radeon
driver and with a fglrx proprietary driver which does not anymore
support my hardware, I do not have a workaround anymore, except for
using VGA which is not a solution, I think (for the record, the new
radeon driver does not improve on the situation).

I tried the options and the modelines Alex suggested (see below), but
without any change in the behaviour. Every scrolling e.g. on the
bugreport page causes a 1-2 s blackout of the screen. You really stop
scrolling.

If you have any more suggestions I would be very happy (you don't even
get a new fan-less AGP card for a reasonable price easily nowadays...).

Thanks,

Florian

------------------------------
Section "Device"
        Identifier      "Configured Video Device"
        Driver          "radeon"
        Option          "ColorTiling" "False"
        Option          "DisplayPriority" "HIGH"
EndSection

Section "Monitor"
        Identifier      "Configured Monitor"
        Modeline        "1680x1050R"  119.00  1680 1728 1760 1840  1050
1053 1059 1080 +HSync -Vsync
        #Modeline "1680x1050_60.00"  147.14  1680 1784 1968 2256  1050
1051 1054 1087  -HSync +Vsync
EndSection

Section "Screen"
        Identifier      "Default Screen"
        Monitor         "Configured Monitor"
        DefaultDepth    24
        SubSection "Display"
                Depth 24
                Modes "1680x1050R"
        EndSubSection
EndSection
----------------------------------

Hello


2009/9/16 Florian <flad@gmx.at>:

This is somewhat offtopic here but perhaps others might look here when
they encounter similar problem and might find reading this discussion
useful.

If you do not insist on acceleration an nVidia GF 6200 based card
should work. Whatever is required for the larger DVI modes these cards
seems to have it. The drawback is that you probably need an AGP 4x or
higher mainboard to use this card with any driver except vesa. Not
that the nv driver is much improvement but the fill rate should be
significantly higher which should improve things like scrolling.

The other option would be to find a Radeon X1xxxx or HDxxxx adapted
for AGP but I have seen few of these and the price can easily get to
or exceed the price of a complete board with an Intel 945 family
chipset with an Atom CPU and DVI output onboard. I don't know if there
is a minimum AGP speed for these cards to work. AFAIK they are adapted
by an additional bridge chip which tends to improve hardware
compatibility.

I cannot recommend i945 anymore as there are many variants of the
graphics in this family and different boards tend to lock up with
different versions of the various X components (most notably the intel
driver, Mesa library, and Linux agp/drm modules) or different X
acceleration methods. It can be quite challenging to get a stable
system using one of these boards and  it's somewhat hard to replace
the graphics in this case. The 3D performance is also poor in part
simply for low speed of these GPUs in part  for lack of support for
some features in both the drivers and the hardware itself.

I am also not sure about the performance of the DVI output of the i945
based boards but the manufacturer specifications should include the
maximum output resolution.

The later chipsets like G43/G45 work with relatively large screens but
the instability may apply here as well, especially since the chipsets
are newer than i945 so you have smaller choice of driver versions that
support them at all. The performance should be somewhat better than
i945.

Thanks

Michal

I'm suffering from an issue similar to this one. I found that switching to
VT and back to X a couple of times seems to fix the problem, but obviously
this isn't a real solution. Also because, with KMS, switching to console
is not going to do anything to the graphic card (and this is why I'm
keeping kms disabled, as the issue is still happening with recent kernel
and video drivers).

With respect to the original submitter situation, I think I'm luckier
because it doesn't happen always. It happens "sometimes" when switching
from VT to X (or starting X), when exiting powersave mode or when I turn
on the display with an X session active. Sometime the screen looks ok and
all works fine, sometimes I see some pixel flashing or fuzzy images (but
never both) and then the monitor will lose the video signal after some
second. Sometimes instead images are sharp but if the screen changes too
much the signal is lost immediately.

I don't think it's exclusively due to the monitor size because I had the
same problem with the same card but a smaller display (15" LCD at
1024x768): with the VGA connection it worked fine, the symptoms described
above appeared using DVI. But surely the problem is correlated with the
size, because it happened about one time every ten with the 15" display,
and now it happens approximately one time every three with a 22" display
(1680x1050 LCD).

ciao,
Riccardo

Dear Maintainer,

After updating my system to wheezy, and in particular the
xserver-xorg-video-ati package to version 1:6.14.4-8, I
now suffer from a similar issue.

I have two monitors. The right one, and only the right one, randomly
turns off and on.

* I use the default Xorg configuration and setup dual monitors
  using xrandr --output DVI-0 --left-of DVI-1 --auto.

* The two monitors are identical models: SAMSUNG SyncMasterB1940.
  The problem does not seem to be in the monitors: when I swap the two DVI
  connectors, the left one starts to flicker on and off and the right
  one works flawlessly.

* If I run "xset dpms force off" the problems disappears completely.


I'm available if you require more information.

Thanks,

Pablo Oliveira.

To clarify, do you mean that after a dpms cycle both monitors work
correctly?  Does a newer kernel help?  3.2 is pretty old.  There were
a number of display related fixes that went into 3.7 for example.

Alex

Yes, after turning off DPMS, both monitors work correctly.
I have been using the system all day without any flickering problems.

I will try with a new kernel and report back.

Also, I would add that, like the other people affected by this bug,
the problem triggers often when scrolling a window.

Pablo Oliveira.

Is this the same issue?  I.e., does the blinking come back after a
dpms cycle if you scroll?  If so, it sounds like it may be a bandwidth
issue.  You might try booting with radeon.disp_priority=2 on the
kernel command line in grub.

Alex

After a dpms cycle the problem disapears *completely*, whether I scroll or not.

If I *do not* dpms cycle, the screen blinks randomly, but the blinking
triggers often during a scroll.

Pablo

Dear Alex,

Before trying with 3.7, to have a conclusive report, I tried to
reproduce on 3.2.
Sadly, I'm unable to reproduce the bug anymore on 3.2 kernel.

Last week, when I first reported on this bug ticket, the flickering
persisted both after a X server restart and a system restart. Only
when I performed a dpms cycle did it went away. Nevertheless, today
I'm unable to reproduce the flickering.

I have not installed or updated x-server packages since last week and
have not changed my video configuration, so I have no specific idea
about why I cannot reproduce anymore.

If in the future, I get the bug back, I will report here.

Thanks,

Pablo.

I have the same Problem on an ATI Radeon HD 3200. It works fine with
wheezy, but I have the described Error with Debian-Jessie, Ubuntu or
Knoppix.

It works if I am keeping KMS disabled, but this is not a proper solution
since radeon is now an KMS only release.

Ciao
Matthias

The Dell 2209WA had some DVI hardware glitch that caused these mysterious
blackouts.

See extended discussion:
http://en.community.dell.com/support-forums/peripherals/f/3529/t/19257125

And upstream: https://bugs.freedesktop.org/show_bug.cgi?id=89110

Some users reported that Sapphire fixed the problem with a BIOS update but
for other manufacturers it was always an issue. Using an active DisplayPort
adaptor was the recommended workaround in the end.

Final comment from Dell:

"Posted by DELL-Chris
I never could find a solid fix, several workarounds for PC, none for Macs.
The issue does not occur for everyone and we could never replicate it in
our lab."