Bug 196011 - "xscreensaver-gl-extras" does not set in after canceling the unlock dialog.
"xscreensaver-gl-extras" does not set in after canceling the unlock dialog.
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-savage (Show other bugs)
6
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Adam Jackson
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-06-20 07:15 EDT by Joachim Frieben
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-10-20 15:46:28 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Patch that fixes RH #196011, RH #195851, and FD #6357 (1.85 KB, text/plain)
2006-09-18 12:21 EDT, Joachim Frieben
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
FreeDesktop.org 6357 None None None Never

  None (edit)
Description Joachim Frieben 2006-06-20 07:15:02 EDT
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.
Comment 1 Mamoru TASAKA 2006-06-20 07:37:18 EDT
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.
Comment 2 Mamoru TASAKA 2006-06-20 08:01:14 EDT
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.
Comment 3 Joachim Frieben 2006-06-20 08:16:27 EDT
(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?
Comment 4 Mamoru TASAKA 2006-06-20 09:07:30 EDT
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.

Comment 5 Joachim Frieben 2006-06-20 10:01:04 EDT
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.
Comment 6 Mamoru TASAKA 2006-06-20 10:15:05 EDT
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.
Comment 7 Joachim Frieben 2006-06-22 13:06:20 EDT
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.
Comment 8 Mamoru TASAKA 2006-06-23 00:26:32 EDT
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.
Comment 9 Joachim Frieben 2006-06-23 03:36:42 EDT
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.
Comment 10 Joachim Frieben 2006-06-23 03:41:16 EDT
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.
Comment 11 Joachim Frieben 2006-06-24 08:29:56 EDT
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.
Comment 12 Mamoru TASAKA 2006-06-24 09:46:56 EDT
Okay. Then I reassign this bug to xorg-x11-drv-savage maintainer.
Comment 13 Mike A. Harris 2006-06-27 11:06:58 EDT
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.


Comment 14 Joachim Frieben 2006-06-27 11:50:06 EDT
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".
Comment 15 Joachim Frieben 2006-06-28 03:13:04 EDT
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
Comment 16 Mike A. Harris 2006-07-06 03:14:52 EDT
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

Comment 17 Joachim Frieben 2006-07-06 14:33:24 EDT
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.
Comment 18 Matthias Clasen 2006-07-06 17:53:42 EDT
Add to FC6Destop tracker
Comment 19 Mike A. Harris 2006-07-24 23:15:58 EDT
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.
Comment 20 Joachim Frieben 2006-09-18 12:18:53 EDT
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).
Comment 21 Joachim Frieben 2006-09-18 12:21:21 EDT
Created attachment 136548 [details]
Patch that fixes RH #196011, RH #195851, and FD #6357
Comment 22 Joachim Frieben 2006-10-15 07:54:06 EDT
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.
Comment 23 Joachim Frieben 2007-04-02 01:58:17 EDT
"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!
Comment 24 Matěj Cepl 2007-04-02 09:54:01 EDT
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.
Comment 25 Joachim Frieben 2007-04-02 10:06:42 EDT
(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.
Comment 26 Joachim Frieben 2007-10-20 15:46:28 EDT
Fixed in "xorg-x11-drv-savage-2.1.2-3.fc6" and recent kernels with
updated "DRM".

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