Red Hat Bugzilla – Bug 196011
"xscreensaver-gl-extras" does not set in after canceling the unlock dialog.
Last modified: 2007-11-30 17:11:35 EST
Description of problem:
When one of the "xscreensaver-gl-extras" sets in and the user hits a
key, the standard unlock dialog appears. If one decides to abort the
operation by clicking the "Cancel" button, the unlock window
disappears. However, the screensaver which has been inactive during
the dialog does not set in anymore. One sits in front of a screen
that is plain black.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Choose a "xscreensaver-gl-extras" module and lock the screen.
2. Hit a key.
3. Click "Cancel".
The unlock dialog goes away, but the screen remains black.
The chosen screensaver should set in again.
For the standard "gnome-screensaver" modules, everything works as
Do you mean that you lock the screen by one xscreensaver-gl-extras hack under
gnome-screensaver locking mechanism?
There is no "Cancel" button on xscreensaver unlock screen.
I just installed gnome-screensaver(-2.15.3-1), launched gnome-screensaver,
chose one xscreensaver-gl-extras hack, locked the screen by the hack,
and pushed one button and the unlock dialog appeared.
Then I chose "Cancel" button, and the hack launched normally (perhaps
as expected), i.e. I cannot reproduce this.
(In reply to comment #1)
Right, "rpm -qa | grep saver" returns:
In particular, "xscreensaver-base-5.00-7.1.fc6" is -not- installed.
I tried a couple of hacks, e.g. "juggler3d". None of them works.
I am using an "IBM ThinkPad T23" which sports a "SuperSavage/IXC 64"
chip. My installed system is -current- Fedora Core rawhide. Maybe
yours is FC5?
No, I always uses current rawhide, i.e. xscreensaver-??-5.00-7.1.fc6 and
I cannot still reproduce this. When I use gnome-screensaver and cancel
unlocking on gnome-screensaver unlock dialog, GL hack of xscreensaver is
My question is, then, when you cancelled unblanking on gnome-screensaver-dialog,
GL xscreensaver hack is disappeared on process table (by the crash of the hack
or something else)? Or, GL xscreensaver hack is still activated according to
process table, however, it cannot be seen on a screen? Please check
it byswitching to CUI when locking the screen on GUI.
The process "juggler3d" actually continues running. Btw, even "rawhide"
does not necessarily equal "rawhide". It can also depend on the update
cycle after the base install. An example is breakage of "xscreensaver"
after updates of "gnome-screensaver". I installed my "rawhide" system
last Sunday starting from a minimum FC5 install, because the "HTTP"
install mode is currently broken.
The "rawhide" installer should work again in a couple of days. If will
then report my results from a fresh install from the "rawhide" tree.
Umm.. when the process of GL xscreensaver hack is present, I feel like
this is due to "gnome-screensaver-dialog" behavior, which I don't know well.
Anyway, I will wait for your report.
No change after a fresh FC6T1 plus rawhide install as of 06/22/06. I had
removed all "GNOME" related dot-files and dot-directories to make sure
that there was really no interference with my previous setup.
I cannot still figure out what is occurring to you. FC6T1 + FE-devel seems no
problem to me.
A. Is GL xscreensaver hack "running" (not stopped) when gnome-screensaver unlock
dialog (/usr/libexec/gnome-screensaver-dialog) quitted?
B. How about GL rss-glx hacks? I have no problem with rss-glx, either.
C. How abour non-GL xscreensaver hacks (in xscreensaver-extras)?
I suspect that your chipset is doing something wrong with GL programs.
My system is an "IBM ThinkPad T23", and the graphics chipset is a
"SuperSavage/IXC 64". Hardware rendering is working albeit comparatively
slowly. The standard "non-GL" screensavers all work normally, e.g.
"Fedora Floating Bubbles" or "Compass" from "xscreensaver-extras".
The "GL" screensavers from "rss-glx" or "xscreensaver-gl-extras" exhibit
several flaws reported in this report, in Bug #195851, and in Bug #195854.
Today, I will upgrade my desktop system at home which is equipped with a
Radeon 7200 chipset to verify if the issue is definitely driver specific.
Btw, I have also observed that sometimes multiple instances of a
particular "GL" hack are running, or one instance when there should
be none, e.g. after after having chosen a "GL" module and having quit
the preferences dialog.
Ok, this seems to a driver issue. On my desktop system which sports a
"Radeon 7200" chipset based graphics card, the lock dialog behaves
correctly after installing "FC6T1" plus "rawhide" updates.
Okay. Then I reassign this bug to xorg-x11-drv-savage maintainer.
joachim: In your initial report, what specific hardware were you using,
and is your statement from comment #11 indicating now that the problem has
been resolved in more recent rawhide updates?
I ask, because comment #11 suggests that your original report is about
a problem on radeon hardware, while Mamoru is claiming to have the same
(or similar) problem on Savage hardware. It is possible that the two
issues are the same problem, but it is also possible that they are two
completely different problems on different hardware, which have similar
I'd like to clarify that before proceeding further.
The original bug report was for an "IBM ThinkPad T23" which features a
"SuperSavage/IXC 64" (chip id: 0x8c2e). Here, the issue is still present
for "development" plus "extras-development" as of 2006-06-27. Direct
rendering is essentially working though.
I added comment #11 after also ugrading my desktop system to "FC6T1"
plus "rawhide" in order to check if the problem was driver related.
The latter is equipped with a "Radeon AIW 7200 PCI" sporting an R100
chip. Since the "Radeon" card is not afflicted by the issue reported
above, I could essentially rule out a bug in "xscreensaver-gl-extras"
and changed the component to "xorg-x11-drv-savage".
A possibly related observation concerns "glxgears" which only produces
a black window for current "Xorg" 7.1 (release 7.0 used to work though).
The system load jumps to 100%, the process is running, but no "FPS"
value is ever written to the console. The issue has already been
(In reply to comment #14)
> The original bug report was for an "IBM ThinkPad T23" which features a
> "SuperSavage/IXC 64" (chip id: 0x8c2e). Here, the issue is still present
> for "development" plus "extras-development" as of 2006-06-27. Direct
> rendering is essentially working though.
If you comment out the 'Load "dri"' line in xorg.conf, and reboot the
system, and start X up again, does the problem also occur with DRI now
disabled? This would help to determine if it is a generic DRI issue, or
a driver specific issue, although I suspect it is hardware specific
> I added comment #11 after also ugrading my desktop system to "FC6T1"
> plus "rawhide" in order to check if the problem was driver related.
> The latter is equipped with a "Radeon AIW 7200 PCI" sporting an R100
> chip. Since the "Radeon" card is not afflicted by the issue reported
> above, I could essentially rule out a bug in "xscreensaver-gl-extras"
> and changed the component to "xorg-x11-drv-savage".
Yep, it appears so far to be limited to savage hardware, and possibly
to your specific chip. It could be a problem in xorg-x11-drv-savage,
or the savage_dri 3D driver, or the associated kernel module. Hopefully
with some further troubleshooting on your part, we can narrow this down.
I've reviewed the upstream bug report linked above also and CC'd myself
on it. Here is the canonical URL:
After commenting out 'Load "dri"' in "xorg.conf" and restarting the "X"
server but without rebooting the system, the screensaver behaves correctly.
Moreover, "glxgears" works again, albeit at an (expected) slow frame rate.
Add to FC6Destop tracker
I've implemented a workaround in the driver, but have no savage hardware
to test it on. The workaround disables DRI by default on the chip reported
here, as well as the rest of the chips reported to not work properly in the
upstream bug report.
Please test the new driver and use a new default config file generated
by "system-config-display --reconfig", then indicate if the problem still
occurs or not, and wether or not DRI is properly getting disabled in the
log file. If the problem persists still, please attach the X server log
and config from the new testing as individual uncompressed file attachments
using the link below.
Thanks in advance.
There exists an upstream patch by A. Deucher:
which fixes the issue for me! The nice thing is that it also fixes bug 195851.
I have adapted the patch to "xorg-x11-drv-savage-2.1.1-5.fc6" (see attachment).
Created attachment 136548 [details]
Patch that fixes RH #196011, RH #195851, and FD #6357
Not only does M. Harris' patch from comment #19 not disable "DRI"
which was undesirable anyway, but my patch of comment #21 which
also applies to bug 195851 has still not been incorporated :o/
Therefore reopening bug 196011.
"Fedora Development" has moved to "Xorg 7.2", and the issue only affects
the "savage" driver, version 2.1.1 delivered with "Xorg 7.1". Therefore,
setting the version to "fc6". However, this does not mean that this annoying
bug is not worth being fixed, in particular since a working patch had been
submitted in comment #21 *half*a*year* ago!
I am really sorry for missing this patch -- somehow it never made it to the Xorg
development team; reassigning and we will deal with this bug promptly.
(In reply to comment #24)
I'm sorry to contradict you: the issue has been brought to the attention
of the "X" maintainers several times. The corresponding report can be
found at bug 195851 which is currently assigned to A. Jackson who even
modified the summary. I guess he had reasons for not applying the patch
submitted above and to which I have referred repeatedly, namely here;
Thus, I would rather ask 'ajax' first if he accepts the suggested patch.
Fixed in "xorg-x11-drv-savage-2.1.2-3.fc6" and recent kernels with