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.


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.

  • 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 7 '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 grepping. Is it somehow doable with existing utilities? – rindeal Nov 14 '17 at 21:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.