Bug 22114 - monitor sometimes stays flashing black
Summary: monitor sometimes stays flashing black
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/radeonhd (show other bugs)
Version: 7.4 (2008.09)
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Luc Verhaegen
QA Contact: Xorg Project Team
Depends on:
Reported: 2009-06-05 12:29 UTC by Elmar Stellnberger
Modified: 2011-01-21 04:56 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Description Elmar Stellnberger 2009-06-05 12:29:55 UTC
Using the new xorg-x11-driver-video-radeonhd-1.2.5_20090506_4be5f71-3.1 driver with kernel2.6.30-rc5-git1-master_20090515173431_9c6d4c14-default as recommended a very strange error annoys me from time to time:
  The screen suddenly turns black for about a second; then it continues to view everything as usual. This happens multiple times in sequence and may not stop at all; very annoying.
  using a FS Scaleoview Q26W-1 1920x1200 monitor.
  Singleton turn-blacks have occured with previous versions but they did not annoy. Now they occur multiple times in sequence and may not stop at all. May be related with bug 21896, since it sometimes occurs more often on scrolling. Very likely related to the new radeonhd driver since the rest of the system has stayed the same; i.e. I have not updated Xorg or any other relevant component than the 2.6.30 kernel required for the new radeonhd.
Comment 1 Xolotl Loki 2009-06-05 14:26:13 UTC

Have you tried replacing only the drm and radeon kernel drivers, rather than the whole kernel?  There are instructions on this page:


Since the 2.6.30 kernel isn't stable yet, there might be other issues which are exacerbating the problem.

