Bug 505915 - gnome-screensaver does not lock screen when active
gnome-screensaver does not lock screen when active
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: gnome-screensaver (Show other bugs)
11
x86_64 Linux
urgent Severity urgent
: ---
: ---
Assigned To: jmccann
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-14 13:04 EDT by udo
Modified: 2015-01-14 18:23 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-06-28 09:00:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
debug log (22.58 KB, text/plain)
2009-07-01 12:15 EDT, udo
no flags Details

  None (edit)
Description udo 2009-06-14 13:04:02 EDT
Description of problem:
gnome-screensaver does not lock screen when active

Version-Release number of selected component (if applicable):
2.26.1-2

How reproducible:
Upgrade F10 to F11

Steps to Reproduce:
1. Set screensaver for 5 minutes
2. Go sleep a while (longer than 5 minutes)
3. Return and find, upon touching key(board), that screen is not locked
  
Actual results:
screen is not locked

Expected results:
screen is locked after timeout

Additional info:
gnome floating feet screensaver in use.
Comment 1 udo 2009-06-15 22:59:20 EDT
To be extra clear:
YES the floating feet appear after 5 minutes
but NO I am not asked for a password when I touch the key(board) or move the mouse after that.
This is a security problem.

Why was this released in this status?
Comment 2 udo 2009-06-20 09:20:08 EDT
I re-tested:
I set the screensaver for one minute.
I set the screensaver to lock the screen when going active.
I waited for over one minute, not using the keyboard or mouse.
NO SCREENSAVER at all.
This worked in F10.
Comment 3 udo 2009-06-20 09:27:51 EDT
I removed gnome-screensaver.
I reinstalled gnome-screensaver.
No change.
I ran it from the commandline:

** (gnome-screensaver:14296): WARNING **: Failed to get session presence proxy: Could not get owner of name 'org.gnome.SessionManager': no such name
Comment 4 udo 2009-06-24 01:14:27 EDT
Reported elsewhere as well:
http://74.125.77.132/search?q=cache:V9-cq1UpQXAJ:https://fcp.surfsite.or
g/modules/newbb/viewtopic.php%3Fviewmode%3Dflat%26topic_id%3D72471%26for
um%3D10+gnome-screensaver+does+not+blank&cd=9&hl=nl&ct=clnk&gl=nl

http://74.125.77.132/search?q=cache:Gp6HOJQbySUJ:osdir.com/ml/fedora-lis
t/2009-06/msg02658.html+gnome-screensaver+does+not+blank+FEDORA&cd=4&hl=
nl&ct=clnk&gl=nl
Comment 5 Byron Clark 2009-07-01 00:13:46 EDT
It appears that gnome-screensaver now (starting with 2.26.0) uses gnome-session to determine idle time.  As long as you start gnome-session before starting gnome-screensaver the screensaver should appear and lock the screen.
Comment 6 udo 2009-07-01 04:49:41 EDT
gnome-session is running.
gnome-session is a child of `pam: gdm-passwd`.
I just updated to F11 from F10.
Why should this change influence the functionality of the screensaver?
How can I fix this?
Or at least debug this?
Comment 7 udo 2009-07-01 10:48:56 EDT
Even when I restart gnome-screensaver with --debug I do not get clear errors that tell me why the saver doesn't activate:

$ cat saver.log 
[gs_debug_init] gs-debug.c:106 (16:40:21):	 Debugging enabled
[main] gnome-screensaver.c:87 (16:40:21):	 initializing gnome-screensaver 2.26.1
[init_session_id] gs-listener-dbus.c:1986 (16:40:21):	 Got session-id: /org/freedesktop/ConsoleKit/Session3
[gs_fade_init] gs-fade.c:689 (16:40:21):	 Fade type: 2
[set_status] gs-watcher-x11.c:345 (16:40:21):	 GSWatcher: not active, ignoring status changes
[gs_watcher_set_active] gs-watcher-x11.c:275 (16:40:21):	 turning watcher: ON
[listener_dbus_handle_system_message] gs-listener-dbus.c:1411 (16:40:21):	 obj_path=/org/freedesktop/DBus interface=org.freedesktop.DBus method=NameAcquired destination=:1.97
[listener_dbus_handle_system_message] gs-listener-dbus.c:1411 (16:40:21):	 obj_path=(null) interface=(null) method=(null) destination=:1.97
[listener_dbus_handle_system_message] gs-listener-dbus.c:1411 (16:40:21):	 obj_path=(null) interface=(null) method=(null) destination=:1.97
[listener_dbus_handle_system_message] gs-listener-dbus.c:1411 (16:40:21):	 obj_path=(null) interface=(null) method=(null) destination=:1.97
[listener_service_deleted] gs-listener-dbus.c:1049 (16:40:21):	 DBUS service deleted: 
[listener_dbus_handle_system_message] gs-listener-dbus.c:1411 (16:40:21):	 obj_path=(null) interface=(null) method=(null) destination=:1.97
[listener_service_deleted] gs-listener-dbus.c:1049 (16:40:21):	 DBUS service deleted: 
[on_bg_changed] gs-manager.c:948 (16:40:21):	 background changed
[listener_service_deleted] gs-listener-dbus.c:1049 (16:42:11):	 DBUS service deleted: 
[listener_service_deleted] gs-listener-dbus.c:1049 (16:42:11):	 DBUS service deleted: 
[listener_service_deleted] gs-listener-dbus.c:1049 (16:42:11):	 DBUS service deleted: :1.415
[listener_service_deleted] gs-listener-dbus.c:1049 (16:42:20):	 DBUS service deleted: :1.7

This was with the saver set for 1 minute and at least one period of inactivity lasting longer than that.
Comment 8 udo 2009-07-01 10:58:18 EDT
See https://bugzilla.redhat.com/show_bug.cgi?id=207966 ?

Is gnome-screensaver maintained at all, you start wondering...
Comment 9 udo 2009-07-01 12:15:59 EDT
Created attachment 350142 [details]
debug log

Anything wrong to be seen in the log?
Comment 10 Joe Sislow 2009-07-05 16:44:08 EDT
Same for me.  I do not have this problem on my non x86-64 F11 installs.  I have two other installs where the screensaver is behaving normally.
Comment 11 udo 2009-07-08 10:18:24 EDT
#10: And your gnome screensaver was OK when using Fedora 10?

