Bug 66917 - xscreensaver changes gamma ramps
xscreensaver changes gamma ramps
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: xscreensaver (Show other bugs)
7.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Ray Strode [halfline]
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-06-18 14:13 EDT by Curtis Zinzilieta
Modified: 2007-04-18 12:43 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-11-10 15:09:21 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
text file of email thread, explaining bug analysis (3.22 KB, text/plain)
2002-06-18 14:16 EDT, Curtis Zinzilieta
no flags Details
patch to provide gamma ramp restoration on close of screensaver (5.07 KB, patch)
2002-06-18 14:18 EDT, Curtis Zinzilieta
no flags Details | Diff

  None (edit)
Description Curtis Zinzilieta 2002-06-18 14:13:19 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):


How reproducible:
Always

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.

Additional info:

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.
Comment 1 Curtis Zinzilieta 2002-06-18 14:16:46 EDT
Created attachment 61444 [details]
text file of email thread, explaining bug analysis
Comment 2 Curtis Zinzilieta 2002-06-18 14:18:40 EDT
Created attachment 61445 [details]
patch to provide gamma ramp restoration on close of screensaver
Comment 3 Jamie Zawinski 2002-07-27 03:14:14 EDT
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".
Comment 4 Ray Strode [halfline] 2004-11-10 15:09:21 EST
Hi,

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.

Thanks

Note You need to log in before you can comment on or make changes to this bug.