Edit: Thanks for all suggestion! In my case (Thinkpad) I managed to make it persistent via udev, as described here.

It looks like there was a pre-existing udev configuration about this, but had slightly wrong SUBSYSTEM and DRIVER parameters:

  • old: SUBSYSTEM=="acpi", DRIVER=="button"
  • correct (in my case): SUBSYSTEM=="platform", DRIVER=="acpi-button"

maybe because of some recent systemd changes?

Hope this may help others.

I have Kubuntu on a Thinkpad, and a S3-sleep state selected in the Bios.

My setup has always been to not resume from sleep when the lid is open. I achieved this by running once

echo "LID" | sudo tee /proc/acpi/wakeup

which toggles the wakeup-on-lid state. The behaviour would be respected upon restart.

Here’s my problem: since some recent update – I don’t know whether from apt or fwupd – I discovered that the laptop was waking up upon lid opening. So I issued the command above again. It works, but it gets reset upon restart, unlike before.

Anyone has good tips on how to make this setting permanent?

In the Bios I didn’t find any settings about this.

Cheers!

  • mote@lemmy.ca
    2·
    2 days ago

    I would assume your system is using systemd (I don’t use Kubuntu specifically); the laptop lid is (now in 2026) controlled by the systemd infrastructure - it’s a matter of setting a config option and this should fix you up. Arch as usual has the best wiki on the subject:

    https://wiki.archlinux.org/title/Power_management#ACPI_events

    You’re probably looking at HandleLidSwitch* options. There’s still nothing wrong with the manual disable to /proc/acpi/wakeup to cover your bases (layers of the onion), I’m fighting with a “modern” laptop that only has s2idle and it’s terrible compared to S3 - I’m in ACPI wakeup hell and still trying to figure out what’s causing it.

    • stravanasu@lemmy.caOP
      1·
      2 days ago

      Thank you for this 🙏. I tried the HandleLidSwitch* options, setting them all to “ignore”, but unfortunately it didn’t work in my case. Adding or modifying udev rules luckily did!