Created attachment 132295 [details]
/sys/kernel/debug/dri/0/eDP-1/i915_dpcd

Smells like a revert to me.

From you i915_dpcd, address 0x702 is 0xf6

That means
BACKLIGHT_BRIGHTNESS_PWM_PIN_CAPABLE == 0
BACKLIGHT_BRIGHTNESS_AUX_SET_CAPABLE == 1

From that, look like using DPCD is the right thing.
This means that the panel advertised wrong DPCD value.

Created attachment 132326 [details] [review]
DEBUG:  Set min DBC to 80

(In reply to Puthikorn Voravootivat from comment #3)
> From you i915_dpcd, address 0x702 is 0xf6
> 
> That means
> BACKLIGHT_BRIGHTNESS_PWM_PIN_CAPABLE == 0
> BACKLIGHT_BRIGHTNESS_AUX_SET_CAPABLE == 1
> 
> From that, look like using DPCD is the right thing.
> This means that the panel advertised wrong DPCD value.

Yeah, except for this caps bit that the panel is advertizing incorrectly, I can't see anything wrong in the DPCD values.

David, 
Can you please try the debug patch that forces the minimum brightness to a higher value?

Sadly the patch doesn't make any difference--the screen still comes up black.

BTW, there's a missing space between the if and the ( :P

Created attachment 132359 [details] [review]
DEBUG: init at max brightness

Maybe the driver has wrong initial brightness level.

Can you try the patch above?

The new patch sadly doesn't work either. I added a debug statement to print

panel->backlight.max and intel_dp_aux_get_backlight(connector);

max is 0xFFFF, the backlight value is 0x200 (suspiciously low compared to the max value).

Could this be a question of the register being detected as a 16-bit register but really only being an 8-bit register?

David, which commits would need to be reverted to fix your panel? Bumping priority. I'll push the reverts on Mon/Tue if there's no obvious fix.

It seems that the issue is with DBC rather than DPCD backlight as I first thought; reverting the DBC patch (or disabling dbc) seems to be enough to get things working.

Setting min=100, max=100 didn't solve anything, neither did min=40, max=60 (just in case the display has some weird hangup about 100%).

The patch that introduces the issue is:

ae25eceab616d16a07bcaa434b84463d58a3bdc3

On a somewhat tangential note, having DBC enabled by default feels very dubious, in my opinion, especially since it's not a user adjustable option. If there's no way to toggle DBC on/off from userspace I much rather adjust the brightness using Fn + F5/F6 than have the system decide what's best for me.

This of course only applies if it's a strict choice between DBC & manual control; if the DBC only adjust the brightness already set by the user, then it's a different story, obviously.

Reverts posted. https://patchwork.freedesktop.org/series/27623/

I faced the same issue and my panel doesnt support AUX Backlight Enable

cat /sys/kernel/debug/dri/0/eDP-1/i915_dpcd 
0000: 12 0a 84 41 00 00 01 c0 02 03 00 00 00 0b 00
0070: 01 00
0080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0100: 0a 84 00 00 00 00 00 00 01 00 00
0200: 01 00 77 77 01 01 00 00
0600: 01
0700: 02
0701: bb ff 00 00
0720: 00 00 00 00 06 06 10 00 01 00 00 00 01 80 00 00
0732: 00 14


With below change its working for my panel, but this wont work for the issue reported in this bug since the panel seems to have wrong DPCD capabilities.

intel_dp_aux_display_control_heuristic(struct intel_connector *connector)
        struct intel_dp *intel_dp = enc_to_intel_dp(&connector->encoder->base);
        uint8_t reg_val;
 
+       /* Panel dosn't support enabling AUX Backlight control */
+       if (!(intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP)) {
+               return false;
+       }
        /* Panel doesn't support adjusting backlight brightness via PWN pin */
        if (!(intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP))
                return true;

Adding tag into "Whiteboard" field - ReadyForDev
*Status is correct
*Platform is included
*Feature is included
*Priority and Severity correctly set
*Logs included

Unless I'm misinterpreting the eDP v1.4 spec, the AUX CH backlight support is for eDP v1.4 and later only. Since the panel in my device reports v1.3 no attempts should be made to use AUX CH for backlight; and indeed, if inserting such a version check in the very beginning of the heuristics, things work as they should.

commit 7d9a1e418c962c2b25b8835dd3a6c68f81912fcd
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Thu Jul 20 12:25:16 2017 +0300

    Revert "drm/i915: Add option to support dynamic backlight via DPCD"

commit d2939424ff89f1ee3aeefdd030cba6ba163e77ac
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Thu Jul 20 12:25:17 2017 +0300

    Revert "drm/i915: Add heuristic to determine better way to adjust brightness"

(In reply to David Weinehall from comment #15)
> Unless I'm misinterpreting the eDP v1.4 spec, the AUX CH backlight support
> is for eDP v1.4 and later only.

You're misinterpreting, but the spec makes it easy to do so. Looking at eDP v1.3 specs is easier for checking what was available then than trying to decipher that from eDP v1.4 spec.

Fair enough. eDP v1.4 spec is the only one I have though. You'd think that they'd prominently annotate everything with "introduced in vX.Y".

Anyway, with the feature no longer defaulting to on we have some time to root cause this, and if indeed it is the panel in the ThinkPad (I think it's an LG display; can provide more information if necessary) rather than a matter of incorrect logic, then the solution would be a panel quirk.