Display backlight is either full or off

[mirrexagon]

I got my Pixelbook a few days ago, installed the MrChromeBox RW_LEGACY and installed NixOS. /sys/class/backlight/intel_backlight is present, and running echo 0 | sudo tee /sys/class/backlight/intel_backlight/brightness (to set brightness to 0) turns off the backlight, but any other value seems to make it physically full brightness, even though cat /sys/class/backlight/intel_backlight/brightness and cat /sys/class/backlight/intel_backlight/actual_brightness reports what I set it to. cat /sys/class/backlight/intel_backlight/max_brightness returns 1500.

I tried this with both Linux 4.14.15 and 4.15.0. Do you have this issue?

[ghost]

yep, same

[EmbeddedAndroid]

Thanks for the report, I'm seeing this as well. I'm going to look at this issue this weekend, and update.

[mirrexagon]

I've finally managed to get the ChromeOS 4.4 kernel (https://chromium.googlesource.com/chromiumos/third_party/kernel) to build and run under NixOS, and backlight control works properly with that!

(My nixpkgs fork with this is here. The main file of interest is pkgs/os-specific/linux/kernel/linux-chromiumos-eve-4.4.nix.)

[urothis]

Any update on this issue @EmbeddedAndroid ?

[XVicarious]

I have some updates to my exploration. I was playing around with the EC and it's i2c buses.

When I run i2cget -y 3 0x4f the screen gets brighter, but flickers a bit. The register currently in use there is 0xfd or 0xff judging by the value I get (0xff).

I'm running Arch Linux on Kernel 5.2.11. I'll be poking around more.

[astatide]

Does that command just make it brighter once, or does it work on repeated invocation?

[XVicarious]

Once. But if you append an address to it (0x0 - 0xff) it will change how bright it is, with 0xff being the brightest. It doesn't get dimmer though.

[XVicarious]

Also something else of note, if you use i2cdump -y 3 0x4f it will gradually raise the brightness as it probes each value.

[valpackett]

hi, I've investigated this because I wanted brightness control on FreeBSD :)

This is because the Pixelbook's panel needs to use DisplayPort DPCD commands for brightness adjustment, but it does not advertise one of the capabilities the i915 driver checks to allow DPCD to be used.

Comment out the last check && !(intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP) in intel_dp_aux_display_control_capable in intel_dp_aux_backlight.c and enjoy :)

