how to disable the button kernel module?

how to disable the button kernel module?

[Bruno GNUser]

I realize that /button/ is a kernel built-in and therefore cannot be disabled
via the /blacklist=<module_name>/ boot parameter. So I thought I'd try
/initcall_blacklist=<function>/ but I cannot find an obvious module
initialization function in button.c

Please, how would one disable the /button/ module? Either using the
/initcall_blacklist=foo/ or some other method is fine, as long as it does
not involve recompiling the kernel. 

Thanks,
Bruno GNUser



--
Sent from: http://linux-kernel.2935.n7.nabble.com/

Re: how to disable the button kernel module?

[Randy Dunlap]

On 11/14/19 4:00 AM, Bruno GNUser wrote:
> I realize that /button/ is a kernel built-in and therefore cannot be disabled
> via the /blacklist=<module_name>/ boot parameter. So I thought I'd try
> /initcall_blacklist=<function>/ but I cannot find an obvious module
> initialization function in button.c

In what kernel version if the button driver built-in?
It currently can be built as a loadable module.

The lines
module_driver(acpi_button_driver, acpi_button_register_driver,
	       acpi_button_unregister_driver);
at the end of the source file create an init function named
acpi_button_driver_init.  You could try:
  initcall_blacklist=acpi_button_driver_init


> Please, how would one disable the /button/ module? Either using the
> /initcall_blacklist=foo/ or some other method is fine, as long as it does
> not involve recompiling the kernel. 

Any help from ACPI people?


> Thanks,
> Bruno GNUser
> 
> 
> --
> Sent from: http://linux-kernel.2935.n7.nabble.com/


-- 
~Randy

Re: how to disable the button kernel module?

[Rafael J. Wysocki]

On Fri, Nov 15, 2019 at 6:33 AM Randy Dunlap <rdunlap@infradead.org> wrote:
>
> On 11/14/19 4:00 AM, Bruno GNUser wrote:
> > I realize that /button/ is a kernel built-in and therefore cannot be disabled
> > via the /blacklist=<module_name>/ boot parameter. So I thought I'd try
> > /initcall_blacklist=<function>/ but I cannot find an obvious module
> > initialization function in button.c
>
> In what kernel version if the button driver built-in?
> It currently can be built as a loadable module.
>
> The lines
> module_driver(acpi_button_driver, acpi_button_register_driver,
>                acpi_button_unregister_driver);
> at the end of the source file create an init function named
> acpi_button_driver_init.  You could try:
>   initcall_blacklist=acpi_button_driver_init
>
>
> > Please, how would one disable the /button/ module? Either using the
> > /initcall_blacklist=foo/ or some other method is fine, as long as it does
> > not involve recompiling the kernel.
>
> Any help from ACPI people?

https://lore.kernel.org/linux-acpi/CAJZ5v0hy2QpJtnGVvOOggOzTDifD1HYosN9vf0y_=15b+M8v0Q@mail.gmail.com/T/#t

Thanks!

how to disable the "button" kernel module?

[Bruno Dantas]

I realize that "button" is a kernel built-in and therefore cannot be disabled via "blacklist=button" boot parameter. So I thought I'd try initcall_blacklist=<function> but I cannot find an obvious module initialization function in button.c 

Please, how would one disable the button module? I'm looking for a method that would not involve recompiling the kernel. 

Thanks, 
Bruno GNUser

Re: how to disable the "button" kernel module?

[Rafael J. Wysocki]

On Thu, Nov 14, 2019 at 3:33 PM Bruno Dantas <kernel@dantas.airpost.net> wrote:
>
> I realize that "button" is a kernel built-in and therefore cannot be disabled via "blacklist=button" boot parameter. So I thought I'd try initcall_blacklist=<function> but I cannot find an obvious module initialization function in button.c
>
> Please, how would one disable the button module? I'm looking for a method that would not involve recompiling the kernel.

It definitely can be built as a module.

Why exactly do you want to disable it?

Re: how to disable the "button" kernel module?

[Bruno Dantas]

> Why exactly do you want to disable it?
>

