Symptom: backlight turns off completely in the MATE desktop environment when turning the brightness way down. I would expect the screen to stay lit, even at the lowest value. I see no use case in turning the screen off completely with the brightness keys, and it is certainly not good for the user experience when you actually just want a very dim screen (e.g. in a dark room). I have this system: Laptop: Lenovo L450 Graphics (lspci): Intel Corporation Broadwell-U Integrated Graphics (rev 09) Distribution: Debian stretch (testing) Kernel: 4.3.0-1-amd64 In /sys/class/backlight, there's just intel_backlight. /sys/class/backlight/intel_backlight/max_brightness is 937. Digging in the MATE sources (mate-power-manager), I found it requests minimum and maximum brightness values using XRRQueryOutputProperty. Unfortunately, this call returns max=937 (correct) and min=0 (IMHO wrong, should be 1). With the result that the screen backlight turns off completely when setting the brightness to the lowest value. I assume this minimum value is reported by the Intel driver. And indeed, at the bottom of the function intel_output_create_resources in the file src/intel_display.c in xf86-video-intel, I found this: intel_output_create_ranged_atom(output, &backlight_atom, BACKLIGHT_NAME, 0, intel_output->backlight_max, intel_output->backlight_active_level, FALSE); I don't really understand what this is doing, but to me it looks like the '0' here is the minimum value, hardcoded in the source. This is how far I've gotten digging in the various sources looking for the issue. As a reference: - https://github.com/mate-desktop/mate-power-manager/issues/179 - http://marc.info/?l=linux-kernel&m=145225412911583&w=2
The ABI is that the minimum backlight brightness is zero; the kernel also only reports max. Differentiating between off and zero is a UI decision, it is already seperate at the driver level (i.e. 0 brightness == min brightness, not off).
Well, the UI has to know somehow at what value the screen is still lit: is that 1 or 0? It is very bad for UX to turn off the screen completely. Can you explain where the bug is, then? Certainly not in the UI, it only talks to an abstracted backlight API. The kernel API here is not consistent (0 can mean both off and the lowest lit value), and the kernel people don't seem willing to fix this (for fear of breaking ABI compatibility): http://marc.info/?l=linux-kernel&m=145225412911583&w=2 Where would the bug otherwise be, if not here?
Here is more background I found on the LKML: http://thread.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/19680/focus=19690 In short, it is a mess. It appears that acpi_video* brightness levels have the '0 equals lowest still lit value' behavior, which is what most userspace expects, but intel_backlight (and possibly others) have the '0 equals backlight off' behavior. The question now, I think, is who has the wrong behavior, and who's gonna fix it? To me it looks like a kernel issue, but the kernel devs don't seem willing to fix it. Other solutions look like workarounds to me. This would be the second appropriate place to fix it, so all X11 using systems will work properly. Desktop Environments could fix it, but that would be duplication of effort in each DE. I set the bug to 'reopened' as there is a bug, but possibly not here.
Wrong.
Well, could you please explain yourself a bit more? This *is* a bug. It is bad for UX. Maybe not in Xorg, but it is a bug. As stated in the LKML, the behavior among drivers varies. Some backends *do* turn off backlight completely. That means, there is something visible on screen if you shine a bright light on the LCD (so the LCD is still working), but because the backlight is off the screen is practically unusable (even in a very dark room). This means your statement: > 0 brightness == min brightness, not off Is not always true. Not on my system, and not on the system of many other people. With that out of the way, could you please tell me where I should go to get this bug fixed, if it's not Xorg?
The backlight sysfs ABI does not define whether 0 means off or not. It means min brightness, which *may* be off. The ABI was defined for hardware which might not be able to switch the backlight off. The minimum also depends on the backlight hardware. From ABI perspective, *both* behaviors are correct. Also for drm/i915, this depends on the panel and whether it's LVDS or eDP.
As I said, the kernel scales the ABI to the hw min/max: static inline u32 scale_user_to_hw(struct intel_connector *connector, u32 user_level, u32 user_max) { struct intel_panel *panel = &connector->panel; return scale(user_level, 0, user_max, panel->backlight.min, panel->backlight.max); } and uses the separate bl_power to actually turn the backlight on/off.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.