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
Steps to Reproduce:
1. see above
*** Bug 107271 has been marked as a duplicate of this bug. ***
I think the logical answer here is to fix the X and kernel bugs.
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
3) its very easy to fix pointless defaults but its a lot more
difficult to fix OpenGL drivers
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?
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
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
I mean, trying to promote OpenGL testing through the screen saver is
just perversely stupid.
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?
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
The trilug comment mentioned is for Red Hat Linux 8.0 as well, FWIW.
The message from email@example.com 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
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.
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.
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
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
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.
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.
Rawhide currently splits xscreensaver up into multiple packages. One
of those packages is xscreensaver-gl-extras which contains all the