How to make the laptop sleep when lid is closed

It will be different varying with laptop make and model, ACPI implementation, BIOS, chipset, 32/64-bit, motherboard type, FreeBSD version, sysctl settings, supported 'S states', 'shallow suspend' vs 'deep suspend' --- it's not even funny ... Google for FreeBSD plus hibernation / suspend / resume, and you will get the drill ..

Then again, maybe someone will enjoy the subject ;)
 
Last edited:
Also look at devd(8)

There are two distinct components to this: getting suspend/resume working (sometimes not possible), making devd do it for you.
 
Last edited by a moderator:
Actually you don't need devd for this.
Just set # sysctl hw.acpi.lid_switch_state=S3 if you know that ACPI state S3 (Suspend) works for you.
 
Last edited by a moderator:
Getting the laptop to sleep on closing the lid is the easy part (though I've chosen to just shut down the screen, and revive the screen when the lid opens), it's the coming back out of sleep/hibernation that's causing the most problems. Suspending is usually fine, resuming is ... quite unpredictable.
 
lme@ said:
Actually you don't need devd for this.
Just set # sysctl hw.acpi.lid_switch_state=S3 if you know that ACPI state S3 (Suspend) works for you.

Code:
# sysctl -a | grep hw.acpi
hw.acpi.supported_sleep_state: S3 S4 S5
hw.acpi.power_button_state: S5         
hw.acpi.sleep_button_state: S3         
hw.acpi.lid_switch_state: S3           
hw.acpi.standby_state: NONE            
hw.acpi.suspend_state: S3              
hw.acpi.sleep_delay: 1                 
hw.acpi.s4bios: 0                      
hw.acpi.verbose: 0                     
hw.acpi.disable_on_reboot: 0           
hw.acpi.handle_reboot: 0               
hw.acpi.reset_video: 0                 
hw.acpi.video.crt0.active: 0           
hw.acpi.video.tv0.active: 0            
hw.acpi.video.ext0.active: 0           
hw.acpi.video.lcd0.active: 1           
hw.acpi.video.lcd0.brightness: 100     
hw.acpi.video.lcd0.fullpower: 100      
hw.acpi.video.lcd0.economy: 80         
hw.acpi.video.lcd0.levels: 100 80 0 10 20 30 40 50 60 70 80 90 100
hw.acpi.video.out0.active: 0                                      
hw.acpi.video.out1.active: 0                                      
hw.acpi.thermal.min_runtime: 0                                    
hw.acpi.thermal.polling_rate: 10
hw.acpi.thermal.user_override: 0
hw.acpi.thermal.tz0.temperature: 57.0C
hw.acpi.thermal.tz0.active: -1
hw.acpi.thermal.tz0.passive_cooling: 0
hw.acpi.thermal.tz0.thermal_flags: 0
hw.acpi.thermal.tz0._PSV: -1
hw.acpi.thermal.tz0._HOT: -1
hw.acpi.thermal.tz0._CRT: 102.0C
hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1
hw.acpi.thermal.tz0._TC1: -1
hw.acpi.thermal.tz0._TC2: -1
hw.acpi.thermal.tz0._TSP: 300
hw.acpi.battery.life: 100
hw.acpi.battery.time: -1
hw.acpi.battery.state: 0
hw.acpi.battery.units: 1
hw.acpi.battery.info_expire: 5
hw.acpi.acline: 1
hw.acpi.cpu.cx_lowest: C2

Code:
echo "hw.acpi.lid_switch_state=S3" >> /etc/sysctl.conf
reboot

Then once the lip is closed and reopened, it's difficult to resume...
 
gnemmi said:
... when not impossible ... and the worst thing is devels don't seem to care about it at all ...

So what are you going to do? sue them? :OO

The developers have no obligation to you ...
 
Carpetsmoker said:
So what are you going to do? sue them? :OO

No ... I just gonna cancel my FreeBSD subscription, stop testing new stuff and advocating for FreeBSD use ... and I think that´s about that ...

Carpetsmoker said:
The developers have no obligation to you ...

That´s a claim I never made. Just a blatant attempt to put your words in my mouth.
 
One has to remember that a project like FreeBSD is made up of software components that various people care enough about to write. Every developer cares about a small set of features which he/she maintains, and the collective of that is what makes the operating system. It's unfortunate that there aren't any or enough people that care enough about suspend/resume to make it work perfectly, but blaming "the developers" in general is a bit unfair. Every developer can't be expected to care about everything. That feature will work excellently when someone comes along who cares enough about it to write the code, and if that's you, shut up and hack! :)
 
