Who is handling the lid if acpid doesn't?

CREED0R · 2013-09-20 09:04:30

Hi guys,

I got a Samsung Series 9 laptop and since my latest system update including the kernel and systemd I lost my "suspend on lid".
This had worked out-of-the-box since day 1 so I never really thought about what actually made it happen. Now on further investigating
why it doesn't work anymore, I came to realize that I have no idea who is actually responsible for suspending and resuming when the lid is closed.

Here's my output

uname:

# uname -a
Linux uknarf 3.11.1-1-ARCH #1 SMP PREEMPT Sat Sep 14 19:30:21 CEST 2013 x86_64 GNU/Linux

acpid is running:

# ps -e | grep acpid
 1000 ?        00:00:00 acpid

lsmod:

# lsmod
Module                  Size  Used by
joydev                  9663  0 
uvcvideo               72804  0 
videobuf2_vmalloc       3272  1 uvcvideo
videobuf2_memops        2335  1 videobuf2_vmalloc
videobuf2_core         27797  1 uvcvideo
videodev              110188  2 uvcvideo,videobuf2_core
media                  11591  2 uvcvideo,videodev
x86_pkg_temp_thermal     6959  0 
intel_powerclamp        8802  0 
kvm_intel             129393  0 
kvm                   379223  1 kvm_intel
crc32_pclmul            3019  0 
crc32c_intel           14249  0 
btusb                  18496  0 
bluetooth             308340  1 btusb
ghash_clmulni_intel     4501  0 
cryptd                  8473  1 ghash_clmulni_intel
coretemp                6326  0 
arc4                    2000  2 
snd_hda_codec_hdmi     30336  1 
snd_hda_codec_realtek    37032  1 
iwldvm                172354  0 
iTCO_wdt                5407  0 
iTCO_vendor_support     1929  1 iTCO_wdt
mac80211              453808  1 iwldvm
psmouse                85356  0 
samsung_laptop          8593  0 
snd_hda_intel          36520  1 
i915                  610807  2 
r8169                  58391  0 
microcode              13488  0 
evdev                  10693  18 
serio_raw               5041  0 
pcspkr                  2027  0 
snd_hda_codec         148129  3 snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_intel
mii                     4027  1 r8169
fan                     2753  0 
battery                 6925  0 
intel_agp              10872  1 i915
snd_hwdep               6332  1 snd_hda_codec
iwlwifi               137145  1 iwldvm
intel_gtt              12664  2 i915,intel_agp
snd_pcm                77765  3 snd_hda_codec_hdmi,snd_hda_codec,snd_hda_intel
wmi                     8347  0 
thermal                 8620  0 
video                  11380  2 i915,samsung_laptop
cfg80211              402729  3 iwlwifi,mac80211,iwldvm
drm_kms_helper         35854  1 i915
rfkill                 15698  4 cfg80211,samsung_laptop,bluetooth
snd_page_alloc          7234  2 snd_pcm,snd_hda_intel
drm                   235996  3 i915,drm_kms_helper
snd_timer              18718  1 snd_pcm
mei_me                  9296  0 
snd                    59141  9 snd_hda_codec_realtek,snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_pcm,snd_hda_codec,snd_hda_intel
mperf                   1267  0 
ac                      3324  0 
mei                    61875  1 mei_me
i2c_algo_bit            5391  1 i915
soundcore               5450  1 snd
button                  4669  1 i915
i2c_i801               11269  0 
shpchp                 25457  0 
lpc_ich                13112  0 
i2c_core               23720  6 drm,i915,i2c_i801,drm_kms_helper,i2c_algo_bit,videodev
processor              24917  0 
ext4                  470412  1 
crc16                   1359  2 ext4,bluetooth
mbcache                 5866  1 ext4
jbd2                   83376  1 ext4
sd_mod                 30899  3 
ahci                   22888  2 
libahci                21393  1 ahci
ehci_pci                4120  0 
libata                171318  2 ahci,libahci
ehci_hcd               48084  1 ehci_pci
xhci_hcd               91419  0 
scsi_mod              128695  2 libata,sd_mod
usbcore               178049  5 btusb,uvcvideo,ehci_hcd,ehci_pci,xhci_hcd
usb_common              1648  1 usbcore

acpid handler:

# cat /etc/acpi/handler.sh 
#!/bin/bash
# Default acpi script that takes an entry for all actions

