Backlight turns off completely when brightness reaches zero

[aykevl]

I have a relatively new laptop (Lenovo L450). When I lower the brightness (either via the brightness applet or via function keys) and the backlight reaches zero, the backlight is turned off completely. At that point, /sys/class/backlight/intel_backlight/brightness is 0 (the maximum value, /sys/class/backlight/intel_backlight/max_brightness, is 973. The LCD is still on (something is still visible when inspecting the screen closely), but the screen appears off.

This may be a kernel bug or an issue with the hardware/firmware, so if it's specific to this model it may be better to work around it in the kernel.

In Cinnamon (Gnome 3 fork) it is not possible to turn the screen off this way with the brightness slider (lowest value appears to be 9), but it is still possible with the function keys.

I am running a fully up-to-date version of Debian testing (stretch), which includes version 1.10.2-1. I can report the issue in Debian if that is a more appropriate place.

My lspci:

00:00.0 Host bridge: Intel Corporation Broadwell-U Host Bridge -OPI (rev 09)
00:02.0 VGA compatible controller: Intel Corporation Broadwell-U Integrated Graphics (rev 09)
00:03.0 Audio device: Intel Corporation Broadwell-U Audio Controller (rev 09)
00:14.0 USB controller: Intel Corporation Wildcat Point-LP USB xHCI Controller (rev 03)
00:16.0 Communication controller: Intel Corporation Wildcat Point-LP MEI Controller #1 (rev 03)
00:19.0 Ethernet controller: Intel Corporation Ethernet Connection (3) I218-V (rev 03)
00:1b.0 Audio device: Intel Corporation Wildcat Point-LP High Definition Audio Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation Wildcat Point-LP PCI Express Root Port #1 (rev e3)
00:1c.2 PCI bridge: Intel Corporation Wildcat Point-LP PCI Express Root Port #3 (rev e3)
00:1c.5 PCI bridge: Intel Corporation Wildcat Point-LP PCI Express Root Port #6 (rev e3)
00:1d.0 USB controller: Intel Corporation Wildcat Point-LP USB EHCI Controller (rev 03)
00:1f.0 ISA bridge: Intel Corporation Wildcat Point-LP LPC Controller (rev 03)
00:1f.2 SATA controller: Intel Corporation Wildcat Point-LP SATA Controller [AHCI Mode] (rev 03)
00:1f.3 SMBus: Intel Corporation Wildcat Point-LP SMBus Controller (rev 03)
00:1f.6 Signal processing controller: Intel Corporation Wildcat Point-LP Thermal Management Controller (rev 03)
04:00.0 Network controller: Intel Corporation Wireless 7265 (rev 59)
05:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS5227 PCI Express Card Reader (rev 01)

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[ericcurtin]

I notice this too, but is this not expected behaviour? It's nice to be able to fully adjust the backlight

[aykevl]

Well, it cannot be expected that the backlight turns off completely, making the screen completely unreadable. I cannot imagine a use case for that.
My use case for setting the minimum to 1 is being able to set the brightness to the lowest possible value while still being able to use the laptop in a dark room.

On the other hand, I checked an older laptop (Lenovo T60) which has 8 brightness levels and level 0 still has the light turned on. Losing one level there would be unfortunate (I don't use the laptop anymore, it's just to show that this behavior is not consistent across systems).

It is quite unfortunate that the kernel is inconsistent in what 'zero brightness' means. The only API I could find is not clear about it.

https://www.kernel.org/doc/Documentation/ABI/stable/sysfs-class-backlight

[ericcurtin]

I have a Lenovo E540 and I have the same behavior as your L540. Do you have this message in the logs on boot up by any chance?

thinkpad_acpi unsupported brightness interface

This is definitely a kernel problem, I will look into it and fix it. Was looking for a reason to make another kernel contribution to be honest! We probably use the same drivers for both our Lenovo machines (hopefully). Would you test on your machine if I gave you a guide, once I make the fix?

[ericcurtin]

As your L450 I meant!

[aykevl]

I looked up the issue once (I have the message too), and this message does not indicate a kernel bug.

[aykevl]

See the bug report and the patch.

I would happily test on my machine if there is a patch.

Maybe we could send a message to Richard Purdie (apparently the maintainer of /sys/class/backlight/<backlight>/brightness) to ask what zero brightness means and which of the two behaviors is the right one.

[ericcurtin]

They actually got rid of this error log and changed it to info instead which is more correct:

torvalds/linux@d618651

[ericcurtin]

Emailed a couple of guys on the kernel mailing list:

http://marc.info/?l=linux-kernel&m=145212864412148&w=2

[aykevl]

Thank you for working on this issue! :)

[ericcurtin]

It looks like my email may have been ignored though! Which is strange, normally the kernel community is quite responsive.

[ericcurtin]

Wait actually one of my email filters caught it by mistake. Looks like the minimum brightness issue will be staying at least in the short term:

"Whether '0' means 'off' or 'lowest brightness level' has been
discussed several times. Sadly, we cannot change semantics without
breaking user-space, so you better work around it. There have been
several proposals to fix it, but I guess no-one cared so far.

Anyway, both features (turning backlight off and lowest backlight
level) are used actively by user-space. Hence, both should be
supported."

[aykevl]

Well, if they don't want to change the kernel interface, I think the best solution would be to put another 'file' in that directory called something like min_brightness or lowest_brightness for the lowest brightness the backlight is still on.

In the meantime, we could make a list of devices that are known to be completely off at brightness 0. IMHO, that's still something we shouldn't need to care about, but until the kernel provides us this information it's a workable solution.

I'm prepared to write a patch if needed. Right now I'm installing the Debian sources.

[ericcurtin]

