[SOLVED]Handle events differently depending on if on AC or BAT

Sweenu · 2017-10-09 09:51:06

Hello,

There seems to be many ways to handle events and act upon them.
My goal is to handle power button press and lid close differently if on AC and on BAT. What should I use to do that? Systemd, Acpid or something else ?

Thanks for your answers,
Sweenu

Last edited by Sweenu (2017-10-14 13:25:14)

seth · 2017-10-09 16:16:03

My personal perception is that acpid is far more flexible (so if I intended more complex stuff, I'd just go for that) but there's at least HandleLidSwitch and HandleLidSwitchDocked in systemd, so it might suffice your needs.
Bottom line: matter of personal preference and actual task. In doubt use acpid.

Sweenu · 2017-10-09 18:00:38

Thank you!

I started using acpid and did this little script: /etc/acpi/power.sh

#!/bin/bash                                                                                    
                                                                                               
/usr/local/bin/lock                                                                            
logger 'Session locked'                                                                        
                                                                                               
if [ $(cat /sys/class/power_supply/BAT0/status) = Discharging ]; then                          
    xset dpms force off;                                                                       
    logger 'Screen powered off';                                                               
fi

It gets logged correctly but nothing happens (no locking or no power-off of the screen...
Do you have any idea why is that?

adesh · 2017-10-09 18:10:50

Because environment is different. More specifically, $PATH variable can be different for these kind of script invocations. So, provide full path to the executables in your script.

Last edited by adesh (2017-10-09 18:11:50)

Sweenu · 2017-10-09 18:18:06

It seems like it is not the problem. I already gave the full path for the lock program. I also tried with /usr/bin/xset but it's still not working

seth · 2017-10-09 18:35:32

it's less PATH and more things like DISPLAY and XAUTHORITY - you intend to talk to the X11 server, but acpid is no X11 client ...

Sweenu · 2017-10-09 18:55:36

Oh okay, thanks I get it. So acpid isn't the right tool for doing that sort of thing ?

seth · 2017-10-09 20:11:19

It's more like your script isn't the right tool for doing that sort of thing.

ACPI events (like the lid) are completely detached from any kind of displayserver or running session - if you want to impact such server, you'll have to tell the system which one to use.
Adapt eg. https://gist.githubusercontent.com/Alad … tfile1.txt to your needs (it operates on the front console that runs xinit - if you don't use xinit for your desired X11 session(s), use a fitting process name.
The alternative are acpi handlers provided by your desktop session (if such exist) which will naturally have made this connection, but whenever you want to come up with your own acpi (or udev/udisks) handling to "do some"™ in your desktop session, such qualified conneciton has to be provided somewhere.

progandy · 2017-10-09 20:28:31

Sweenu wrote:

Oh okay, thanks I get it. So acpid isn't the right tool for doing that sort of thing ?

It is not wrong, but with acpid you start from the bottom and have to define or detect the way to access the currently running display server. seth already gave a good example.

As mention at the beginning, instead of using acpid, you could also write a service or daemon that you run inside your display session. In that case access to the display server is trivial. Then you can take an inhibitor lock to block the default systemd action and then add your own, similar to the power managers of DEs like gnome-power-manager, or lxqt-powermanagemnt. This is a bit more involved, since you'll have to subscribe to dbus events and a shell script is not enough.
https://www.freedesktop.org/wiki/Softwa … d/inhibit/

Last edited by progandy (2017-10-09 20:34:29)

Sweenu · 2017-10-09 22:04:27

Thanks for your answers, I'll try to see if I can get to understand how I can make a daemon for that. Or else, I'll just use acpid and the little snippet.

Last edited by Sweenu (2017-10-09 22:27:51)

Sweenu · 2017-10-13 10:52:50

I succeded in turning the screen off by putting "xset -display $DISPLAY dpms force off" but the locking program didn't work even with XAUTHORITY and USER exported.

So I guess using systemd would indeed be really more beneficial and clean however I lack a bit of skills for that. Do I need to make a service or is it something else? If it is indeed a service, how can I put the condition of my computer being plugged or not?
I also don't really understand why I would need to inhibit anything as, I deactivated every auto sleep in /etc/systemd/logind.conf anyway.

seth · 2017-10-13 12:22:36

What is the locking program? Does it rely on dbus?

Sweenu · 2017-10-13 13:09:46

It's i3lock-fancy (just a fork of i3lock). I have no idea if it relies on dbus though.

seth · 2017-10-13 13:18:20

i3lock only needs the DISPLAY variable set.
Whats yout actual script and what parameters do you apply on i3lock (assuming the lock exe is some wrapper script?)
Does i3lock instead of i3lock-fancy work?

Sweenu · 2017-10-13 16:00:51

with DISPLAY hardcoded :

DISPLAY=:0                                                                                     
export DISPLAY                                                                                 
                                                                                               
i3lock && logger 'Session locked'                                                              
                                                                                               
if [ $(cat /sys/class/power_supply/BAT0/status) = Discharging ]; then                          
    xset -display $DISPLAY dpms force off && logger 'Screen powered off';                      
fi

I also tried with "su <username> i3lock" but none worked even though the xset command worked.

seth · 2017-10-13 17:18:37

Neither i3lock nor slock won't run as root it seems.

su -c 'env DISPLAY=:0 i3lock' - <username>
sudo -u <username> env DISPLAY=:0 i3lock

Sweenu · 2017-10-14 13:24:46

Works that way! Thank you

Arch Linux

#1 2017-10-09 09:51:06

[SOLVED]Handle events differently depending on if on AC or BAT

#2 2017-10-09 16:16:03

Re: [SOLVED]Handle events differently depending on if on AC or BAT

#3 2017-10-09 18:00:38

Re: [SOLVED]Handle events differently depending on if on AC or BAT

#4 2017-10-09 18:10:50

Re: [SOLVED]Handle events differently depending on if on AC or BAT

#5 2017-10-09 18:18:06

Re: [SOLVED]Handle events differently depending on if on AC or BAT

#6 2017-10-09 18:35:32

Re: [SOLVED]Handle events differently depending on if on AC or BAT

#7 2017-10-09 18:55:36

Re: [SOLVED]Handle events differently depending on if on AC or BAT

#8 2017-10-09 20:11:19

Re: [SOLVED]Handle events differently depending on if on AC or BAT

#9 2017-10-09 20:28:31

Re: [SOLVED]Handle events differently depending on if on AC or BAT

#10 2017-10-09 22:04:27

Re: [SOLVED]Handle events differently depending on if on AC or BAT

#11 2017-10-13 10:52:50

Re: [SOLVED]Handle events differently depending on if on AC or BAT

#12 2017-10-13 12:22:36

Re: [SOLVED]Handle events differently depending on if on AC or BAT

#13 2017-10-13 13:09:46

Re: [SOLVED]Handle events differently depending on if on AC or BAT

#14 2017-10-13 13:18:20

Re: [SOLVED]Handle events differently depending on if on AC or BAT

#15 2017-10-13 16:00:51

Re: [SOLVED]Handle events differently depending on if on AC or BAT

#16 2017-10-13 17:18:37

Re: [SOLVED]Handle events differently depending on if on AC or BAT

#17 2017-10-14 13:24:46

Re: [SOLVED]Handle events differently depending on if on AC or BAT

Board footer