You are not logged in.
I've been a tester of Devuan since the first beta release, and while most issues I've encountered have been resolved, there always remains work to be done. Allow me to shed some light on and draw attention towards ACPI event handling.
First, let me preface this with stating the obvious. My download of Devuan matched both the signature and the checksum provided. I installed using a flash drive with default install options.
I wrote the ISO file to my flash drive using:
dd if=ISOIMAGE of=DeviceName
.
My hardware is as follows:
System:
Kernel: 3.16.0-4-amd64 x86_64 (64 bit)
Desktop: N/A Distro: Devuan GNU/Linux 1
Machine:
System: Dell product: Latitude D630
Mobo: Dell model: 0KU184 Bios: Dell v: A15 date: 11/24/2008
CPU:
Dual core Intel Core2 Duo T9300 (-MCP-) cache: 6144 KB
Clock Speeds: 1: 800 MHz 2: 1600 MHz
Graphics:
Card: Intel Mobile GM965/GL960 Integrated Graphics Controller (primary)
Display Server: X.Org 1.16.4 drivers: intel (unloaded: fbdev,vesa)
Resolution: 1440x900@59.90hz
GLX Renderer: Mesa DRI Intel 965GM GLX Version: 2.1 Mesa 10.3.2
Audio:
Card Intel 82801H (ICH8 Family) HD Audio Controller
driver: snd_hda_intel
Sound: Advanced Linux Sound Architecture v: k3.16.0-4-amd64
Network:
Card-1: Intel Ultimate N WiFi Link 5300 driver: iwlwifi
IF: wlan0 state: up mac: ##:##:##:##:##:##
Card-2: Broadcom NetXtreme BCM5755M Gigabit Ethernet PCI Express
driver: tg3
IF: eth0 state: down mac: ##:##:##:##:##:##
Everything went without a hitch during installation. Once I booted into my new Devuan Jessie install, I proceeded to configure the panel.
The Xfce Power Manager Plugin for the Panel does not display the battery icon properly and is frozen, displaying a static image of a power plug (the one usually only displayed when charging).
ALSA or the Audio Mixer plugin will function with the Mute Button on my Laptop; however, only the Master channel works as expected while the Speaker channel will only mute but never unmutes. I must meticulously open ALSA Mixer and manually unmute the Speaker channel in order to restore audio functionality to my Laptop.
Now, for the pinnacle of dysfunction, my Laptop Lid Debacle. I attempted configuring Xfce Power Manager, as I have done hundreds/thousands of times before, to Suspend my Laptop when the Lid is closed (irrespective of charging status). Closing the lid had no effect other than to turn my screen off. Opening my laptop turned the screen on. The problem isn't that the Lid Button ACPI event wasn't registering but, rather, that the event wasn't triggering suspend as it was configured in Xfce Power Manager.
~$ acpi_listen
button/lid LID close
button/lid LID open
The aforementioned code snippet proves that my Laptop Lid is capable of registering to my system, so I delved deeper and found some ACPI events from various contributors on obscure support forums which could function in /etc/acpi/events/ for the purpose I intend (and perhaps others as well). I followed all recommended permissions attributes on all of these files foremost.
This was saved as lm_lid in /etc/acpi/events/
event=button/lid.*
action=/etc/acpi/lid.sh
This shell script was the counterpart to lm_lid and was saved as lid.sh in /etc/acpi/
#!/bin/sh
grep -q closed /proc/acpi/button/lid/*/state
if [ $? = 0 ]
then
/etc/acpi/Laptop/lidman-trigger;
else
/etc/acpi/Laptop/lidman-trigger;
fi
I saved the following in /etc/sudoers.d/Lidpermit using visudo -f
InsertUsernameHere ALL=(ALL:ALL) NOPASSWD:/etc/acpi/Laptop/export_x_info
This was saved as export_x_info in /etc/acpi/Laptop/ and added to Xfce Session and Startup.
# Export the dbus session address on startup so it can be used by any other environment
sleep 5
env | grep DBUS_SESSION_BUS_ADDRESS >> /home/clokedfigure/.Laptop/lidman
echo 'export DBUS_SESSION_BUS_ADDRESS' >> /home/clokedfigure/.Laptop/lidman
# Export XAUTHORITY value on startup so it can be used by cron
env | grep XAUTHORITY >> /home/clokedfigure/.Laptop/lidman
echo 'export XAUTHORITY' >> /home/clokedfigure/.Laptop/lidman
lidman was saved in /home/InsertUsernameHere/.Laptop/ & since it is generated by export_x_info, I suspect therein lies the dilemma. The DBUS_SESSION_BUS_ADDRESS is most notably missing, yet when I manually enter the command as root, the expected DBUS_SESSION_BUS_ADDRESS makes an appearance in Lidman.
export DBUS_SESSION_BUS_ADDRESS
XAUTHORITY=/home/clokedfigure/.Xauthority
export XAUTHORITY
And finally the insignificant lidman-trigger saved in /home/InsertUsernameHere/.Laptop/
source /home/clokedfigure/.Laptop/lidman
If anyone can inform me of the best approach to resolving this sooner, I'd very much appreciate your efforts. I've shown most of what I could glean from a day's worth of research, trial, and error; please throw some compassion my way. Thank you!
Last edited by Adhil (2017-10-24 16:43:22)
Offline
I can confirm this is an issue using both XFCE power manager, and Mate power manager, also tried using XFCE pm in Openbox. No lid-triggered events to be had here.
The power icon is also static in Mate and won't update it's status during session, I suspect something in removed systemd components/actions in this case as it works in Debian, but I could be wrong about that.
Mate power manager does very little in fact these days as hibernate and suspend functions seem also to be broken and are grayed out in the gui, so it really doesn't do squat.
https://sourceforge.net/projects/vuu-do/
Vuu-do GNU/Linux, minimal Devuan-based openbox systems to build on, maximal versions if you prefer your linux fully-loaded.
Please donate to support Devuan and init freedom! https://devuan.org/os/donate
Offline
I'm not sure what that "obscure" scripting attempts to do, but you really only need the following script as /etc/acpi/lid.sh:
#!/bin/bash
if [ "$3" = "close" ] ; then
/usr/sbin/pm-suspend
fi
The program pm-suspend is from the pm-utils package.
Of course, if you want screen lock, the script needs some more, and it depends of which screen locking you are using.
Offline
I'm not sure what that "obscure" scripting attempts to do, but you really only need the following script as /etc/acpi/lid.sh:
#!/bin/bash if [ "$3" = "close" ] ; then /usr/sbin/pm-suspend fi
The program pm-suspend is from the pm-utils package.
Of course, if you want screen lock, the script needs some more, and it depends of which screen locking you are using.
Well that's a fix for laptop lid events, guess you would need some more code to be able choose hibernate or the screen locker you mentioned.
But unfortunately it doesn't address these power manager bugs. Are there any gui power managers available that don't have multiple broken features?
The mate one in particular is so bad it ought to be pulled until there's a version that actually does something.
https://sourceforge.net/projects/vuu-do/
Vuu-do GNU/Linux, minimal Devuan-based openbox systems to build on, maximal versions if you prefer your linux fully-loaded.
Please donate to support Devuan and init freedom! https://devuan.org/os/donate
Offline
Is it a fix if I've changed the lid.sh script as ralph suggested, rebooted, attempted restarting acpi daemons, and still to no avail? I don't mean this in a snide way either, I'm just stating I've tried the code ralph ronnquist volunteered to provide to no effect. I forgot to mention in the initial post that suspend works when run from the terminal, but not using the pm-suspend command. I do have pm-utils installed (by default during Devuan's installation); however, pm-suspend does not work unless you are the root user as per my terminal:
InsertUsernameHere@HostMachine:~$ /usr/sbin/pm-suspend
This utility may only be run by the root user.
Only typing suspend or clicking Log Out and manually selecting Suspend works, and intermittently at that! As I write this now, typing suspend just hangs in the terminal. Logging into a root terminal, I found pm-suspend command to work flawlessly regardless. This has me stymied.
Perhaps adding pm-suspend to my sudoers.d file and prefixing the command with sudo might work? My other thought was with changing lm_lid from this:
event=button/lid.*
action=/etc/acpi/lid.sh
To this:
event=button[ /]lid.*
action=/etc/acpi/lid.sh
Anyone who can help to solve this will be greatly lauded by the community, especially me. I'm going to keep working on this when I have time; until then, I encourage others to post their suggestions and potential solutions for the community.
P.S. Thanks for weighing in Green Jeans, its nice to know others are experiencing the same frustrations; the more prominent an issue this becomes, the greater attention that will be garnered from developers like you, thank you!
Last edited by Adhil (2017-07-12 16:05:24)
Offline
I'm afraid I overlooked the importance of having a working event declaration file in /etc/acpi/events. Mine is:
event=button[ /]lid
action=/etc/acpi/lidbtn-suspend.sh %e
and my script is named accordingly.
Especially the %e on the invoked command is important; it gets replaced with the triggering input line from acpid
button/lid LID close
or
button/lid LID open
or
any other acpid event lines
and it thus gives three arguments to the script, the third of which is the lid action. The script I suggested peeps a those, and requires the third to be close in order to suspend.
Note that your alternative pattern lines are all ok, I think, in the sense of matching the event line. An observation though (irrelevant as it is), since the pattern is a regular expression, an ending of d* says that there must be zero or more d at that match point. I guess you intended it to be d.* (saying "a d followed by whatever"). But "followed by whatever" is implied unless there is a $ at the end.
Hopefully that can make it work for you.
Offline
I'll be gone for the next week, but I shall return and reinvigorate this dying thread. By July 24th, you'll hear from me again, hopefully with a report of success. I will not allow this thread to be left abandoned.
Offline
I was just posting to let everyone know that I did a fresh install on a Thinkpad T440 with xfce4 and it would not sleep on lid close. Using this thread and some searching I got it to work.
First was running visudo as root to allow my user to run pm-suspend
# username suspend permission
username ALL=NOPASSWD: /usr/sbin/pm-suspend
then I created an acpi event by creating /etc/acpi/events/lid
event=button/lid
action=/etc/acpi/actions/lid_suspend.sh %e
(make sure to make it executable with "chmod +x lid")
Finally I created the folder and file /etc/acpi/actions/lid_suspend.sh
#!/bin/bash
if [ "$3" = "close" ] ; then
/usr/sbin/pm-suspend
fi
(chmod +x lid_suspend)
I did "service acpid restart" as root for good luck and it worked!
Thank you everyone for your help!
Last edited by quadcricket (2017-10-16 20:49:53)
Offline
Will be trying this out on mine later, thanks for posting!
I was just posting to let everyone know that I did a fresh install on a Thinkpad T440 with xfce4 and it would not sleep on lid close. Using this thread and some searching I got it to work.
First was running visudo as root to allow my user to run pm-suspend
# username suspend permission username ALL=NOPASSWD: /usr/sbin/pm-suspend
then I created an acpi event by creating /etc/acpi/events/lid
event=button/lid action=/etc/acpi/actions/lid_suspend.sh %e
(make sure to make it executable with "chmod +x lid")
Finally I created the folder and file /etc/acpi/actions/lid_suspend.sh
#!/bin/bash if [ "$3" = "close" ] ; then /usr/sbin/pm-suspend fi
(chmod +x lid_suspend)
I did "service restart acpid" for good luck and it worked!
Thank you everyone for your help!
https://sourceforge.net/projects/vuu-do/
Vuu-do GNU/Linux, minimal Devuan-based openbox systems to build on, maximal versions if you prefer your linux fully-loaded.
Please donate to support Devuan and init freedom! https://devuan.org/os/donate
Offline
I just had to use this again for a fresh install of Devuan and XFCE on a Thinkpad x220. It worked on this machine too.
Offline
Just a quick update. The above method worked for me, but I used obsession-exit to suspend since it's already on my systems, bonus: didn't have to give sudo privilege to user to do it this way.
#!/bin/bash
if [ "$3" = "close" ] ; then
/usr/bin/obsession-exit -s
fi
I imagine you can just add " && [lock program or command] " to that command and it will lock as well?
https://sourceforge.net/projects/vuu-do/
Vuu-do GNU/Linux, minimal Devuan-based openbox systems to build on, maximal versions if you prefer your linux fully-loaded.
Please donate to support Devuan and init freedom! https://devuan.org/os/donate
Offline
Ideally you should insert the locking program before the suspend action as otherwise it'll wake up unlocked until the locking starts. For example:
if [ "$3" = "close" ] ; then
DISPLAY=:0 su -c "xtrlock -b" ralph &
/usr/bin/obsession-exit -s
fi
Note also that (afaik) the lid button script is run by acpid as root and not "the DE user", so a sudo isn't needed, but some way to ensure GUI access is. The added command line above includes the two parts of making the locking program (xtrlock) have the right $DISPLAY set up, and (via su) be the right user (for my laptop).
Offline
Thanks Ralph, i'll keep messing with it, right now can't get the locker to work with it (i3lock) no matter what I do.
And doesn't look like there's a way to mod the XFCE power manager to run the proper commands, it offers close/lid options but they don't work. This is what's really needed IMO, but I guess the power manager would need to be modded and re-compiled.
Last edited by greenjeans (2017-10-16 22:44:44)
https://sourceforge.net/projects/vuu-do/
Vuu-do GNU/Linux, minimal Devuan-based openbox systems to build on, maximal versions if you prefer your linux fully-loaded.
Please donate to support Devuan and init freedom! https://devuan.org/os/donate
Offline
I confirm all problems still persist in xfce on Devuan:
- no lid-based actions in xfce (only via acpi-script hack -> but this still doesn't trigger anything power-related in the xfce gui)
- no battery actions -> this is particularly annoying as you don't get warning when you run out of battery or also don't see if you are charging or not
- strangly: volume and display buttons work
- power button works sometimes (usually not)
I tried diffrent versions of xfce4-power-manager, upower, acpid - even from ceres - all don't work.
I don't actually understand why all this doesn't work? Anybody has a better idea what is missing in xfce4-power-manager?
All this does work on voidlinux (I haven't tried artix yet).
Offline
I confirm all problems still persist in xfce on Devuan:
- no lid-based actions in xfce (only via acpi-script hack -> but this still doesn't trigger anything power-related in the xfce gui)
- no battery actions -> this is particularly annoying as you don't get warning when you run out of battery or also don't see if you are charging or not
- strangly: volume and display buttons work
- power button works sometimes (usually not)I tried diffrent versions of xfce4-power-manager, upower, acpid - even from ceres - all don't work.
I don't actually understand why all this doesn't work? Anybody has a better idea what is missing in xfce4-power-manager?
All this does work on voidlinux (I haven't tried artix yet).
It is disappointing, the Mate power manager is even worse.
You got all that to work on voidlinux? Maybe doublecheck packagelists and see if there's something extra that's helping it work right in the other distro? Version used in voidlinux?
https://sourceforge.net/projects/vuu-do/
Vuu-do GNU/Linux, minimal Devuan-based openbox systems to build on, maximal versions if you prefer your linux fully-loaded.
Please donate to support Devuan and init freedom! https://devuan.org/os/donate
Offline
acpi-script hack
That's such a beautifully mis-informed notion!
It reads as a praise to the layers and layers of code in between the person and the action, simply to make a drawing of it, so it can be operated without articulated thought.
Other than that, I have nothing
Offline
This works for me for pm-suspend/hibernate, and works with acpi/lid.sh:
/etc/pm/sleep.d/00lock
#!/bin/sh
# Specify the display for acpi
export DISPLAY=:0
# Run a specified program as user
run(){
su -c "$1" omega
}
# Run programs for pm-utils
case $1 in
suspend|hibernate)
run /usr/bin/slock &
;;
resume|thaw)
;;
esac
/etc/acpi/lid.sh
#!/bin/sh
if [ "$3" = "close" ]; then
/usr/sbin/pm-suspend
fi
Last edited by siva (2018-05-23 14:01:38)
Offline
BUMP!
I have a solution to the lid suspend problem that works without pm-utils
/etc/acpi/events/lid:
event=button/lid
action=/etc/acpi/lid
/etc/acpi/lid (must be executable):
#!/bin/sh
grep -q close /proc/acpi/button/lid/LID/state && echo mem > /sys/power/state
Then reload the configuration:
# pkill -hup acpid
(This presumes that acpid is already installed and started.)
Last edited by Head_on_a_Stick (2019-03-26 18:35:58)
Brianna Ghey — Rest In Power
Offline
Thanks Head on a Stick,
That was very useful. As an additional note...
On my Dell XPS 13 I also had to check the contents of /sys/power/mem_sleep as the default (between brackets) was s2idle and it indicated that also 'deep' or suspend to RAM was possible, saving even more power.
I followed the instructions of https://www.kernel.org/doc/html/v4.18/a … tates.html to make 'deep' the default by adding it to /etc/default/grub e.g.
GRUB_CMDLINE_LINUX_DEFAULT="quiet mem_sleep_default=deep"
and ran 'update-grub' afterwards.
Offline