At night, I usually turn my brightness down as far as it will go using the brightness keys. This makes it dim, but visible and not off. When I walk away for a while, the screen goes to sleep, and when I come back and move the mouse, the screen jumps to full brightness, which is very unpleasant at night. Investigating, it seems that the brightness in intel_backlight is getting reset to 4437, but the one in acpi_video0 reads 0. This can be triggered by running xset dpms force standby. Here's the conflicting brightness values: $ for file in brightness max_brightness actual_brightness; > do > for directory in /sys/class/backlight/intel_backlight/ /sys/class/backlight/acpi_video0/ > do > echo $directory$file : $(cat $directory$file) > done > done /sys/class/backlight/intel_backlight/brightness : 4437 /sys/class/backlight/acpi_video0/brightness : 0 /sys/class/backlight/intel_backlight/max_brightness : 4437 /sys/class/backlight/acpi_video0/max_brightness : 15 /sys/class/backlight/intel_backlight/actual_brightness : 4437 /sys/class/backlight/acpi_video0/actual_brightness : 0 After I press the button to increase the brightness one notch, they are back in sync, and then I can turn it back down as well. $ for file in brightness max_brightness actual_brightness; > do > for directory in /sys/class/backlight/intel_backlight/ /sys/class/backlight/acpi_video0/ > do > echo $directory$file : $(cat $directory$file) > done > done /sys/class/backlight/intel_backlight/brightness : 53 /sys/class/backlight/acpi_video0/brightness : 1 /sys/class/backlight/intel_backlight/max_brightness : 4437 /sys/class/backlight/acpi_video0/max_brightness : 15 /sys/class/backlight/intel_backlight/actual_brightness : 53 /sys/class/backlight/acpi_video0/actual_brightness : 1 This is on a fresh install of Xubuntu 18.04 with default packages including the latest version of the i915 Intel Driver which is active. Seems like a regression from Xubuntu 16.04, which I ran on the same laptop without this issue. I initially filed this as a bug in XFCE power manager but after some troubleshooting there I can reproduce the same issue under Gnome as well. Original bug with troubleshooting: https://bugs.launchpad.net/ubuntu/+source/xfce4-power-manager/+bug/1782177
Luke, Can you set kernel parameters drm.debug=0x1e log_buf_len=4M and reboot the machine. Reproduce the issue and attach the dmesg log from boot. This way we know more information about the issue. BTW have you tried this issue with drm-tip? (https://cgit.freedesktop.org/drm-tip)
Created attachment 142454 [details] DMESG output with drm.debug enabled
Jani, any comments here? verifying with latest drm-tip will help here?
I don't think we have any fixes in drm-tip that should affect this; for that matter I don't recall changes in the area that should regress either. Backlight has been fairly solid for some years now. 1) Please paste the sysfs attributes *before* display gets disabled. 2) Is the behaviour reproducible if you don't go to minimum before disabling display? I.e. stay at the next higher level. Or, use # echo 1 > /sys/class/backlight/intel_backlight/brightness to stay above 0. We do have a check in place to crank the brightness to max if it's at the minimum upon encoder enable. However, that bit policy has been in place for ages.
(In reply to Jani Nikula from comment #4) > We do have a check in place to crank the brightness to max if it's at the > minimum upon encoder enable. However, that bit policy has been in place for > ages. Should be, "that bit of policy"
Yes, it only happens on the minimum brightness setting. This is what it looks like before standby to trigger the bug: /sys/class/backlight/intel_backlight/brightness : 0 /sys/class/backlight/acpi_video0/brightness : 0 /sys/class/backlight/intel_backlight/max_brightness : 4437 /sys/class/backlight/acpi_video0/max_brightness : 15 /sys/class/backlight/intel_backlight/actual_brightness : 0 /sys/class/backlight/acpi_video0/actual_brightness : 0 If I increase brightness to setting 1 the bug is not triggered.
I really can't think of any reason why this behaviour would have changed for you because of a kernel change. For 10 years now, since the introduction of i915 KMS support, we've had code in place to set the backlight to max if it's at 0 on panel enable. (In retrospect, that was not such a good policy decision, but I fear it's pretty much carved in stone now. Hindsight 20/20.) I suspect something changed in your userspace so that it now sets brightness to 0 rather than some non-zero low value. That something would typically truncate the 4438 levels provided by intel_backlight to a handful of discrete levels. The kernel change to nuke the policy would technically be as simple as diff --git a/drivers/gpu/drm/i915/intel_panel.c b/drivers/gpu/drm/i915/intel_panel.c index b6df63aa11e3..beb4801702d3 100644 --- a/drivers/gpu/drm/i915/intel_panel.c +++ b/drivers/gpu/drm/i915/intel_panel.c @@ -1104,8 +1104,8 @@ void intel_panel_enable_backlight(const struct intel_crtc_state *crtc_state, WARN_ON(panel->backlight.max == 0); - if (panel->backlight.level <= panel->backlight.min) { - panel->backlight.level = panel->backlight.max; + if (panel->backlight.level < panel->backlight.min) { + panel->backlight.level = panel->backlight.min; if (panel->backlight.device) panel->backlight.device->props.brightness = scale_hw_to_user(connector, but if there's any userspace around that relies on the behaviour, we'd have to revert back.
Luke, any updates here? If not a kernel bug, I would like to close this bug.
What's the distinction between acpi_video0 and intel_backlight? It seems like a bug to me that those don't match, even if we decide that for legacy reasons the bugged behavior of triggering max brightness is necessary.
I agree that it was probably a userspace change.
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.