I'd like to disable it because I want my laptop's lid switch state to be 100% invisible to userland--as if the lid switch were broken and always in the "open" state. All the less drastic attempts I've made at achieving this have failed: 
http://forum.tinycorelinux.net/index.php/topic,23326.0.html

I realize that disabling the "button" module would likely make my laptop's power button inoperable, but that's okay because I only use the button to power up the laptop, never to power it down.

Re: how to disable the "button" kernel module?

[Rafael J. Wysocki]

On Thu, Nov 14, 2019 at 3:50 PM Bruno Dantas <kernel@dantas.airpost.net> wrote:
>
> > Why exactly do you want to disable it?
>
> I'd like to disable it because I want my laptop's lid switch state to be 100% invisible to userland--as if the lid switch were broken and always in the "open" state.

I wonder why?

Anyway, you can try to echo the lid device name to
/sys/bus/acpi/drivers/button/unbind to unbind the button driver from
the lid device.

That name should be something like PNP0C0D:00 (note that you need to
escape the colon when in a shell).

Re: how to disable the "button" kernel module?

[Bruno Dantas]

> Anyway, you can try to echo the lid device name to
> /sys/bus/acpi/drivers/button/unbind to unbind the button driver from
> the lid device.
> 
> That name should be something like PNP0C0D:00 (note that you need to
> escape the colon when in a shell).

Thank you, Rafael. I've tried that, but some applications (e.g., xscreensaver) are still somehow able to detect the lid switch state. In the case of xscreensaver, it still refuses to start playing the video animations if the lid is closed.

> I wonder why?
> 
If the driver is unbinded, how can an application possibly know the lid switch state? I asked the xscreensaver developer how his application queries the lid switch state and he said that it doesn't. So there you have it--there's some voodoo going on.

I have two toddlers and a baby that crawl around, so I often have to close the laptop lid during long-running commands to keep the kids from pressing random keys and wreaking havoc. If I can't predict the effect that closing the lid will have on applications, I would like to completely disable it.

