# Laptop 'close lid' action is not executed as intended

## greenfork

Hello,

I have an HP 350g1 laptop and when I close the lid the expected screen locker (/usr/bin/i3lock) does not execute. I tried to execute it with acpid, namely with /etc/acpi/default.sh or /etc/acpi/actions/lm_lid.sh. Both work fine with 

```
echo "smth" > /file.txt
```

 The script also executes correctly if I launch it from the terminal. When I close the lid, the screen switches off and switches on again when I open. Acpi events work fine by examining them with acpi_listen.

My assumption is that some kind of a kernel driver takes precedence over acpi when the lid is closing and impedes to launch i3lock this way. Can you point me to where I can hack it? Or give me some information on this matter.

/etc/acpi/actions/lm_lid.sh:

```

#! /bin/sh

/usr/bin/i3lock

logger "i3lock should work now"

```

/var/log/messages:

```

Feb 17 12:32:05 greenfork kernel: [ 4694.216649] atkbd serio0: Unknown key pressed (translated set 2, code 0xd8 on isa0060/serio0).

Feb 17 12:32:05 greenfork kernel: [ 4694.216653] atkbd serio0: Use 'setkeycodes e058 <keycode>' to make it known.

Feb 17 12:32:05 greenfork kernel: [ 4694.224617] atkbd serio0: Unknown key released (translated set 2, code 0xd8 on isa0060/serio0).

Feb 17 12:32:05 greenfork kernel: [ 4694.224620] atkbd serio0: Use 'setkeycodes e058 <keycode>' to make it known.

Feb 17 12:32:05 greenfork dmitry: i3lock should work now

Feb 17 12:32:06 greenfork kernel: [ 4694.933066] atkbd serio0: Unknown key pressed (translated set 2, code 0xd9 on isa0060/serio0).

Feb 17 12:32:06 greenfork kernel: [ 4694.933069] atkbd serio0: Use 'setkeycodes e059 <keycode>' to make it known.

Feb 17 12:32:06 greenfork kernel: [ 4694.940800] atkbd serio0: Unknown key released (translated set 2, code 0xd9 on isa0060/serio0).

Feb 17 12:32:06 greenfork kernel: [ 4694.940804] atkbd serio0: Use 'setkeycodes e059 <keycode>' to make it known.

Feb 17 12:32:06 greenfork dmitry: i3lock should work now

```

PS the script executes 2 times on lid close and lid open events. Starting i3lock just one time on lid close event doesn't work.

----------

## toralf

Ensure that it is run as your desktop user and not as root, so something like :

```
    case $action in

      brightnessdown)

        su - <user> -c "export DISPLAY=:0; <command>" ;;

```

----------

## greenfork

```
export DISPLAY=:0;
```

 helped!

Thank you so much!

----------

## The_Great_Sephiroth

I am curious as I have not had issues with this on my Plasma desktop. I normally go into Plasma's settings and configure my actions there and they "just work". I also know that it is not recommended to run acpid and a desktop because then you have two things managing inputs such as lid close. Is this laptop not using a desktop? Is the desktop something that cannot handle ACPI input on its own? I am curious because I am tossing the idea around about making a live CD based on Gentoo with XFCE or LXDE as the desktop and I "assumed" it would work like Plasma.

----------

## Hu

Where did you see the advice not to use acpid on a desktop computer?  As for why it works for you, perhaps your computer delivers lid-close as some other type of event.  It's also possible that Plasma has its own ACPI hooks so that it is notified and performs the appropriate action.  Although using ACPI to notify about lid close makes sense from a hardware perspective, it's a sufficiently counterintuitive approach for most users that the Plasma developers may have decided to compensate for it in software, rather than document the workaround and expect users to apply it individually.

----------

## greenfork

 *The_Great_Sephiroth wrote:*   

> Is this laptop not using a desktop? Is the desktop something that cannot handle ACPI input on its own?

 

I use i3-gaps as a window manager, so no desktop environment. But last time I used xfce4 on arch linux, I installed slock screen locker and ticked 'lock on lid close' in power management, then it magically found my locker and applied it without any further actions.

----------

## The_Great_Sephiroth

Hu, first Google search result. Read the box just below the description. It has been this way for years. You're not supposed to run acpid and the big desktops at the same time. I only use acpid on shell-only servers.

acpid - ArchWiki

Yes, I know we're not Arch, but we're right behind them AND I could swear I read this on OUR wiki too. I cannot find the info right now, however.

----------

## Ant P.

 *Hu wrote:*   

> Where did you see the advice not to use acpid on a desktop computer?

 

The bulk of acpid's default handlers is (fragile and outdated) code to get out of the way if it sees a DE running. The only other function it provides on its own is to wire up the power button to sysvinit shutdown, and I'm not aware of any packages that add to it in a meaningful way, probably because replacing the default cruft requires causing file collisions or editing by hand. It really needs an eselect module to be useful, IMO.

----------

## Hu

We have a terminology problem here.  When I read "desktop" without a qualifier, I think of a desktop computer, a tower that is inconvenient to move, as opposed to a laptop computer or rack-mounted server.  You are using it as shorthand for "big bloated desktop software environment."  :Smile:   Acpid works fine on tower systems that don't have other programs competing for ACPI events, such as most minimal systems oriented toward using a window manager and a few select programs, rather than the massive "Desktop Environments" like GNOME or Plasma.

I've always used acpid on towers, but only for the purpose of wiring the power button to halt or hibernate, depending on use case.  I do this even on graphical systems, but only those that use a basic window manager, rather than a full desktop environment.  I considered it normal to edit the acpid scripts to my needs.

----------

## khayyam

 *toralf wrote:*   

> Ensure that it is run as your desktop user and not as root, so something like :
> 
> ```
>     case $action in
> 
> ...

 

toralf, greenfork ... let's not hardcode things that can be aquired from the environment:

```
case "$group" in

   button)

      case "$action" in

[...]

                 lid) case "$id" in

            close) /etc/acpi/actions/lid.sh ;;

            *) log_unhandled $* ;;

            esac ;;
```

```
#!/bin/sh

set -e

xpid="$(pgrep -n X)"

xuser="$(ps -o user --no-headers $xpid)"

display="$(egrep -aoz ':[0-9](.[0-9])?' /proc/$xpid/cmdline)"

export XAUTHORITY="/home/$xuser/.Xauthority"

export DISPLAY="$display"

su - "$xuser" -c /usr/bin/i3lock
```

EDIT: as an afterthought, you probably want:

```
su - "$xuser" -c "/usr/bin/i3lock ; xset dpms force standby"
```

HTH & best ... khay

----------

## The_Great_Sephiroth

Ah I see. Yes I refer to "desktop" when I should have used "DE" or "WM". Yes, I use acpid on towers running shell-only installs. I simply don't use it on KDE/Plasma systems because it is already handled. I see we are actually on the same page.

----------

