Bug 107270

*** 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 
     the problem
  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 
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.

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:

http://www.trilug.org/pipermail/trilug/Week-of-Mon-20031006/020829.html

And I haven't had a chance to install fedora-core but I will be trying 
it soon.

http://www.redhat.com/archives/fedora-test-list/2003-October/msg01802.html

http://www.redhat.com/archives/fedora-test-list/2003-October/msg00983.html

The trilug comment mentioned is for Red Hat Linux 8.0 as well, FWIW.

The message from alan 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
acceleration.

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
by 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
Queens.

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
OpenGL screensavers.