ACPI Button The Lid Device Is Not Compliant To SW_LID | Lid Suspend Fixes

ACPI Button The Lid Device Is Not Compliant To SW_LID Message Explained

Seeing ACPI: button: The lid device is not compliant to SW_LID in dmesg or your system log can look scary, especially when your laptop stops suspending when you close the lid. This line comes from the Linux ACPI button driver and means the firmware does not follow the expected rules for reporting lid state through the special SW_LID switch event.

On a well behaved laptop, the firmware signals lid open and lid close through ACPI methods, and the kernel turns that into the SW_LID input event that tools such as systemd-logind listen to. When the kernel detects odd or unreliable patterns from the lid device, it logs that the lid device is not compliant to SW_LID and may switch to a safer mode where it ignores some notifications or assumes the lid starts out open.

That small line in the log is the kernel warning you that the firmware does not follow ideal rules. In many real cases nothing breaks, which is why some distributions treat it as noise by default.

The warning itself does not always mean something is broken. On many machines the lid still reports state, suspend works, and the only side effect is extra noise in the log. On others, the same message shows up together with real symptoms such as no reaction on lid close, suspend loops, or resume glitches. The rest of this guide walks through simple tests and tweaks you can apply when acpi button the lid device is not compliant to sw_lid shows up on your system.

Acpi Button Lid Device Not Compliant To Sw_Lid On Linux Laptops

Before digging into configuration files, it helps to understand what pieces are involved when you close the lid. The path from the hinge sensor to suspend looks like this on a typical Linux laptop:

• Firmware signals lid events — ACPI firmware sends notifications when the lid moves and exposes a control method named _LID that reports whether the lid is open or closed.
• Kernel translates events to SW_LID — The ACPI button driver listens to those notifications and exposes a logical switch named SW_LID through the Linux input layer.
• Userspace listens for SW_LID — A user space component such as systemd-logind, a desktop power manager, or an older acpid daemon watches that switch and runs actions such as suspend, screen blank, or ignore.

When this warning appears, the kernel has decided that the lid device does not line up well with the expectations for that switch. That can be harmless if you only rely on the control method, or it can cause trouble when your desktop expects clean SW_LID events and receives something odd or nothing at all.

Common Symptoms When Lid Events Misbehave

Real problems show up in several recurring patterns shared across bug reports and forum threads. Recognizing them helps you match your laptop behavior with the right fix later.

• No suspend on lid close — Closing the lid blanks the display or does nothing, while manual systemctl suspend still works. Logs show the non compliant lid message from ACPI around boot or resume.
• Repeated wake right after suspend — The laptop starts to suspend, spins down for a second, then wakes as if the lid had been opened again or some stray wake event fired.
• Lid events seen but ignored — journalctl shows systemd-logind lines such as Lid closed and Lid opened, yet the session keeps running because desktop settings or docks override the action.
• Wrong initial lid state — After boot or resume, tools report the lid as closed when it is open, or the other way round, until you move the lid through a full cycle.

If you recognize one of these patterns, your hardware likely falls into the group that triggers the non compliant warning and needs a small amount of tuning instead of a full reinstall or kernel downgrade.

Quick Checks To Test Lid Events In Linux

Before changing any settings, confirm whether lid events reach user space correctly. That shortens the list of possible causes and tells you whether the firmware issue is only cosmetic.

