I'm trying to make my linux laptop (a T400 ThinkPad with Libreboot) behave exactly the same way whether the lid is open or closed. To put it another way, I'm trying to simulate a laptop with a broken lid switch that's always in the "lid open" position. I'm looking for a low-level solution that does not require a particular init system or a particular power manager--just software that's expected to be present (or usable) in any GNU/Linux system.

My two OSes are Devuan ASCII (64 bit) and Tiny Core Linux 10.1 (64 bit) running Xorg and fluxbox in case it matters. Kernel versions are 4.16.2 (Devuan) and 4.19.10 (Tiny Core Linux).


I'm using xscreensaver (set to start playing its animations after 1 minute of inactivity) as my test application because I've noticed that xscreensaver does not kick in and start playing animations while the lid is closed. So when I can close the lid, wait just over a minute, re-open the lid, and find that an xscreensaver animation is playing, I'll know that I've found a solution.


  1. Mechanical. My laptop is a T400 which uses a little magnet above the Bluetooth LED as its lid switch. Putting a tiny refrigerator magnet at that spot causes the lid switch to be stuck in the "closed" position and the xscreensaver test fails. Booting with button.lid_init_state=open kernel boot parameter does not help.

  2. button module boot parameters. This built-in module is the driver for the laptop's lid switch. Using button.lid_report_interval=0 or =-1 or =500000 does not help.

  3. i915 module boot parameters. The kernel in Devuan supports the i915.panel_ignore_lid boot parameter. Setting it to -2 does not help pass the xscreensaver test.

  4. video module boot parameters. Using video.report_key_events=0 does not help.

  5. ACPI. Disabling it with acpi=off kernel boot parameter does not help pass the test.

  6. Disabling the lid switch. Amazingly, disabling the lid switch does not help. It is difficult to disable the button module because it built-in to the kernel (i.e., it shows up with ls /sys/module but not with lsmod). However, it is possible to unbind all the devices that use the button module after the system is booted:

  # 1. find the devices that use the button driver:
$ ls /sys/bus/acpi/drivers/button
LNXPWRBN:00  PNP0C0D:00   PNP0C0E:00   bind         uevent       unbind
  # 2. disable the devices one by one:
$ echo "LNXPWRBN:00" | sudo tee /sys/bus/acpi/drivers/button/unbind
$ echo "PNP0C0D:00" | sudo tee /sys/bus/acpi/drivers/button/unbind
$ echo "PNP0C0E:00" | sudo tee /sys/bus/acpi/drivers/button/unbind
  # 3. satisfy oneself that the devices are gone:
$ ls /sys/bus/acpi/drivers/button
bind    uevent  unbind

Even with this, xscreensaver animations kick in while lid is open but never when lid is closed.

  1. Capturing touchpad events. I noticed by watching the output of cat /dev/input/event5 that opening and closing the laptop lid causes the synaptics touchpad to generate some input. Grabbing all the input with evtest --grab /dev/input/event5 >/dev/null does not help.

  2. Telling X to stay out of the way. I run these commands as regular user at boot after X starts: xset s off; xset -dpms; xset s noblank. The commands tell X that I don't want its blank screen screensaver, that I don't want DPMS, and that it should never blank the screen. It doesn't help.

  3. BIOS. I've searched for ways of disabling the lid switch at the BIOS (Libreboot, in my case) level, but did not find anything relevant.

That's all that I've tried so far. Even with all the above in combination, userland applications (xscreensaver being their representative) still behave differently depending on whether the laptop lid is open or closed. (In the case of xscreensaver, it only starts playing animations when laptop lid is open, never when it is closed.)

Surely there must be a way to completely disable the laptop's lid switch via software, and make userland applications think the laptop lid is always open. What am I missing?

  • I already tried that. It's #6 above. Alas, it does not completely disable the lid switch, as the xscreensaver test demonstrates.
    – GNUser
    Nov 15, 2019 at 18:13
  • BTW, I contacted the xscreensaver developer to ask him how xscreensaver detects the laptop lid switch state. His answer: "Basically, it doesn't." So it's not that xscreensaver itself is detecting a closed laptop lid: Something in the OS (some video or power management setting hidden in Xorg or one of the kernel modules?) is detecting the closed lid and preventing the screensaver from kicking in.
    – GNUser
    Nov 15, 2019 at 19:29
  • In case it helps, here are all the kernel modules that are loaded when I'm using Tiny Core Linux: pastebin.com/25g8kvu4
    – GNUser
    Nov 15, 2019 at 19:33

1 Answer 1


number 6 above actually does completely disable the lid switch.

The issue is that the T400's touchpad actually generates some noise while the lid is closed, which is what prevents an application such as xscreensaver (which waits for input devices to be idle) from running. I discovered this by watching the output of

$ sudo cat /dev/input/event5

(on my system, event5 is the touchpad)

Disabling the lid switch and the touchpad, like so, leads to the expected behavior:

# echo "PNP0C0D:00" > /sys/bus/acpi/drivers/button/unbind
# echo "PNP0C0E:00" > /sys/bus/acpi/drivers/button/unbind
# echo "serio1" > /sys/bus/serio/drivers/psmouse/unbind

Now all applications behave the same whether lid is open or closed.

Note, however, that unbinding serio1 causes my trackpoint ("nipple mouse") to become unresponsive. This is an undesirable side effect.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .