2

I have recently installed Debian 12 amd64 on a Lenovo IdeaPad 100s. There seem to be a problem with the laptop lid, in paricular I do not find where the behaviour the system should take is set.

In xfce-power-manager gui I have set to "Do nothing". Still when I close the lid the system goes to hibernation. After I reopen the lid it goes in a strange mode in which it is not fully out of hibernation in the graphical session. Still the system is "awake enough" that I can go in the second log in (CTRL-ALT-F2) and log in text mode and reboot.

I have tried to chance "Do nothing" in other settings, but the system always does the same, as if xfce-power-manager were not really setting anything. I have tried to modify by hand /etc/systemd/logind.conf changing the lines

HandleLidSwitch=suspend
HandleLidSwitchExternalPower=suspend

leaving the rest fully commented as I found it

...
#HandleLidSwitchDocked=ignore
#PowerKeyIgnoreInhibited=no
#SuspendKeyIgnoreInhibited=no
#HibernateKeyIgnoreInhibited=no
#LidSwitchIgnoreInhibited=yes
...

After restarting the service systemctl restart systemd-logind.service and even after rebooting the behavior of the closure of the lid did note change. I doubt systemd-logind is doing anything here because all options are listed as inactive because systemctl status sleep.target suspend.target hibernate.target hybrid-sleep.target returns

○ sleep.target - Sleep
     Loaded: loaded (/lib/systemd/system/sleep.target; static)
     Active: inactive (dead)
       Docs: man:systemd.special(7)

○ suspend.target - Suspend
     Loaded: loaded (/lib/systemd/system/suspend.target; static)
     Active: inactive (dead)
       Docs: man:systemd.special(7)

○ hibernate.target - System Hibernation
     Loaded: loaded (/lib/systemd/system/hibernate.target; static)
     Active: inactive (dead)
       Docs: man:systemd.special(7)

○ hybrid-sleep.target - Hybrid Suspend+Hibernate
     Loaded: loaded (/lib/systemd/system/hybrid-sleep.target; static)
     Active: inactive (dead)
       Docs: man:systemd.special(7)

At this point I am left to wonder which program is handling the lid ..

Please note that if I use the logout button to do anything like suspend or hibernate or sleep it does it correctly and I am able to wake the machine getting back to a working state. Only when the lid is closed I get this mess ...

9
  • Please run xev then close the lid to see what keycode closing the lid is generating.
    – td211
    Jan 8 at 7:24
  • I do not see any special event from the closing of the lid. xev seems associated to events on the window manager, not system events. I have redirected xev output to a file and really see nothing. The lid is not a button, maybe that's the problem?
    – Rho Phi
    Jan 10 at 22:36
  • My lid generates keycode (XF86Sleep) when closed, are you sure you didn't see any?
    – td211
    Jan 11 at 7:22
  • 1
    It's often useful to see what archlinux has on the subject. It links to xfce and we can then see the buglist. One of them sounds similar, with a workaround of disabling the compositor.
    – meuh
    Jan 11 at 8:34
  • 1
    I use i3lock and can testify the issue has to do with the screensaver not beign shown. If I type the password I get in and works ok. Of course if one disables the screensaver removes the problem, but this leaves the door open. For clarity, my systemctl suspend originally did not include launching the screensaver, so it worked fine!
    – Rho Phi
    Jan 14 at 21:33

1 Answer 1

2

It's often useful to see what archlinux has on the subject. It links to xfce and the xfce4-power-manager, and we can then see the buglist.

One of them sounds similar:

suspending by closing the lid freezes graphics after resuming

using "When laptop lid is closed" = "Suspend" ... "Lock screen when system is going to sleep"

When closing the lid and then opening it back up, the screen will be frozen with what it should look like without the lock screen activated.

The suggested workaround is disabling the compositor with

 xfconf-query -c xfwm4 -p /general/use_compositing -s false 

The issue is linked back to an earlier issue which is still open (at 15jan2023), where someone with a Lenovo Ideapad on Debian 12 has another fix that seems to work, creating /etc/X11/xorg.conf with just the lines:

Section "Device"
  Identifier "Card0"
  Driver "intel"
EndSection

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .