Bug 107270 - Please turn off OpenGL screensavers by default
Please turn off OpenGL screensavers by default
Product: Fedora
Classification: Fedora
Component: xscreensaver (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ray Strode [halfline]
: FutureFeature
: 107271 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2003-10-16 08:44 EDT by Ed Hill
Modified: 2007-11-30 17:10 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-01-16 14:53:23 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Ed Hill 2003-10-16 08:44:39 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.7 (X11; Linux i686; U;) Gecko/20030131

Description of problem:
The default screen saver setting in past versions of Red Hat is *lousy* because
the following often happens:

  1) it randomly cycles through the default list which includes
     all screen savers

  2) on many machines the OpenGL drivers are flaky

  3) after some (random) time period, an OpenGL screen saver is 
     run which exercises the flaky OpenGL driver and causes a 

  4) the (often inexperienced) user then can't figure out why 
     his/her workstation has locked up while they were *away* 
     from the machine.

Note that this is a fairly common scenario.  See bugs:

Please do one or more of the following:

  1) turn off OpenGL screensavers by default

  2) warn users about the above when they explicitly turn on 
     OpenGL screen savers


Version-Release number of selected component (if applicable):
Please disable OpenGL screensavers by default

How reproducible:

Steps to Reproduce:
1. see above

Additional info:
Comment 1 Bill Nottingham 2003-10-16 13:58:58 EDT
*** Bug 107271 has been marked as a duplicate of this bug. ***
Comment 2 Bill Nottingham 2003-10-16 14:19:36 EDT
I think the logical answer here is to fix the X and kernel bugs.
Comment 3 Ed Hill 2003-10-16 15:46:24 EDT
Your "logical answer" disregards a few very important practical concerns:

  1) xscreensaver is silly eye-candy, not critical infrastructure
  2) by design, it generally runs when the user isn't present so 
     it can be mighty difficult (read: fustrating) to diagnose 
     the problem
  3) its very easy to fix pointless defaults but its a lot more 
     difficult to fix OpenGL drivers
Comment 4 Bill Nottingham 2003-10-16 16:07:08 EDT
But, if the issues are constantly worked around, the OpenGL drivers will never
get fixed, which is bad for general use.

Note that the bugs referenced are all for 8.0 and earlier. Do you have recent
issues caused by this?
Comment 5 Ed Hill 2003-10-16 19:17:02 EDT
Ok, I do agree that it would be nice to have the kernel and OpenGL bugs
seen and worked on.

But this is an idiotic way to go about it.  Do you *really* think its 
best to have the machine lockup when it is, almost by definition, 
unattended?  Wouldn't you rather see the OpenGL lockups happen when 
the user is present, running an interactive OpenGL application, and 
able to:

  1) see it happen,
  2) *easily* and *quickly* reproduce it (remember, the screen saver
     cycles randomly and only unattended), and 
  3) most of all -- *SEE* the connection between the lockup and whats 
     causing it.

I mean, trying to promote OpenGL testing through the screen saver is 
just perversely stupid.
Comment 6 Bill Nottingham 2003-10-16 21:31:06 EDT
That's not the *goal*, it's just a side comment. Saying 'oh, fixing the drivers
is *hard*, so we should just paper around it' is also obtuse.

My second point still stands. The bugs you quoted are all from two releases ago.
Are there current issues you're trying to work around?
Comment 7 Ed Hill 2003-10-16 21:57:25 EDT
Unfortunately, it does happen fairly often because theres a lot
old and/or oddball video cards out there.  I've run across it at 
least twice at my old lab (using both RH 8 and 9) and heres a much 
more recent example:


And I haven't had a chance to install fedora-core but I will be trying 
it soon.
Comment 10 Bill Nottingham 2003-10-16 22:16:49 EDT
The trilug comment mentioned is for Red Hat Linux 8.0 as well, FWIW.

The message from alan@clueserver.org is completely unrelated to DRI; the SIGALRM
loop has happened in various drivers from time to time with *2D* accel (notably
the NeoMagic driver).

The bug referenced in 84214 is reported on a driver that doesn't even *have* 3D
Comment 11 Bill Nottingham 2003-10-16 22:22:05 EDT
I'm not saying that there *aren't* problems in Fedora; I just want to make sure
that there actually *are* problems before debating what action to take.
Comment 12 Ed Hill 2003-10-16 22:45:41 EDT
Ok, thats cool.  Back at my old lab, I had two machines that would 
pretty reliably lock-up when using the default screen saver in RH 
8 & 9.  It was fustrating since those machines were used for control 
and data acquisition (http://cesep.mines.edu/facilities.htm).

In any case, I'm at a new lab and no longer have direct access to 
those machines.  I will be installing fedora-core soon and will make 
sure to submit further bugs when I have more problems.
Comment 13 Bevan Bennett 2004-02-23 15:14:03 EST
I am still having 'GL screensavers lock desktop' issues in Fedora Core
1 with several of my users. 

I would very much like there to be an easy way to identify and disable
just the GL-based screensavers. Not only would it help provide a
'quick fix' for users whose systems randomly crash (Some of them
stubbornly resist switching to a single, known-safe screensaver
because they "like variety"), but I can think of several other
situations where one might want to avoid graphics-heavy screensavers.

Yes, we want to fix the real bugs, but that seems to be more
complicated than once thought.  I absolutely second the need for the
screensaver configuration tool to have an easy way to deselect all
GL-based screensavers (and would prefer to make it the default).  At
the very least we need some way to be able to tell which screensavers
are GL-based, as not all of them have 'GL' in their name anymore and
it's rather labor intensive to go through the hundreds of options one
by one.
Comment 14 Nico Kadel-Garcia 2004-05-06 14:03:43 EDT
Are you folks by any chance using NVidia cards with the added-on 
NVidia kernel modules and OpenGL libraries, or using NVidia cards 
*without* the NVidia modules? NVidia keeps their souce on their 
OpenGL libraries closed, which makes this kind of thing quite 
difficult to repair.

It's helpful to have the ability to turn off OpenGL as a class, 
especially when the tool is operating unattended and OpenGL has 
established itself as so untrustworthy in this context. Perhaps the 
list of available screen savers could lest the OpenGL based ones as a 
different color, or in a slightly different font, so we know what 
we're picking and choosing among
Comment 15 Aaron Schlaegel 2004-07-26 12:33:57 EDT
I would like to see all of the GL screensavers take names like
GLMatrix. Most of them do, but some of them have regular names like

The problem is not that GL locks up, this was fixed a few releases
ago. The problem is that GL goes horribly slow, even on my brand new
system. This eats the CPU and gives the impression that Linux and
Redhat are slow.

I recommend moving the GL screensavers to a separate rpm.
Comment 16 Nick Richards 2004-10-03 13:48:12 EDT
Another voice asking if the GL screensavers could be either off or
removable. As for GL drivers breaking: bug 127731 is one I suffer
from. As noted above the pernicious thing is that the error will
*always* occur when the user isn't at the computer. I consider myself
fairly experienced at this sort of thnig and even then it took me a
little while to pin down the DRI driver as the problem.
Comment 17 Ray Strode [halfline] 2005-01-16 14:53:23 EST
Rawhide currently splits xscreensaver up into multiple packages.  One
of those packages is xscreensaver-gl-extras which contains all the
OpenGL screensavers.

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