Screen sometimes jumps to full brightness on resume from suspend

[Luke Schlather]

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.

    $ 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. Seems like a regression from 16.04, which I ran on the same laptop without this issue.

[Theo Linkspfeifer (lastonestanding)]

Does the following command trigger this issue?

xset dpms force standby

Furthermore, are there any related messages in the `dmesg` output?

[Luke Schlather (luke2760)]

xset dpms force standby triggers the issue. When the screen turns on it's full brightness (if I have the brightness set to the lowest setting.) It doesn't cause any new dmesg output when I run that command.

[Theo Linkspfeifer (lastonestanding)]

I would think that this is not Xfce specific, but a new bug in the Xorg Intel driver or kernel code.

Things to test:

- installing/removing the xserver-xorg-video driver package (+ relog)
- booting the Xubuntu 18.10 daily ISO, trying to trigger the bug in live mode
- maybe even testing with a different distribution

Lastly, which Intel GPU is that exactly?

[Launchpad Janitor (janitor)]

[Expired for xfce4-power-manager (Ubuntu) because there has been no activity for 60 days.]

[Luke Schlather (luke2760)]

I can trigger the bug on the xubuntu 18.10 live mode. The GPU is "Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09)" so I think that's just the integrated chipset for my CPU (Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz).

[Luke Schlather (luke2760)]

Oh, and yes it does appear to be lower level than XFCE. I can repro with xset dpms force standby by logging into a Gnome session.

[Luke-schlather (luke-schlather)]

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

[Lakshminarayana-vudum (lakshminarayana-vudum)]

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)

[Luke-schlather (luke-schlather)]

Created attachment 142454
DMESG output with drm.debug enabled

[Lakshminarayana-vudum (lakshminarayana-vudum)]

Jani, any comments here? verifying with latest drm-tip will help here?

[Jani-nikula (jani-nikula)]

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.

[Jani-nikula (jani-nikula)]

(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"

[Luke-schlather (luke-schlather)]

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.

[Jani-nikula (jani-nikula)]

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.

[Joseph Salisbury (jsalisbury)]

Did this issue start happening after an update/upgrade? Was there a prior kernel version where you were not having this particular problem?

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v4.20 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.20-rc2

[Lakshminarayana-vudum (lakshminarayana-vudum)]

Luke, any updates here? If not a kernel bug, I would like to close this bug.

[Luke-schlather (luke-schlather)]

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.

[Luke-schlather (luke-schlather)]

I agree that it was probably a userspace change.

[Kai-Heng Feng (kaihengfeng)]

Does this issue still happen?