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

[bugzilla-daemon at freedesktop.org]

http://bugs.freedesktop.org/show_bug.cgi?id=13677


erez.hadad at gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |erez.hadad at gmail.com




------- Comment #9 from erez.hadad at gmail.com  2007-12-24 02:56 PST -------
(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.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.