The issue appears to relate to a hand-off from xfce4-power-manager to systemd/logind, which is controlled by a hidden xfconf property that didn't exist on this machine (possibly because it does not have systemd installed). Adding that property and setting it to "false" hands back control to xfce4-power-manager and everything works as it should. Perhaps something for the devs to look into; maybe Devuan should set this property by default?
Would be interesting to hear what the Devuan gods say about this?
]]>Laptop lid action not respected
Xfce4-power-manager not respecting laptop lid setting. Regardless of power manager setting (Switch off display or Lock screen), closing the lid always results in suspend on ac or battery.
Not quite the same issue I was experiencing, but close enough to be potentially relevant. At first I was disappointed that the proposed solution didn't seem to have any effect (xfconf-query -c xfce4-power-manager -p /xfce4-power-manager/logind-handle-lid-switch -s false), but in comment #10 on that bug report someone says
Just in addition to the answers above, the setting didn't exist for me yet. I needed to create it.
He suggests
sudo xfconf-query -c xfce4-power-manager -n -t 'bool' -p /xfce4-power-manager/logind-handle-lid-switch -s false
but since xfce4-power-manager runs in the user context (started from Sessions and Start Up > Application Autostart) I ran the command without sudo - expecting to see a warning that the key already existed. But I got no such warning - and when I closed the lid afterwards the laptop suspended and locked. Multiple tests on battery & on AC, with multiple reboots, confirms that this indeed fixed the problem.
So the lessons learned are 1) xfce4-power-manager handles suspend and locking without involving any scripts in /etc/acpi - as indicated by the CheckPolicy condition in lid.sh 2) the acpi-support package is not needed (for this functionality anyway). 3) the issue appears to relate to a hand-off from xfce4-power-manager to systemd/logind, which is controlled by a hidden xfconf property that didn't exist on this machine (possibly because it does not have systemd installed). Adding that property and setting it to "false" hands back control to xfce4-power-manager and everything works as it should. Perhaps something for the devs to look into; maybe Devuan should set this property by default?
Edit: Just to be clear, I now only have two acpi events/scripts defined, one of which is my home made mic-mute function:
$ ls /etc/acpi
events powerbtn-acpi-support.sh thinkpad_micmute.sh
$ ls /etc/acpi/events
powerbtn-acpi-support thinkpad_micmute
So the whole suspend & lock on lid close process takes place elsewhere (i.e. xfce4-power-manager), and all that digging in /etc/acpi only turned up a red herring. Smelly, but red.
]]>TRACE[xfpm-xfconf.c:216] xfpm_xfsession_property_changed_cb(): property /shutdown/LockScreen
TRACE[xfpm-xfconf.c:225] xfpm_xfsession_property_changed_cb(): Property modified: /shutdown/LockScreen
TRACE[xfpm-xfconf.c:203] xfpm_xfconf_property_changed_cb(): Property modified: /xfce4-power-manager/lock-screen-suspend-hibernate
TRACE[xfpm-xfconf.c:203] xfpm_xfconf_property_changed_cb(): Property modified: /xfce4-power-manager/logind-handle-lid-switch
TRACE[xfpm-manager.c:645] xfpm_manager_inhibit_sleep_systemd(): Inhibiting systemd sleep: handle-power-key:handle-suspend-key:handle-hibernate-key
(xfce4-power-manager:7608): GLib-CRITICAL **: 00:53:09.746: g_error_free: assertion 'error != NULL' failed
And when I uncheck the checkbox I get:
TRACE[xfpm-xfconf.c:216] xfpm_xfsession_property_changed_cb(): property /shutdown/LockScreen
TRACE[xfpm-xfconf.c:225] xfpm_xfsession_property_changed_cb(): Property modified: /shutdown/LockScreen
TRACE[xfpm-xfconf.c:203] xfpm_xfconf_property_changed_cb(): Property modified: /xfce4-power-manager/lock-screen-suspend-hibernate
TRACE[xfpm-xfconf.c:203] xfpm_xfconf_property_changed_cb(): Property modified: /xfce4-power-manager/logind-handle-lid-switch
TRACE[xfpm-manager.c:645] xfpm_manager_inhibit_sleep_systemd(): Inhibiting systemd sleep: handle-power-key:handle-suspend-key:handle-hibernate-key:handle-lid-switch
(xfce4-power-manager:7608): GLib-CRITICAL **: 00:54:21.371: g_error_free: assertion 'error != NULL' failed
What's going on with handle-lid-switch in the output above?
I removed the acpi-support package (and rebooted) to reduce the number of moving parts, and had another look at the behaviour. If I close the lid with the box unchecked, the laptop suspends. If I close the lid with the box checked, nothing happens. If I press the suspend hotkey (Fn+F4) with the box checked, the laptop suspends and locks. If I press the suspend hotkey with the box unchecked, the laptop suspends. So the hotkey works exactly as it should, but the lidswitch doesn't. This is where I am after another long session - the battle continues tomorrow, and I will get this to work.
]]>Oh and I realised I made a mistake earlier; I shouldn't have run xfce4-power-manager --dump as root, this will give misleading results since it normally runs as the user.
]]>(xfce4-power-manager:7459): xfce4-power-manager-WARNING **: 22:25:05.954: Screensaver lock command not set when attempting to lock the screen.
Please set the xfconf property /general/LockCommand in xfce4-session to the desired lock command
Which strengthens my suspicion that xfce4-power-manager is indeed where the problem lies. But:
$ xfconf-query -lc xfce4-session
/general/FailsafeSessionName
/general/SaveOnExit
/general/SessionName
/sessions/Failsafe/Client0_Command
/sessions/Failsafe/Client0_PerScreen
/sessions/Failsafe/Client1_Command
/sessions/Failsafe/Client1_PerScreen
/sessions/Failsafe/Client2_Command
/sessions/Failsafe/Client2_PerScreen
/sessions/Failsafe/Client3_Command
/sessions/Failsafe/Client3_PerScreen
/sessions/Failsafe/Client4_Command
/sessions/Failsafe/Client4_PerScreen
/sessions/Failsafe/Count
/sessions/Failsafe/IsFailsafe
/shutdown/LockScreen
/splash/Engine
There is no such xfconf property for xfce4-session, and not for root either:
$ sudo xfconf-query -lc xfce4-session
/general/FailsafeSessionName
/sessions/Failsafe/Client0_Command
/sessions/Failsafe/Client0_PerScreen
/sessions/Failsafe/Client1_Command
/sessions/Failsafe/Client1_PerScreen
/sessions/Failsafe/Client2_Command
/sessions/Failsafe/Client2_PerScreen
/sessions/Failsafe/Client3_Command
/sessions/Failsafe/Client3_PerScreen
/sessions/Failsafe/Client4_Command
/sessions/Failsafe/Client4_PerScreen
/sessions/Failsafe/Count
/sessions/Failsafe/IsFailsafe
/splash/Engine
Should I try to add it? And set it to, I dunno, light-locker-command -l?
]]>There's more. The acpi-support package also installs an event and support script for "lid" events - and this does get triggered when I open/close the lid (I moved my hommade acpi lid event handler out of the way first, of course), but it exits on the first condition:
/etc/acpi/lid.sh:
if { CheckPolicy || HasLogindAndSystemd1Manager; }; then
exit
fi
Ok, so we don't have SystemD, it must be CheckPolicy which returns true then. Turns out CheckPolicy is just a list of power management utilities - including xfce4-power-manager - which, if present on the system, should handle the lid events.
/usr/share/acpi-support/policy-funcs:
...
CheckPolicy() {
local PMS
getXconsole
PMS="/usr/bin/xfce4-power-manager /usr/bin/mate-power-manager /usr/lib/dalston/dalston-power-applet"
pidof -x $PMS > /dev/null ||
PowerDevilRunning ||
GnomeSettingsDaemonPowerRunning
}
...
Or so the acpi script expects and happily exits. So I come back to xfce4-power-manager and not acpi as the likely culprit; hence the output of sudo xfce4-power-manager --dump above.
]]>** (xfce4-power-manager:7459): WARNING **: 20:37:14.848: Failed to get name owner:
GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not get owner of name 'org.xfce.PowerManager': no such name
** (xfce4-power-manager:7459): WARNING **: 20:37:14.849: Failed to get name owner:
GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not get owner of name 'org.freedesktop.PowerManagement': no such name
** (xfce4-power-manager:7459): WARNING **: 20:37:14.850: Failed to get name owner:
GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not get owner of name 'org.xfce.PowerManager': no such name
(xfce4-power-manager:7459): xfce4-power-manager-WARNING **: 20:37:14.850: Unable to connect to session manager :
Failed to connect to the session manager: SESSION_MANAGER environment variable not defined
(xfce4-power-manager:7459): GLib-GObject-WARNING **: 20:37:14.981: ../../../gobject/gsignal.c:2523:
signal 'Changed' is invalid for instance '0x55e8e96c81e0' of type 'GDBusProxy'
(xfce4-power-manager:7459): xfce4-power-manager-WARNING **: 20:37:15.026: could not map keysym 1008ffa8 to keycode
(xfce4-power-manager:7459): GLib-CRITICAL **: 20:37:15.047: g_error_free: assertion 'error != NULL' failed
** (xfce4-power-manager:7459): WARNING **: 20:37:15.048: No outputs have backlight property
xfce4-power-manager-Message: 20:37:15.089: Set kernel brightness switch to 0
(xfce4-power-manager:7459): xfce4-power-manager-WARNING **: 20:37:15.096: Failed to get keyboard max brightness level :
GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such interface “org.freedesktop.UPower.KbdBacklight” on object at path
/org/freedesktop/UPower/KbdBacklight
---------------------------------------------------
Xfce power manager version 1.6.1
With policykit support
With network manager support
---------------------------------------------------
Can suspend: True
Can hibernate: True
Authorised to suspend: True
Authorised to hibernate: True
Authorised to shutdown: True
Has battery: True
Has brightness panel: True
Has power button: True
Has hibernate button: True
Has sleep button: True
Has LID: True
Does that look right to you?
Edit: A lot of the errors and warnings here come from the fact that, like an idiot, I ran the command with sudo. xfce4-power-manager should run in the user context and the root account (being disabled) likely misses many of the pieces which make it work.
]]>The issue is that when "Lock screen when system is going to sleep" is selected, resuming from suspend takes me to a blank screen - essentially an active screensaver - on which I have to press a key again in order to wake up the computer to show the login screen.
https://files.devuan.org/devuan_beowulf … _notes.txt
### Workarounds for known lightdm issues/bugs
lightdm prevents some accessibility features from working and gives the
error, "Couldn't register with accessiblity bus" in ~/.xsession-errors.
(See Debian bug [#760740](https://bugs.debian.org/760740))This can be mitigated in the current X session by running:
xprop --root --remove AT_SPI_BUS
For a persistent solution edit /etc/lightdm/lightdm.conf to add:
xserver-share=false
Power buttons are disabled on the lightdm login screen with elogind.
(See Debian bug [#932047](https://bugs.debian.org/932047))Add the following line to /etc/pam.d/lightdm-greeter
session optional pam_elogind.so
Edit: I have confirmed that this is the same option as the "Lock screen when the system goes to sleep" checkbox on the security tab of Xfce Power Manager. Toggling one toggles the other.
]]>Integrate Light Locker configuration into Xfce Power Manager. This
allows proper settings synchronization between the two applications
and eliminates some of the hackiness used in Light Locker Settings
to accomplish the same effect, and streamlines similar tools into
a single location. This depends on light-locker 1.5.1 configured
with the GSettings backend.
"Aha" I thought, and tried setting lid close to "Lock Screen" in the power management applet, and hey presto, the computer now suspends and locks when I close the lid. If I remove the pm-suspend command from my acpi script it only locks, so this is still needed. And when it resumes the screen blinks multiple times before going to DPMS-off; I have to press a key on the keyboard to turn it back on. So it's not a perfect solution, but I'm definitely getting closer!
Edit: dconf-gsettings-backend is already installed.
]]>