# How to make the laptop sleep when lid is closed



## everypot (Sep 10, 2009)

and wake up when lip is open...


----------



## DutchDaemon (Sep 10, 2009)

Talk about opening a can of worms ..


----------



## everypot (Sep 10, 2009)

DutchDaemon said:
			
		

> Talk about opening a can of worms ..



then I'd better give up...


----------



## DutchDaemon (Sep 10, 2009)

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


----------



## aragon (Sep 11, 2009)

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.


----------



## lme@ (Sep 11, 2009)

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.


----------



## DutchDaemon (Sep 11, 2009)

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.


----------



## LateNiteTV (Sep 11, 2009)

is there a difference with what will happen if you do the sleep/hibernation while in the console or in x?


----------



## everypot (Sep 12, 2009)

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.




```
# 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
```


```
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 (Sep 16, 2009)

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


----------



## Carpetsmoker (Sep 17, 2009)

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 ...


----------



## everypot (Sep 17, 2009)

gnemmi said:
			
		

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



most of them use macbook...


----------



## gnemmi (Sep 17, 2009)

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.


----------



## DutchDaemon (Sep 17, 2009)

Enough guys, this doesn't help.


----------



## gnemmi (Sep 18, 2009)

roger that


----------



## aragon (Sep 19, 2009)

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!


----------



## Carpetsmoker (Sep 19, 2009)

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).


----------



## gnemmi (Sep 19, 2009)

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


----------



## everypot (Sep 19, 2009)

Now it's RC1. Happy updating.


----------



## ring_zero (Mar 19, 2012)

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:

```
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:

```
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.


----------



## zennybsd (Apr 10, 2012)

@ring_zero: Thanks for saving a hell lot of time to reinvent the wheel! ;-)


----------



## ring_zero (Apr 11, 2012)

No problem.  I'm glad someone found it useful.


----------



## dch (Jun 22, 2017)

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.


----------



## onawhim (Jul 9, 2017)

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:


```
# sysctl hw.acpi.lid_switch_state=S3
```

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


```
# 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.


----------



## stig (Jul 31, 2017)

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.


----------



## debguy (Oct 17, 2017)

hw.acpi.lid_switch_state=S3

works for Dell Lattitude D510 (note: running xfce with agp intel driver)


----------



## s5e (Jan 11, 2018)

`/etc/sysctl.conf:`

```
hw.acpi.lid_switch_state=s3
hw.acpi.reset_video=1
```

did not help..

*HP Envy 13-d004no *FreeBSD 12 fails to raise up from suspend.
Maybe I should test TrueOS instead?


----------



## Sensucht94 (Jan 11, 2018)

s5e said:


> `/etc/sysctl.conf:`
> 
> ```
> hw.acpi.lid_switch_state=s3
> ...



Is S3 listed among the supported suspend states? 
Look in the output of:
`sysctl hw.acpi.video.lid.levels`

If S1 is listed, try it first. Also, don't enable hw.acpi.reset_video unless you already tried without: it might be the cause of a failed attempt.  Give also a try to the the sleep button:

```
hw.acpi.sleep_button_state=S*
```



> Maybe I should test TrueOS instead?


Unfortunately, unless you found the developed on their own an acpi driver for HP laptops, chances are very high it wouldn't work either


----------



## Partel (Jan 30, 2018)

Some info is useful for me, thanks


----------



## golpemortal (Sep 6, 2019)

This actually works on my Lenovo ThinkPad T450... I am a very happy camper


----------



## Geezer (Sep 20, 2019)

Tried this on my Lenovo z51-70.

Suspend worked ... never to resume.


----------



## holala (Aug 13, 2020)

hw.acpi.lid_switch_state=S3 works fine on my ThinkPad X220i


----------