A patch fixing this issue on the MATE side rather than the kernel side? Yeah, that would be cool, let me know if you want any help. I feel like we are just working around a kernel issue here but if it works, that's fine I guess! :)

[aykevl]

I'm not so sure I want to sign up for the LKML (AFAIK it has a lot of traffic), but maybe you can propose such an interface?

In the mean time I've looked into the issue. I think I can fix it, but I cannot promise anything.

[aykevl]

Well, it turns out this stuff isn't so simple...

I was under the impression that mate-power-manager managed the brightness directly. Apparently this isn't the case (which is logical as a normal user cannot directly change brightness).

It looks like it is managed within X11 via the XRRQueryOutputProperty call (see gpm_brightness_output_get_limits in gpm-brightness.c). Apparently X11 does have some idea of devices having a minimum limit, as there is also a min parameter. It looks like MATE even takes the min parameter into account when calculating the brightness, so I think the MATE side of this is okay.

I ran mate-power-manager with --verbose and got a lot of messages when changing the brightness, including this one:

TI:22:54:58 TH:0x181af80    FI:gpm-brightness.c FN:gpm_brightness_output_get_percentage,330
 - hard value=46, min=0, max=937

So, X11 reports the wrong values.
I've dug a bit further and reported the issue here, hoping someone will pick it up:
https://bugs.freedesktop.org/show_bug.cgi?id=93643

[aykevl]

Here is a hack/workaround if you're interested. This works on my laptop. That is, I haven't actually tested the git source, but doing the same modifications to the Debian package works for me.
https://github.com/aykevl/mate-power-manager/tree/fix-min-brightness

The first commit was necessary, it appears this is a bug in the handling of min. The second commit works around the issue on backlight interfaces that have a large range (where it doesn't really matter if the lowest value is ever reached, as long as the backlight stays on).
If we go down this rabbit hole, I think it's a good idea to also check if it's the intel_backlight, so we only work around that interface.

Feel free to merge one or both of the commits.

Note: the // HACK in the second commit is there for a reason ;)

Oh, and I found this thread: http://thread.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/19680/focus=19680
It gives some insight into why the backlight mess is the mess it currently is.

[ericcurtin]

I probably won't merge, this doesn't annoy me enough to compile my own package :) But if you plan on merging this to master of course I can build and test this. I suppose you could just check what symlink/directory is in /sys/class/backlight and do this if it's interl_backlight or is that a bit hacky, is there a cleaner way of checking? This will work I guess. Do all distros use this directory structure? /sys/class/backlight I'm just asking the question I don't actually know.

[psyborg55]

kernel problem. on 3.2.11 this worked fine (min brightness=dimmed screen, max brightness=bright screen), on 4.9 min brightness=backlight off, max brightness=bright screen; such behavior seems to allow wider dimming range, and it works as expected with CCFL backlights, but breaks normal operation with LED backlight: min brightness=backlight off, max brightness=dimmed screen; if patched drm drivers for LED inversion; min brightness(8)=dimmed screen, max brightness(255)=backlight off - need to set 254 for max brightness or alternetively not use Fn+F9/F10 keys but adjust brightness only via GUI slider

[lukefromdc]

I can confirm this one, I get this on a converted Chromebook too. I can excape it by terminating the X server and starting another session. If that failed, ctrl-alt-F2 to another VT will bring back a working monitor from this, allowing killing the x session (if you have ctrl-alt-backspace disabled) or other recovery steps.

I agree this is serious and a deterrrent to using the applet. Even if it ALWAYS recovers on starting a new session (I have tested one machine only), you still lose your work. We really do need a minimum brightness here.

[cwendling]

FWIW, I this is still relevant and I had a user having set the display off that way (through the applet's slider), and didn't know how to get the screen back on.

I think we need either a (configurable) hard value for the minimum if that's something that can actually work reliably across hardware (some hardware will dim all the way to off through the kernel API, some won't), or rather a minimal percentage (e.g. don't go below 5% of the available range or so). We need a setting for that in any case because there really are some people that want very low settings, or even off, so there won't ever be a perfect one-size-fits-all value.

I quickly investigated doing so using a percentage minimum, but unfortunately the handling of key shortcuts is kind of separate from the absolute percentage setting, which might require refactoring more code than I found time for. If anybody's interesting in continuing this, here's what I had: https://gist.github.com/cwendling/797796eaffdf8688f1f286b96f637a28 (not that it's necessarily super useful as it might require a lot more refactoring).

[ericcurtin]

I remembered talking to the Linux kernel community on this one. To them zero meant zero as in off. Now if from a userspace perspective if Mate wanted a configurable minimum, that seems reasonable and fine to me!

[psyborg55]

maybe you can use similar solution i used to prevent backlight from going off when set max brightness.
it is last hunk in this commit: psyborg55/linux@421273b

RADEON_MAX_BL_LEVEL - 1

note that this is on a system that had CCFL backlight as default, and i upgraded it to LED backlight (didnt ever bothered with BIOS support for the change, it is possible BIOS have some effect on it too), on systems with LED default it may need different kind of change, but in general you get an idea how to patch the driver...

[fornellas]

Same scenario with a Dell Precision 5550:

• /sys/class/backlight/intel_backlight/max_brightness max is 120000.
• This code breaks down brightness in 20 discrete steps.
• Lowest value ends up being 0, screen fully black, and the next step is 6000, which is just way too bright for night time.
  • I'm not totally sure, but it seems that in my case, these values are linear, not gamma compensated, which may explain why the minimum value is so bright.

Given the range of differences across various implementations on how brightness works, IMHO the only reasonable solution here is to have user configurable values:

• Min / max brightness.
• Number of steps.
• Gamma correction.

Ideally we could have a database of such values for various laptops, though this would be a stretch.