3

As you probably know ACPI procfs is deprecated in new kernel versions and with sysfs I don't know of a clean way of reading the state of the lid button.

The only way I've come up with is hooking up acpid event of lid button change and writing its state to some file. But the issue with this approach is that in case you put your laptop to sleep with lid closed and resume it with lid open, you will end up with a wrong state written in that status file.

Also I wouldn't mind if there was a way to retrieve the state with acpi_call module.

rindeal
  • 758
  • 7
  • 13

2 Answers2

2

So the final TL;DR answer is: this feature is not going to be implemented, because of poor quality and buggy highly valued, NDAed intellectual property called firmware in laptops.

According to this thread on Linux kernel bug tracker, in way too many laptops firmware initializes its internal lid state variable to zero on boot - meaning "closed", even though you cannot turn the laptop on with the lid closed (this is checked by firmware before power-on).

For this reason kernel and therefore userspace can rely only upon changes in state after the device is booted and assume it's open unless proven otherwise.

Root users can check the kernel state directly by calling the appropriate input device, the C code is simple, but you can still use existing utility called "evtest" as shown in the answer by Stuart P. Bentley:

# evtest --query /dev/input/EVENT_N EV_SW SW_LID && echo open || echo closed

Normal users can call systemd's logind over D-Bus (since v240):

dbus-send --system --print-reply=literal \
    --dest=org.freedesktop.login1 /org/freedesktop/login1 \
    org.freedesktop.DBus.Properties.Get \
        string:org.freedesktop.login1.Manager string:LidClosed | \
            awk 'NR==1{print $3=="true"?"closed":"open"}'

or

busctl get-property org.freedesktop.login1 /org/freedesktop/login1 \
    org.freedesktop.login1.Manager LidClosed | \
        awk 'NR==1{print $2=="true"?"closed":"open"}'
rindeal
  • 758
  • 7
  • 13
1

I had the same question - it would appear that, sadly, there isn't one (at least, not for the way my system is set up). A patch was submitted to the Linux Kernel Mailing List in 2010 that would have added files to sysfs for querying the state of a GPIO switch, but the patch appears to have been withdrawn after the submitter was told of the ioctl() calls to read this (EVIOCG*).

The solution I'm going with is to use evtest to query the switch state (which exits 0 if the lid is open and 10 if the lid is closed):

sudo evtest --query /dev/input/event5 EV_SW SW_LID

It'd be nice if there were a version of this solution that didn't require root access, though.

Stuart P. Bentley
  • 1,619
  • 1
  • 10
  • 15
  • I suspect there may be a way to expose the GPIO pin state via exporting the underlying gpio in /sys/class/gpio, possibly using information around /proc/device-tree/gpio-keys/lid-switch to determine which gpio it'd be, but I can't make heads or tails of it. – Stuart P. Bentley Nov 07 '17 at 21:28
  • nice, now it just needs a way to reliably determine which event device is the LID switch. I looked at some udev rules and they're doing it by searching for `Lid Switch` substring. `evtest` doesn't have a command to output such a list for `grep`ping. Is it somehow doable with existing utilities? – rindeal Nov 14 '17 at 21:21