How to get this problem fixed or at least debugged?
Comment 12 Tim Taiwanese Liim 2009-07-10 01:08:29 EDT
Udo,
Have you tried to create a new user account to see if g-screensaver
locks properly with this new account?  I asked because you stated you
upgraded from F10 to F11, so you may have some config file from F10
that caused g-ssaver to misbehave.  When I upgraded from KDE3 to KDE4,
my existing config file caused KDE4 to miss letter 'e', ie. keyboard
works fine except 'e' key (yes, letter 'e' is used most frequently in
English).  I thought it's a major bug in KDE4, but how come I was the
only one saw it.  Turned out to be a KDE3/4 config file
incompatibility issue, with this workaround: remove ~/.kde/.

On the several F11 I have, they all have g-ssaver worked fine,
ie. locks ok (with password protection) at specified time.  I used
"new installation" for F11, not upgrade from F10, which may be the
difference from you installation.  g-ssaver on my F10 also locked ok.

I do still have problem with g-ssaver: it locks screen, but did not
turn off display as instructed by "Power Management" option.  It
(display off by power management) worked well in F10, but not F11.
Comment 13 udo 2009-07-10 06:40:48 EDT
Didn't try that but I did do an uninstall/reinstall.
Where is the config for gnome-screensaver stored?
Comment 14 Tim Taiwanese Liim 2009-07-10 14:23:16 EDT
> but I did do an uninstall/reinstall.
Do you mean uninstall/reinstall of the g-ssaver.rpm?  I guess this
does not remove your config.  Gnome apps queries gconfd
(/usr/libexec/gconfd-2) for config info, which is stored in 
    ~/.gconf/
    /etc/gconf/
You can probably rename both, restart gnome and see if it makes any
difference.

Creating a new account to test is a cleaner way for me.
Comment 15 udo 2009-07-22 23:11:39 EDT
Now at gnome-screensaver-2.26.1-3.fc11.x86_64, no change.
Comment 16 Tim Taiwanese Liim 2009-07-22 23:21:03 EDT
Udo,
By any chance did you try the new account method?  Did it make
any difference?  On the several F11 (32- and 64-bit) I have,
g-ssaver does always lock with password.
Comment 17 Tim Taiwanese Liim 2009-07-24 00:12:43 EDT
Udo,
Did you get the chance to try the new account test?  If so, could you
post the result?  Either it works or it does not?  If you don't want
to try it, any reason?
Comment 18 Laurent Jacquot 2009-07-24 02:36:07 EDT
hello,
Same problem here: upgrade from F10 to F11 and screen saver does not ask for a password anymore.
However, sytem->lock screen works.

I'll try tonight the new account test to pin down the problem
gnome-screensaver-2.26.1-3.fc11.i586
Comment 19 Laurent Jacquot 2009-07-24 16:38:35 EDT
It works with a new user. Problem must be within the old conf not properly forward ported.
Comment 20 udo 2009-07-25 00:35:54 EDT
How to erase just the gnome-screensaver part of the config?
Comment 21 Tim Taiwanese Liim 2009-07-25 01:31:48 EDT
Laurent,
Thanks a lot!  For confirming the issue is with the old setting not
properly forward ported.

Udo,
Earlier I stated gnome stores config in ~/.gconf, so
    cd ~/.gconf
    find | grep saver
which in my case shows
    ./apps/gnome-screensaver/%gconf.xml
which is in XML format.  If you want to know exactly which entry
caused the issue, which I am curious anyway, you can rename the
file
    d=~/.gconf/apps/gnome-screensaver
    f=%gconf.xml
    mv $d/$f /tmp/

Note that g-ssaver does not read config file directly; it (or any
gnome app) asks gconfd-2.  So after renaming said file, you need to
restart gconfd-2 and g-ssaver.  The safe way I know is to log out of
gnome and log in again.  I guess you can kill gconfd-2 and restart,
but I don't know the implication.

Also note that in gnome, some settings are shared by several
applications, eg. ~/.gconf/desktop/gnome/interface/%gconf.xml has
"cursor_blink", which can be used by any gnome app that cares to use
it.  But let's be optimistic first, hoping that
    ~/.gconf/apps/gnome-screensaver/
is the one in question.

If renaming the file works, and you are as curious as I am, you can
start add items in the old config file to $d/$f and see which one
caused the issue.

Good luck to your adventure, and please let us know what item it is,
if you find it out.
Comment 22 Laurent Jacquot 2009-07-25 02:49:58 EDT
OK, this morning everything works: yesterday's update must have repaired the right(s) package(s). 

There were a lot of them, but here are those that could have an impact (ie remotely related in my opinion):
    cairo-1.8.8-1.fc11.i586
    glib2-2.20.4-1.fc11.i586
    compiz-gnome-0.7.8-19.fc11.i586
    gnome-keyring-2.26.3-1.fc11.i586
    orca-2.26.3-1.fc11.i586
    policycoreutils-2.0.62-12.12.fc11.i586
    pango-1.24.4-1.fc11.i586
    gnome-session-2.26.2-1.fc11.i586
    1:dbus-1.2.12-2.fc11.i586
    gnome-panel-2.26.3-1.fc11.i586
    1:gnome-applets-2.26.3-1.fc11.i586
Comment 23 udo 2009-07-25 04:28:08 EDT
I did move %gconf.xml to ~.
I did the updates.
I logged out and in.
I set the screensaver for the floating feet and 1 minute.
I waited 1 minute.
No screensaver.
Comment 24 Laurent Jacquot 2009-07-25 05:53:28 EDT
for the record: I did not touch gconf configuration, and I rebooted (due to the kernel update).
My screensaver is the "picture directory"

hope this helps
Comment 25 Tim Taiwanese Liim 2009-07-27 01:08:03 EDT
Maybe Udo can try what Laurent did (update to latest everything and
reboot)?  And see if we have better luck.  Or create a new account
(using system-config-users) and repeat Comment #19.

Re: Comment #23
Udo,
So you verified that ~/.gconf/apps/gnome-screensaver/%gconf.xml does
not make a difference.  If you don't want to create a new account, how
about the nuclear option?
    mv ~/.gconf/ ~/gconf.old
That is, nuke out your user setting for gnome.  To play it safe,
please follow this sequence:
    1. logout from gnome, so you are at login screen.  So we know gconfd-2
       is not messing with your ~/.gconf/.
    2. Press Ctrl-Alt-F2 to access tty2.
    3. login as the user in question.
    4. mv ~/.gconf/ ~/gconf.old
    5. Press Ctrl-Alt-F1 to get back to gnome login screen.
    6. Login and see how it goes.