This is assuming that you are using 2.6.30 in order to get 2D acceleration, if not please ignore.
Comment 2 Elmar Stellnberger 2009-06-08 07:48:43 UTC
With kernel it is at least as bad as with 2.6.30 (if not even worse) which means that the flash-blacks are in all likelihood related to the new radeon/drm driver.
Comment 3 Alex Deucher 2009-06-08 08:27:20 UTC
This sounds like display underflow or a bad pll selection.  Does disabling acceleration fix it?
Comment 4 Elmar Stellnberger 2009-06-08 08:31:43 UTC
Hmm, I will have to upgrade again and turn DRM off. The driver is hardly usable in this configuration but wanna have a try on this, ok.
Comment 5 Alex Deucher 2009-06-08 08:33:35 UTC
(In reply to comment #4)
> Hmm, I will have to upgrade again and turn DRM off. The driver is hardly usable
> in this configuration but wanna have a try on this, ok.

You can turn it off in your xorg.conf:
Option "DRI" "False"
Option "AccelMethod" "ShadowFB"
Comment 6 Elmar Stellnberger 2009-06-08 09:12:44 UTC
No flashblacks as soon as DRI is turned off (xorg-x11-driver-video-radeonhd-1.2.5_20090506_4be5f71-3.1).
Wanna now try to keep the new driver by adding "AccelMethod" "ShadowFB".
Comment 7 Elmar Stellnberger 2009-06-18 04:24:05 UTC
see also: bug 21896,comment  #14.
Comment 8 Elmar Stellnberger 2009-06-22 13:00:34 UTC
This is most likely some kind of graphics mode auto adjustment bug since it only applies to monitors externally plugged via the HDMI output but not to my internal notebook monitor. What about the info sent via the Plug&Play pins?
Comment 9 Elmar Stellnberger 2009-07-01 01:21:37 UTC
still an issue for xorg-x11-driver-video-radeonhd-1.2.5_20090506_4be5f71-7.23 although flashblack frequency may be a bit lower.
Comment 10 Elmar Stellnberger 2009-09-06 03:30:43 UTC
seems to be resolved with xorg-x11-driver-video-radeonhd-1.2.5_20090506_4be5f71-7.16.
Comment 11 Elmar Stellnberger 2009-10-15 07:01:05 UTC
occurs again with xorg-x11-driver-video-radeonhd-1.3.0_20091009_8cbff7b-2.1.
Comment 12 Matthias Hopf 2009-10-19 05:54:44 UTC
(In reply to comment #8)
> This is most likely some kind of graphics mode auto adjustment bug since it
> only applies to monitors externally plugged via the HDMI output but not to my
> internal notebook monitor. What about the info sent via the Plug&Play pins?

No, this sounds like we don't have enough info about PLL or logic driver settings, and they are misprogrammed. Which results in a lower quality signal, which can drop out sometimes.

However, this does neither correlate with DRM initialized or not, and it does not correlate with the driver versions you tested.
You sure that 1.2.5_20090506_4be5f71 didn't have any issues?

Also please test the option
  Option "UseAtomBIOS" "yes"
Comment 13 Elmar Stellnberger 2009-10-19 09:35:03 UTC
Yes I am sure that xorg-x11-driver-video-radeonhd-1.2.5_20090506_4be5f71-2.13.x86_64 does not habe the problem;
going to test the UseAtomBIOS - Option ....
Comment 14 Elmar Stellnberger 2009-10-20 02:03:36 UTC
Unfortunately the UseAtomBIOS - Option does not help.
Comment 15 Matthias Hopf 2009-10-20 03:07:23 UTC
1.2.5_20090506_4be5f71 didn't initialize DRM by default AFAIR, so it's no use bisecting this. :-(
Comment 16 Elmar Stellnberger 2009-11-18 08:58:02 UTC
reoslved with xorg-x11-driver-video-radeonhd-1.3.0_20091106_619706-2.1.x86_64;
hurrah. Now I would only need 3D support for my Radeon Mobility HD-2700.
Comment 17 Matthias Hopf 2009-11-18 09:04:41 UTC
That's... interesting :-)
Thanks for testing!
Comment 18 Elmar Stellnberger 2009-11-18 09:38:01 UTC
 Just before with xorg-x11-driver-video-radeonhd-1.3.0_20091026_8b89b9-1.1.1.x86_64.rpm there were massive flashblacks.   
 You`d better have a look at the changes to see what could have resolved it so that we can avoid it for the future.
Comment 19 Matthias Hopf 2009-11-19 05:27:58 UTC
It's not that trivial.
What probably fixed this case is af5f1e1 which fixes I2C readout.
Comment 20 Elmar Stellnberger 2009-11-28 03:56:19 UTC
The flashblacks have not gone completely for this version but they are so seldom that they do not annoy (Really annoying are only multiple flashblacks in sequence.).
Comment 21 Elmar Stellnberger 2009-12-02 02:48:21 UTC
As bad as before with xorg-x11-driver-video-radeonhd-1.3.0_20091124_6387ab4-15.1.x86_64. I wonder how to downgrade because these flashblacks will make me womit.
Comment 22 Elmar Stellnberger 2009-12-03 10:18:44 UTC
perhaps there was an error in my xorg.conf; will have to check again.
Comment 23 Elmar Stellnberger 2010-01-22 07:51:38 UTC
 Really horrifying with the latest version xf86-video-radeonhd- 1.3.0-38_g17bbb4d_2010_01_19. It has NEVER BEEN AS BAD AS THIS!! The screen stays black for more than 5 seconds. The picture that should be displayed flashes up only for short. It is completely impossible to use radeonhd like this!
  I have already had considerable endeavor in testing radeonhd but you as the developers of radeonhd seem to be completely ignorant to this issue not even trying to find out what has caused this error. That way I will have to give up being forced to use the proprietary driver for the future.
Comment 24 Elmar Stellnberger 2010-11-22 13:04:57 UTC
Still persists for radeonhd-1.3.0_20100325_f6c9991-1.13.x86_64 while the problem has been resolved since already a couple of time for radeon (kernel
Comment 25 Elmar Stellnberger 2010-12-17 03:11:38 UTC
Hey, anyone still working on radeonhd?
It would be super if you could eliminate the flashblack problem!
I do currently not have anything else: Radeon has dropped user mode settting support, fglrx does not work either and kernel modesetting is still far from working even with the newest releases. I guess that there will be some place for radeonhd in the future as well as not all OS-es have KMS (FreeBSD, etc.).
If the radeon developers could solve it you can do as well.
Comment 26 Julien Cristau 2010-12-17 04:13:32 UTC
> --- Comment #25 from Elmar Stellnberger <estellnb@gmail.com> 2010-12-17 03:11:38 PST ---
> Hey, anyone still working on radeonhd?

Comment 27 Michel Dänzer 2010-12-17 05:13:45 UTC
(In reply to comment #25)
> Radeon has dropped user mode settting support, [...]

Not true, it's just that the developer focus is on KMS.
Comment 28 Elmar Stellnberger 2011-01-21 04:56:01 UTC
Good work! Resolved.


Not a single flashblack-sequence for more than a whole week!
Definitely gone (remember it used to be tricky - 3 days no fb. then every few minutes till` I felt like having to womit. Singleton very very scarce/seldom flashblacks can still occur but do not disturb at all. )

possibly related to 2.6.37: occasional video mode restoration problem (flirring screen with light green rounding of the leaves in the background image) which can only be resolved by a xinit -- :1, not by a chvt or a new s2ram/powersave -u

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.