Home | News | Download | Packages | Forum | Wiki | Github

Do not suspend when laptop's lid is closed


#1

Well, the title is pretty self explanatory. I have acpid and tlp running.

In Mate and Gnome there is an option to disable the standard behaviour of suspending when the lid is closed. I have set those options in Mate and in Gnome to do nothing in AC power, but it does not work with either of them. The reason I want this behaviour is because I have an external monitor which is much nicer for me to use, so there is no need for me to have the lid open, leaving me with extra space on the table.

Another quirk is that when the lid is closed and opened afterwards, neither Gnome nor Mate lock the computer, the computer can be used without a password right away, which is also not desired and most likely related to the issue.

Maybe tlp is interfering with this option, though I doubt of that possibility, since it works great with another linux I have installed in the same computer.

Any ideas or output I should provide will be given. Many thanks in advance.


#2

I have the same problem with the Xfce4 spin. I have everything turned off in the power manager, & unless I shut the lid of the notebook early in boot process & don’t open it I have that problem. Meaning if I then open it, I can’t close it again without it going to sleep.

Last night I renamed the Xfce4-power-manager (can’t delete it as it is paft of the Xfce4 metapackage) & installed Laptop-Mode. I haven’t started that machine yet to test how it went. I’ll post back here after I’ve checked it out.


(Masato the Empty) #3

acpid might be doing that - the generic handler script does have routines for suspending on a closed lid (/etc/acpi/handler.sh) If you haven’t disabled the event, then it is almost certainly at least one thing that’s going to be doing it.

while acpid isn’t all that configurable (multiple rule files covering the same events will always have their actions run in no particular order) there is one rule which will take precedence if you have it configured; you can have it drop an event, and it will not process any rules for that event.

Try creating an event handler: /etc/acpi/events/nolid containing:

event=$REGEX
action=<drop>

$REGEX is a regex covering the events generated by a lid event. I can’t tell what they are from looking at the handler script, and I’m not on a laptop. To figure out what events they are, try editing /etc/acpi/anything temporarily: comment out the action line and replace it with action=echo %e | wall
You need to restart acpid any time you change a rule.

When you generate a lid event, instead of doing something, acpid will instead echo the events to all your terminals so you can see what it does.

For instance, my power button generates
button/power PBTN 00000080 00000000
and
button/power LNXPWRBN:00 00000080 00000009
so my regex for capturing that is “event=(PBTN|LNXPWRBN).*

Before changing the “anything” rule back, you can check to make sure your new rule works; if you generate a lid event, and it’s caught by the rule, then you shouldn’t see any output to your consoles anymore.


#4

I just made that little file for acpi & it did not change the lid closing now I sleep problem.

So I edited the relevant part of the /etc/acpi/handler.sh

It is now like this & the problem is solved. :smiley: I love it when something works… lol

button/lid) case "$3" in close) logger 'LID closed' ;; open) logger 'LID opened' ;; *) logger "ACPI action undefined: $3" ;; esac

The original code wasn’t really quite right, as you’ll see when you compare it to this (which I stole from the Manjaro file - I’m not that bright! :wink: ).

Actually, it is a little bug that needs to be fixed. I suspect the author was working very late & was tired when he/she was writing it. Been there done that.


(Masato the Empty) #5

what event= pattern did you use? (note that I made an error in my post that I’ve corrected; the example file with the dummy value was correct, but later I put “action=” and it should have been “event=”…

at any rate, if you put the event= patterns that I gave in my example, they were for power button events as I mentioned, since I don’t know what the lid events are… you have to find out using some other method (maybe documented somewhere), otherwise, the dirty method I mentioned)

the good news is that your solution works fine as well; being in /etc, the handler.sh script is seen as a config file, so it won’t normally be overwritten when packages are upgraded.


#6

As I said, if you look at the handler.sh you’ll see that there are errors in it. I’m pretty sure that this is why those of us that have this problem are having it. I think that this is a little bug that is easily fixed by Void’s creators by them just looking at this section of script & making it right. Or copying what I used to make it right?


(Masato the Empty) #7

What errors do you see? The void maintainers take those seriously enough (script error fixes get merged pretty quickly in my experience)… That part of the script looks OK to me, but I could be overlooking something (since I’m not running it and throwing any errors)

EDIT: there is a minor cosmetic issue I see with the logger output… I’d personally include the $3 parameter in the output message… but that’s just because I think it might be more informative as to what the acpi event was, as we were testing $3, not $2, even if $2 is important for the log… thus it’s a matter of opinion and one I don’t feel particularly strongly about.


(Masato the Empty) #8

to clarify, if the laptop is sleeping on a lid close event, then that’s the intended behavior. And in that case, if you want to stop it, adding a drop rule for the relevant event to /etc/acpi/events will do the trick. If you craft the right event match, then handler.sh will not be run for that event at all.
(And in that case, anything acting on the lid close event is not doing so through acpid, so disabling other systems might still be needed)

EDIT: more good news - it seems you can use the first field of the event as well, so event=button/lid.* should do the trick. (it works for event=button/power.* stopping the aforementioned powerbutton events, but I can’t test it as I don’t know offhand how to simulate a lid close event on a desktop or a VM)


