Red Hat Bugzilla – Bug 1329803
gnome-shell to set LockedHint property from logind
Last modified: 2016-11-03 21:44:21 EDT
Description of problem: Logind is not used to the lock the session but it is always used to unlock it by gdm. This makes it hard to reliably track if session is locked or not. Steps to Reproduce: You can verify it by monitoring the Session from login1 and Locking you session. gdbus monitor --system --dest org.freedesktop.login1 --object-path /org/freedesktop/login1/session/_31 Actual results: You can see that the Unlock signal was emitted but Lock was not. It is also possible to see that IdleHint property changed correctly but that isn't reliable enough IMHO (It is broken in my F23, for instance) Expected results: Lock signal should be emitted. Additional info: Bug was filled upstream as well [0] and this is interesting for spice-vdagent in order to disable features like drag-and-drop when system is locked [1] [0] https://bugzilla.gnome.org/show_bug.cgi?id=764773 [1] https://bugzilla.redhat.com/show_bug.cgi?id=1323623
So we can fix gnome-shell to lock itself via logind but: 1) doing it introduces a race where logind will emit Locked before it's actually Locked (unless gnome-shell calls logind's Lock method after it's already locked and then ignores the ensuring locked signal itself) 2) I don't think any other desktop environment does locking that way at the moment. The cross desktop api for screen locking is the org.freedesktop.ScreenSaver interface (which is a bit of a misnomer) so I'd recommend vdagent use that.
So actually the cross desktop api for screen locking won't work. Our implementation is currently this: } else if (g_strcmp0 (method_name, "GetActive") == 0) {• goto unimplemented;• } So you'd need to use org.gnome.ScreenSaver.GetActive instead for RHEL.
Another way to have this is by using logind's new property LockedHint. gnome-shell can set this property and applications can query it to track if session is Locked or not. Proposal patch on upstream bugzilla.
Changing the summary based on comment #4 Patch for this is upstream: https://git.gnome.org/browse/gnome-shell/commit/?id=ddea54a5398c123a4711243e55811c8ba26f8b85
Just for future reference, build with this patch is: 3.14.4-45
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2016-2258.html