I recently got a new laptop (yoga 2 pro) and am running Manjaro. When I close the lid on the laptop sometimes it will suspend properly most of the time it just wakes up immediately, this is unacceptable behavior. The power settings are set to suspend on lid close but I'm unsure what powerdevil is doing is it calling systemctl suspend (which by the way suspends the laptop properly but doesn't ask you for your password on resume which is a security hole)? I have tried messing with logind.conf as well as handler.sh both seem unable to solve this problem. I believe that something is waking it up right away but I'm not sure what exactly I've been looking through log files but nothing stands out. This is a partial copy of the log file http://pastebin.com/jCREV26g. Hopefully someone here has more knowledge about this than I do.

The reason why you are not prompted for your password on resume when you use "systemctl suspend" is because this is a system level command - and it is unlikely KDE is aware your system has been suspended.

In terms of diagnosing this, have you tested whether manually suspending the system (ie. leaving the lid open) allows it to enter sleep successfully?

Oh Ok that makes sense, thank you. Yes suspend works manually but the (start) menu (as well as cairo dock) must call systemctl suspend because it doesn't ask for the password on resume. The system goes into suspend properly after a set amount of time and will ask me for my password on resume so that part is working properly. The power button that I have set to display logout menu also works properly. It just seems to be something with the lid because most of the time it wakes up immediately after I close it.

This sounds like unusual hardware specific behaviour. You'll likely need to ask some kernel folks about how to investigate this unfortunately - neither KDE nor any other user space process has any influence at this point. It is likely an unusual interaction between the Linux kernel and ACPI as implemented on your system (for my computer to suspend properly, the USB modules must be unloaded first otherwise it hangs before entering sleep).

Ok I could give you the benefit of the doubt that it is a kernel issue but that doesn't explain why (using kernel 3.12) I can get it to work on say a distro like ubuntu using unity or manjaro using openbox. If I was just dealing with systemd and not powerdevil I could just have it run a script to suspend it on lid close but the way that powerdevil seems to suspend this laptop causes it to fail around 3/4 of the time. However if it is a kernel issue maybe it has something to do with the 360 degree hinge, or like you say maybe something with usb. Who would I contact about something like this anyways I have no idea.

I see. Powerdevil uses UPower to initiate suspend, so I would suggest you look into the mechanisms it uses to suspend the system. I would be quite surprised if Unity were using something else, but as Unity is based on Ubuntu it could be using completely different versions of the kernel, UPower, etc.

As for why Openbox succeeds - what mechanism does it use to initiate suspend?

I will have a look into upower, thank you. Openbox succeeds by changing the line HandleLidSwitch=suspend in /etc/systemd/logind.conf.

In that instance, Openbox isn't doing anything - it is systemd doing it instead.

Alright I thought that I had this solved yesterday but I guess it was just the placebo effect. I need to find the page on the internet where it is thoroughly explains just how powerdevil works. The arch wiki needs to be updated cause when you go to the power management page it still mentions pm-utils, the upower section is also out of date and its man page might as well not exist. From what I have observed this computer is doing 1 of maybe 2 things when I close the lid. One it is being interrupted or its being woken up immediately after the lid is closed, now this could have something to do with usb errors (https://bbs.archlinux.org/viewtopic.php?id=172587). Or two powerdevil is using the wrong command to suspend the computer which I can't confirm or deny because I can't find any information to explain how it works. If powerdevil is working properly it should use upower to send the command (dbus command dbus-send --system --print-reply --dest="org.freedesktop.UPower" /org/freedesktop/UPower org.freedesktop.UPower.Suspend). Tried putting that around line 62 in the handler.sh file but it still doesn't work half the time either.

If I were to remove powerdevil and just use systemd would that work cause this is BS?

Nevermind guess dbus-send --system --print-reply --dest="org.freedesktop.UPower" /org/freedesktop/UPower org.freedesktop.UPower.Suspend is depreciated too.

As a temporary fix what command could I use (not systemctl suspend) that will lock the screen on resume. Need to fix cairo dock and the main menu so that it uses the same command powerdevil uses, then I'll just assign a shortcut for suspend.

The following command will lock the screen, but it will not initiate a system suspend. It needs to be run as the user who is currently logged in to work.

Code: Select all

qdbus org.kde.ksmserver /ScreenSaver Lock

Hmmm thats weird command doesn't work qdbus command not found.

Found this link https://www.csslayer.info/wordpress/linux/yoga-2-pro-on-linux/. Turns out that it is something to do with the usb waking the laptop up sometimes because since I've run the following script (thanks to csslayer) my problem seems to be solved.

Code: Select all

echo XHC > /proc/acpi/wakeup
echo EHC1 > /proc/acpi/wakeup

Just ran it as a root script or I guess could have put into rc.local but whatever works.

If you are using a Plasma Workspace that is extremely unusual, as part of the login process uses the qdbus command.
Can you check to see if your distribution hasn't renamed it something like qdbus-qt4 or something similar?