(You'll also need to enable the enable_dpcd_backlight module parameter.)

There was a "more proper" patch @chromium.org people tried to contribute, which introduced a "prefer DPCD" parameter, but that part got lost/abandoned :(

IIRC more specifically it's because like… that check is for the absence of a direct PWM line. It's not absent on the panel, so it reports that it's present. But (LOL) Google just did not wire it

[XVicarious]

I knew I was on the right track with the DisplayPort thing! Thank you so much! I'm checking that out right now!

Sent from ProtonMail mobile

-------- Original Message -------- On Sep 9, 2019, 9:19 AM, myfreeweb wrote:

hi, I've investigated this because I wanted brightness control on FreeBSD :)

This is because the Pixelbook's panel needs to use DisplayPort DPCD commands for brightness adjustment, but it does not advertise one of the capabilities the i915 driver checks to allow DPCD to be used.

Comment out the last check && !(intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP) in intel_dp_aux_display_control_capable in intel_dp_aux_backlight.c and enjoy :)

(You'll also need to enable the enable_dpcd_backlight module parameter.)

There was a "more proper" patch @chromium.org people tried to contribute, which introduced a "prefer DPCD" parameter, but that part got lost/abandoned :(

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[XVicarious]

By the way I found the patch here.

[valpackett]

Update: new patches — https://patchwork.freedesktop.org/series/69914/ though doesn't seem like they're getting rid of the hard DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP check

[satmandu]

This patch fixes the problem on 5.9-rc5 on Ubuntu 20.10 Groovy/dev for Pixel Slate/nocturne, and might do so for eve as well since have the same issue with a DPCD backlight and the PWM pin disconnected.

https://gist.github.com/satmandu/d6c2192f66cd14525049fd34d356d71d

diff -Paur linux-5.9-rc6/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c new/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
--- linux-5.9-rc6/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c 2020-09-20 19:33:55.000000000 -0400
+++ new/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c   2020-09-23 14:29:57.647511808 -0400
@@ -334,8 +334,7 @@
     * the panel can support backlight control over the aux channel
     */
    if (intel_dp->edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP &&
-       (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP) &&
-       !(intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP)) {
+       (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP)) {
        drm_dbg_kms(&i915->drm, "AUX Backlight Control Supported!\n");
        return true;
    }

[9ary]

An identical patch has been merged into Linux 5.12, and auto detection should also allow it to just work now. https://github.com/torvalds/linux/commit/98e497e203a58b6419e20a8f820c8fd8c50e8da7 I have a Slate, but haven't had a chance to test this yet.

[satmandu]

5.12 does not work on the slate.

Here's the current working patch I need to submit upstream which does fix backlight for nocturne:

diff -Npaur a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c 2021-05-07 18:57:14.612178675 -0400
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c 2021-05-07 18:58:15.107279925 -0400
@@ -593,7 +593,6 @@ intel_dp_aux_supports_vesa_backlight(str
     * work just fine using normal PWM controls anyway.
     */
    if (intel_dp->edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP &&
-       (intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP) &&
        (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP)) {
        drm_dbg_kms(&i915->drm, "AUX Backlight Control Supported!\n");
        return true;

[9ary]

Oh yeah this was explicitly added in after the other patch I linked: https://github.com/torvalds/linux/commit/fe7d52bccab674a22776a2f31236bf4232e85410. I don't think they'll accept this. It's not impossible that the panel simply mis-advertises its capabilities and that we'll need a quirk to be cleanly supported upstream.

[satmandu]

Hmm. Lyude Paul actually suggested I send in that patch for discussion.

[satmandu]

How would we implement a quirk for this? If that's the cleaner method, I'm happy to suggest that. I just want the board supported by mainline properly.

[9ary]

Hmm. Lyude Paul actually suggested I send in that patch for discussion.

Fair enough, please CC me when you submit the patch (my email is on my profile).

How would we implement a quirk for this? If that's the cleaner method, I'm happy to suggest that. I just want the board supported by mainline properly.

I'm not sure to be honest, I don't hack on the kernel all that often, but it's at least worth asking whether that's a reasonable alternative. According to the description of the last commit I linked, the change we need would break another device. I too want proper mainline support (with vanilla coreboot as well, which should be less difficult to get working).

https://crrev.com/c/2344844 lists two more changes that are needed for proper backlight on Eve, I'm not sure how relevant they are to Nocturne, but apparently dynamic backlight is an important power saving feature.

[dsem]

I haven't exactly looked in to how he did it, but https://github.com/jmontleon/pixelbook-fedora has a working setup for backlight (and sound) on Fedora for the Pixelbook. Both are working for me after running his ansible playbook (on Fedora though).

[9ary]

I haven't exactly looked in to how he did it, but https://github.com/jmontleon/pixelbook-fedora has a working setup for backlight (and sound) on Fedora for the Pixelbook. Both are working for me after running his ansible playbook (on Fedora though).

Still patching the kernel. https://github.com/jmontleon/pixelbook-fedora/blob/main/kernel/reversed-drm-i915-dp-Don-t-use-DPCD-backlights-that-need-PWM-enable-disable.patch

[9ary]

Actually, it looks like this landed in 5.16. https://github.com/torvalds/linux/commit/04f0d6cc62cc1eaf9242c081520c024a17ba86a3 I can confirm that the stock 5.16.1 kernel in Arch now works out of the box on nocturne, no need for special kernel parameters either.

[satmandu]

Fantastic! I have been pushing kernel patches upstream to try to make this happen for nocturne for months!

[satmandu]

Actually, it looks like this landed in 5.16. https://github.com/torvalds/linux/commit/04f0d6cc62cc1eaf9242c081520c024a17ba86a3 I can confirm that the stock 5.16.1 kernel in Arch now works out of the box on nocturne, no need for special kernel parameters either.

Hmmm. The 5.16.2 Ubuntu mainline kernel causes flickers and lines on the nocturne screen. Do you see this too?

[9ary]

Yeah I already had that on 5.13, sometimes it gets even weirder. I'm not sure what the cause may be.

[satmandu]

Yeah I already had that on 5.13, sometimes it gets even weirder. I'm not sure what the cause may be.

I don't actually see that flickering problem on the 5.15 kernels... The backlight doesn't work perfectly on the 5.15 kernels, but it isn't dim either.

[valpackett]

"flickering problem" could be PSR (Panel Self-Refresh)? don't recall having problems with it on eve though

[satmandu]

How would I debug a PSR issue?

[valpackett]

i915.enable_psr=0