I have a laptop (Compaq Evo N1000v) with a graphics card of ATI Technologies Inc Radeon Mobility M7 LW [Radeon Mobility 7500] with 32MB memory. I'm running Fedora 8, and the auto-installed X driver is "radeon". The kernel version (although it updated several time with no improvement) is 2.6.23.8-63.fc8 and the Xorg server version is 7.3 (Xorg 1.3.0). My problem is that whenever I switch from the default graphics mode (1400x1050@60Hz) to any other mode, and specifically to text mode, the LCD screen displays a white stain that expands and engulfs the entire screen, making it completely white (kind of a fade-to-white effect). However, when I switch back to graphics mode, the display is resumed perfectly with the graphic desktop environment. The machine does not freeze or crash. To make sure this is not a hardware problem, I ran X with the "vesa" driver, and it worked smoothly for all mode switch operations, although this driver yields (not surprisingly) lower performance in 3D, as I measured with the glxgears app. I attached the configuration and the log files of both vesa and radeon. One thing I noted is that the radeon driver operates on all 3 outputs of the card: the LVDS (which I believe is the LCD screen), the CRT (the external VGA connector) and the TV (which is the external S-Video connector). I also inserted "@@@@@" strings in the logs at the places where the mode-switch took place. It seems that the "radeon" driver performs "RESTORE" operations on all the outputs when it comes back to graphics mode. However, when it switches to text mode, it does not "RESTORE" the LVDS, just the TV and CRT outputs (I think). Can this be somehow attributed to the fade-to-white problem I mentioned above? Alternatively, can anyone suggest a way to make the "radeon" driver work properly? Note that the "vesa" driver does not log any meaningful operation on the graphics card at all during mode switch - just switch the Synaptics touchpad on and off. I have also tried various combinations (from man-pages and web sites) of both radeon-specific and generic options in the xorg.conf. None of these combinations solved my problem. Last but not least: the "ati" driver has the same problem as the "radeon" driver. Recent updates, thanks to Alex Deucher: - The most recent git version has the same problem - Reverting commit 80eee856938756e1222526b6c39cee8b5252b409 doesn't help (it's a report about a similar problem on a BSD that got fixed using that version, but not on my platform) - On Fedora Core 2 (kernel version 2.6.10-1.771_FC2 and X server is Xorg 6.7.0-14) the problem does not occur. I also attach a zip of the logs/confs there. - This bug resembles bug 13533 https://bugs.freedesktop.org/show_bug.cgi?id=13533
Created attachment 13129 [details] A zip of confs and logs of the original problem on Fedora 8
Created attachment 13130 [details] Fedora Core 2 conf and log - without the problem
Does commenting out line 4040 (OUTREG(RADEON_LVDS_PLL_CNTL, restore->lvds_pll_cntl);) of radeon_driver.c from ati git master help?
(In reply to comment #3) > Does commenting out line 4040 (OUTREG(RADEON_LVDS_PLL_CNTL, > restore->lvds_pll_cntl);) of radeon_driver.c from ati git master help? > This modification changes something, but doesn't fix the problem. With this modification, the screen becomes all-white at once instead of the fade-like effect that was before. I attached the log in attachment #3 [details] [review]. Also, I tried commenting line 4039 w/ and wo/ 4040, but this causes the screen to simply blank at VT switch. As always, the screen is properly restored when switching back to graphics mode. I attached the logs for 4039+4040 and 4039 alone in attachments 4 and 5, respectively.
Created attachment 13186 [details] Log with line 4040 commented
Created attachment 13187 [details] Log with both 4039 and 4040 commented
Created attachment 13188 [details] Log with only 4039 commented
Can you try again with ati git master (commit 653da558148cc601bc1f80253e92ef98c75ef37a)?
(In reply to comment #8) > Can you try again with ati git master (commit > 653da558148cc601bc1f80253e92ef98c75ef37a)? > First, there was an update to both kernel and xorg driver (probably following the announcement on the xorg-ati list). I applied the update and got back to square 1, that is, switching to text mode creates a fade-to-white effect and the display is resumed only when switching back to graphics. Current kernel version: 2.6.23.9-85.fc8 Current xorg-ati version: xorg-x11-drv-ati-6.7.196-2.fc8 Second, git revert 653da558148cc601bc1f80253e92ef98c75ef37a does not work ("Could not find ...") So I started clean and did "git clone", rebuilt and installed the driver. Still the exact same effect of fade-to-white. I attached the log. Last, I have a few questions, given that the old FC2 driver works perfectly: 1. is it possible to read back register values that were previously written to the card? 2. If the answer to 1 is "yes", can I add an option to the xorg.conf to make it read and display all register values in the log after every write? If the answer to both questions is "yes", then using a remote console I can simply compare the register values after switching to text mode (in FC2 and F8), and immediately provide the correct values that need to be written. 3. I noticed that my kernel version is SMP although I have only one processor (old P4 2.2GHz). Can this have anything to do with the display problem? This is just a long shot.. 4. What are PLL values? There's a mail in the list (from "Yanick..") which suggests that if we make the driver compute PLL values instead of relying on the BIOS there's a good chance the problem may be solved. I tried the setting of "IgnoreEDID" "on" and "LVDSProbePLL" "off" but nothing changes the problem.
Created attachment 13338 [details] Xorg.0.log of driver from git master (in response to comment #8)
I have the same problem that you do. However, I also experience the same effect changing resolutions in X itself. I found out that the Option "XaaNoOffscreenPixmaps" or using EXA for acceleration causes the fade to white effect if enabled.
Is this still an issue with a newer driver (6.9.0 or newer)?
(In reply to comment #12) > Is this still an issue with a newer driver (6.9.0 or newer)? > Hi Alex. I am about to install F10 (+ latest updates) on my laptop sometimes in the next 10 days (until next weekend). When I'm done installing, I'll check the driver for VT behavior and let you know.
Closing as Fedora now has KMS deployed for this hardware. Reopen if this is still an issue.
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.