how to completely disable lid switch?

[Rich]

Hi GNUser
Does your machine report anything for:

Code: [Select]

cat /sys/module/button/parameters/lid_report_intervalIf it does, try setting it to  0  or  -1.

[GNUser]

Thank you, Rich.
My laptop reports 500.
I cannot set it to -1 ("Invalid argument"). I can set it to 0, but it does not seem to help (xscreensaver still refuses to kick in while lid is closed)

[GNUser]

I set it to 500000 to see what would happen. xscreensaver still refuses to kick in when lid is closed.

I have to say this is the most stubborn issue I've ever had with GNU/Linux. It's usually a very malleable OS.

[GNUser]

I found /proc/acpi/button/lid/LID/state which does seem to consistently accurately report the lid switch state. Getting warmer?

Code: [Select]

$ cat /proc/acpi/button/lid/LID/state
state: open
$ sleep 5; cat /proc/acpi/button/lid/LID/state # I close the lid after entering the command
state: closed
$ echo 0 | sudo tee /sys/module/button/parameters/lid_report_interval
$ sleep 5; cat /proc/acpi/button/lid/LID/state # I close the lid after entering the command
state: closed
$ echo 500000 | sudo tee /sys/module/button/parameters/lid_report_interval
$ sleep 5; cat /proc/acpi/button/lid/LID/state # I close the lid after entering the command
state: closed
$ sudo acpitool -W 17 # this disables the lid switch wakeup device
$ cat /proc/acpi/button/lid/LID/state
state: open
$ sleep 5; cat /proc/acpi/button/lid/LID/state # I close the lid after entering the command
state: closed

Bottomline from all the above: No matter what I do, I cannot disable the lid switch--but at least the output of cat /proc/acpi/button/lid/LID/state is always accurate with regard to whether the lid is open or closed.

Maybe there's a way to force the file to always say open? (Alas, I wouldn't expect chattr +i to work on the /proc virtual filesystem.)

[jazzbiker]

Hi, GNUser!

Sorry again for my silly posts, but so much time spent struggling with this lid switch was enough to compile custom lid-less kernel. If you hate this lid switches, solve the problem once and forever.

Thanks for Your answers.

[GNUser]

A last attempt before recompiling kernel: Finding a way to disable the button kernel module.

I took a look at the kernel's source code, and the module that enables the lid switch is called button
https://github.com/torvalds/linux/blob/master/drivers/acpi/button.c

button does not show up in output of lsmod or find /lib/modules/4.19.10-tiny
core64/kernel/ -name 'button.ko.gz' but does show up in output of ls /sys/module, so it's loaded and must be a kernel builtin. Therefore, it cannot be blacklisted with blacklist=<module_name> kernel boot parameter.

However, it seems there is a way to disable built-in kernel modules: initcall_blacklist=<module's_initialization_function>. I can't find a function in button.c that has the __init attribute, so I tried blacklisting various functions in button.c that have _init in the name, to no avail.

Can someone help me figure out which initcall I should blacklist in order to prevent the button kernel module from being loaded (or some other way to disable that module short of recompiling kernel)? I realize it would probably disable both my lid switch and power button, but that's fine--I only use the power button to power on, never to poweroff.

[Rich]

Hi GNUser
Try:

Code: [Select]

initcall_blacklist=acpi_button_register_driver

[GNUser]

Thank you, Rich, but no joy. The module still gets loaded.

[Juanito]

Maybe you could use the acpid extension and write a rule to achieve what you wish to happen when the lid is closed?

[GNUser]

acpid would be a great tool if I were looking to do something special when the kernel reports that the lid is closed.
However, what I want is for the kernel to never report to userland that the lid is closed--for it to either always report it as open or else ignore it completely.

[Rich]

Hi GNUser

Thank you, Rich, but no joy. The module still gets loaded.

Did  dmesg  log any output in response to the blacklist request?

[GNUser]

Hmm, it did, but it doesn't look good:

Code: [Select]

$ dmesg | grep blacklist
Command line: BOOT_IMAGE=/boot/vmlinuz64 tce=sda2/tce opt=sda2 blacklist=pcspkr blacklist=uvcvideo tz=EST+5EDT,M3.2.0/2,M11.1.0/2 syslog lang=en_US.UTF-8 user=bruno initcall_blacklist=acpi_button_register_driver
Kernel command line: BOOT_IMAGE=/boot/vmlinuz64 tce=sda2/tce opt=sda2 blacklist=pcspkr blacklist=uvcvideo tz=EST+5EDT,M3.2.0/2,M11.1.0/2 syslog lang=en_US.UTF-8 user=bruno initcall_blacklist=acpi_button_register_driver
initcall_blacklist requires CONFIG_KALLSYMS
It seems that Pure64's kernel was compiled without the configuration option needed for initcall_blacklist to work. Darn.

-----

It the meantime, I tried my old trick of taping a magnet over the lid switch (my T400's lid switch is actually a little magnet above the bluetooth LED). However, doing this results in the switch always being in the "closed" state. I tried the boot parameter button.lid_init_state=open but it makes no difference--the magnet causes constant "closed" state.

-----

It seems I'm running out of options. I'll ask on the kernel mailing list just to make sure we aren't missing something.

[Rich]

Hi GNUser

... It the meantime, I tried my old trick of taping a magnet over the lid switch (my T400's lid switch is actually a little magnet above the bluetooth LED). However, doing this results in the switch always being in the "closed" state. I tried the boot parameter button.lid_init_state=open but it makes no difference--the magnet causes constant "closed" state. ...

You could try weakening/dispersing the magnetic field by placing something metallic between the lid magnet and the switch. Maybe
several layers of aluminum foil or a piece of sheet steel (top of a tuna can).

[GNUser]

Excellent idea! I'll try that, or some magnetic insulation tape if it doesn't work.

Either way, I'll stop bothering you guys with this miniscule issue. If I hear something helpful back from the kernel guys, I'll share it.

Cheers,
gnuser

[Rich]

Hi GNUser

... I'll stop bothering you guys with this miniscule issue. ...

No bother. It allowed me to spend some quality time looking through the  /proc  and  /sys  file systems as well as driver code.