Comment 26 Laurent Jacquot 2009-07-27 02:25:57 EDT
hello,
I would have added a 4.5 bullet: be sure gconfd is shutdown: 
ps -ef |grep gconf 
and kill the process if it is running
Comment 27 Tim Taiwanese Liim 2009-07-27 10:39:38 EDT
Re: Comment #26
I concur with Laurent.
Comment 28 Tim Taiwanese Liim 2009-08-04 17:01:35 EDT
Udo,
Any news?
Comment 29 udo 2009-08-05 01:11:05 EDT
Sorry no news.
I did not find a time yet to test. (busyily preparing for HAR2009)
Do we have a fix or just a workaround? I do not get this from the comments.
Comment 30 udo 2009-08-05 02:18:07 EDT
Hmm.
Logged out.
Switched to a vt.
Killed gconf
Then had to init 3 ; init 5
Then logged in, started some stuff.
Then timed 1 minute.
And it appears to work.

By why? I did not change anything except do updates. So who/what fixed it?
Comment 31 udo 2009-08-05 02:59:08 EDT
Did not log out or update aything but now the screensaver does *not* activate.
Comment 32 Tim Taiwanese Liim 2009-08-13 12:42:20 EDT
Re: Comment #30
> Then had to init 3 ; init 5
Did you try step #5 in Comment #25?  
    5. Press Ctrl-Alt-F1 to get back to gnome login screen.
Comment 33 Tim Taiwanese Liim 2009-08-13 12:43:05 EDT
Udo,
Could you post the content of these two files?
    cat ~/.gconf/apps/gnome-screensaver/%gconf.xml    #1
    cat ~/.gconf/desktop/gnome/session/%gconf.xml     #2
The content of my "good" F11 (upgraded from F10) is as attached.

On you "bad" system, could you use 
    gnome-screensaver-preferences
to set your preference again and post the content of #2 again?
And also please check if this causes g-ssaver to lock with passwd.

In F10, g-ssaver uses #1 for "idle_delay";
In F11, g-ssaver uses #2 for "idle_delay".

When upgrade from F10 to F11, the preference in #1 is not ported to #2
automatically, as pointed out by Laurent in Comment #19.
    "Problem must be within the old conf not properly forward ported."


Content of #1,#2 in my "good" system.
    [timliim@taiwan ~]$     cat ~/.gconf/apps/gnome-screensaver/%gconf.xml
    <?xml version="1.0"?>
    <gconf>
            <entry name="themes" mtime="1250180573" type="list" ltype="string">
                    <li type="string">
                            <stringvalue>screensavers-footlogo-floaters</stringvalue>
                    </li>
            </entry>
            <entry name="mode" mtime="1250180573" type="string">
                    <stringvalue>single</stringvalue>
            </entry>
===>        <entry name="idle_delay" mtime="1249938965" type="int" value="2"/>
            <entry name="power_management_delay" mtime="1249938603" type="int" value="30"/>
    </gconf>
    [timliim@taiwan ~]$     cat ~/.gconf/desktop/gnome/session/%gconf.xml
    <?xml version="1.0"?>
    <gconf>
===>        <entry name="idle_delay" mtime="1250180575" type="int" value="1"/>
    </gconf>
Comment 34 Tim Taiwanese Liim 2009-08-13 13:05:30 EDT
Re: Comment #26, #27
I checked gconfd-2 just now, by
   ps -ef | grep gconf 
A new instance is started (and old one stopped) when you log out and
log in, so there is no need to kill gconfd-2 when doing test in
Comment #25.
Comment 35 udo 2009-08-19 12:15:01 EDT
In response to #33:
$  cat ~/.gconf/apps/gnome-screensaver/%gconf.xml 
<?xml version="1.0"?>
<gconf>
	<entry name="themes" mtime="1249455557" type="list" ltype="string">
		<li type="string">
			<stringvalue>screensavers-footlogo-floaters</stringvalue>
		</li>
	</entry>
	<entry name="mode" mtime="1249455557" type="string">
		<stringvalue>single</stringvalue>
	</entry>
</gconf>
$ cat ~/.gconf/desktop/gnome/session/%gconf.xml 
<?xml version="1.0"?>
<gconf>
	<entry name="idle_delay" mtime="1248510279" type="int" value="1"/>
</gconf>
Comment 36 Tim Taiwanese Liim 2009-08-20 12:05:58 EDT
Re: Comment #35
So you have a good ~/.gconf/desktop/gnome/session/%gconf.xml.  But you
said in Comment #31 g-ss "does *not* activate."  Is this still the
case?  How about after rebooting your system?
Comment 37 udo 2009-08-20 12:36:44 EDT
did so two days ago. no change. no screensaver after the one (1!) minute I set the screensaver to.
Comment 38 Chris 2009-08-25 06:41:40 EDT
I think I can add a bit to this as I am having the same (or similar) problem.  

