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): xscreensaver-gl-extras-5.00-7.1.fc6 How reproducible: Always. Steps to Reproduce: 1. Choose a "xscreensaver-gl-extras" module and lock the screen. 2. Hit a key. 3. Click "Cancel". Actual results: The unlock dialog goes away, but the screen remains black. Expected results: The chosen screensaver should set in again. Additional info: For the standard "gnome-screensaver" modules, everything works as expected.
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.
Umm.. 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: "xscreensaver-gl-extras-5.00-7.1.fc6 gnome-screensaver-2.15.3-1 rss-glx-gnome-screensaver-0.8.1.p-3.fc6" 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 respawned again. 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 symptoms. 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 reported upstream: https://bugzilla.freedesktop.org/show_bug.cgi?id=6357
Thanks Joachim, (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 for now. > 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: https://bugs.freedesktop.org/show_bug.cgi?id=6357
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. xorg-x11-drv-savage-2.1.1-5.fc6 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: https://bugs.freedesktop.org/attachment.cgi?id=7041 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; https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=195851#c6 , and here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=195851#c10 . 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 updated "DRM".