#9

I hope OP doesn’t mind but I wanted to ask a question here instead of making a separate thread since my ‘issue’ is sort of related. Regarding acpid, I’d like to make it so that it’d also run i3lock when I close the lid and the system suspends to RAM. I tried this myself earlier by editing the handler.sh(I just added ‘i3lock &&’ in front of zzz) and while it did ‘work’, after coming out of suspend and i3lock prompted me for my password, my keys must have not been properly registering or something so I was essentially locked out. I’m pretty sure I didn’t make any mistakes entering the password and I tried several times. Beforehand, I used i3lock from the term and my password went through fine. Does anyone have any idea what could be the issue and what the proper way to do this would be?


(Masato the Empty) #10

If you are sure that your keystrokes aren’t being registered (you can confirm this by not using the -u option so that keystrokes are accompanied by an indicator, or you can try ctrl-alt-<F#> keys to try switching to a different VT) then I’ve unfortunately heard things like this (maybe even on this forum) but have never had to troubleshoot it myself. It’s most likely related to acpi, kernel and your laptop/motherboard, though probably not affected by acpid. It could also be related to X, but I just can’t say anything about it.

You might want to search this forum for other threads related to sleep/wake problems, especially on laptops.


#11

Thanks, I’ll go ahead and see if I can find something from previous threads in the past on this matter.


(Masato the Empty) #12

I didn’t find anything on the forum but the problem is all over the internet, going back years. And it appears to definitely be related to Xorg. If you plug in a USB keyboard/mouse, that might get you control of the system. You want to look through xorg logs for messages about input devices having changed and being disabled.

From there??? I don’t really know…

@ferviron - sorry for getting off track. I think you might want to look at my first and fourth responses for possible leads.


#13

Hi @masato I’m sorry I had to leave the conversation earlier, as Discourse locked me out for 5 hours. :frowning: I’m familiar with Discourse so I’ve just been doing other stuff setting up my Void notebook.

OK, to answer your question I’ll paste what I wrote before being told by Discourse to wait before I can’t reply:

I’m no scripting guru, but from memory (I didn’t keep a backup) in the original script there is a $2 instead of a $3 I think that would be enough to stop that section of script from functioning at all. As the $3 is the variable that defines that section:

button/lid) case "$3" in

Also there is the zzz which tells the system to suspend, I removed that too. :slight_smile: Which is fine by me as I never want my machine to suspend.

Either way, there are scripting errors in that section beyond what I have stated, it really was quite messy. Which is why I suggested earlier that whoever did it was very likely very tired at the time.


(Masato the Empty) #14

You might be on the same schedule as me. Somewhere in the western hemisphere?

Actually, parameter 3 is most likely the one that needs to be tested as it’s the one that would say open or close. I can’t confirm this for sure because I can’t generate lid events to see what the actual acpi message is, but it’s highly doubtful that it would ever sleep the PC if that was not correct (if that parameter is neither open or close, then it would log an error and do nothing).

As far as it being messy, I dunno. that part of it looks pretty messy, and like I said, I don’t really see any scripting errors. By the way, the author of that script is JRP (Xtraeme), up to and including the commit that added lid events, so make of that what you will.

At any rate, as I mentioned before, nothing wrong with editing that script, and what you put in there looks nice and clean. In fact, if you wanted to change the behavior to something other than ignore, then you’d have to either edit that script or make a custom version which you then pointed all actions to, so it’s not going to be unheard of anyway. (since addtional rules for an acpi event will be applied in addition to the catchall).


#15

OK, I just put the zzz back into that section of the handler.sh file & rebooted my machine & I can still open & close the notebooks lid without it shutting down.

So I think that the $2 needs to be changed to a $3 the other stuff is probably just cosmetic, though whether the following line being undefined matters or not is beyond me:

[edit:] Removed a section as it was for systemd & it got past me.


#16

In Void there is no such logind, which is part of systemd’s internals, it’s substitute, to make Gnome work, is elogind.

@masato @royaldibble it’s okay if the thread moves just a tiny bit away from the original question as long as it is related.

I had seen the handler script, but did not bother to change it, since it was supposed to be designed correctly. Here are my concerns:

zzz and ZZZ work pretty much flawlessly. However, they do not send a suspend signal. What I mean: they do sleep and hibernate perfectly, yet no system is able to understand the computer is entering in any of those modes and is unable to answer correctly (locking the system and asking for a password). This is a bit undesired.

Editing the script is a solution, yes, which I’ll try to put into effect in a couple of day. However, this does not solve that any change in any configuration software (gnome-settings, xfce4-power, mate-power, lxqt-power; yes I have tried them all and can confirm none of them work), is unable to set the user’s options. It may be related to Void having designed their own management solution (zzz). And therefore a fully working solution that is able to integrate well within existing desktops is the desired goal.

I’ll look into more detail how these systems handle the lid and I’ll see if I can come up with a solution.


#17

@ferviron Sorry about the systemd thing, I just saw it & posted it, I didn’t look into it as I have no need for it. I’ll edit my post & get rid of it.