I have found that the Screensaver (Either Gnome or xsreensaver will not lock if Ubuntu is booted from either CD or USB even if a new user is created with a password and without root privileges.

I have tried this on a couple of machines - all with the same effect I have also tried all of the suggestions in this (and other)posts.

It seems that Ubutnu knows when it is booted from USB/CD and (perhaps) sets a flag to indicate that the screen should not lock.  If I could find this flag I could perhaps solve the problem.
Comment 39 Tim Taiwanese Liim 2009-08-28 16:57:51 EDT
Chris, Udo,

Thanks for update.  That's good info, the g-ssaver locking may be
disabled.  Looking thru g-ss code, I found in src/gs-prefs.c 
    #define GNOME_LOCKDOWN_DIR "/desktop/gnome/lockdown"
    #define KEY_LOCK_DISABLE          GNOME_LOCKDOWN_DIR "/disable_lock_screen"
    #define KEY_DIR            "/apps/gnome-screensaver"
    #define KEY_LOCK_ENABLED   KEY_DIR "/lock_enabled"
Also the default values:
        prefs->lock_enabled            = TRUE;
        prefs->lock_disabled           = FALSE;

As a test, I manually created 
    ~/.gconf/desktop/gnome/lockdown/%gconf.xml
with this content
    <?xml version="1.0"?>
    <gconf>
            <entry name="disable_lock_screen" mtime="1248404079" type="bool"
                value="true"/>
    </gconf>
Logged out of gnome and login (so gconfd-2 reads the newly created
file) And indeed, my g-ss starts in 1 minute (showing floating foots),
but did _not_ ask for passwd when resumed.

Udo,
Chris,
Could you post the result of this?
    cat ~/.gconf/desktop/gnome/lockdown/%gconf.xml
Comment 40 udo 2009-08-29 00:54:13 EDT
$  cat ~/.gconf/desktop/gnome/lockdown/%gconf.xml
cat: /home/udo/.gconf/desktop/gnome/lockdown/%gconf.xml: No such file or directory
Comment 41 udo 2009-08-29 11:58:29 EDT
I set the screensaver for 2 minutes.
I set the screensaver for 1 minutes.
I killed the gnome-screensaver process.
I started gnome-screensaver --debug --no-daemon, maximized the screen and waited a minute:

$ gnome-screensaver --debug --no-daemon
[gs_debug_init] gs-debug.c:106 (17:54:47):	 Debugging enabled
[main] gnome-screensaver.c:87 (17:54:47):	 initializing gnome-screensaver 2.26.1
[init_session_id] gs-listener-dbus.c:1986 (17:54:47):	 Got session-id: /org/freedesktop/ConsoleKit/Session2
[gs_fade_init] gs-fade.c:689 (17:54:47):	 Fade type: 2
[set_status] gs-watcher-x11.c:345 (17:54:47):	 GSWatcher: not active, ignoring status changes
[gs_watcher_set_active] gs-watcher-x11.c:275 (17:54:47):	 turning watcher: ON
[listener_dbus_handle_system_message] gs-listener-dbus.c:1411 (17:54:47):	 obj_path=/org/freedesktop/DBus interface=org.freedesktop.DBus method=NameAcquired destination=:1.847
[listener_dbus_handle_system_message] gs-listener-dbus.c:1411 (17:54:47):	 obj_path=(null) interface=(null) method=(null) destination=:1.847
[listener_dbus_handle_system_message] gs-listener-dbus.c:1411 (17:54:47):	 obj_path=(null) interface=(null) method=(null) destination=:1.847
[listener_dbus_handle_system_message] gs-listener-dbus.c:1411 (17:54:47):	 obj_path=(null) interface=(null) method=(null) destination=:1.847
[listener_service_deleted] gs-listener-dbus.c:1049 (17:54:47):	 DBUS service deleted: 
[listener_dbus_handle_system_message] gs-listener-dbus.c:1411 (17:54:47):	 obj_path=(null) interface=(null) method=(null) destination=:1.847
[listener_service_deleted] gs-listener-dbus.c:1049 (17:54:47):	 DBUS service deleted: 
[on_bg_changed] gs-manager.c:948 (17:54:47):	 background changed

(after the previous line, probably related to resizing the terminal window, I did not touch the keyboard nor mouse for a minute; nothing happened)
Comment 42 Chris 2009-09-01 04:00:39 EDT
Thanks for the reply.

Tried adding the file manually but it made no difference for me. I am looking in to it this week so I will let you know how I get on.

Regards

Chris
Comment 43 udo 2009-09-11 06:02:18 EDT
Today the screensaver started working for me.

xorg-x11-server-Xorg-1.6.1.901-1.fc11.x86_64.rpm
xorg-x11-server-common-1.6.1.901-1.fc11.x86_64.rpm           
xorg-x11-utils-7.4-4.fc11.x86_64.rpm
xorg-x11-server-utils-7.4-7.fc11.x86_64.rpm
gnome-screensaver-2.26.1-3.fc11.x86_64
Comment 44 Laurent Jacquot 2009-09-11 14:03:28 EDT
me too, works for me now
Comment 45 udo 2009-09-12 00:44:30 EDT
It stopped working for me now.
Comment 46 udo 2009-09-12 06:32:50 EDT
Killing and restarting gnome-screensaver does not restart the 'it works' sequence.
Comment 47 Martin Donald 2009-09-18 15:03:55 EDT
I use XFCE4 as my desktop and for some months gnome-screensaver has not been activating after the set period of inctavity. I now see that the reason is that gnome-session is not running and that gnome-screensaver will not now start without that process running.

Will this be fixed for XFCE4 users?

Is there any workaround?
Comment 48 udo 2009-09-29 14:10:05 EDT
How can we help fix, work around, etc?
Comment 49 udo 2009-10-03 08:37:52 EDT
I booted into 2.6.30.8 with CONFIG_EVDEV to work around the Xorg crash reported in https://bugzilla.redhat.com/show_bug.cgi?id=522936.
Xorg is now at 1.6.4-0.1.
Strangely gnome-screensaver now does not even activate right after a boot.
See comment #48...
Comment 50 udo 2009-10-04 06:59:22 EDT
$ gnome-screensaver --nodaemon --debug

** (gnome-screensaver:31248): WARNING **: Unknown option --nodaemon
[udo@surfplank2 ~]$ gnome-screensaver --no-daemon --debug
[gs_debug_init] gs-debug.c:106 (12:56:10):	 Debugging enabled
[main] gnome-screensaver.c:87 (12:56:10):	 initializing gnome-screensaver 2.26.1
[init_session_id] gs-listener-dbus.c:1986 (12:56:10):	 Got session-id: /org/freedesktop/ConsoleKit/Session4
[gs_fade_init] gs-fade.c:689 (12:56:10):	 Fade type: 2
[set_status] gs-watcher-x11.c:345 (12:56:10):	 GSWatcher: not active, ignoring status changes
[gs_watcher_set_active] gs-watcher-x11.c:275 (12:56:10):	 turning watcher: ON
[listener_dbus_handle_system_message] gs-listener-dbus.c:1411 (12:56:10):	 obj_path=/org/freedesktop/DBus interface=org.freedesktop.DBus method=NameAcquired destination=:1.131
[listener_dbus_handle_system_message] gs-listener-dbus.c:1411 (12:56:10):	 obj_path=(null) interface=(null) method=(null) destination=:1.131
[listener_dbus_handle_system_message] gs-listener-dbus.c:1411 (12:56:10):	 obj_path=(null) interface=(null) method=(null) destination=:1.131
[listener_service_deleted] gs-listener-dbus.c:1049 (12:56:10):	 DBUS service deleted: 
[listener_dbus_handle_system_message] gs-listener-dbus.c:1411 (12:56:10):	 obj_path=(null) interface=(null) method=(null) destination=:1.131
[listener_service_deleted] gs-listener-dbus.c:1049 (12:56:10):	 DBUS service deleted: 
[listener_dbus_handle_system_message] gs-listener-dbus.c:1411 (12:56:10):	 obj_path=(null) interface=(null) method=(null) destination=:1.131
[on_bg_changed] gs-manager.c:948 (12:56:10):	 background changed
[listener_service_deleted] gs-listener-dbus.c:1049 (12:56:13):	 DBUS service deleted: 
[listener_service_deleted] gs-listener-dbus.c:1049 (12:56:13):	 DBUS service deleted: 
[listener_service_deleted] gs-listener-dbus.c:1049 (12:56:13):	 DBUS service deleted: :1.130
[listener_service_deleted] gs-listener-dbus.c:1049 (12:56:18):	 DBUS service deleted: :1.7
[listener_service_deleted] gs-listener-dbus.c:1049 (12:56:26):	 DBUS service deleted: 
[listener_service_deleted] gs-listener-dbus.c:1049 (12:56:32):	 DBUS service deleted: :1.7

Over here I let the system sit for a minute, the timeout for the screensaver, but nothing happened when the minute had passed.
Comment 51 Tim Taiwanese Liim 2009-10-12 16:32:54 EDT
Udo,
Laurent,
Could you try this?  Thanks.
  - run g-ssaver with debug option:
        gnome-screensaver --no-daemon --debug
  - in another terminal, strace g-ssaver:
        pid=<pid of g-ssaver>
        strace -tt -e read=all -e write=all  -o g-ssaver.strace -p $pid
  - stop the strace (ctrl-c) after 2 minutes (assume you have
    1 minute g-ssaver timeout).
  - and post the result g-ssaver.strace.

My recent observation:
  - g-ssaver --debug shows this line before waiting for timeout
        [on_bg_changed] gs-manager.c:948 (11:24:04): background changed

  - after 1 minute time, g-ssaver show this line
        [watcher_idle_notice_cb] gs-monitor.c:161 (11:25:08):    
            Idle notice signal detected: 1
    and start its fade-out/lock sequence.

  - In Comment #50, Comment #41, Udo's report lacks this line
        Idle notice signal detected: 1
    and g-ssaver did not initiate its fade-out/lock sequence
    after timeout.

  - strace revealed g-ssaver received msg#1 ("StatusChanged" msg,
    see Appendix A) prior to printing msg#2 ("Idle notice signal
    detected: 1").

  - In the bad case it would be helpful to find out if g-ssaver
    receives msg#1 or not.  If it does, the issue is within
    g-ssaver; if not, the issue is with the entity sending msg#1,
    probably gnome-session.

