how to completely disable lid switch?

[GNUser]

I run Pure64 10.1 on my laptop. I'd like the laptop's behavior to be identical regardless of whether its lid is open or closed. In the past, I found that the only way to achieve completely identical behavior is to disable the lid switch at the level of the kernel.

In Debian, I can find the lid's sysfs node (e.g., PNP0C0D:00) by running cat /proc/acpi/wakeup, then this command completely disables the lid switch by unbinding its driver:

Code: [Select]

echo 'PNP0C0D:00' | sudo tee /sys/bus/acpi/drivers/button/unbindIn Pure64, cat /proc/acpi/wakeup shows me that laptop lid's sysfs node is PNP0C0D:00 as expected, but notice what happens when I try to unbind the driver:

Code: [Select]

echo 'PNP0C0D:00' | sudo tee /sys/bus/acpi/drivers/button/unbind
PNP0C0D:00
tee: /sys/bus/acpi/drivers/button/unbind: I/O error
Can you please help me completely disable the lid switch? I'm aware of the acpi=off kernel boot parameter, but that has the unpleasant side effect of also disabling kernel's battery stats (which I need for one of my shell scripts). I'd like to disable only the lid switch.

[Rich]

Hi GNUser
I see  laptop-mode-tools.tcz  includes:

Code: [Select]

/usr/local/share/laptop-mode-tools/files/acpi/actions/lm_lid.sh
/usr/local/share/laptop-mode-tools/files/acpi/events/lm_lidMaybe they are of some use?

[GNUser]

Hi, Rich. acpitool (not currently in repo) gets me part of the way there:

Code: [Select]

$ acpitool -w
   Device S-state   Status   Sysfs node
  ---------------------------------------
  1. HDEF   S4 *disabled  pci:0000:00:1b.0
  2. USB1   S4 *enabled   pci:0000:00:1d.0
---snip---
  17. LID   S3 *enabled   platform:PNP0C0D:00
$ sudo acpitool -W 17
  Changed status for wakeup device #17 (LID)

   Device S-state   Status   Sysfs node
  ---------------------------------------
  1. HDEF   S4 *disabled  pci:0000:00:1b.0
  2. USB1   S4 *enabled   pci:0000:00:1d.0
---snip---
  17. LID   S3 *disabled  platform:PNP0C0D:00

However, even after the above, if laptop lid is closed then xscreensaver does not kick in after the appropriate number of minutes. So disabling the lid switch under acpi is not the whole story.

Any idea how to completely disable the lid switch via software (or at least make xscreensaver unaware of it)?

[GNUser]

acpi is a red herring. Even if it is completely disabled with acpi=off kernel boot parameter, xscreensaver still refuses to kick in while laptop lid is closed.

xscreensaver must be aware of the lid switch some other way (BIOS? kernel? Xorg?). I'll contact the xscreensaver developer to see if he can point me in the right direction.

[Rich]

Hi GNUser
I'm not sure I'm following you. Are you saying the display won't blank with the lid closed?

[GNUser]

My monitor stays on while lid is closed. I like it that way.

When I give the laptop some long-running job, I turn the brightness all the way down then close the lid just to keep my toddlers and baby from accidentally pressing any keys. I want the screensaver to kick in while the lid is closed, same as it would if the lid were open.

[jazzbiker]

Hi, Core guys!

Sorry for interrupting your essential talk.
GNUser, why not to move towards allowing acpi power off your monitor while lid closed? And no matter, what screensaver has on its (his?) mind.
I use notebook in the same manner, put some task to work, and close lid. Monitor is powered off by acpi and things roll on.
Not trying to advice, as you are much more experienced, but do you remember about "xset dpmi a b c"?

[GNUser]

Thank you, jazzbiker. That's perfectly sensible advice and would yield a great result. However, this is more about control at this point: I don't like the lid switch, so am on a war path to disable it