case "$1" in
    button/power)
        case "$2" in
            PBTN|PWRF)
                logger 'PowerButton pressed'
                ;;
            *)
                logger "ACPI action undefined: $2"
                ;;
        esac
        ;;
    button/sleep)
        case "$2" in
            SLPB|SBTN)
                logger 'SleepButton pressed'
                ;;
            *)
                logger "ACPI action undefined: $2"
                ;;
        esac
        ;;
    ac_adapter)
        case "$2" in
            AC|ACAD|ADP0)
                case "$4" in
                    00000000)
                        logger 'AC unpluged'
                        ;;
                    00000001)
                        logger 'AC pluged'
                        ;;
                esac
                ;;
            *)
                logger "ACPI action undefined: $2"
                ;;
        esac
        ;;
    battery)
        case "$2" in
            BAT0)
                case "$4" in
                    00000000)
                        logger 'Battery online'
                        ;;
                    00000001)
                        logger 'Battery offline'
                        ;;
                esac
                ;;
            CPU0)
                ;;
            *)  logger "ACPI action undefined: $2" ;;
        esac
        ;;
    button/lid)
        case "$3" in
            close)
                logger 'LID closed'
                ;;
            open)
                logger 'LID opened'
                ;;
            *)
                logger "ACPI action undefined: $3"
                ;;
    esac
    ;;
    *)
        logger "ACPI group/action undefined: $1 / $2"
        ;;
esac

# vim:set ts=4 sw=4 ft=sh et:

I always thought lid close/open were acpi events that got handled by the acpi-daemon, which in fact is running in my case. But as you can see, my handler script is completely useless.
Funny enough, if I '# systemctrl suspend' on purpose the system goes into suspend and can be woken up by closing and re-opening the lid. It even resumes correctly, so there must
be something that recognizes the lid being opened and resumes the system.

Who does that?

Since the change to systemd I never took the time to get used to it and since the last update also changed systemd I assume it has something to do with systemd?
I've read the logind thing can actually make some trouble, but looking at my logind.conf I don't think that's it:

logind.conf:

# cat /etc/systemd/logind.conf 
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.
#
# See logind.conf(5) for details

[Login]
#NAutoVTs=6
#ReserveVT=6
#KillUserProcesses=no
#KillOnlyUsers=
#KillExcludeUsers=root
#InhibitDelayMaxSec=5
#HandlePowerKey=poweroff
#HandleSuspendKey=suspend
#HandleHibernateKey=hibernate
#HandleLidSwitch=suspend
#PowerKeyIgnoreInhibited=no
#SuspendKeyIgnoreInhibited=no
#HibernateKeyIgnoreInhibited=no
#LidSwitchIgnoreInhibited=yes
#IdleAction=ignore
#IdleActionSec=30min

So, do any of you guys have any idea how to restore the "suspend-on-lid" feature? It's really buggin' me that it's not working anymore
and that I have no idea how it actually worked before.

Thanks & Greetings
CREED0R

Last edited by CREED0R (2013-09-20 09:18:06)

BUR · 2013-09-20 09:27:12

Have you tried to uncomment this line?

#HandleLidSwitch=suspend

wwn · 2013-09-20 09:36:47

here I got some valuable informations:
https://bbs.archlinux.org/viewtopic.php?id=169157

CREED0R · 2013-09-20 09:50:08

Hi there,

thanks for your answers!

I've tried to uncomment HandleLidSwitch in the logind.conf, followed by a reboot. But this doesn't change a thing.
What's interesting is, that when I start a youtube video and close the lid, the screen get's black but the music continues.
When I open the lid everything's back to normal, even the wifi connection is still on. Not at all like a couple of days ago, where
closing/opening the lid meant reassociating with the wifi AP...

So bottom line: logind.conf HandleLidSwitch didn't help but something else must recognize the lid close and blank the screen....

-CREED0R

Edit:
Maybe I should mention, that if I press the 'power' button, my laptop shuts down. Which exactly what I want to happen,
so I'm happy with that and this, too, has worked since day 1 and was not changed by the update.

Who shuts down my laptop, when I press the power button? Systemd I guess, but where can I find the place where this is
configured?

I suppose it's this line in the /usr/lib/udev/rules.d/70-power-switch.rules:

SUBSYSTEM=="input", KERNEL=="event*", SUBSYSTEMS=="acpi", TAG+="power-switch"

Am I right?

Edit 2:
NOW it get's really confusing. What's this suppose to mean?

# # cat /etc/systemd/logind.conf 
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.
#
# See logind.conf(5) for details

[Login]
#NAutoVTs=6
#ReserveVT=6
#KillUserProcesses=no
#KillOnlyUsers=
#KillExcludeUsers=root
#InhibitDelayMaxSec=5
#HandlePowerKey=poweroff
#HandleSuspendKey=suspend
#HandleHibernateKey=hibernate
HandleLidSwitch=suspend
#PowerKeyIgnoreInhibited=no
#SuspendKeyIgnoreInhibited=no
#HibernateKeyIgnoreInhibited=no
#LidSwitchIgnoreInhibited=yes
#IdleAction=ignore
#IdleActionSec=30min

