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