• Check recent logs for lid lines — Run journalctl -b | grep -i lid after closing and opening the lid a few times. If you see lines from systemd-logind that say Lid closed and Lid opened, then logind at least sees the events.
• Watch SW_LID with evtest — Install evtest from your distribution, list devices with sudo evtest, pick the one that mentions SW_LID, then close and open the lid. You should see SW_LID events toggle between 0 and 1.
• Read the legacy ACPI lid state — On many kernels you can run cat /proc/acpi/button/lid/*/state. Run it once, move the lid, then run it again to see if the text switches between open and closed.
• Confirm which service handles lid events — On a systemd based laptop, run systemd-inhibit --list and look for items that mention handle-lid-switch. Desktop power tools often register there and can override your global setting.

If all these checks show clean lid events and correct state changes, this line is likely a warning about rare edge cases. If events never reach userspace or the reported state sticks, you need configuration changes or a kernel hint to cope with buggy firmware.

Fixing Lid Suspend Problems On Systemd Distros

On most current Linux distributions, systemd-logind is the central point that decides what happens when you close the lid. Even when the kernel complains about a non compliant lid device, you can often restore sane behavior by adjusting its settings and keeping desktop tweaks in sync.

• Set explicit lid actions in logind.conf — Open /etc/systemd/logind.conf as root and set lines such as HandleLidSwitch=suspend, HandleLidSwitchExternalPower=suspend or ignore, and HandleLidSwitchDocked=ignore. Remove any leading comment characters so these values apply instead of defaults.
• Reload logind cleanly — After editing, run sudo systemctl restart systemd-logind. Be sure to save work first, since logind tracks sessions and may end them during restart. Then repeat the lid tests from earlier.
• Align desktop power settings — In GNOME, KDE, XFCE, and similar desktops, open the power settings tool and pick suspend, blank screen, or nothing for lid close. If both your desktop and logind try to act, the stronger one wins, so set them to matching goals.
• Disable extra power daemons while testing — Tools such as TLP or vendor power utilities can change sleep behavior. Stop them temporarily and retry lid events to see whether one of them interacts badly with the non compliant lid device.

If systemd now logs lid events and your laptop suspends as requested, you can treat the warning as a noisy hint about fragile firmware instead of a hard error. When the message appears together with missing events, the next step is to nudge the ACPI lid driver with a kernel parameter.

Tuning The ACPI Lid Driver With Kernel Parameters

The Linux ACPI lid driver includes several modes to handle buggy firmware that does not pair lid notifications correctly. The kernel documentation describes three settings for the initial lid state and one switch that forces the use of SW_LID even on older setups. You can pass these options on the kernel command line through your bootloader.

• Force method based initial state — Add button.lid_init_state=method to the kernel command line if the firmware returns a reliable lid value from the _LID control method but fails to send an initial notification. This mode trusts the method and can fix laptops that always start as closed until the lid moves.
• Force open initial state — Add button.lid_init_state=open when the initial state tends to be wrong. The driver will assume the lid starts open, and later notifications refine the state as you move the lid.
• Use power button like behavior — On some platforms, you can add button.lid_init_state=ignore or rely on desktop tools to drive suspend, treating the lid only as an extra hint instead of a strict trigger.
• Prefer SW_LID in new setups — Recent kernels gradually push userspace toward the switch based model. When your desktop is ready, adding acpi_debug or related options while testing can show how the lid behaves and help you pick the safest lid driver mode.

To apply one of these options on a GRUB based system, edit /etc/default/grub, append the parameter to the GRUB_CMDLINE_LINUX_DEFAULT line, then run sudo update-grub and reboot. Other bootloaders use similar steps. Keep notes of which mode you tried so you can roll back if the lid stops working or suspend behavior becomes worse.

When You Can Safely Ignore The SW_LID Warning

Not every appearance of this message needs action. Once you know what it means and you have confirmed that lid events behave, you can decide whether to accept the warning as harmless.

• Lid close triggers the expected action — If your laptop suspends, blanks the screen, or stays awake exactly as you have configured, and log files only show the warning during boot, the cost of chasing firmware quirks may outweigh any benefit.
• Events look correct in evtest and journal — When the lid switch changes cleanly between open and closed and the input events appear as expected, your setup already handles the non compliant hardware well enough.
• Firmware updates are not available — On older laptops without BIOS updates or vendor fix packs, the warning mainly tells you that the kernel spotted quirks. Stable behavior matters more than a perfectly clean log.
• Other hardware problems take priority — If suspend works but storage, graphics, or network need attention, treat the SW_LID complaint as a lower priority note instead of the first thing to chase.

When lid close still fails after these checks, gather logs around the warning, note your kernel version and distribution, and search for reports for your exact model. Many lid issues repeat across specific laptops, and kernel bug trackers, distribution wikis, or forums often hold patches or workarounds written for those models. Sharing your findings back helps the next person who hits that acpi lid message on similar hardware.

Symptom	Likely Cause	Helpful Fix To Try
Lid close does nothing, manual suspend works	Logind or desktop ignores SW_LID events	Set lid actions in logind.conf and desktop power settings, then reload systemd-logind
Laptop wakes as soon as it suspends	Spurious lid or USB wake events around SW_LID	Disable wake on extra devices in firmware setup and test lid events again
Lid state stuck as closed or open	Buggy _LID method and missing initial notification	Try button.lid_init_state=method or open on the kernel command line