Appendix A: msgs from g-ssaver.strace (see attached file for 
            full strace)
msg#1 ("StatusChanged") ### probably this is the trigger
17:15:43.740666 read(4, "l\4\1\1\4\0\0\0"..., 2048) = 164
 | 00000  6c 04 01 01 04 00 00 00  65 00 00 00 8d 00 00 00  l....... e....... |
 | 00010  01 01 6f 00 22 00 00 00  2f 6f 72 67 2f 67 6e 6f  ..o."... /org/gno |
 | 00020  6d 65 2f 53 65 73 73 69  6f 6e 4d 61 6e 61 67 65  me/Sessi onManage |
 | 00030  72 2f 50 72 65 73 65 6e  63 65 00 00 00 00 00 00  r/Presen ce...... |
 | 00040  02 01 73 00 21 00 00 00  6f 72 67 2e 67 6e 6f 6d  ..s.!... org.gnom |
 | 00050  65 2e 53 65 73 73 69 6f  6e 4d 61 6e 61 67 65 72  e.Sessio nManager |
 | 00060  2e 50 72 65 73 65 6e 63  65 00 00 00 00 00 00 00  .Presenc e....... |
 | 00070  03 01 73 00 0d 00 00 00  53 74 61 74 75 73 43 68  ..s..... StatusCh |
 | 00080  61 6e 67 65 64 00 00 00  08 01 67 00 01 75 00 00  anged... ..g..u.. |
 | 00090  07 01 73 00 04 00 00 00  3a 31 2e 30 00 00 00 00  ..s..... :1.0.... |
 | 000a0  03 00 00 00                                       ....              |

msg#2 ("Idle notice signal detected: 1") 
      ### marks beginning of fade-out/lock sequence.
17:15:43.743040 write(2, "[watcher_idle_notice_cb] gs-monit"..., 86) = 86
 | 00000  5b 77 61 74 63 68 65 72  5f 69 64 6c 65 5f 6e 6f  [watcher _idle_no |
 | 00010  74 69 63 65 5f 63 62 5d  20 67 73 2d 6d 6f 6e 69  tice_cb]  gs-moni |
 | 00020  74 6f 72 2e 63 3a 31 36  31 20 28 31 37 3a 31 35  tor.c:16 1 (17:15 |
 | 00030  3a 34 33 29 3a 09 20 49  64 6c 65 20 6e 6f 74 69  :43):. I dle noti |
 | 00040  63 65 20 73 69 67 6e 61  6c 20 64 65 74 65 63 74  ce signa l detect |
 | 00050  65 64 3a 20 31 0a                                 ed: 1.            |
Comment 52 udo 2009-11-01 05:14:09 EST
I get:

