Patrick Bartek wrote: > Did my original post below make to the list? Or did it end up being > filtered as spam? Just wondering. I saw it. If you ever wonder then check the mailing list archives. https://lists.debian.org/debian-user/2013/12/msg01326.html > Any conjecture on why the script is not working? I haven't gotten any > where with it. No idea. So didn't answer before. I assume none of the 2,000+ other subscribers had an answer either. > > Installed Wheezy-LXDE 32-bit off LXDE flavor ISO via thumb drive to > > replace Eeebuntu 3.0 that I installed on it 3 years ago or so. Chose > > Base, Desktop GUI and Laptop tasks. Nothing else. All went well and > > as far as I can tell everything works, except Suspend (sleep, not Sounds good. > > hibernate) when the lid is closed. Don't want hibernate anyway. > > Instead of sleeping, the display is shutdown, but the computer itself > > is still fully powered and running. I don't know if LXDE installs a sleep handler or not. > > (The "sleep" key combo FnF1 works however.) That is my normal method of sleeping my laptop. I consider it a feature. It sleeps when I tell it to and not just because I closed the lid. Allows me to carry my laptop from here to there and open it and not have it asleep and needing to reconnect and not having killed my ssh logins. (And without using screen, autossh or mosh. Although connections over the vpn will bridge.) So all I can say is what you are seeing is perfectly normal for me too. I am not using LXDE on my laptop though. I am running a simple window manager only and so don't have all of the fancy scripts that are installed by the heavier desktop session managers. > > I installed the eeepc-apci-scripts from the repo thinking that might > > solve the problem. It didn't, but fortunately those scripts are > > compatible with the others, so no conflicts. I think something you are thinking is a bug, that it does not sleep on lid close, is simply an extra feature of GNOME, KDE, possibly others, and is simply not a feature of LXDE. Nor would I consider it a bug since it is counter to the way that I wish to operate. On the contrary if for some reason the laptop were to suddenly start to sleep upon lid close I would find that annoying and would file that as a bug. And so we have confirmation that one person's bug is another's feature. :-) > > I finally traced the "problem" to lid.sh from the original acpi > > scripts. Full script is below. Toward the top, this if-then is not > > being triggered. Don't know why. > > > > if [ x$LID_SLEEP = xtrue]; then > > pm-suspend > > > > Any answers come to mind? No idea. But it looks like you are on the right trail. Let me cheer you on from the sidelines. I am sure you will figure it out. > > I did a work-around by having the "lid" event call my own suspend.sh > > action directly. It works, sort of: Goes back to sleep after > > initially waking up, requiring a second key press, then it sticks. Frankly that just sounds like a bug that you have introduced with your hacking to debug the problem. But I am sure it will make sense to you once you find it. Good luck! Bob
Attachment:
signature.asc
Description: Digital signature