After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 696169 - Screen shield never blanks after waking up
Screen shield never blanks after waking up
Status: RESOLVED OBSOLETE
Product: gnome-shell
Classification: Core
Component: lock-screen
3.7.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
3.8.1
: 696309 (view as bug list)
Depends on: 696522
Blocks:
 
 
Reported: 2013-03-20 01:49 UTC by sangu
Modified: 2014-11-09 20:06 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
screenshield: HACK (1.26 KB, patch)
2013-03-24 22:45 UTC, drago01
rejected Details | Review
idle-monitor: Allow multiple "became-active" watches (4.64 KB, patch)
2013-03-25 08:36 UTC, Bastien Nocera
rejected Details | Review
screenshield: Share watch callback (4.10 KB, patch)
2013-03-25 20:31 UTC, drago01
reviewed Details | Review
screenshield: Share watch callback (4.39 KB, patch)
2013-03-25 21:16 UTC, drago01
rejected Details | Review

Description sangu 2013-03-20 01:49:36 UTC
Despite moving mouse in Back Screen, gnome-shell doesn't switch to unlock screen.
Only mouse arrow moves in black screen.

gnome-shell-3.7.92-1.fc19.x86_64
mutter-3.7.92-1.fc19.x86_64

See Also :
https://bugzilla.redhat.com/show_bug.cgi?id=923364
https://bugzilla.redhat.com/show_bug.cgi?id=923386
Comment 1 Matthias Clasen 2013-03-20 09:44:05 UTC
Seeing this too. Blocker !
Comment 2 darkxst 2013-03-20 09:47:55 UTC
same. <esc> does appear to bring the login screen back, however
Comment 3 drago01 2013-03-20 10:47:40 UTC
This should be fixed in clutter 1.13.10
Comment 4 darkxst 2013-03-20 10:56:00 UTC
I am seeing this using clutter 1.3.10.
Comment 5 Matthias Clasen 2013-03-20 14:28:17 UTC
not fixed with clutter 1.3.10. it is only happening for lock on idle here, if I use C-A-L to lock the screen, things behave as expected
Comment 6 drago01 2013-03-20 15:38:55 UTC
(In reply to comment #5)
> not fixed with clutter 1.3.10. it is only happening for lock on idle here, if I
> use C-A-L to lock the screen, things behave as expected

Hmm ok ... any JS errors when this happens?
Comment 7 Colin Walters 2013-03-20 23:29:22 UTC
For reference, affects current gnome-ostree master too, but only sometimes.  I haven't seen it recently.  I've also seen it in a Fedora 18 VM (running on RHEL 6.4).
Comment 8 Adam Williamson 2013-03-21 02:42:21 UTC
confirm I see this with clutter 1.3.10 also. I'll check for journalctl output with 1.3.10 soon.
Comment 9 Jasper St. Pierre (not reading bugmail) 2013-03-21 17:23:54 UTC
*** Bug 696309 has been marked as a duplicate of this bug. ***
Comment 10 Bastien Nocera 2013-03-22 12:26:22 UTC
Retitling. We're supposed to show the shield on this screen, which is why "Esc" will dismiss it.

Turning on the screensaver through:
gdbus call --session --dest org.gnome.ScreenSaver --object-path /org/gnome/ScreenSaver --method org.gnome.ScreenSaver.SetActive 'true'
won't replicate the problem though.
Comment 11 Dmitry Shachnev 2013-03-22 14:52:47 UTC
I'm seeing a similar issue in Ubuntu 13.04 with GNOME Fallback 3.6, so maybe it's a regression deeper in the stack?
Comment 12 Colin Walters 2013-03-24 17:50:48 UTC
Ok.  Before I mention anything else, let me point out:
https://bugzilla.gnome.org/show_bug.cgi?id=696500
which makes debugging this even more confusing as you have different behavior if you're running in a VM versus baremetal.  Boot with gnome.is_vm=0 to work around the VM special casing.

Now, there are *five* actors here:

* gnome-session (SessionIsActive DBus property)
* systemd's logind (backend for SessionIsActive)
* gnome-settings-daemon (power plugin)
* gnome-shell (lock screen, compositor)
* X.org (idletime, via gnome-desktop).  

The relationship between these and the lock screen is rather complicated, and they all communicate.

So first, why is the screen black?  I think (but haven't completely verified) it's because the gsd power plugin has DPMS off'd the monitor.

Now, what's the difference between locking the screen with Control-Alt-L or DBus versus waiting for the timeout?  It's the gnome-session SessionIsActive property, from what I can see.

Still debugging.
Comment 13 Bastien Nocera 2013-03-24 20:03:35 UTC
It's not gnome-settings-daemon setting the DPMS. You'd see the mouse cursor, backlight on and possibly keyboard backlight on when this happens. So the display is woken up. In fact you should be able to reproduce this with g-s-d's power plugin disabled.
Comment 14 Colin Walters 2013-03-24 20:19:55 UTC
(In reply to comment #13)
> It's not gnome-settings-daemon setting the DPMS. 

Yeah...that seems to be the case.  At the moment I'm guessing this is some sort of redraw bug.  I see gnome-shell receiving XI motion events from the cursor.  I'm guessing the reason the keyboard works is because it causes the shield to raise, which triggers a redraw.
Comment 15 drago01 2013-03-24 20:29:06 UTC
(In reply to comment #14)
> (In reply to comment #13)
> > It's not gnome-settings-daemon setting the DPMS. 
> 
> Yeah...that seems to be the case.  At the moment I'm guessing this is some sort
> of redraw bug.  I see gnome-shell receiving XI motion events from the cursor. 
> I'm guessing the reason the keyboard works is because it causes the shield to
> raise, which triggers a redraw.

Does triggering a redraw by hand (like calling queue_redraw using the dbus eval method) make it work then?
Comment 16 Colin Walters 2013-03-24 20:50:17 UTC
(In reply to comment #15)
> (In reply to comment #14)
> > (In reply to comment #13)
> > > It's not gnome-settings-daemon setting the DPMS. 
> > 
> > Yeah...that seems to be the case.  At the moment I'm guessing this is some sort
> > of redraw bug.  I see gnome-shell receiving XI motion events from the cursor. 
> > I'm guessing the reason the keyboard works is because it causes the shield to
> > raise, which triggers a redraw.
> 
> Does triggering a redraw by hand (like calling queue_redraw using the dbus eval
> method) make it work then?

Looks like it - if I attach with gdb from a serial console, and do:

(gdb) p clutter_actor_queue_relayout (clutter_stage_get_default ())

then it wakes up.
Comment 17 Colin Walters 2013-03-24 20:54:22 UTC
(In reply to comment #16)
> 
> (gdb) p clutter_actor_queue_relayout (clutter_stage_get_default ())

Hm, I must have accidentally hit a key - trying again, I can't make it wake up with _redraw or _relayout.
Comment 18 Colin Walters 2013-03-24 21:11:27 UTC
(In reply to comment #17)
> (In reply to comment #16)
> > 
> > (gdb) p clutter_actor_queue_relayout (clutter_stage_get_default ())
> 
> Hm, I must have accidentally hit a key - trying again, I can't make it wake up
> with _redraw or _relayout.

Ok, mouse motion is definitely triggering redraws, I end up in _clutter_stage_do_paint()/cogl_onscreen_swap_buffers().  But we're just not drawing the right thing?
Comment 19 Colin Walters 2013-03-24 21:50:30 UTC
(In reply to comment #18)

> Ok, mouse motion is definitely triggering redraws, I end up in
> _clutter_stage_do_paint()/cogl_onscreen_swap_buffers().  But we're just not
> drawing the right thing?

And inside GDB, I see redraws being queued automatically from the clock changing.  So it's still mysterious to me why pressing a key works...
Comment 20 drago01 2013-03-24 22:17:37 UTC
I have tested in a VM when the screen turns black I cannot activate it unless I do:

gdbus call --session --dest org.gnome.Shell --object-path /org/gnome/Shell --method org.gnome.Shell.Eval 'Main.screenShield._onUserBecameActive();'

_onUserBecameActive() is supposed to be called by the idleMonitor when it thinks that the user is active again.
Comment 21 drago01 2013-03-24 22:39:03 UTC
Actually 
gdbus call --session --dest org.gnome.Shell --object-path /org/gnome/Shell --method org.gnome.Shell.Eval 'Main.screenShield._lightbox.hide();'

is enough ... we don't hide the lightbox when the user moves the mouse ... because _onUserBecameActive does not get called.
Comment 22 Colin Walters 2013-03-24 22:39:23 UTC
Ok yeah, it's definitely the lightbox - which I didn't realize at first was completely black, anyways I'm stupid =)

gdbus call --session --dest org.gnome.Shell --object-path /org/gnome/Shell
--method org.gnome.Shell.Eval 'Main.screenShield._lightbox.hide()' shows everything of course.

So yeah, at this point it does look like a bug in the idle monitor.
Comment 23 drago01 2013-03-24 22:45:40 UTC
Created attachment 239702 [details] [review]
screenshield: HACK

idleMonitor does not like us ...

---

OK this makes it work for me which confirms that this is an idleMonitor bug.
Comment 24 Colin Walters 2013-03-24 23:23:02 UTC
Possibly related: https://bugzilla.gnome.org/show_bug.cgi?id=696522
Comment 25 Bastien Nocera 2013-03-24 23:30:07 UTC
I'm pretty certain it's not a bug in GnomeIdleMonitor, as g-s-d would have used it to bring back the backlight. Note that when Jasper changed the API  he made it so that the became-active callback will only get called once. You'll need to set up another callback after that.
Comment 26 Colin Walters 2013-03-24 23:30:42 UTC
Ok, yep I think this is a regression from:

commit a9815ae1e9844ac8ae06496981a9ddd23a4a30eb
Author: Giovanni Campagna <gcampagna@src.gnome.org>
Date:   Sat Dec 29 15:24:03 2012 +0100

    ScreenShield: don't animate arrows if the user is idle

    https://bugzilla.gnome.org/show_bug.cgi?id=690857

Because it overwrites the active time idle watch from the other part of the screen shield.  Which is understandable given https://bugzilla.gnome.org/show_bug.cgi?id=696522
Comment 27 Colin Walters 2013-03-24 23:34:53 UTC
Confirmed this small patch fixes it:

@@ -991,9 +1004,6 @@ const ScreenShield = new Lang.Class({
             Mainloop.source_remove(this._arrowAnimationId);
             this._arrowAnimationId = 0;
         }
-
-        if (!this._arrowActiveWatchId)
-            this._arrowActiveWatchId = this.idleMonitor.add_user_active_watch(Lang.bind(this, this._startArrowAnimation));
     },
 
     _stopArrowAnimation: function() {
Comment 28 Jasper St. Pierre (not reading bugmail) 2013-03-24 23:35:38 UTC
Let's just revert that for now and work on a better solution for 3.8.1.
Comment 29 Matthias Clasen 2013-03-25 01:06:47 UTC
That gets my +1
Comment 30 Bastien Nocera 2013-03-25 08:11:18 UTC
You found a bug (or a limitation, depending on what Jasper meant in this new API) in GnomeIdleMonitor:
        g_hash_table_insert (monitor->priv->watches,
                             GUINT_TO_POINTER (watch->id),
                             watch);

You can only have one became-active callback per GnomeIdleMonitor object. This should be fixable within the existing API, as long as the current behaviour wasn't meant.
Comment 31 Bastien Nocera 2013-03-25 08:36:27 UTC
Created attachment 239733 [details] [review]
idle-monitor: Allow multiple "became-active" watches

UNTESTED

We were using the same identifier for all the "became-active"
requests, even though some code (such as the screenShield in
gnome-shell) would expect each _add_user_active_watch() to result
in a separate callback.

This should fix a black screen in gnome-shell when the screenShield
would have been expected.
Comment 32 Florian Müllner 2013-03-25 08:43:44 UTC
(In reply to comment #31)
> Created an attachment (id=239733) [details] [review]
> idle-monitor: Allow multiple "became-active" watches

That's what bug 696522 is supposed to fix, no?
Comment 33 Bastien Nocera 2013-03-25 09:17:20 UTC
Yes.
Comment 34 drago01 2013-03-25 20:31:07 UTC
Created attachment 239827 [details] [review]
screenshield: Share watch callback

Currently gnome-desktop only supports one user active callback, we need two so
share the one that we have.
Comment 35 Colin Walters 2013-03-25 21:08:22 UTC
Review of attachment 239827 [details] [review]:

You're leaving around this bit of code:

        if (this._becameActiveId != 0) {
            this.idleMonitor.remove_watch(this._becameActiveId);
            this._becameActiveId = 0;
        }

right?

My preference here is to fix gnome-desktop, since that's the clearly correct thing to do for git master.
Comment 36 drago01 2013-03-25 21:16:02 UTC
Created attachment 239833 [details] [review]
screenshield: Share watch callback

Currently gnome-desktop only supports one user active callback, we need two so
share the one that we have.

---

Yeah removed that now ... yeah I prefer to fix gnome-desktop as well.
This is just the "fallback plan" if we consider fixing gnome-desktop to
be to invasive.
Comment 37 Colin Walters 2013-03-25 22:27:12 UTC
So https://bugzilla.gnome.org/show_bug.cgi?id=696522 is now pushed to master.

I'm waiting on gnome-ostree to output the latest build so I can test; if that pans out, I recommend we go with backporting the g-d patches to 3.8.
Comment 38 Colin Walters 2013-03-26 00:41:46 UTC
Ok, after some testing I'm happy enough with the patches from bug 696522.

However, there is another bug...but we can ship with this one and fix it in 3.8.1.
Comment 39 Matthias Clasen 2013-03-26 00:55:46 UTC
what is the other bug ?
Comment 40 Colin Walters 2013-03-26 01:57:37 UTC
(In reply to comment #39)
> what is the other bug ?

I haven't debugged this yet enough to file, but basically after we wake up from user activity in the lock screen, we never go back to sleep.
Comment 41 Matthias Clasen 2013-03-26 12:32:10 UTC
sounds better than the opposite
Comment 42 Jasper St. Pierre (not reading bugmail) 2013-03-27 13:49:03 UTC
Let's consider this fixed for now.
Comment 43 drago01 2013-03-27 15:32:52 UTC
(In reply to comment #42)
> Let's consider this fixed for now.

Er... comment 40 ? Or do we consider this a different bug?
Comment 44 Florian Müllner 2013-03-27 15:39:28 UTC
(In reply to comment #43)
> Er... comment 40 ? Or do we consider this a different bug?

No.
Comment 45 drago01 2013-03-29 15:16:39 UTC
Review of attachment 239833 [details] [review]:

We decided to just fix gnome-desktop.
Comment 46 Jasper St. Pierre (not reading bugmail) 2013-04-02 04:25:09 UTC
Colin, have you done any additional investigation on this?
Comment 47 drago01 2013-09-07 11:41:16 UTC
*** Bug 707649 has been marked as a duplicate of this bug. ***
Comment 48 Bastien Nocera 2014-11-09 20:06:10 UTC
No additional work has been done on this, so closing.