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.
Elmar, Have you tried replacing only the drm and radeon kernel drivers, rather than the whole kernel? There are instructions on this page: http://wiki.x.org/wiki/radeonhd%3Ar6xx_r7xx_branch 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.
With kernel 2.6.27.21-0.1-default 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.
This sounds like display underflow or a bad pll selection. Does disabling acceleration fix it?
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.
(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"
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".
see also: bug 21896,comment #14.
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?
still an issue for xorg-x11-driver-video-radeonhd-1.2.5_20090506_4be5f71-7.23 although flashblack frequency may be a bit lower.
seems to be resolved with xorg-x11-driver-video-radeonhd-1.2.5_20090506_4be5f71-7.16.
occurs again with xorg-x11-driver-video-radeonhd-1.3.0_20091009_8cbff7b-2.1.
(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"
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 ....
Unfortunately the UseAtomBIOS - Option does not help.
1.2.5_20090506_4be5f71 didn't initialize DRM by default AFAIR, so it's no use bisecting this. :-(
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.
That's... interesting :-) Thanks for testing!
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.
It's not that trivial. What probably fixed this case is af5f1e1 which fixes I2C readout.
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.).
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.
perhaps there was an error in my xorg.conf; will have to check again.
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.
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 2.6.34.7-0.5).
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 #25 from Elmar Stellnberger <estellnb@gmail.com> 2010-12-17 03:11:38 PST --- > Hey, anyone still working on radeonhd? no.
(In reply to comment #25) > Radeon has dropped user mode settting support, [...] Not true, it's just that the developer focus is on KMS.
Good work! Resolved. xorg-x11-driver-video-radeonhd-1.3.0_20100512_80ba041-34.19.x86_64, 2.6.37-8.99.14.138eeaa-desktop 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.