11:11:09.636945 restart_syscall(<... resuming interrupted call ...> <unfinished ...>

Nothing more than this.
Comment 53 udo 2009-11-01 05:17:52 EST
Also: '[watcher_idle_notice_cb] gs-monitor.c:161' is not seen.
Comment 54 udo 2009-11-30 12:39:06 EST
Upgraded to F12.
For now it appears to work!
May need a few more days of observation.
Comment 55 udo 2009-12-03 01:59:07 EST
No problems found so far. Screen saver behaves normally.
Comment 56 solanum 2009-12-10 00:46:32 EST
F12 clean install. pretty much everything is default.

The screensaver/xlock works normally except when are working in a VM (qemu/vnc) session window. In which case it does not lock UNTIL you release the pointer and go back to the desktop, then it activates. (I believe it also seems to activate when you work in the vm window for longer then your screensaver timeout..) 

(this is the default gnome desktop, and most of the gui stuff is a default install)

From reading this thread, this seems to be a design flaw rather then a bug.
Comment 57 Tim Taiwanese Liim 2010-02-28 18:39:51 EST
Any one still sees this issue, either in F11 or F12?  If yes, please
provide info.  If not, should we close this bug?

Re: Comment #52, Comment #53
Udo,
Thanks for reply!  Eventually I found time to debug the control flow
of g-ss.  Your comment #52 meant g-ss (gnome-screensaver) receives no
idle notice from g-s (gnome-session), which in turn should receive
idle notice from Xorg (X server).  One bug I found in Xorg
   bug566350 Xext/sync.c IDLETIME counter sometimes fails to fire 
             when wrapped around
would prevent Xorg to send idle notice to g-s, thus g-ss no lock.
Comment 58 Martin Donald 2010-02-28 23:19:27 EST
A problem persists across Fedora 11 and 12 on all 3 of my computers:
x86_64 desktop machine
i686 desktop machine
An old DEll laptop

The problem is that I use XFCE4 as my desktop, not Gnome itself. Others have the same problem running other Gnome-based desktops. Gnome screensaver is only triggered now by gnome-session. This is since Fedora 10 (or was it 9), before the change there was no problem.

This bug #505915 has confused the issues about screen-locking not working and the issue that gnome-screensaver does not activate at all. These are two separate issues.

I would like to have gnome-screensaver working again after so long of an absence. The screensaver should be triggered as it was previously so that users of desktops other than Gnome may benefit.
Comment 59 Tim Taiwanese Liim 2010-03-01 01:18:16 EST
Martin,
I tried XFCE4 as my desktop just now, and indeed g-ss did not kick in
as you stated.  I did strace on xfce4-session (which I presumed to be
the counter part of gnome-session); xfce4-session (x-s) received no
idle notice from Xorg (the X server), probably because x-s did not
register with Xorg for idle notice.

So x-s should but does not receive idle notice; isn't this a problem
with x-s itself?  Shouldn't we open a new bug for x-s?

> The screensaver should be triggered as it was previously ...
Do you mean you want gnome-screensaver (g-ss) to take two sources of
idle notice (from gnome-session (g-s) and from whatever previous
sources g-ss used in F10)?  If so, shouldn't it be a separate
enhancement bug for g-ss?
Comment 60 Martin Donald 2010-03-01 01:50:25 EST
Tim,
Many thanks for your very prompt response. A reasonable course of action is to determine whether fixes could be made to xfce4-session. It would be better if a fix in just one place could solve the problem but I do not have much knowledge about the inter-process communication to be of much more help.

I do hope that it can be fixed because I like the picture slideshow feature of gnome-screensaver and have no wish to change from XFCE4 to Gnome.
Comment 61 solanum 2010-03-01 09:42:27 EST
I reported it for F12. It is the most annoying on the i686 laptop but my desktop x64 has the same issue (both F12).  

It is =really= bad when you have a qemu virtual machine console running in the foreground.  The screensaver won't kick in until you click on a window outside of the console session. IE you can work in the qemu vm console walk away for an hour and if the qemu console was in the foreground the qemu session is still active. (if it isnt the screensaver usually kicks in.)  The screensaver won't kick in until you click on a window outside the console. Once you click on something outside the qemu session it immediately kicks in. (this is all with the default gnome desktop.)
Comment 62 Tim Taiwanese Liim 2010-03-01 22:17:00 EST
Solanum,
I ran qemu console and indeed I reproduced the issue you described.  I
see this as a design conflict, not a g-ss issue, though.  When you
click on the qemu vm console, it grabs the input (mouse and keyboard):
    Pointer grabbed
    The mouse pointer has been restricted to the
    virtual console window.  To release the pointer, 
    press the key pair: Ctrl+Alt
When g-ss activates, it also tries to grab the input, but could not:
    [gs_grab_get_keyboard] gs-grab-x11.c:171 (20:32:26): 
                Grabbing keyboard widget=2800003
    [gs_grab_get_keyboard] gs-grab-x11.c:186 (20:32:26): 
                Couldn't grab keyboard!  (AlreadyGrabbed)

So here is the conflict: both qemu vm console and g-ss want to grab
input, but only one can do it; and since g-ss is the 2nd one, g-ss
will not get the grab, thus no lock.  Good news for my LCD backlight
is, g-p-m (gnome-power-manager) does not require grab, so it turns off
my LCD backlight on time, although this does not help my laptop
security.

Can you live with vnc access to the vm?  vnc will not do the grab, so
g-ss will work as usual.

Agree that this could be annoying, but I see it as an issue with qemu
vm console, not with g-ss.  You can register your complaint here in
g-ss, but the guy in charge of qemu vm console will not see it, and
thus no fix, since they are the only one who can release the input
grab from qemu vm console.  You should file a bug against the
component "virt-manager", if it annoys you enough.
Comment 63 solanum 2010-03-02 10:15:15 EST
Thanks!!! I filed it as a bug with the virt-manager folks. I wasn't sure -where- the bug actually was.  :)
Comment 64 Tim Taiwanese Liim 2010-03-02 22:40:38 EST
Solanum,
Glad that I can help!  Just in case anyone comes to g-ss for this same
issue, the bug in virt-manager is
    bug569830 qemu session not allowing screensaver on host os to 
              activate
Comment 65 Tim Taiwanese Liim 2010-03-02 23:44:17 EST
Re: Comment #60

Martin,
So here is a summary of possibilities:

#1 enhance xfce4-session (and any equivalent of gnome-session) so
   they behave like the new (F11 and later) gnome-session.  That is,
   xxx-session registers idle alarm with Xorg (X server), and when
   informed of idleness, relay the info to g-ss.   

#2 request g-ss owner to add back its g-ss's old behavior (F10 and
   before).  That is, in addition to receive idle notice from
   gnome-session (g-s), g-ss probably need to register with Xorg
   directly for idle alarm.  The pros of #2 (according to Martin
   Comment #60) is, no need to change all equivalents of gnome-session.

If you decide to go for #1, we need to file a bug for xfce4-session.
If #2, we need to file a new enhancement bug for g-ss; I don't think
#2 is related enough to be part of this bug505915.

Personally I think #1 is the right way to go; but you decide what you
want to do.

> I like the picture slideshow feature of gnome-screensave
Agree; g-ss is doing well now.  I had hard time when F11 first came
out.
Comment 66 Martin Donald 2010-03-03 00:23:38 EST
Tim,

