> 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!
