Bug 13677

Summary:

Fedora 8 / Xorg 7.3 - VT switch yields all-white screen on ATI Mobility 7500

Product:

xorg

Reporter:

Erez Hadad <erez.hadad>

Component:

Driver/Radeon

Assignee:

xf86-video-ati maintainers <xorg-driver-ati>

Status:

RESOLVED INVALID

QA Contact:

Xorg Project Team <xorg-team>

Severity:

normal

Priority:

medium

CC:

erez.hadad

Version:

7.3 (2007.09)

Keywords:

regression

Hardware:

x86 (IA32)

OS:

Linux (All)

Whiteboard:

i915 platform:

i915 features:

Attachments:

Description	Flags
A zip of confs and logs of the original problem on Fedora 8	none
Fedora Core 2 conf and log - without the problem	none
Log with line 4040 commented	none
Log with both 4039 and 4040 commented	none
Log with only 4039 commented	none
Xorg.0.log of driver from git master (in response to comment #8)	none

Description Erez Hadad 2007-12-15 13:26:47 UTC

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

Comment 1 Erez Hadad 2007-12-15 13:27:47 UTC

Created attachment 13129 [details]
A zip of confs and logs of the original problem on Fedora 8

Comment 2 Erez Hadad 2007-12-15 13:32:03 UTC

Created attachment 13130 [details]
Fedora Core 2 conf and log - without the problem

Comment 3 Alex Deucher 2007-12-16 10:29:24 UTC

Does commenting out line 4040 (OUTREG(RADEON_LVDS_PLL_CNTL, restore->lvds_pll_cntl);) of radeon_driver.c from ati git master help?

Comment 4 Erez Hadad 2007-12-18 08:51:49 UTC

(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.

Comment 5 Erez Hadad 2007-12-18 08:53:41 UTC

Created attachment 13186 [details]
Log with line 4040 commented

Comment 6 Erez Hadad 2007-12-18 08:54:45 UTC

Created attachment 13187 [details]
Log with both 4039 and 4040 commented

Comment 7 Erez Hadad 2007-12-18 08:55:09 UTC

Created attachment 13188 [details]
Log with only 4039 commented

Comment 8 Alex Deucher 2007-12-23 22:17:33 UTC

Can you try again with ati git master (commit 653da558148cc601bc1f80253e92ef98c75ef37a)?

Comment 9 Erez Hadad 2007-12-24 02:56:50 UTC

(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.

Comment 10 Erez Hadad 2007-12-24 03:03:14 UTC

Created attachment 13338 [details]
Xorg.0.log of driver from git master (in response to comment #8)

Comment 11 Steven Barrett 2007-12-30 17:02:35 UTC

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.

Comment 12 Alex Deucher 2008-12-03 00:59:19 UTC

Is this still an issue with a newer driver (6.9.0 or newer)?

Comment 13 Erez Hadad 2008-12-03 01:18:07 UTC

(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.

Comment 14 Corbin Simpson 2010-03-26 19:16:44 UTC

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.