Description of problem: samsung X20 laptop bios 11Z. The OSD Icons like LCD brightness, battery status) in the left upper corner are broken, after starting Xorg FC5. This problem was not in FC4. Version-Release number of selected component (if applicable): How reproducible: Boot FC5 on X20 in runlevel 3. Start only Xorg like "> Xorg", quit the xserver. The icons are broken when the xserver is running and after this on the console too. Before start of the xserver, the icons are fine. Steps to Reproduce: 1. 2. 3. Actual results: Broken OSD Icons. Expected results: OSD Icons are fine. Like before starting Xorg in FC5 or like FC4. Additional info: I tried to disable some entries in "my" xorg.conf. But the problems is the same.
Created attachment 127365 [details] xorg.conf
I tried the modules directory from FC4 xorg 6.8.2 today, and there's no problem, means the icons look normal. So the problem comes with xorg 7.0 FC5.
This seems to be ok again with the following packages: mesa-libGLU-devel-6.4.2-6 mesa-libGL-devel-6.5-4 mesa-libGL-6.5-4 mesa-libGLU-6.4.2-6 xorg-x11-drv-ati-6.6.0-1 kernel-2.6.16-1.2147self_FC5
This is generally performed by the BIOS, presumeably via SMM mode, and not something that X draws on screen itself. Since you've indicated that the problem goes away with updating a few packages to newer rawhide builds (I presume the versions indicated in comment #3 are from rawhide at some point), it would seem that some hardware state may have not been preserved in the FC5 drivers. Realistically, to diagnose the problem further would require direct physical access to the laptop that the problem is occuring on. As such, the best way to proceed with this is to report the problem directly to X.Org developers by filing a bug report in the X.Org bugzilla located at http://bugs.freedesktop.org in the "xorg" component. That will increase the likelyhood that someone has this hardware available who can diagnose the problem directly. Once you've filed your bug report to X.Org, if you paste the new bug URL here, Red Hat will continue to track the issue in the centralized X.Org bug tracker, and will review any bug fixes that become available for consideration in future updates. Setting status to "NEEDINFO_REPORTER", awaiting X.Org bug URL for tracking.
(In reply to comment #4) > This is generally performed by the BIOS, presumeably via SMM mode, and not > something that X draws on screen itself. Yes, I know. But X can setup a different video buffer so that, X output look ok (because X knows this layout) and the icons from the bios are broken. Since you've indicated that the > problem goes away with updating a few packages to newer rawhide builds > (I presume the versions indicated in comment #3 are from rawhide at some > point), it would seem that some hardware state may have not been > preserved in the FC5 drivers. Yes, so it is. Never change the bios from FC4 to FC5, but with FC5 (=xorg 7.x) this broken icons appear. > > Realistically, to diagnose the problem further would require direct > physical access to the laptop that the problem is occuring on. No problem - there're a lot of pc or laptops with the radeon r300 chipset - just try it - it's reproducable. As such, > the best way to proceed with this is to report the problem directly to > X.Org developers by filing a bug report in the X.Org bugzilla located at > http://bugs.freedesktop.org in the "xorg" component. That will increase > the likelyhood that someone has this hardware available who can diagnose > the problem directly. > > Once you've filed your bug report to X.Org, if you paste the new > bug URL here, Red Hat will continue to track the issue in the > centralized X.Org bug tracker, and will review any bug fixes that > become available for consideration in future updates. > > Setting status to "NEEDINFO_REPORTER", awaiting X.Org bug URL > for tracking. This problem is not there any more with this kernel version from rawhide. It's bad that nobody says, if this patch is also included in the current kernel version. Please forward to bugzilla from xorg.
See Bug #189471. Depends on radeon drm 1.24 in kernel and ati driver Xorg. Works for me with the versions given in Bug 189471.