[i915] intel_backlight does not function - Lenovo X1 Yoga OLED

added Community feature: display/backlight platform: SKL priority::lowest severity::normal + 1 deleted label

Dan Sanders uploaded an attachment:

~~Attachment 126689~~, "Output of xrandr --verbose":
xrandr.txt

Dan Sanders uploaded an attachment:

~~Attachment 126690~~, "Output of intel_reg dump":
intel_reg_dump.txt

Jani Nikula @jani said:

Shot in the dark without much looking at the logs: please try i915.enable_dpcd_backlight=1 module parameter.

Jani Nikula @jani said:

(In reply to Jani Nikula from comment 3)

Shot in the dark without much looking at the logs: please try
i915.enable_dpcd_backlight=1 module parameter.

And please use the fresh kernel from the ppa for this.

Dan Sanders said:

I was not able to identify any changed behavior with this setting. Relevant log output appears to be:

[ 1.815585] [drm:intel_dp_read_dpcd] DPCD: 12 0a 84 41 00 00 01 80 02 00 00 00 0f 0b 00
[ 1.816123] [drm:intel_edp_init_dpcd] Detected EDP PSR Panel.
[ 1.816434] [drm:intel_edp_init_dpcd] EDP DPCD : 02 00 00

Dan Sanders uploaded an attachment:

Attachment 126710, "Full dmesg output with i915.enable_dpcd_backlight=1":
dmesg2.txt

Jani Nikula @jani said:

(In reply to Dan Sanders from comment 5)

[ 1.816434] [drm:intel_edp_init_dpcd] EDP DPCD : 02 00 00

Okay, this means i915.enable_dpcd_backlight=1 doesn't matter.

What's under /sys/class/backlight/? Under each directory there, can you change backlight by echoing (as root) values between 0 and $(cat max_brightness) to the brightness sysfs attribute file?

Dan Sanders said:

There is only intel_backlight.

There are a variety of LED controls, mostly exposed by thinkpad_acpi: capslock, numlock, scrolllock, phy0, kbd_backlight, power, standby, thinklight, thinkvantage; none of these affect screen brightness.

Ricardo said:

sorry for neglecting this bug, Dan the problem still occur with latest kernel? if so please update logs and place the bug in reopen state.

If no response is received will be closed in 30 days

Dan Sanders said:

I tested with the Ubuntu kernel-ppa image tagged:
cod/tip/drm-intel-next/2017-02-07 (28b6def6ec6408e08970a0f1107b483961bfc7ae)

I did not note any new or different backlight behavior.

Dan Sanders uploaded an attachment:

Attachment 129924, "Full dmesg output with drm.debug=0x1e log_buf_len=1M (kernel 4.10)":
dmesg.txt

Dan Sanders uploaded an attachment:

Attachment 129925, "Output of xrandr --verbose (kernel 4.10)":
xrandr.txt

Dan Sanders uploaded an attachment:

Attachment 129926, "Output of intel_reg dump (kernel 4.10)":
intel_reg_dump.txt

Elizabeth said:

From dmesg:

[ 5.387513] thinkpad_acpi: This ThinkPad has standard ACPI backlight brightness control, supported by the ACPI video driver
[ 5.387513] thinkpad_acpi: Disabling thinkpad-acpi brightness events by default...
[ 5.392293] thinkpad_acpi: Standard ACPI backlight interface available, not loading native one

Maybe it has nothing to do, but just in case, have you tried the "acpi_backlight=vendor" method?
http://www.debugpoint.com/2016/10/2-ways-fix-laptop-brightness-problem-ubuntu-linux/
More info:
https://wiki.ubuntu.com/Kernel/Debugging/Backlight

Thanks, sorry for the delay.

Jani Nikula @jani said:

(In reply to Jani Nikula from comment 7)

What's under /sys/class/backlight/? Under each directory there, can you
change backlight by echoing (as root) values between 0 and $(cat
max_brightness) to the brightness sysfs attribute file?

I didn't see a reply to the second part of this.

Elizabeth said:

Hello Dan, any change on this? Last update was on February, is this still a issue for you? If so, could you please provide the requested information. Thank you.

Dan Sanders said:

I have re-tested with cod/tip/drm-intel-next/2017-09-30 (e18063e88bd579c479a2b45820be6c4625f841c3) from the kernel-ppa.