(I'd do it mechanically, except that on my T400 the lid switch is actually a little magnet just below the display and above the Bluetooth icon. In the past I've "disabled" it by taping a small magnet in that area, but found that it was actually keeping the switch in the "lid closed" position, causing a wakeup-suspend loop when running some distros.)

P.S. xset is a great tip. I'm aware of it, and one of my startup jobs is actually xset s off; xset -dpms; xset s noblank to disable any interference from X.

[GNUser]

It seems that opening and closing the laptop lid don't generate any libinput events?! Very strange.

Code: [Select]

bruno@box:~$ cat /proc/bus/input/devices
---snip---
I: Bus=0019 Vendor=0000 Product=0005 Version=0000
N: Name="Lid Switch"
P: Phys=PNP0C0D/button/input0
S: Sysfs=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:2a/PNP0C09:00/PNP0C0D:00/input/input1
U: Uniq=
H: Handlers=event1
B: PROP=0
B: EV=21
B: SW=1

# notice my laptop's lid switch is supposedly "event 1"

bruno@box:~$ tce-load -wi libinput
bruno@box:~$ sudo libinput debug-events
 event6   POINTER_MOTION    +2.02s   0.79/  0.00 ( +1.00/ +0.00)
 event6   POINTER_MOTION    +2.04s   1.40/  2.79 ( +1.00/ +2.00)
 event6   POINTER_MOTION    +2.05s   2.52/ 10.09 ( +1.00/ +4.00)
 event6   POINTER_MOTION    +2.08s   1.10/  3.31 ( +1.00/ +3.00)
 event6   POINTER_MOTION    +2.09s   1.61/  3.21 ( +1.00/ +2.00)
 event6   POINTER_MOTION    +2.12s   0.00/  0.56 ( +0.00/ +1.00)
### in here I close and open the laptop lid. nothing related to event1 is logged as you can see.
 event3   KEYBOARD_KEY      +9.93s *** (-1) pressed
 event3   KEYBOARD_KEY     +10.05s *** (-1) pressed
If opening and closing the laptop lid doesn't cause any input device events to fire, how come xscreensaver knows when lid is closed? Something is aware that the lid is closed, because the xscreensaver's animations never start as long as laptop lid is closed.

[GNUser]

This just in from xscreensaver's developer, Jamie Zawinski:

Code: [Select]

Q (GNUser): How does xscreensaver detect laptop lid switch state?

A (Zawinski): Basically, "it doesn't." It's all terrible. Everything about power management on Linux is laughable.
Oops. It seems I hit a nerve. Maybe I'm just going to leave this voodoo alone and settle for a workaround similar to what jazzbiker suggests. I feel defeated. You'd think it would be trivial to disable an input device.

[Rich]

Hi GNUser

Code: [Select]

### in here I close and open the laptop lid. nothing related to event1 is logged as you can see.
 event3   KEYBOARD_KEY      +9.93s *** (-1) pressed
 event3   KEYBOARD_KEY     +10.05s *** (-1) pressed

It appears closing and opening the lid causes  keyboard pressed  events without the corresponding  keyboard released  events.

[GNUser]

No, those two keyboard (event3) events are from me pressing Control+c after I re-opened the lid. Opening and closing the lid causes nothing whatsoever to show up on the list.

[Rich]

Hi GNUser
I should have realized that was something else. The events are only 0.120 seconds apart.

[jazzbiker]

Hi GNUser!

Is it your laptop with libreboot? May it entertain you with some funny tricks?
Have You tried Xfbdev?

[GNUser]

Hi, jazzbiker.
Yes, it's my T400 ThinkPad with Libreboot. Alas, it does not entertain me with funny tricks.
Xfbdev is a good idea, except that I depend on some full-blown Xorg features.

I will try disabling acpi on my wife's laptop (Sony Vaio with stock BIOS) and seeing whether xscreensaver is still aware of the laptop's lid switch. If it's not, it would point to a low-level awareness of the lid switch on my Libreboot machine.