The underlying logind API does not only indicate whether suspend is
available, but also whether the user is eligible for executing the
operation without further authentication. This information can be
relevant, so pass it to the callback.
https://bugzilla.gnome.org/show_bug.cgi?id=725960
Logind recently got support for a hint property in Session Object to
inform if session is Locked or not. It is up to desktop environments
to keep this property up to date.
https://bugzilla.gnome.org/show_bug.cgi?id=764773
According to systemd logind's documentation, the CanSuspend() method
"returns 'na' in case "the operation is not available because hardware,
kernel or drivers do not support it", while "'no' is returned if the
operation is available but the user is not allowed to execute it".
See http://www.freedesktop.org/wiki/Software/systemd/logind
Thus, we need to return true here when the reply for the CanSuspend
method is neither 'no' nor 'na', or we would providing false positives
in cases where suspension is simply unsupported.
https://bugzilla.gnome.org/show_bug.cgi?id=748338
The code path is completely unmaintained and untested (and probably
unused as well, considering that nobody has complained about accessing
the session object's Active property which does not exist in the
ConsoleKit case).
Most of our ConsoleKit code is already a dummy anyway, just do the
same for the remaining functionality.
https://bugzilla.gnome.org/show_bug.cgi?id=686626
When a user logs in to a wayland session, we keep the login screen
running on the X server with the login screen running in a deactivated mode.
This commit makes sure it get reactivated when the user comes back to
the VT (from user switching, logout or just ctrl-alt-f1).
https://bugzilla.gnome.org/show_bug.cgi?id=726989
It's important to compare the version components as integers,
not strings, so "10" evaulates as greater than "5"
This fixes the login screen in gnome 3.10.
https://bugzilla.gnome.org/show_bug.cgi?id=708691
These don't go through gnome-session, so they don't properly update
its state machine. We should use these in the future when we want to
use logind user sessions, but for now, they're just a trap.
https://bugzilla.gnome.org/show_bug.cgi?id=706612
With fallback mode dropped, we can no longer rely on gnome-screensaver
to be installed, so we'll have cases where we are unable to lock the
screen. The user menu should not show the "Lock" item in this case,
but as UnlockDialog includes UserMenu, we cannot use the existing check
without creating a circular dependency; move the function to a more
generic place to fix.
https://bugzilla.gnome.org/show_bug.cgi?id=693403
If screen locking is enabled, the screen shield should drop down
on suspend. Currently this is achieved by either explicitly locking
the screen (when selecting "Suspend" from the user menu) or by
relying on g-s-d delaying the suspension enough time for the shield
to get into place (lid close, power button).
Systemd inhibitors offer a safer way to ensure that the screen is
locked before going to sleep, so add a small abstraction for them
in the loginManager - with inhibitors being a systemd-only feature,
the ConsoleKit path only has a dummy implementation.
https://bugzilla.gnome.org/show_bug.cgi?id=686482
Logind provides a Suspend method, which we should use instead of
the UPower API when available. Expose this in loginManager, using
the UPower API for the ConsoleKit implementation.
https://bugzilla.gnome.org/show_bug.cgi?id=686482
Various code around had different paths for ConsoleKit and
logind. Consolidate it by making an abstract class that all
callers can use, which hides the implementation details of the
two daemons.
https://bugzilla.gnome.org/show_bug.cgi?id=682096
