Red Hat Bugzilla – Bug 66917
xscreensaver changes gamma ramps
Last modified: 2007-04-18 12:43:15 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020513
Description of problem:
when xscreensaver starts a screensaver, code in fade.c changes the gamma
correction to a standard set, and doesn't restore the original settings when the
screensaver is deactivated.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. configure gamma settings on a monitor
2. allow a screensaver to activate
3. disengage the screensaver, the gamma settings have changed
Expected Results: The original gamma settings should be restored.
Attached is a patch to 3.33-4 that corrects the problem. Can this be rolled
into the distro going forward? Is there a chance to make this part of an
official errata, if another one is released for 7.1/7.2?
Also note that the full body of an email will be attached in subsequent events
for this bug.
Created attachment 61444 [details]
text file of email thread, explaining bug analysis
Created attachment 61445 [details]
patch to provide gamma ramp restoration on close of screensaver
As far as I can tell, xscreensaver *does* restore the previous gamma setting,
and has ever since the gamma ramp code was introduced in 3.34.
The above patch basically calls XF86VidModeGetGammaRamp, remembers the value
statically, and restores it afterward. But the code *already did* that:in
xf86_gamma_fade, line 33, "Get the current gamma maps for all screens.".
Then, in the body of the function, xf86_whack_gamma is called, setting the gamma
ramps to progressive *percentages* of their original values until it reaches 0%
or 100% (depending.)
Just about the last thing that happens in the function line 780, after the
"DONE:" tag), it calls xf86_whack_gamma for each screen with 100% -- setting the
gamma values not to 100% intensity, but to 100% *of their initial value*, that
is, the value they had before this function was called.
So, it's possible there is a logic error in this function somewhere that I
haven't seen by reading it, or in my testing (it does, in fact, set the gamma
ramps back to their original values for me) but the above patch is definitely
wrong, since it just duplicates logic that the existing code is already doing.
Tested against 4.05, but my cvs logs show no changes (except a missing ifdef)
since xscreensaver 3.34, "2001/10/25".
This bug is quite old now. Given the lack of activity on this report and the
likelihood that this bug has already been fixed, I am going to close it. If you
encounter the problem discussed in this report with Fedora Core 3 or a recent
version of xscreensaver, feel free to reopen.