Maybe it has nothing to do, but just in case, have you tried the
"acpi_backlight=vendor" method?

Yes, I have tested this. It does not help.

> What's under /sys/class/backlight/? Under each directory there, can you
> change backlight by echoing (as root) values between 0 and $(cat
> max_brightness) to the brightness sysfs attribute file?

There is only intel_backlight (c.f. #8 (closed)). intel_backlight has a max_brightness (852), but changing brightness has no effect.

> Hello Dan, any change on this?

There is no change. Considering that Intel shipped a special release of their Windows driver just for this laptop to fix brightness controls, I do not expect to be surprised by a fix.

Jani Nikula @jani said:

Basically, we don't know how brightness is controlled on this laptop.

Niklas Kielblock said:

(In reply to Jani Nikula from comment 18)

Basically, we don't know how brightness is controlled on this laptop.

On Windows this is handled by a kernel module separate from the main Intel graphics driver. The build for the model mentioned in this report is available at https://support.lenovo.com/en/us/downloads/ds113141 though some other laptops (X1 Yoga Generation 2, Alienware 13 R3) use slightly different versions of what's clearly the same codebase.

The download above contains debug symbols, so I've done some cursory analysis. It communicates with the panel via eDP AUX (couldn't say if it's using I2C-over-AUX, though) through an interface exposed by the primary Intel graphics driver. References to gamma and voltages (ELVSS) indicate it's considerably more low-level.

It's developed by Intel, not a third-party manufacturer; I have no insight into your organisation so forgive me if I'm wrong but I would imagine you can inquire about this internally.

arkonbob@yahoo.com said:

(In reply to Niklas Kielblock from comment 19)

The download above contains debug symbols, so I've done some cursory
analysis. It communicates with the panel via eDP AUX (couldn't say if it's
using I2C-over-AUX, though) through an interface exposed by the primary
Intel graphics driver. References to gamma and voltages (ELVSS) indicate
it's considerably more low-level.

It's developed by Intel, not a third-party manufacturer; I have no insight
into your organisation so forgive me if I'm wrong but I would imagine you
can inquire about this internally.

Do you think the panel on the Asus Taichi might also be controlled in the same way? (Bug 73156 - https://bugs.freedesktop.org/show_bug.cgi?id=73156)

@jani - if you are able to track someone down at Intel I'd be grateful if you could add that to your list of questions :-)

patnel97269-all@yahoo.fr said:

Hi

i have the same problem with a x1 yoga gen2 kabylake.
please let me know if you want me to provide logs and ifi can help.

Marten van Kerkwijk said:

Mostly adding that it indeed remains an issue on the 2nd generation X1 Yoga OLED. The only difference with the report above is that max_brightness is 1060.

Niklas Kielblock said:

(In reply to arkonbob from comment 20)

Do you think the panel on the Asus Taichi might also be controlled in the
same way? (Bug 73156 - https://bugs.freedesktop.org/show_bug.cgi?id=73156)

While I haven't looked at the Taichi's driver, I highly doubt that, as the brightness setting protocol for the devices mentioned in *this* thread appears to involve low level (OLED technology specific) commands.

By the way - I'm new to Freedesktop's Bugzilla so I'm wary to change things, but is the reporter really who this bug should be assigned to?

Elizabeth said:

(In reply to Niklas Kielblock from comment 23)

...By the way - I'm new to Freedesktop's Bugzilla so I'm wary to change things,
but is the reporter really who this bug should be assigned to?
Hello Niklas,
Bugs are assigned to the reporters when some information is needed from them, in this case it seems that to reset the assignee field skipped our sight, thanks for pointing that.

Jani Nikula @jani said:

(In reply to Niklas Kielblock from comment 19)

The download above contains debug symbols, so I've done some cursory
analysis. It communicates with the panel via eDP AUX (couldn't say if it's
using I2C-over-AUX, though) through an interface exposed by the primary
Intel graphics driver. References to gamma and voltages (ELVSS) indicate
it's considerably more low-level.

The panel's DPCD indicates that it doesn't support the DP standard native aux backlight control (see comment 7). It seems like some proprietary sauce.

> It's developed by Intel, not a third-party manufacturer; I have no insight
> into your organisation so forgive me if I'm wrong but I would imagine you
> can inquire about this internally.

Suffice it to say, it's not just tracking this down, it's also getting the permission to open source something that the display vendor apparently deemed best to do in their own proprietary way instead of following the DP specs.

Marten van Kerkwijk said:

Jani - just so we are sure not to give up hope unnecessarily: the display is made by Samsung and the driver by intel; neither are the worst in terms of open-sourcing drivers (nor is Lenovo in fact). So, are you sure the driver is in fact proprietary, rather than this simply being an oversight? The fact that even the windows machines initially couldn't change their brightness suggests oversight/incompetence is not an implausible explanation. Also, since formally there is no back light for OLED displays, it is not that strange to not think of using the backlight API -- though I certainly would have thought it would be very logical to re-purpose that!

p.s. If it helps to have someone outside to attempt to contact about this, I'd gladly do it -- but it would almost certainly help to know where start! Likely, the post to the Lenovo forum I just made [1] is not going to be much use... If you have any specific person where an e-mail would help, just let me know.

[1] https://forums.lenovo.com/t5/ThinkPad-X-Series-Laptops/X-1-Yoga-OLED-brightness-control-under-linux/td-p/3948282

Niklas Kielblock said:

(In reply to Marten van Kerkwijk from comment 26)

...So, are you sure the driver is in fact proprietary,
rather than this simply being an oversight? The fact
that even the windows machines initially couldn't change their brightness
suggests oversight/incompetence is not an implausible explanation.

The *protocol* is "proprietary" as in (apparently) vendor-specific and not publicly documented, and the *driver* is "proprietary" in that it has certainly never gotten an opensource release; it also utilises an API provided by the general Windows Intel GPU driver for talking to the display.

Windows systems naturally also depend on this driver, device-specific versions of which are shipped with all laptops using such a display in addition to being provided online, to change brightness. The fact that the brightness controls on Windows don't do anything without it installed appears to be intended behaviour.

> Also, since formally there is no back light for OLED displays, it is not that
> strange to not think of using the backlight API -- though I certainly would
> have thought it would be very logical to re-purpose that!

(In reply to Jani Nikula from comment 25)
> Suffice it to say, it's not just tracking this down, it's also getting the
> permission to open source something that the display vendor apparently
> deemed best to do in their own proprietary way instead of following the DP
> specs.

Hi Jani, thanks for responding. FWIW, I can see technical reasons for this decision beyond just politics/NIH. While I'm not sure anybody's actually using it for that (the laptop in question has custom color management software, but I think that uses standard software/GPU LUTs internally), the protocol ought to allow for color management / gamma correction in display voltage levels, which I believe is more flexible than what DP provides.

Have you tried to contact anyone about this? Is there anything you can say about our chances of having this hardware supported in intel_backlight?

Jani Nikula @jani said:

(In reply to Niklas Kielblock from comment 27)

Have you tried to contact anyone about this? Is there anything you can say
about our chances of having this hardware supported in intel_backlight?

Based on my current (and possibly flawed, mind you) understanding, the chances are slim, I'm afraid.

If anyone can enable CONFIG_DRM_DP_AUX_CHARDEV=y and dump the DPCD using the aux chardev (IIRC should pop up somewhere under /sys/class/drm/card0-eDP-1), it might give some clues.

Udi Fuchs said:

I've created a small tool that works around this issue using ICC color profiles to apply the brightness:

https://github.com/udifuchs/icc-brightness

I've tested it on Ubuntu 17.10 with Gnome on Wayland.

Benjamin Lorenz uploaded an attachment:

(In reply to Jani Nikula from comment 28)

If anyone can enable CONFIG_DRM_DP_AUX_CHARDEV=y and dump the DPCD using the
aux chardev (IIRC should pop up somewhere under /sys/class/drm/card0-eDP-1),
it might give some clues.

Almost full DPCD data from X1 Yoga 2nd generation is attached.

Reading it with cat gives only the first few bytes and several
[drm:intel_dp_aux_ch] *ERROR* dp_aux_ch receive error status 0x6f4003ff
in dmesg.
ddrescue was able to extract everything except for byte 0x53:
# pos size status
0x00000000 0x00000053 +
0x00000053 0x00000001 -
0x00000054 0x000FFFAC +

The file is zeros except for the following parts:
00000000: 120a 8441 0000 0180 0200 0000 0f0b 0000 ...A............
00000060: 0111 0100 0100 0100 0001 0600 0000 0000 ................
00000070: 010b 0000 0000 0000 0000 0000 0000 0000 ................
00000100: 0a84 0000 0000 0000 0108 0000 0000 0000 ................
00000200: 0100 7777 0101 0000 0000 0000 0000 0000 ..ww............
00000210: 0080 0080 0080 0080 000a 0000 0000 0000 ................
00000220: 0400 0000 0000 0000 0000 0000 0002 0000 ................
00000240: c440 b354 9810 2200 0000 0000 0000 0000 .@.T..".........
00000300: 0000 0000 0000 0000 0000 0000 0200 0000 ................
00000320: 0100 0000 0000 0000 0000 0000 0000 0000 ................
00000400: 001c f800 0000 0000 0001 1b14 0316 0000 ................
00000410: 0000 0080 0080 0000 0000 0000 0000 0000 ................
00000600: 0100 0000 0000 0000 0000 0000 0000 0000 ................
00000700: 028a ef00 0000 0000 0000 0000 0000 0000 ................
00000720: 0000 ffc0 0a03 0a00 0100 0010 00ff 0000 ................
00000730: 0000 0014 0000 0000 0000 0000 0000 0000 ................
00002000: 0000 0000 0002 0000 0008 0000 7777 0101 ............ww..

Thanks a lot for looking into this!

Attachment 137494, "/dev/drm_dp_aux0 from X1 Yoga 2nd gen OLED":
dpcd_x1yoga.gz

Niklas Kielblock said:

I get the same output on a 1st gen X1 Yoga OLED, except for 0x240-0x248, which change over time.

Ryan Novosielski said:

I've got one of these Lenovo X1 Yoga (Gen 2) OLED-equipped machines. It seems like you already have the data that you asked for, so I don't know if I need to do the same as the other guys have done, but let me know if it would be helpful.

And Udi, I really have to thank you -- this is the first time since the upgrade to 17.10/switch to Wayland that I wasn't stuck having my display at whatever brightness it uses when uncontrollable. It was really obnoxious in a dark room. I can recommend it to anyone who's got one of these and needs to get by in the meantime.

Udi Fuchs said:

I'm glad you found my tool useful. I created a wiki page that explains how to apply color management for this display:

https://github.com/udifuchs/icc-brightness/wiki

Ryan Novosielski said:

Do you have any idea whether this color management form of brightness control has the positive impacts on power consumption that traditional backlight adjustments do?

Udi Fuchs said:

I can clearly observe that my laptop uses less power when lowering the brightness using color management to reduce brightness. This is how OLED works -- the amount of power used is relative to the brightness of the pixels.

Jani Saarinen @jani.saarinen said:

First of all. Sorry about spam.
This is mass update for our bugs.

Sorry if you feel this annoying but with this trying to understand if bug still valid or not.
If bug investigation still in progress, please ignore this and I apologize!

If you think this is not anymore valid, please comment to the bug that can be closed.
If you haven't tested with our latest pre-upstream tree(drm-tip), can you do that also to see if issue is valid there still and if you cannot see issue there, please comment to the bug.

Jani Saarinen @jani.saarinen said:

Jani any help from you on this?

Jani Nikula @jani said:

(In reply to Jani Saarinen from comment 37)

Jani any help from you on this?

No. Please see comment 18, comment 25, comment 28.

Adjusting priority to lowest.

Jani Nikula @jani said:

(In reply to Udi Fuchs from comment 35)

I can clearly observe that my laptop uses less power when lowering the
brightness using color management to reduce brightness. This is how OLED
works -- the amount of power used is relative to the brightness of the
pixels.

Correct. There is no *backlight* as such.

When I have gone through the Lenovo x1 yoga OLED model laptop spec,I understood that for this particular OLED model laptops will not have backlight feature. As LED displays emitts brighter light and backlight feature will be incorporated in LCD displays. Please refer the doc below:- http://www.notebookreview.com/notebookreview/lenovo-thinkpad-x1-yoga-oled-2017-review/

As backlight feature is not supported,can we close the bug?

The desired effect is that one can change the brightness via the brightness keys. I don’t agree that this should be closed; the problem still exists.

The terminology around brightness control predates proliferation of OLED displays; it used to be solely about backlight control. The bug is still very much valid.

FWIW there's an old patch trying to add the properietary DPCD brightness control to this panel: http://patchwork.freedesktop.org/patch/msgid/20191009161346.21306-1-shawn.c.lee@intel.com

I tested the above patch for the OLED Display in the XPS 15 7590 OLED Laptop, because this model also has a SDC panel, just with a different Product ID.

It works very good. I have now proper brightness control without any loss of color depth. The patch nearly worked out of the box for me:

I applied the patch on the current Ubuntu 5.3.0-26-generic kernel.

All I had to do was to disable the following capable check in:

int intel_dp_aux_init_backlight_funcs(struct intel_connector *intel_connector)
	...
	if (!intel_dp_aux_display_control_capable(intel_connector))
		return -ENODEV;

I think the check is not needed in this case, because we know that we are going to use the quirk brightness method (based on the EDID check and the enable check before the capable check).

For my quick test I just commented both lines out. A proper fix would be to add the quirk check inside of intel_dp_aux_display_control_capable or move the capable check inside the else branch of the drm_dp_has_quirk check.

Hi @xLAva Can you please verify the issue with the patch :https://patchwork.freedesktop.org/series/72991/ and post the results?

Hi @skarana1

I tried the https://patchwork.freedesktop.org/series/72991/ patch against the 5.6.0-rc1 kernel, but backlight / brighness control did not work:

[drm:drm_dp_get_edid_quirks [drm_kms_helper]] DP sink: EDID mfg 4c-83 prod-ID 29-a0 quirks: 0x0000

I even tried to add the mfg and prod-ID to the quirk list and added the option i915.enable_dpcd_backlight=1 to the grub script, but it still did not work:

[drm:drm_dp_get_edid_quirks [drm_kms_helper]] DP sink: EDID mfg 4c-83 prod-ID 29-a0 quirks: 0x0010

I get this message if I try to change the brightness, but nothing happens:

[drm:intel_backlight_device_update_status [i915]] updating intel_backlight, brightness=90300/120000
[drm:intel_backlight_device_update_status [i915]] updating intel_backlight, brightness=96240/120000
[drm:intel_backlight_device_update_status [i915]] updating intel_backlight, brightness=102180/120000

Lyude's patches aren't expected to fix this bug.

I believe I have the same laptop that Lyude mention in the patch as well: Lenovo ThinkPad X1 Extreme 2nd, model 20QVCTO1WW that experience the same issue.

I'm using the following boot options: GRUB_CMDLINE_LINUX_DEFAULT="quiet iwlwifi.power_save=Y iwldvm.force_cam=N power_level=5 i915.fastboot=1 i915.enable_psr=0 i915.enable_guc=2 i915.enable_fbc=1 i915.enable_dpcd_backlight=1 nouveau.modeset=0 apparmor=1 security=apparmor udev.log_priority=3"

in order to be able to adjust the backlight. Unfortunately turning backlight up/down does not happen with monotonically incremental steps, but jerky ones.

Linux organic 5.6.7-1-MANJARO #1 (moved) SMP PREEMPT Thu Apr 23 10:50:31 UTC 2020 x86_64 GNU/Linux

The patch mentioned in #28 (comment 387675) is not for this device, unfortunately, but for the 2019 OLED ThinkPad models. (Display ID "SDC4141" according to the patch - it's actually PnP ID LEN4141 on Windows (SDC4141 is an unrelated LCD) but shows up as SDC4141 in EDID on Linux for some reason.)

This and the other drm-intel patches for Samsung AMOLED panel support are all for laptops from 2019 and later, supporting standard(ish) backlight control mechanisms.

Earlier laptops (starting with the 2016 ThinkPad this issue is about) all seem to use the same process as mobile devices with Samsung AMOLED displays - configuring much lower-level detail over panel-specific (though similar) protocols. There are drivers for some of these mobile devices in mainline (e.g. https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c ) and OEM kernels.

That communication goes through eDP AUX via the Tcon (a Parade DP699, specific to Samsung AMOLED) - at least on the X1 Yoga.

(Original research, unfortunately I don't have enough details for implementation.)

Hi Reporter, please confirm if this issue is still seen on latest kernel also.

If yes, provide the steps to reproduce it for further debugging.

[i915] intel_backlight does not function - Lenovo X1 Yoga OLED

Submitted by Dan Sanders

Description

Child items 0

Activity

Admin message

Admin message

[i915] intel_backlight does not function - Lenovo X1 Yoga OLED

Submitted by Dan Sanders

Description

Activity