You are not logged in.

#1 2017-11-16 17:25:17

kihanos
Member
Registered: 2012-08-06
Posts: 13

Who sets backlight back on on resume?

Hi,

On my laptop, if the screen backlight is set to 0 before going to sleep, it is set to its maximal value on resume. Does anyone know what process does that? Basically, I'd like the screen to stay black when resuming.

I have looked around and found the following:

  • The systemd-backlight@.service does that, but only is only called on boot (see its man page). I checked and there is nothing in the logs about it on suspend/resume.

  • This is neither X nor KDE, as this also happens if they are not running.

  • I could not find anything in the logs about anyone changing the brightness on suspend/resume.

My guess is, it could be the kernel, hence my posting here. Does someone know? It could also be the BIOS or the video card though.


The reason I ask is the following.
I am trying to adapt the delayed_hibernation service (see Power management on the wiki). This script is called when suspending. It sets up an alarm and wakes up your computer after a while and then puts it into hibernation. The goal is to save power.
The problem about this is that when the computer wakes up to go back into hibernation, the screen turns on and wakes me up. So I'm trying to keep it black and then turn it back on when resuming from hibernation.
The point is, if my script sets brighness to 0 before suspending, it is back to its max for the suspend-to-hibernate phase.

Thanks a lot for your help!


PS: I'm running a Dell Latitude 7370 with Arch, linux-ck kernel 4.13.13 (also tested on latest stock kernel (4.13.12)). The video card is an Intel Corporation HD Graphics 515.

Offline

#2 2017-11-17 00:45:55

holytrousers
Member
From: 3rd Rock from the Sun
Registered: 2007-10-19
Posts: 75

Re: Who sets backlight back on on resume?

hi kihanos, on my laptop (hp dv9700) backlight doesn't change after a resume.
Also, after a reboot, the brightness stays the same but is changed to 100% when the kernel is loaded and then restored back to 0 ( by the systemd-backlight probably )
So my guess would be that it's your bios that restores the backlight to full brightness.
What happens after a reboot ?

Offline

#3 2017-11-17 01:09:01

GenkiSky
Member
From: This account is henceforth dis
Registered: 2017-04-04
Posts: 82

Re: Who sets backlight back on on resume?

OP: Looks like your issue happens on my (Intel graphics) laptop too, though I've never noticed that before. If I had to hazard a guess, the hardware is detecting if the screen brightness is 0 and trying to be user friendly and setting it to max for you. Doesn't seem like something the kernel would do, though I'd be happy to eat my words if someone looked into this more.

Anyway, here's a workaround that might be "good enough" for you: At least on my machine, it looks like setting it to any value != 0 does result in the same value after resume. For example, the value 1 (which to my eye looks the same as 0) before suspending means when I resume, the screen is still effectively pitch black. So for example, you could could put this in /usr/lib/systemd/system-sleep/backlight and make it executable:

#!/bin/sh
[ $1 = pre ] && [ $2 = suspend ] && echo 1 > /sys/class/backlight/intel_backlight/brightness

Last edited by GenkiSky (2017-11-17 01:13:31)

Offline

#4 2017-11-17 15:49:16

kihanos
Member
Registered: 2012-08-06
Posts: 13

Re: Who sets backlight back on on resume?

Hi,

Thanks for your replies!

holytrousers wrote:

What happens after a reboot ?

Well, I don't know if the BIOS set the brightness back to its maximum, but systemd-backlight is indeed called and puts back the value it recorded before shutdown. That is if the latter value was not below 5%. If it was below 5%, then I get a message in the logs from systemd-backlight saying that it sets it back to 5% (in my case 46 out of 937). The behaviour on suspend/resume is definitely different.

GenkiSky wrote:

Anyway, here's a workaround that might be "good enough" for you: At least on my machine, it looks like setting it to any value != 0 does result in the same value after resume. For example, the value 1 (which to my eye looks the same as 0) before suspending means when I resume, the screen is still effectively pitch black. So for example, you could could put this in /usr/lib/systemd/system-sleep/backlight and make it executable:

#!/bin/sh
[ $1 = pre ] && [ $2 = suspend ] && echo 1 > /sys/class/backlight/intel_backlight/brightness

I had thought about that, but when the brightness is set to 1 (out of 937), the screen of my laptop is still pretty bright (as in: it lights up the room even though the lid is shut...). There seems to be a big gap between 0 and 1.


Obviously, my question is not critical... I just thought it would be nice to have a completely phantom suspend-to-hibernate transition.

Offline

#5 2017-11-17 16:10:57

V1del
Forum Moderator
Registered: 2012-10-16
Posts: 21,743

Re: Who sets backlight back on on resume?

When the screen turns back on, what does the value read? Still 0? Maybe a form of https://wiki.archlinux.org/index.php/Ba … 15_only.29 You could try that and instead of using 1 use -1

i915.invert_brightness=-1

which should force the non-reversal behaviour.

Last edited by V1del (2017-11-17 16:16:57)

Offline

#6 2017-11-17 16:49:03

kihanos
Member
Registered: 2012-08-06
Posts: 13

Re: Who sets backlight back on on resume?

V1del wrote:

When the screen turns back on, what does the value read? Still 0?

No, the brightness is set to 937 (its max): reading /sys/class/backlight/intel_backlight/brightness gives me 937.

V1del wrote:

Maybe a form of https://wiki.archlinux.org/index.php/Ba … 15_only.29 You could try that and instead of using 1 use -1

i915.invert_brightness=-1

which should force the non-reversal behaviour.

I just tried that, no change in behaviour. The thing is, everything else works perfectly fine with the backlight (keyboard control, /sys/class/backlight/intel_backlight folder). I have no reason to think that this is a bug or a mishandling of the card by the kernel. I guess clamping the backlight is probably a voluntary behaviour of either the driver, the BIOS or the card firmware. The question is: is it something I can tweak?

V1del wrote:

In general have you gone through that page and ruled out potential culprits, like the systemd service?

Well, yes, that I have (see my first message). I checked in the logs for info, no luck. I also tried masking the systemd service just in case, but no improvement (as expected). I have thoroughly read the backlight page on the wiki, without finding anything else to try.
I even tried controlling the backlight using setpci, but could not make it work (don't know if the card supports it).

Offline

#7 2017-11-17 17:51:34

kihanos
Member
Registered: 2012-08-06
Posts: 13

Re: Who sets backlight back on on resume?

Did some more testing.

First, I tried to have the driver keep the screen off when the lid is shut (this would be a decent enough solution to my original problem). I hoped that was what the parameter

i915.panel_ignore_lid=0

was for. It does not work, although forcing the driver to believe the lid was shut with a

i915.panel_ignore_lid=-1

resulted in the wanted black screen. There might be an issue with the module trying to detect whether the lid is closed or not. This may explain why the default parameter value is 1 (i.e. ignore the lid status).

Second, I enabled

i915.verbose_state_checks

hoping to get more in the logs, if the driver was indeed the one clamping the brighness. No luck.

Offline

Board footer

Powered by FluxBB