I really do not have enough knowledge of the direction that gnome and derivative desktops are headed. I'm just a user, not a developer. 

If things are really headed towards standardization of xxx-session for different desktops then #1 is probably a good way to go.

Solution #2 has the advantage of a fix in one place -- cut out the middle-man. A screensaver is very closely associated with the display and Xorg. I tend to favour solution #2 but, once again, I'm totally ignorant of how this all fits together.

I don't know how xscreensaver is activated but it was working fine last time I used it in Fedora fc11. (xscreensaver does not have that nice slideshow of my multi-Gbyte photo collection).
Comment 67 Tim Taiwanese Liim 2010-03-04 00:12:29 EST
Martin,
I opened a bug against xfce4-session:
    bug570380 xfce4-session should send idle notice to gnome-screensaver
Let me know if it addresses your concern.  If so, we can move the
discussion on x-s to bug570380.

In that bug, I left the decision as to who should change to x-s and
g-s folks, by saying
    If you believe it's g-ss that should revert its change, please
    negotiate with g-ss folks.
They know what they are doing, so they should be able to make better
decision than us.

ps. yes, I also found the slideshow of g-ss a thing to enjoy.
Comment 68 Martin Donald 2010-03-04 12:03:44 EST
Tim,

Thanks. I don't mind how this will be resolved. I would just like g-ss to work for me again. I have a feeling that this issue was not well thought out at the beginning.
Comment 69 Tim Taiwanese Liim 2010-03-04 23:44:03 EST
Martin,
Definitely we need to move this issue to bug570380.  In short, we are
witnessing a war between gnome and xfce, with no resolution in sight.
We probably need to pray more often :-).

View from gnome (who owns g-ss):
    https://bugzilla.gnome.org/show_bug.cgi?id=592093#c2
    2010-01-29
    I'd say that the xfce session should probably do something like
    gnome-session. Either that or an external module that implements the
    same dbus interface.
    I don't think we are going to fix this.  This is the gnome screensaver
    after all :)

View from xfce (who borrows g-ss for its own use but complains about 
change in g-ss):
    http://bugzilla.xfce.org/show_bug.cgi?id=5927#c4
    2009-10-30
    Yes, it definitely suck, but there's not much one can do, exept asking
    for GNOME people to revert the change and stay with the X idle
    counter.
Comment 70 Tim Taiwanese Liim 2010-03-04 23:53:59 EST
Can we close this bug now?
  - Comment #55 Udo no longer sees this issue in F12.
  - Comment #56 Solanum qemu-gss conflict now tracked in bug569830
  - Comment #58 Martin  xfce-gss conflict now tracked in bug570380
  - Comment $57 Tim Liim filed bug566350 for Xext/sync.c IDLETIME
                counter bug

Granted that the outlooks of bug569830, bug570380 are not great
(everyone says someone else should fix it), but we should track
separate issues in their own bugs.  So I propose we close this bug
now.
Comment 71 Bug Zapper 2010-04-27 10:54:52 EDT
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 72 Tim Taiwanese Liim 2010-05-12 10:07:42 EDT
Re: Comment #70
Can we close this bug now?
Comment 73 udo 2010-05-12 10:37:59 EDT
For me it works, but for the others?
Comment 74 Tim Taiwanese Liim 2010-05-12 11:16:45 EDT
Udo,
Yes, that's the reason why I kept on asking.  Two months have passed
since Comment #70 and no one said "I still have this issue, don't
close it."  Also it's not like once a bug is closed it's cemented in
the underworld; people can reopen bugs, or open a new bug with
reference to existing bugs, or keeping on commenting a closed bug.

