On Thu, Nov 14, 2019 at 4:58 PM Bruno Dantas <kernel@xxxxxxxxxxxxxxxxxx> 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.
