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?

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](#2?email_source=notifications&email_token=AAORBPH77VNXBBHF7WN6ME3QIZENTA5CNFSM4EOOWONKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6HRGHQ#issuecomment-529470238), or [mute the thread](https://github.com/notifications/unsubscribe-auth/AAORBPB3GZCPECG63PPBH2LQIZENTANCNFSM4EOOWONA).

[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. torvalds/linux@98e497e
I have a Slate, but haven't had a chance to test this yet.