Re. your problem: As I see it there is at least one error in the handler.sh script that matters. If you use the following & put the zzz in where it belongs, (you’ll see where it is in your current script), then you “may” be out of trouble, as that script should then work properly as best I can see. (Keep a copy of the original script as backup for just in case you need it, then you have nothing to loose.)

button/lid) case "$3" in close) logger 'LID closed' ;; open) logger 'LID opened' ;; *) logger "ACPI action undefined: $3" ;; esac

I left the esac in at the end just for good measure.

I used the above & my problems were solved, after that I put the zzz back in & it still works fine, BUT I haven’t tested whether suspend does still work if you turn it on as I’m not & never have been interested in suspend. (I probably should give it a test shouldn’t I.)

That’s almost the best I can do for you, I hope it helps. :slight_smile:


(Masato the Empty) #18

Still seeing nothing wrong with the script that ships, and you’ve yet to point out otherwise.

But it could be fun to keep poking at this to see what else comes out, if @ferviron doesn’t mind.

If you’re still talking about the line logger "ACPI action undefined..." then that doesn’t affect any functionality; you can change that to logger: "elephants are pink and green" and it wouldn’t affect the function of the script beyond giving you an inaccurate log entry, since no other action is performed on that fallthrough condition.

I still wonder if that’s the correct decision (rather than logging “$2 $3”), but the script has been that way since 2014, and it works, so I’m not complaining. Not enough to bother with it though (and I’d rather just ask Xtraeme his line of reasoning than try to guess his state of mind… he’s way more knowledgable than I and he seems the nice fellow too)

Additionally, assuming that it was acpid that was suspending the OP’s post, which we actually haven’t established, so everything is still tentative, then the script already worked as intended if it was putting his system to sleep, and this thread has been about preventing that. Which your solution also does (by simply removing the action) and does it just fine, don’t get me wrong.

One thng I hadn’t mentioned before that you might want to do. Instead of editing the file as originally named, if you edit a renamed copy then you have the original one unchanged, and you can point /etc/acpi/events/anything to that script. The advantage? If the original file (classified by the package as a config) is seen as changed, then if improvements are ever made to the script, you won’t see them installed; but if you don’t change the file, then I xbps will not replace it with the new version.


#19

I am going to try to be as clear as possible, there seems to be quite a confusion going here.

  • zzz and ZZZ work as intended and acpi (acpid) seems to work as expected.

  • What I (or should be) want(ed): configure the behaviour of the lid (button?) within any DE’s power manager, which is the expected behaviour in any distro. Setting an option correctly, no matter where, should yield the desired outcome, however, this does not happen with the power settings. I don’t what my computer to suspend if it is in AC power (there is an explicit option for that), yet I do want to maintain the suspend utility for whenever I am using the battery.

  • What I know: it does not work with any DE, so it seems to be directly related to how Void handles the power settings. Void ditched pm-utils in favour of a homemade solution zzz, that may be the cause of the problem. I said that zzz works as intended… Well, not really. zzz only suspends the system, however, no suspend signal (or whatever you want to call it) is sent. zzz freezes and powers down the system, just that, the DEs seem to have no way of knowing whether the system went to sleep or not, which in turn, makes them to ignore prompting for a password and locking the system. When you input an event after the computer has suspended through zzz, it just continues with what it was doing (you should be able to reproduce this behaviour quite easily, in a DE, WM, or tty). Extra bit: I am back trying different DEs, with GNOME 3.24 (which relies on systemd’s logind) a solution was created, elogind. During the boot process, for a couple of seconds just before GDM shows up I can read something like the following (note that I am writing by memory here about something that shows up a second): /dev/input/event1 Lid intput /bin/elogind. I am pretty sure this has something to do with the problem here, yet the results are the exact same, nothing. Battery states are reported correctly.

  • What I don’t know: how DE’s power managers handle their options, pretty sure in a systemd distro they rely on systemd’s utilities.


(Masato the Empty) #20

If you mean no acpi event is generated as a result of running zzz, then that’s to be expected. It’s acpi events from the kernel that generates those signals; your lid button sends the signal itself, and the acpid handlers take care of those on Void. zzz is run as a result by acpid…

As far as doing things through the desktop PM system, I think I see your point.

But that’s probably just the way it is. If acpid is running, then it captures all signals, and runs handler.sh, which processes them if it contains code to do so. I don’t know if this necessarily prevents other pm systems from acting on them as well, but if you don’t want your system to sleep, and acpid thinks the system should sleep, then you nonetheless have to tell acpid to drop the event and not act on it.

But having acpid not handle those things is probably not a desired default for the maintainers, so you can’t make everybody happy. If you want something different, you have to use a different system. Things like pmutils I guess can be configured to work with acpid (rather acpid can trigger pmutils stuff) but they’re not related, and each can live without the other.

It seems likely also that DE pm utils (in addition to systemd when available) are simply implementing their own methods based on udev and other bits that are still able to live outside of systemd (when not available).

But this is just from what I can tell about acpid. Its capabilities are all very simple. It’s just the daemon and related tools; Void wrote the handler we use with it. Maybe there is more to it, but it’s also not very extensively documented, so it really does seem that what you see is all there is.