Created attachment 319990 [details] Xorg.0.log to show version of hardware and driver Description of problem: X sometimes shows small areas with "noise". When screen is redrawn - perhaps in other areas - then it is shown correctly. Even trying to take a screenshot (in gnome) fixes it. I have taken some screen shots with a camera and will attach them. nomodeline seems to make no difference. Version-Release number of selected component (if applicable): xorg-x11-drv-radeonhd-1.2.1-3.9.20080917git.fc10.i386 But I think problem has been seen with all radeon drivers since I began testing f10 beta. Nothing in /var/log/messages. How reproducible: occasionally, several times an hour
Created attachment 319992 [details] photo of screen with redraw errors
Created attachment 319993 [details] photo of same part of screen after it has been redrawn
Are you booting your system with or without using kernel modesetting? On my system with a mobile X1400 chipset, kernel modesetting messes up the display so much on F10beta that I would not trust a system wrt graphics errors until the next cold boot. Are you booting with the kernel parameter "nomodeset"? If not, is the issue reproducible after booting with "nomodeset"?
Until a couple of days ago I had the same experience as you and had to use nomodeset, but with recent updates I haven't seen any problems with correlation to nomodeset. Right now I am not using nomodeset (double negation - so to make it clear: I _do_ get plymouth highres progress bar). But I get the same behaviour when _not_ using nomodeset. I will verify in a moment.
Hmm. It seems like you are right. Without nomodeset I can reproduce it with a maximized gnometerminal matrix-like text flying by - with while true; do cat /var/log/messages; done Staring deeply into the screen I see the drawing error several times a minute. With nomodeset I couldn't provoke the error. Next week I will continue running with nomodeset and see if that keeps the problem away.
This is a duplicate of bug 466663 , which is kms + xorg-x11-drv-ati bug. Your logs show you are using it, rather than radeonhd.
(In reply to comment #6) > This is a duplicate of bug 466663 , which is kms + xorg-x11-drv-ati bug. Your > logs show you are using it, rather than radeonhd. Very much so indeed. However, I can confirm that radeonhd did have similar issues on my mobile X1400 in conjunction with KMS - and those issues are fixed in xorg-x11-drv-radeonhd-1.2.3-1.2.20081014git.fc10 :-) *** This bug has been marked as a duplicate of bug 466663 ***
You are right. I am sorry for having provided wrong information. But _now_ I am running radeonhd. I'm quite sure ... Compiz doesn't work, but otherwise it is ok ... What happened? In my Xorg.0.log I saw '(II) LoadModule: "radeon"' '(II) Loading /usr/lib/xorg/modules/drivers//radeon_drv.so' and concluded that the radeon driver was used. When entering an bugzilla bug there was only one package mentioning radeon, and I thought that was the right one to choose, hd or not. When I can get it wrong then other users might get it wrong too. Not to blame others, but please take this as constructive feedback to avoid similar problems, some for radeonhd, some for xorg in general: * It is not obvious from looking at an Xorg.0.log which driver is used. Could it be made more explicit? * Xorg.0.log is hard to read; apparently the blank line after '(II) LoadModule: "radeon"' should be before it? * 3 different X drivers supporting my card is confusing. Choice is good, but for Fedora end users there should be only one that works. Apparently "ati" and "radeon" is 100% the same? * Yes, radeonhd is experimental and I am glad to test it. Please put "experimental" in the package name, and make it clear in the X logs that the experimental driver is used. That will distinguish it more from the spurious "radeon" driver.