(I'd disable the lid switch at the level of the BIOS if I could, but I use Libreboot and this is not an option AFAIK.)

Re: how to disable the "button" kernel module?

[Rafael J. Wysocki]

On Thu, Nov 14, 2019 at 4:58 PM Bruno Dantas <kernel@dantas.airpost.net> wrote:
>
> > Anyway, you can try to echo the lid device name to
> > /sys/bus/acpi/drivers/button/unbind to unbind the button driver from
> > the lid device.
> >
> > That name should be something like PNP0C0D:00 (note that you need to
> > escape the colon when in a shell).
>
> Thank you, Rafael. I've tried that, but some applications (e.g., xscreensaver) are still somehow able to detect the lid switch state. In the case of xscreensaver, it still refuses to start playing the video animations if the lid is closed.
>
> > I wonder why?
> >
> If the driver is unbinded, how can an application possibly know the lid switch state?

I don't know.

You can try to unbind all devices handled by the button driver and see
if that makes any difference.  That would be as good as unloading it.

> I asked the xscreensaver developer how his application queries the lid switch state and he said that it doesn't. So there you have it--there's some voodoo going on.

If the panel is automatically turned off by the platform when closing
the lid, the GPU driver will see that and may notify user space in
theory.  I'm not a GPU expert, though.

> I have two toddlers and a baby that crawl around, so I often have to close the laptop lid during
> long-running commands to keep the kids from pressing random keys and wreaking havoc.
> If I can't predict the effect that closing the lid will have on applications, I would like to completely disable it.
>
> (I'd disable the lid switch at the level of the BIOS if I could, but I use Libreboot and this is not an option AFAIK.)

You can definitely prevent the button driver from handling any events
(by unbinding it from all devices that it is bound to), but that may
not be sufficient for what you want to achieve.

Re: how to disable the "button" kernel module?

[Bruno Dantas]

> You can try to unbind all devices handled by the button driver and see
> if that makes any difference.  That would be as good as unloading it.
> 
Good idea, Rafael. I gave it a try:

bruno@box:~$ ls /sys/bus/acpi/drivers/button
LNXPWRBN:00  PNP0C0D:00   PNP0C0E:00   bind         uevent       unbind
bruno@box:~$ echo "PNP0C0D:00" | sudo tee /sys/bus/acpi/drivers/button/unbind
PNP0C0D:00
bruno@box:~$ echo "PNP0C0E:00" | sudo tee /sys/bus/acpi/drivers/button/unbind
PNP0C0E:00
bruno@box:~$ echo "LNXPWRBN:00" | sudo tee /sys/bus/acpi/drivers/button/unbind
LNXPWRBN:00
bruno@box:~$ ls /sys/bus/acpi/drivers/button
bind    uevent  unbind

Still, xscreensaver animations refuse to kick in while laptop lid is closed. Very mysterious, indeed...

Would it be correct to say that I've excluded the button driver's devices as "culprits" in telling xscreensaver about my lid state?

Even though this issue is somewhat trivial, I feel compelled to keep digging because of how mysterious it is to me. *Something* is obviously aware of the lid switch. Maybe it's my video module (i915)? Maybe it's X? Would either of these be able to assess the lid switch's status if all the button driver's devices are all unbound?

Thanks a lot for your help!

Re: how to disable the "button" kernel module?

[Rafael J. Wysocki]

On Thu, Nov 14, 2019 at 7:46 PM Bruno Dantas <kernel@dantas.airpost.net> wrote:
>
> > You can try to unbind all devices handled by the button driver and see
> > if that makes any difference.  That would be as good as unloading it.
> >
> Good idea, Rafael. I gave it a try:
>
> bruno@box:~$ ls /sys/bus/acpi/drivers/button
> LNXPWRBN:00  PNP0C0D:00   PNP0C0E:00   bind         uevent       unbind
> bruno@box:~$ echo "PNP0C0D:00" | sudo tee /sys/bus/acpi/drivers/button/unbind
> PNP0C0D:00
> bruno@box:~$ echo "PNP0C0E:00" | sudo tee /sys/bus/acpi/drivers/button/unbind
> PNP0C0E:00
> bruno@box:~$ echo "LNXPWRBN:00" | sudo tee /sys/bus/acpi/drivers/button/unbind
> LNXPWRBN:00
> bruno@box:~$ ls /sys/bus/acpi/drivers/button
> bind    uevent  unbind
>
> Still, xscreensaver animations refuse to kick in while laptop lid is closed. Very mysterious, indeed...
>
> Would it be correct to say that I've excluded the button driver's devices as "culprits" in telling xscreensaver about my lid state?

Yes, it would.

> Even though this issue is somewhat trivial, I feel compelled to keep digging because of how mysterious it is to me.
> *Something* is obviously aware of the lid switch. Maybe it's my video module (i915)? Maybe it's X? Would either of
> these be able to assess the lid switch's status if all the button driver's devices are all unbound?

As I said, that may be the panel state rather than the lid switch status.

> Thanks a lot for your help!

YW

Re: how to disable the "button" kernel module?

[Bruno Dantas]

> As I said, that may be the panel state rather than the lid switch status.
> 
One last question: What keeps tabs on the "panel state"? Is it the kernel, a kernel module, X, or something else? Would you be so kind as to point me in the right direction? I'd like to find what keeps track of the panel state so that I can disable it (or configure it to lie and say that the panel is always open).

Most internet searches for "panel state" lead me right back to the laptop lid switch, which I guess has been a red herring all along.

Many thanks,
Bruno

Re: how to disable the "button" kernel module?

[Rafael J. Wysocki]

On Thu, Nov 14, 2019 at 8:36 PM Bruno Dantas <kernel@dantas.airpost.net> wrote:
>
> > As I said, that may be the panel state rather than the lid switch status.
> >
> One last question: What keeps tabs on the "panel state"?
> Is it the kernel, a kernel module, X, or something else? Would you be so kind as to point me in the right direction?
> I'd like to find what keeps track of the panel state so that I can disable it (or configure it to lie and say that the panel is always open).
>
> Most internet searches for "panel state" lead me right back to the laptop lid switch, which I guess has been a red herring all along.

Not necessarily.

The i915 driver (for Intel GPUs) contains some code related to that
too, see drivers/gpu/drm/i915/display/intel_opregion.c for example.