How to make lidclose suspend?

Hello

I have installed openSUSE Tumbleweed with Gnome 3.26.2 (Xorg) on a Samsung series 5 laptop with a “AMD® A6-4455m apu with radeon™ hd graphics” chip".

I would think that the intended behavior for closing the lid would be suspending, but it doesn’t. I have it set in the Gnome settings, but it still doesn’t work. The screen powers off, but it instantly turns on when it is reopened, and I’m still logged in and everything.
It does work when I suspend manually (ie. search for it in the overview or hold the “alt” key while pressing the “power-off button” from the top right drop down menu).

I was previously running KDE neon where it worked out of the box, so I suppose it should be possible.

Anyone else had this problem or know a fix?

Thanks,
rtbj

Hi
Settings as in via the gnome-tweak-tool -> Power, or via System Settings -> Power?

Nothing changed manually in /etc/systemd/logind.conf (#HandleLidSwitch=suspend)

Hello!

It’s on in both in the tweak-tool and the normal system settings.

I tried uncommenting that line, restarting and test it but it still didn’t work. Should I do something else than just reboot to get it to work? (And i “re-commented” that line again, since it didn’t work).

Thanks

Hi
The system is not in a dock or similar is it?

I would unrem that and also HandleSuspendKey and reboot and see if that helps…

No dock or anything, I haven’t even had it plugged into anything with hdmi.
Sadly that didn’t work either :frowning:

Thanks though

Run the following command to see whether some other daemon is handling the lid-switch events…

systemd-inhibit --list --mode=block

This will probably confirm that a Gnome utility is preventing the suspend action.

This may be relevant to your situation…
https://github.com/systemd/systemd/issues/7137

For reference, I’m using Leap 42.3 with Plasma 5 desktop, and I get…

~> systemd-inhibit --list --mode=block
     Who: PowerDevil (UID 1000/dean, PID 1514/org_kde_powerde)
    What: handle-power-key:handle-suspend-key:handle-hibernate-key:handle-lid-switch
     Why: KDE handles power events
    Mode: block

1 inhibitors listed.

Hi
I see the following, but I explicitly disable the lid switch event (ignore) via logind.conf…


 systemd-inhibit --list --mode=block
     Who: me (UID 1000/me, PID 1966/gsd-media-keys)
    What: handle-power-key:handle-suspend-key:handle-hibernate-key
     Why: GNOME handling keypresses
    Mode: block

1 inhibitors listed.

… and “loginctl show-session” to see whether it is handled by systemd-logind itself.

That’s exactly what I expect to happen on suspend so I’m still unsure what does not work (or why you think system is not suspended).

Okay so I tried running the commands you gave me, and I got the following results, which actually differs from yours!:

“systemd-inhibit --list --mode=block” gave (Both with the stuff commented and un-commented from the previous reply):

     
Who: gdm (UID 464/gdm, PID 1739/gsd-media-keys)
    What: handle-power-key:handle-suspend-key:handle-hibernate-key
     Why: GNOME handling keypresses
    Mode: block

     Who: me (UID 1000/me, PID 2366/gsd-media-keys)
    What: handle-power-key:handle-suspend-key:handle-hibernate-key
     Why: GNOME handling keypresses
    Mode: block

2 inhibitors listed.

“loginctl show-session” gave:


EnableWallMessages=no
NAutoVTs=6
KillUserProcesses=no
RebootToFirmwareSetup=no
IdleHint=no
IdleSinceHint=0
IdleSinceHintMonotonic=0
BlockInhibited=handle-power-key:handle-suspend-key:handle-hibernate-key
DelayInhibited=shutdown:sleep
InhibitDelayMaxUSec=5s
HandlePowerKey=poweroff
HandleSuspendKey=suspend
HandleHibernateKey=hibernate
HandleLidSwitch=suspend
HandleLidSwitchDocked=ignore
HoldoffTimeoutUSec=30s
IdleAction=ignore
IdleActionUSec=30min
PreparingForShutdown=no
PreparingForSleep=no
Docked=no
RemoveIPC=yes
RuntimeDirectorySize=781475840
InhibitorsMax=8192
NCurrentInhibitors=9
SessionsMax=8192
NCurrentSessions=2
UserTasksMax=10813

I’m not really sure what I’m looking for here, but I really appreciate your help!

I would expect it to suspend to RAM or the disk (ie. not only the screen should power off, the fans and the disk etc. should too, and it should log me out so that I’m greeted with the gdm login screen when I open it/power it back on. That’s what I would consider normal and also what I have seen from some other distros at least.)

I would expect it to suspend to RAM or the disk (ie. not only the screen should power off, the fans and the disk etc. should too, and it should log me out so that I’m greeted with the gdm login screen when I open it/power it back on.

Just to clarify ‘suspending to disk’ is hibernation, while ‘suspending to RAM’ is suspending in the Linux world. From your earlier description, it appears that only the display is shutting down (with backlight turned off), rather than suspending actually occurring.

Do you have an additional display device attached or just the laptop display?

Did you try configuring via GNOME Tweak Tool as Malcolm already mentioned?

Does ~/.config/autostart/ignore-lid-switch-tweak.desktop exist?

FWIW, the first answer in this Ubuntu thread contains an image showing the advanced settings in the Gnome Tweak Tool that might be helpful. How are your lid close settings configured? (AC and battery)

Well, you never said they did not.

and it should log me out so that I’m greeted with the gdm login screen when I open it/power it back on

The whole point of suspend is that it does not log you out - it leaves system in exactly the same state it was. Your DE may notice suspend and display lock screen on wakeup, but it is configurable and may be disabled. But you also did not mention what DE you are using.

“loginctl show-session” gave:

BlockInhibited=handle-power-key:handle-suspend-key:handle-hibernate-key
DelayInhibited=shutdown:sleep
InhibitDelayMaxUSec=5s
HandleLidSwitch=suspend
HandleLidSwitchDocked=ignore
Docked=no

So logind is configured to suspend on lid close, this action is not inhibited (or intercepted) and logind believes your system is not docked. The obvious first step to troubleshoot is to check whether it suspends manually - “systemctl suspend”.

And it will likely be useful if you upload “journalctl -b” output after lid close/open; it should show whether any suspend was attempted at all.