In your opinion, how long should we wait till we can close a bug that
is no longer seen?
Comment 75 udo 2010-05-12 11:36:40 EDT
For me it was fixed after upgrading to F12.
I saw one report that they still had the issue after upgrading to F12.
Maybe wait for two different reports to confirm or deny a fix?
Comment 76 Tim Taiwanese Liim 2010-05-12 11:53:58 EDT
> I saw one report that they still had the issue after upgrading to
> F12.
Could you point out which Comment (or bug#) it is?

> Maybe wait for two different reports to confirm or deny a fix?
Agree, but I'd add "within certain time limit."  How long should we
wait is personal opinion, and two months is long enough for me,
because this (closing a bug) is not a one-way operation; you can
always undo it by reopening a bug (or by opening a new bug).
Comment 77 Sean Sheedy 2010-05-12 12:14:12 EDT
I'm still seeing this problem in Fedora 12.
Comment 78 Tim Taiwanese Liim 2010-05-12 12:19:40 EDT
Great!  You proved Udo's point.  Could you please run
    gnome-screensaver --nodaemon --debug
and attach the output, as in Comment #50?  Thanks!
Comment 79 Tim Taiwanese Liim 2010-05-12 12:23:41 EDT
Umm. Typo.  Should be --no-daemon
    gnome-screensaver --no-daemon --debug
Comment 80 Sean Sheedy 2010-05-12 12:37:04 EDT
I set the idle time to 1 minute, and ran:
    gnome-screensaver --no-daemon --debug
The results:

[gs_debug_init] gs-debug.c:106 (09:32:16):	 Debugging enabled
[main] gnome-screensaver.c:87 (09:32:16):	 initializing gnome-screensaver 2.28.3
[init_session_id] gs-listener-dbus.c:1979 (09:32:16):	 Got session-id: /org/freedesktop/ConsoleKit/Session2
[gs_fade_init] gs-fade.c:881 (09:32:17):	 Fade type: 3
[set_status] gs-watcher-x11.c:345 (09:32:17):	 GSWatcher: not active, ignoring status changes
[gs_watcher_set_active] gs-watcher-x11.c:275 (09:32:17):	 turning watcher: ON
[listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:17):	 obj_path=/org/freedesktop/DBus interface=org.freedesktop.DBus method=NameAcquired destination=:1.282
[listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:17):	 obj_path=(null) interface=(null) method=(null) destination=:1.282
[listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:17):	 obj_path=(null) interface=(null) method=(null) destination=:1.282
[listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:17):	 obj_path=(null) interface=(null) method=(null) destination=:1.282
[listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:17):	 obj_path=(null) interface=(null) method=(null) destination=:1.282
[on_bg_changed] gs-manager.c:949 (09:32:17):	 background changed
[listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:17):	 obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null)
[listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:17):	 obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null)
[listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:18):	 obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null)
[listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:18):	 obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null)
[listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:18):	 obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null)
[listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:18):	 obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null)
[listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:19):	 obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null)
[listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:19):	 obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null)
[listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:19):	 obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null)
[listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:20):	 obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null)
[listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:20):	 obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null)
[listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:20):	 obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null)
[listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:21):	 obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null)
[listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:21):	 obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null)
[listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:21):	 obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null)
[listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:21):	 obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null)
[listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:22):	 obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null)
[listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:22):	 obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null)
[listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:22):	 obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null)
[listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:23):	 obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null)
[listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:23):	 obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null)
[listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:23):	 obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null)
[listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:24):	 obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null)
[listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:24):	 obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null)
[listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:24):	 obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null)
[listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:24):	 obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null)
[listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:25):	 obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null)
[listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:25):	 obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null)
[listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:25):	 obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null)
[listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:26):	 obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null)
[listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:26):	 obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null)
[watcher_idle_notice_cb] gs-monitor.c:125 (09:33:27):	 Idle notice signal detected: 1
[gs_grab_grab_offscreen] gs-grab-x11.c:540 (09:33:27):	 Grabbing an offscreen window
[gs_grab_get_keyboard] gs-grab-x11.c:171 (09:33:27):	 Grabbing keyboard widget=3A00003
[gs_grab_get_mouse] gs-grab-x11.c:206 (09:33:27):	 Grabbing mouse widget=3A00003
[_gs_watcher_set_session_idle_notice] gs-watcher-x11.c:202 (09:33:28):	 Changing idle notice state: 1
[watcher_idle_notice_cb] gs-monitor.c:125 (09:33:28):	 Idle notice signal detected: 0
[watcher_idle_notice_cb] gs-monitor.c:149 (09:33:28):	 manager not active, performing fade cancellation
[gs_fade_reset] gs-fade.c:826 (09:33:28):	 Resetting fade
[_gs_watcher_set_session_idle_notice] gs-watcher-x11.c:202 (09:33:28):	 Changing idle notice state: 0
[listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:33:28):	 obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null)
[gs_grab_release] gs-grab-x11.c:418 (09:33:29):	 Releasing all grabs
[gs_grab_release_mouse] gs-grab-x11.c:267 (09:33:29):	 Ungrabbing pointer
[gs_grab_release_keyboard] gs-grab-x11.c:244 (09:33:29):	 Ungrabbing keyboard
[xorg_lock_smasher_set_active] gs-grab-x11.c:124 (09:33:29):	 No XFree86-Misc extension present
Comment 81 Martin Donald 2010-05-12 13:12:27 EDT
Regarding myself, you may close this bug
Comment 82 Tim Taiwanese Liim 2010-05-12 14:52:22 EDT
Re: Comment #80
Sean,
Thanks for fast response.  I see this time line in Comment #80:
  09:32:16 g-ss started
  09:33:27 Idle notice signal detected: 1
           [start gamma fading (10 sec)]
  09:33:28 Idle notice signal detected: 0
            manager not active, performing fade cancellation

That is, after 60 sec g-ss received idle notice and started gamma
fading, which would take 10 sec.  But you interrupted the fading in 1
sec, so you see no lock, which is expected and desired behavior.

Could you repeat the same test, but wait at least 15 sec (ie. do not
interrupt the fading).  And when posting the result, please skip the
"listener_dbus_handle_system_message" portion; these seems to be
unrelated to our issue.
Comment 83 Tim Taiwanese Liim 2010-05-12 14:54:24 EDT
Re: Comment #81
Martin, thanks.
Comment 84 Sean Sheedy 2010-05-12 15:10:03 EDT
(In reply to comment #82)
> Thanks for fast response.  I see this time line in Comment #80:
>   09:32:16 g-ss started
>   09:33:27 Idle notice signal detected: 1
>            [start gamma fading (10 sec)]
>   09:33:28 Idle notice signal detected: 0
>             manager not active, performing fade cancellation
> 
> That is, after 60 sec g-ss received idle notice and started gamma
> fading, which would take 10 sec.  But you interrupted the fading in 1
> sec, so you see no lock, which is expected and desired behavior.

I didn't touch the keyboard, mouse, etc., until long after these messages printed.  Apparently something other than user activity is interrupting the fading.  I repeated the test and got the same results.
Comment 85 Tim Taiwanese Liim 2010-05-12 16:18:26 EDT
Understand, that you did not touch keyboard nor mouse, but someone/
something somewhere told g-ss to stop fading because the user is no
longer "idle."  Did you see g-ss in action for more than a few sec?
From Comment #80 I would guess g-ss kicked in and then went away in 1
sec.

Is my guess correct?  If so, this is a different bug than this
bug505915 (Comment #1), and we should file a new bug to track this new
issue.  By now bug505915 has many different issues of the same
symptoms crammed in and is hard to keep track.

If you want to keep this issue on this bug, fine by me, but I am
afraid we will bore many on the cc list.
Comment 86 Sean Sheedy 2010-05-12 19:43:54 EDT
(In reply to comment #85)
> Understand, that you did not touch keyboard nor mouse, but someone/
> something somewhere told g-ss to stop fading because the user is no
> longer "idle."  Did you see g-ss in action for more than a few sec?
> From Comment #80 I would guess g-ss kicked in and then went away in 1
> sec.

Your understanding is correct.  g-ss came and went in the span of about 1 second without any human intervention.

> Is my guess correct?  If so, this is a different bug than this
> bug505915 (Comment #1), and we should file a new bug to track this new
> issue.  By now bug505915 has many different issues of the same
> symptoms crammed in and is hard to keep track.

I agree.  I'll open a new bug.
Comment 87 Sean Sheedy 2010-05-12 20:00:10 EDT
(In reply to comment #86)
> I agree.  I'll open a new bug.    

See bug591750
Comment 88 Tim Taiwanese Liim 2010-05-14 14:53:14 EDT
Anyone still seeing this issue?  
If so, please provide info.
If not, can we close this bug in two weeks?
Comment 89 Bug Zapper 2010-06-28 09:00:14 EDT
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 90 Tim Taiwanese Liim 2010-06-28 11:13:26 EDT
For the record here is my objection to the resolution "Closed
WontFix".

It should be "Closed Fixed", since no one sees this issue (or 
bothers to say so) anymore.

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