Bug#686971: [radeon] display unwantingly dimmed, dimming state leaking across VT switch

[Alex Deucher]

On Fri, Sep 7, 2012 at 3:45 PM, Yann Dirson <ydirson at free.fr> wrote:
> Package: xserver-xorg-video-radeon
> Version: 1:6.14.4-5
> Severity: normal
>
> What I can easily reproduce:
>
> Running "xscreensaver-command -activate", and hitting Ctrl-Alt-F1
> while it is fading away leaves me on a dimmed tty1.  Switching to
> other text consoles does not change the dimming.  Switching back to my
> X session shows correct luminosity, and it I then go back to text
> consoles they are OK as well.  Not so important if it were not for the
> original problem, which is not so easy to reproduce:
>
> (I was told) there was a Ctrl-alt-Fn console switch while xscreensaver
> was fading out my X display.  When I went back and switched back to my
> own session, my display was dimmed, while other X displays were not
> when I switched to them.  When I switched to a text console, it was
> dimmed when I switched from my dimmed X, and was not dimmed when I
> switched from the other, non-dimmed, ones.
>
> A quick look at utils/fade.c in the xscrensaver source shows it is
> possibly using xf86vidmode for the fading operation, so I went looking
> for a tool to query the xf86vm settings, but found none.  The closest
> I found was xcalib, but I could not have anything queried with it
> either.  Eventually I guessed right with "xcalib -a -c" and everything
> was back in good shape, but less stubborn ones would have rebooted
> their machines like a windows box long before...
>
> The "leaking dim state" makes me guess the problem would be more in
> the radeon side of things, rather than at the xf86vm level, but that's
> a wild guess only...
>

The fade effect is done by adjusting the gamma.  When you switch VTs,
just the display base address is changed.  The gamma is not changed.
I suspect this may affect other drivers as well so probably needs to
be fixed in common code.

Alex