# Turn off display when lid is closed



## abishai (Aug 14, 2016)

Hello, I have a problem with turning off laptop display when I close the lid. I remember that some time ago this was the working solution, so maybe something has changed.

I try to execute `xset dpms force off` with `devd`, however `xset` is not working under superuser.

```
No protocol specified
xset: unable to open display ":0"
```
Any solutions?


----------



## tobik@ (Aug 14, 2016)

That sounds like a bug to me. Does your laptop do this on other OSes?

Try with `sudo -u abishai DISPLAY=:0 xset dpms force off`.


----------



## abishai (Aug 14, 2016)

Can't tell anything about other OSes, this is fresh new Dell XPS13 (Skylake). I tried only FreeBSD
I forgot to mention that `xset dpms force off` under user credentials works, so you idea will work as well, however it's not general purpose solution and I'm 100% sure I used `xset dpms force off` before (years ago) without any glitches.


----------



## SirDice (Aug 15, 2016)

The "problem" is that the root user is not allowed to access the user's X session, see xauth(1). You'll get similar error messages when you open a terminal as a 'regular' user, su(1) or sudo(8) to root and then try to run an Xorg application as root.


----------



## abishai (Aug 15, 2016)

So, I must use xauth to give nesessary rights to superuser first?  Strange that thereis no ready solution in the net, I doubt I'm the first.


----------



## windscape (Aug 16, 2016)

Hi abishai,

Since xset works as a normal user there is no reason to run it as root. However, an easy way to allow root to run X applications locally is to run xhost + as a normal user. It can be added to your X environment's startup file so it runs at every login. Not the most secure solution, but it should work.


----------



## youngunix (Aug 16, 2016)

Try the solution on this thread.


----------



## abishai (Aug 16, 2016)

youngunix said:


> Try the solution on this thread.


That's the same solution, just for X and console. devd starts action under root, so `xset` will fail.


----------



## youngunix (Aug 16, 2016)

abishai said:


> That's the same solution, just for X and console. devd starts action under root, so `xset` will fail.


You can try using acpi(4) by enabling it in /etc/rc.conf or /boot/loader.conf and instead of using `xset`, you can do for "_*SCREEN OFF*_" `sudo sysctl hw.acpi.video.lcd0.active=0` and "_*SCREEN ON*_" `sudo sysctl hw.acpi.video.lcd0.active=1`.

P.S.: Of course the commands above need to match the lid states (OPEN or CLOSED).


----------



## uzsolt (Aug 17, 2016)

youngunix said:


> You can try using acpi(4) by enabling it in /etc/rc.conf or /boot/loader.conf and instead of using `xset`, you can do for "_*SCREEN OFF*_" `sudo sysctl hw.acpi.video.lcd0.active=0` and "_*SCREEN ON*_" `sudo sysctl hw.acpi.video.lcd0.active=1`.
> 
> P.S.: Of course the commands above need to match the lid states (OPEN or CLOSED).


You should load acpi_video module (`kldload acpi_video`) 

But it doesn't work for me:

```
# sysctl hw.acpi.video.lcd0.active=0
hw.acpi.video.lcd0.active: 1 -> 1
```


----------



## youngunix (Aug 17, 2016)

uzsolt said:


> You should load acpi_video module (`kldload acpi_video`)


When dealing with kernel modules, it's obvious that you need to load them or reboot after editing the configuration files. That's why I posted acpi(4).



> But it doesn't work for me:
> 
> ```
> # sysctl hw.acpi.video.lcd0.active=0
> ...


Post the output of `# sysctl hw.acpi.` command.


----------



## uzsolt (Aug 18, 2016)

```
# sysctl hwi.acpi.
hw.acpi.video.lcd0.levels: 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
hw.acpi.video.lcd0.economy: 14
hw.acpi.video.lcd0.fullpower: 15
hw.acpi.video.lcd0.brightness: 15
hw.acpi.video.lcd0.active: 1
hw.acpi.video.crt0.active: 0
hw.acpi.acline: 1
hw.acpi.battery.info_expire: 5
hw.acpi.battery.units: 1
hw.acpi.battery.state: 0
hw.acpi.battery.time: -1
hw.acpi.battery.life: 0
hw.acpi.thermal.tz0._TSP: 30
hw.acpi.thermal.tz0._TC2: 10
hw.acpi.thermal.tz0._TC1: 2
hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1
hw.acpi.thermal.tz0._CRT: 105,0C
hw.acpi.thermal.tz0._HOT: -1
hw.acpi.thermal.tz0._PSV: 104,0C
hw.acpi.thermal.tz0.thermal_flags: 0
hw.acpi.thermal.tz0.passive_cooling: 1
hw.acpi.thermal.tz0.active: 5
hw.acpi.thermal.tz0.temperature: 60,0C
hw.acpi.thermal.user_override: 1
hw.acpi.thermal.polling_rate: 10
hw.acpi.thermal.min_runtime: 20
hw.acpi.cpu.cx_lowest: C1
hw.acpi.reset_video: 1
hw.acpi.handle_reboot: 0
hw.acpi.disable_on_reboot: 0
hw.acpi.verbose: 0
hw.acpi.s4bios: 0
hw.acpi.sleep_delay: 1
hw.acpi.suspend_state: S3
hw.acpi.standby_state: NONE
hw.acpi.lid_switch_state: NONE
hw.acpi.sleep_button_state: S3
hw.acpi.power_button_state: S5
hw.acpi.supported_sleep_state: S3 S4 S5
```

The `sysctl hw.acpi.lcd0.brightness=10` works well (and not only with `10`  ).


----------