I'm sorry about my message, looking back it was a unnecessarily rude and harsh and didn't convey the message (aragon did a better job at that).
 
Sorry for my message too .. it's just that I've been following FreeBSD 8 since -CURRENT and I just need a fix on bge .. and I see -BETAS pass by and nobody caring about it and it really makes me think .. what's the point of chasing down bugs that no one pays attention too?

http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/136876

I'm not a devel, otherwise: yes, I would shut up and hack as I beleive I should, but I just can't ..

Sorry if I offended anyone, really.

My apologies and best regards for you all.
Gonzalo Raúl Nemmi
 
Sorry for posting on such an old thread, but every time I google FreeBSD and suspend/resume I wind up here, so I will assume that others do as well. That being said, fire up vim, ee, emacs, whatever else you may use and edit /etc/sysctl.conf as follows:
Code:
hw.acpi.lid_switch_state=s3
hw.acpi.reset_video=1
Save and close. The next part is completely optional, but while video should now be working on resume, most likely the mouse will not be. Restarting the mouse daemon will bring it back, but for a more seamless solution open /boot/device.hints in your favorite editor (I chose to do this with an editor rather than echo so I could keep it with the other hints for psm), and insert:
Code:
hint.psm.0.flags="0x2000"
Save the file. You will get a warning about saving a Read Only File, and as such, the standard disclaimer "DO THIS AT YOUR OWN RISK" applies. Now reboot the machine, close the lid, and wait for the machine to suspend, once it does, open the lid, and hopefully you should be in business. A side note that might help: I tested this on a Toshiba Satellite C665D with an ATI M880G chipset, and an ATI HD4250 video card, version of FreeBSD is 9.0 RELEASE with a generic kernel. I have seen indicators that this solution will work with NVIDIA, as well as ThinkPads and several other platforms.

gnemmi said:
... when not impossible ... and the worst thing is devels don't seem to care about it at all ...

I think that it has less to do with the FreeBSD devels, and more to do with the fact that the BIOS manufacturers don't implement the ACPI standard to the letter, and seem to think that the world at large only uses various versions of Microsoft products. As such they only test their implementations of ACPI under those products, and the rest of the computing community gets left out.

I hope that this solution can save someone else a few hours, a lot of reboots, and a headache to get this working.
 
Super handy. I'm running the drm-next code on a Dell XPS13 and only required hw.acpi.lid_switch_state=s3 to have fully functioning suspend/resume just by closing the lid, from X, with wifi, mouse etc all working fine afterwards. So sweet.
 
I have a Lenovo ThinkPad T420 running FreeBSD 11.0-RELEASE-p1 with Xfce as my DE and all I had to do to get the lid closing to trigger a suspend was:

Code:
# sysctl hw.acpi.lid_switch_state=S3

To make it permanent add the following to /etc/sysctl.conf:

Code:
# Enable lid closing to trigger suspend
hw.acpi.lid_switch_state=S3

There's a couple of seconds delay upon resume before keyboard and mouse start responding, but otherwise works nicely.
 
I had to do the above and recompile the Kernel without VESA to make suspend and resume work. I am using an older lenovo x220 to run FreeBSD 11.1.
 
Back
Top