00:00.0 Host bridge [0600]: ATI Technologies Inc RS480 Host Bridge [1002:5950] (rev 01)
	Subsystem: Hewlett-Packard Company Device [103c:3009]
01:05.0 VGA compatible controller [0300]: ATI Technologies Inc RS480 [Radeon Xpress 200G Series] [1002:5954]
	Subsystem: Hewlett-Packard Company Device [103c:3009]

Created attachment 34561 [details]
XorgLogOld.txt

Created attachment 34562 [details]
XorgLog.txt

Created attachment 34563 [details]
CurrentDmesg.txt

Created attachment 34564 [details]
BootDmesg.txt

Created attachment 34565 [details]
regdump_good.txt

Created attachment 34566 [details]
regdump_bad.txt

Created attachment 34567 [details]
regdump.diff

This kms drm patch may help for the kms case:
http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=d805f50aa1d9eef63fec356b2be557e2da3cd643

This might be related to other reports about the CLUT not getting properly restored after VT switching away from the X server while the screensaver is doing its fade-out effect. Does something like

xgamma -gamma 1.0

restore the proper display?

(In reply to comment #10)
> Does something like
> 
> xgamma -gamma 1.0
> 
> restore the proper display?

Yes it does. 

(In reply to comment #10)
> This might be related to other reports about the CLUT not getting properly
> restored after VT switching away from the X server while the screensaver is
> doing its fade-out effect. Does something like
> 
> xgamma -gamma 1.0
> 
> restore the proper display?
> 

The binary fglrx driver is also affected by this bug. And also here xgamma -gamma 1.0 saves the day. So does this mean that the problem lies with the X server? And is there anyway distro's can workaround this bug till it's get fixed? 

(In reply to comment #12)
> The binary fglrx driver is also affected by this bug. And also here xgamma
> -gamma 1.0 saves the day. So does this mean that the problem lies with the X
> server?

Yes, there have also been reports with the intel driver. Reassigning, this should probably also block the xserver 1.8 blocker bug, if there was one...

A workaround we could apply at the distro level would be very helpful.

*** Bug 27505 has been marked as a duplicate of this bug. ***

Problem seems to be to be commented out option xf86HandleColormaps.

Bool drmmode_setup_colormap(ScreenPtr pScreen, ScrnInfoPtr pScrn)
{
    xf86DrvMsgVerb(pScrn->scrnIndex, X_INFO, RADEON_LOGLEVEL_DEBUG,
                  "Initializing kms color map\n");
    if (!miCreateDefColormap(pScreen))
        return FALSE;
    /* all radeons support 10 bit CLUTs */
    if (!xf86HandleColormaps(pScreen, 256, 10,
                             drmmode_load_palette, NULL,
                             CMAP_PALETTED_TRUECOLOR
#if 0 /* This option messes up text mode! (eich@suse.de) */
                             | CMAP_LOAD_EVEN_IF_OFFSCREEN
#endif
                             | CMAP_RELOAD_ON_MODE_SWITCH))
         return FALSE;
    return TRUE;
}


If I enable the disabled option lut is restored correctly when
switching back from VT.

But there is still problem that lut is not restored when switching
away from xserver. So this is not correct fix to the problem.

(In reply to comment #14)
> A workaround we could apply at the distro level would be very helpful.

I doubt finding a workaround in the server would be significantly easier than fixing the problem in the first place.

*** Bug 27821 has been marked as a duplicate of this bug. ***

I'm pretty sure this is fixed now.

Could you let us know whether this is fixed in the 1.12.x branch, or the 1.11.x branch of xserver? (A pointer to the relevant git commit would be nice as well.)

I am currently running Debian Sid with xserver 1.11.3, and the bug is still present. When I change to a virtual terminal from the X server while gnome-screensaver is fading out, the virtual terminal is also faded. (Please see my duplicate Bug 27821 for a detailed explanation of how to reproduce this bug.)

I can confirm this is still a bug running gentoo with  1.12.2

I don't think this old bug is an issue anymore.