# loginctl show-session
NAutoVTs=6
KillExcludeUsers=root
KillUserProcesses=no
IdleHint=no
IdleSinceHint=0
IdleSinceHintMonotonic=0
InhibitDelayMaxUSec=5s
HandlePowerKey=poweroff
HandleSuspendKey=suspend
HandleHibernateKey=hibernate
HandleLidSwitch=suspend
IdleAction=ignore
IdleActionUSec=30min
PreparingForShutdown=no
PreparingForSleep=no

This could explain why pressing the power button shuts down the laptop, right?

Last edited by CREED0R (2013-09-20 10:09:10)

Trilby · 2013-09-20 10:26:22

CREED0R wrote:

I've tried to uncomment HandleLidSwitch in the logind.conf, followed by a reboot. But this doesn't change a thing

The answer to all your questions is systemd/logind.

This is well documented in the wiki, man pages, and forum posts here. You uncommented the default setting to suspend when the lid switch is activated ... but you didn't change it!

man logind.conf

EDIT: I think I misread, or confused this with a different but similar thread. I was thinking you wanted to disable suspending on lid switch. Sorry for the noise.

Last edited by Trilby (2013-09-20 17:40:17)

CREED0R · 2013-09-20 11:41:00

I have read the documentation, but I still not seem to get it just yet.

Why should I change the HandleLidSwitch if I want it to suspend on lid close? Leaving the default setting untouched besides uncommenting the option seemed to be the right thing to do.
The problem is, that although it is set to suspend in the logind.conf it doesn't suspend.

When I look at all the other settings, which are still commented and therefore inactive in the logind.conf, I don't get how when I query the current logind-session info, they can be 'active'...

So it's two-fold:
1) The settings in the logind.conf file don't match what the session tells me
2) Although the settings are set to suspend on lid close in the logind.conf as well as in the current session (loginctrl show-session) my laptop still doesn't suspend on lid close.

Last edited by CREED0R (2013-09-20 11:44:06)

65kid · 2013-09-20 11:50:39

I just tested this on my Series 9 and it doesn't suspend on lid close for me either. I never actually used this, so I didn't really notice it.

You can see acpi events by starting the acpid service and running acpi_listen. On my machine there is no ACPI event when the lid is closed, meaning this is probably a bug in the kernel.

CREED0R · 2013-09-20 11:55:17

Yeah, I have also recognized this that acpi_listen doesn't register the lid close event but didn't know how to process that information.
This being a kernel bug never occured to me since I thought I'm doing something wrong ^^.

Thanks, guess I ... just wait? 'till it gets fixed ?

Edit:
Wait wait wait... how can this be a kernel bug? The last kernel I used, was from the AUR 'linux-git' package. So I've been using the unstable 3.11.
Now that it has become stable I upgraded to the mainline 3.11 kernel from the official Arch repos.

I actually changed back now, to the 3.11-1-dirty one and the problem still exists, although it didn't before. So I don't know if they introduced a
new bug or whether it's systemd. Because that changed too and now I'm using the (supposed to be) working kernel with the new systemd version
and it doesn't work. Maybe I'm reversing the systemd update too, just to be sure what's causing what here ...

Edit #2:
Okay, nevermind. I backrolled everything to the setup that I thought existed before, which means: linux-git, linux-firmware-git and systemd-204.
But even with my old setup it doesn't suspend on lid close, which - I am 100% - it did before, because I use suspend on lid close nearly
10 times a day and everytime the wifi reassoc had to happen, which is my indicator that the system really suspended.

Now I'm back to current setup, linux, linux-firmware and systemd-207 all from the official repos and waiting for some magical patch to happen ^^

Last edited by CREED0R (2013-09-20 12:28:17)

qwazix · 2013-11-28 20:20:56

Hello, first post here. I'm not an arch user but I have some info that might be useful. If you press the battery disconnect button on the bottom of the Series9 while the laptop is not on the power, the suspend on lid close returns for some time, until it get's lost again a few days later. When in the state of suspend-on-lid not working, in my case, it also ignores the power adapter, and if booted in uefi mode, the keyboard backlight doesn't work.

I'm running ubuntu on it now btw.

Arch Linux

#1 2013-09-20 09:04:30

Who is handling the lid if acpid doesn't?

#2 2013-09-20 09:27:12

Re: Who is handling the lid if acpid doesn't?

#3 2013-09-20 09:36:47

Re: Who is handling the lid if acpid doesn't?

#4 2013-09-20 09:50:08

Re: Who is handling the lid if acpid doesn't?

#5 2013-09-20 10:26:22

Re: Who is handling the lid if acpid doesn't?

#6 2013-09-20 11:41:00

Re: Who is handling the lid if acpid doesn't?

#7 2013-09-20 11:50:39

Re: Who is handling the lid if acpid doesn't?

#8 2013-09-20 11:55:17

Re: Who is handling the lid if acpid doesn't?

#9 2013-11-28 20:20:56

Re: Who is handling the lid if acpid doesn't?

Board footer