| Age | Commit message (Collapse) | Author |
|---|
|
https://bugs.freedesktop.org/show_bug.cgi?id=82485
|
|
With proprietary graphics drivers, there won't be any 'drm' devices in
sysfs, so logind will never suspend the system upon closing the lid,
even if only one (internal) display is connected. This has been reported
by multiple users so far.
IMHO, it's better to suspend the system in this case for safety reasons,
to avoid having nvidia blob users' laptops overheat, for the same reason
that sleep inhibitors are overridden (LidSwitchIgnoreInhibited=yes).
|
|
No functional change expected :)
|
|
udev_device_get_parent() may return NULL when the device doesn't have a
parent, as is the case with (for example) /sys/devices/virtual/drm/ttm.
Also, log an actual error message instead of "-12 displays connected".
|
|
startup
This is needed to give USB docking stations and suchlike time to settle,
so that a display connected to an USB docking station can actually act
as a lid swith inhibitor correctly.
With this change we should have somewhat reliable docking station
support in place.
|
|
|
|
Previously we expected the desktop environment to take an inhibitor
lock, but this opened a race on boot-up where logind might already be
running but no DE is active.
Hence, let's move checking for additional displays into logind. This
also opens up this logic for other DEs, given that only GNOME
implemented the inhibitor logic so far.
|
|
processing
This should make operation nicer with docking stations, but will not
cover anything that does not implement SW_DOCK.
|
|
sleep immediately again
This is quite useful on laptops such as the Lenovo Yoga, where the power
button is placed on the front side of the laptop and can be pressed by
accident even if the lid is closed.
This reworks a bit of the logind logic to repeatedly try to suspend the
system as long as a lid is closed. We use the new "post" event source
for this, so that we don't keep things busy.
This also adds some code to check the lid status on boot, so that a
powered-off machine that is accidentaly powered on goes into suspend
immediately.
Yay! From now on I can put my Yoga safely in my backpack without fearing
that it might turn itself on and drain the battery.
|
|
|
|
|
|
https://bugs.freedesktop.org/show_bug.cgi?id=55248
|
|
A new config file /etc/systemd/sleep.conf is added.
It is parsed by systemd-sleep and logind. The strings written
to /sys/power/disk and /sys/power/state can be configured.
This allows people to use different modes of suspend on
systems with broken or special hardware.
Configuration is shared between systemd-sleep and logind
to enable logind to answer the question "can the system be
put to sleep" as correctly as possible without actually
invoking the action. If the user configured systemd-sleep
to only use 'freeze', but current kernel does not support it,
logind will properly report that the system cannot be put
to sleep.
https://bugs.freedesktop.org/show_bug.cgi?id=57793
https://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=7e73c5ae6e7991a6c01f6d096ff8afaef4458c36
http://lists.freedesktop.org/archives/systemd-devel/2013-February/009238.html
SYSTEM_CONFIG_FILE and USER_CONFIG_FILE defines were removed
since they were used in only a few places and with the
addition of /etc/systemd/sleep.conf it becomes easier to just
append the name of each file to the dir name.
|
|
The information about the unit for which files are being parsed
is passed all the way down. This way messages land in the journal
with proper UNIT=... or USER_UNIT=... attribution.
'systemctl status' and 'journalctl -u' not displaying those messages
has been a source of confusion for users, since the journal entry for
a misspelt setting was often logged quite a bit earlier than the
failure to start a unit.
Based-on-a-patch-by: Oleksii Shevchuk <alxchk@gmail.com>
|
|
- Don't allow any locks to be taken while we are in the process of
executing the specific operation, so that apps are not surprised if a
suspend/shutdown happens while they rely on their inhibitor.
- Get rid of the Resumed signal, it was a bad idea, and redundant due to
PrepareForSleep(false), see below.
- Always send out PrepareFor{Shutdown,Sleep} signals, instead of only if
a delay lock is taken.
- Move PrepareForSleep(false) after we come back from the suspend, so
that apps can use this as "Resumed" notification. This also has the
benefit that apps know when to take a new lock.
|
|
This should make sure that closing the lid while shutting down won't
suspend the machine but will simply cause the shutdown to complete.
|
|
|
|
|
