SOLVED: Issues using "live" install on Thinkpad T410

Lomax · 2021-02-02 13:47:37

Update: I've got suspend/resume working on lid close by using a similar route to the mic mute solution above:

/etc/acpi/events/thinkpad_lidbutton:

event=button[ /]lid
action=/etc/acpi/thinkpad_lidbutton.sh %e

/etc/acpi/thinkpad_lidbutton.sh:

#!/bin/bash

if [  "$3" = "close" ] ; then
     /usr/sbin/pm-suspend
fi

And:

sudo chmod +x /etc/acpi/thinkpad_lidbutton.sh
sudo service acpid restart

But I cannot get it to lock the screen. I changed from Slim to to LightDM and installed light-locker; from a user prompt I can issue "light-locker-command -l" and the screen will lock, but when I do this from my acpi script I get GDBus.error ServiceUnknown org.freedesktop.screensaver. Any ideas?

dice · 2021-02-02 14:05:13

Lomax wrote:

Update: I've got suspend/resume working on lid close by using a similar route to the mic mute solution above:
/etc/acpi/events/thinkpad_lidbutton:
event=button[ /]lid
action=/etc/acpi/thinkpad_lidbutton.sh %e
/etc/acpi/thinkpad_lidbutton.sh:
#!/bin/bash

if [  "$3" = "close" ] ; then
     /usr/sbin/pm-suspend
fi
And:
sudo chmod +x /etc/acpi/thinkpad_lidbutton.sh
sudo service acpid restart
But I cannot get it to lock the screen. I changed from Slim to to LightDM and installed light-locker; from a user prompt I can issue "light-locker-command -l" and the screen will lock, but when I do this from my acpi script I get GDBus.error ServiceUnknown org.freedesktop.screensaver. Any ideas?

Nice, in regards to GDBus.error i had this recently when i installed mate desktop for a friend on their laptop.

Try installing dconf-gsettings-backend to see if that helps.

Lomax · 2021-02-02 14:49:37

Thanks, I'll try that, but I just had a minor break through: I found this old issue on Xfce's old bugtracker: https://bugzilla.xfce.org/show_bug.cgi?id=11488 Reading a bit further down, there are details of a patch that has been applied to xfce4-power-manager, the description of which is:

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.

Last edited by Lomax (2021-02-02 14:56:54)

Lomax · 2021-02-02 15:03:11

Hmm... Digging around in dconf-editor I found the light-locker settings. One of the options is "lock-on-suspend", and this was enabled. So why didn't it lock on suspend?

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.

Last edited by Lomax (2021-02-02 15:13:25)

dice · 2021-02-02 15:04:08

have a look at the release notes for devuan beowulf.

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

Last edited by dice (2021-02-02 15:04:39)

Lomax · 2021-02-02 15:07:11

Seems I'm not alone experiencing a blank screen after resume: https://www.reddit.com/r/xfce/comments/ … umes_to_a/

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.

Lomax · 2021-02-02 20:48:19

sudo xfce4-power-manager --dump

** (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.

Last edited by Lomax (2021-02-03 15:19:07)

Lomax · 2021-02-02 21:05:23

So I noticed something odd, on my X230 I have installed the acpi-support package (or something has pulled it in as a dependency), but this was not installed on the T410. It's really just a bunch of event definitions and handler scripts for /etc/acpi - including things like volume up/down, and lid close. So this is the mechanism my X230 uses to control the volume for example, which is why I don't need to add them as Application Shortcuts on that machine. BUT. Now that I have installed acpi-support on the T410, it still doesn't work without the Application Shortcuts, despite the event looking identical on the two systems (e.g. button/volumedown VOLDN 00000080 00000000 K). So something else is missing or getting in the way.

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.

Last edited by Lomax (2021-02-02 21:06:42)

Lomax · 2021-02-02 22:44:19

The plot thickens. If I leave sudo xfce4-power-manager --dump running while I close/open the lid I get messages like this:

(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?

Lomax · 2021-02-02 23:40:50

No that didn't work - or at least not while xfce4-power-manager is running. I noticed that if I kill it then light-locker will lock the screen when I close the lid (because CheckPolicy now returns false in the acpi lid script). If xfce4-power-manager is running nothing at all happens when I close the screen. xfce4-power-manager --debug shows nothing when the lid is closed and opened.

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.

Last edited by Lomax (2021-02-03 00:49:30)

Lomax · 2021-02-03 01:45:23

When I check the box in the power management applet that says "Lock screen when system is going for sleep", xfce4-power-manager --debug outputs this:

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.

Last edited by Lomax (2021-02-03 02:03:05)

Lomax · 2021-02-03 10:04:29

Ha! I think I found the problem - and by the smell only. Something smelled wrong with the xfpm_manager_inhibit_sleep_systemd(): Inhibiting systemd sleep: handle-lid-switch messages in the xfce-power-manager --debug output, so I started digging in that spot. I soon found some interesting bug reports on the Xfce bug tracker, including this one:

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.

Last edited by Lomax (2021-02-03 14:04:54)

Lomax · 2021-02-03 12:16:56

I can haz cookie?

Lomax · 2021-02-04 10:45:31

No cookie :'(

dice · 2021-02-04 12:03:28

https://www.i-dont-care-about-cookies.eu/

Lomax · 2021-02-04 12:09:30

https://noscript.net

Lomax · 2021-02-04 14:57:40

Seriously though

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?

The officially official Devuan Forum!

#26 2021-02-02 13:47:37

Re: SOLVED: Issues using "live" install on Thinkpad T410

#27 2021-02-02 14:05:13

Re: SOLVED: Issues using "live" install on Thinkpad T410

#28 2021-02-02 14:49:37

Re: SOLVED: Issues using "live" install on Thinkpad T410

#29 2021-02-02 15:03:11

Re: SOLVED: Issues using "live" install on Thinkpad T410

#30 2021-02-02 15:04:08

Re: SOLVED: Issues using "live" install on Thinkpad T410

#31 2021-02-02 15:07:11

Re: SOLVED: Issues using "live" install on Thinkpad T410

#32 2021-02-02 20:48:19

Re: SOLVED: Issues using "live" install on Thinkpad T410

#33 2021-02-02 21:05:23

Re: SOLVED: Issues using "live" install on Thinkpad T410

#34 2021-02-02 22:44:19

Re: SOLVED: Issues using "live" install on Thinkpad T410

#35 2021-02-02 23:40:50

Re: SOLVED: Issues using "live" install on Thinkpad T410

#36 2021-02-03 01:45:23

Re: SOLVED: Issues using "live" install on Thinkpad T410

#37 2021-02-03 10:04:29

Re: SOLVED: Issues using "live" install on Thinkpad T410

#38 2021-02-03 12:16:56

Re: SOLVED: Issues using "live" install on Thinkpad T410

#39 2021-02-04 10:45:31

Re: SOLVED: Issues using "live" install on Thinkpad T410

#40 2021-02-04 12:03:28

Re: SOLVED: Issues using "live" install on Thinkpad T410

#41 2021-02-04 12:09:30

Re: SOLVED: Issues using "live" install on Thinkpad T410

#42 2021-02-04 14:57:40

Re: SOLVED: Issues using "live" install on Thinkpad T410

Board footer