Bug 97883 - [i915] intel_backlight does not function - Lenovo X1 Yoga OLED
Summary: [i915] intel_backlight does not function - Lenovo X1 Yoga OLED
Status: REOPENED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: DRI git
Hardware: Other All
: lowest normal
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-09-21 06:04 UTC by Dan Sanders
Modified: 2018-04-23 08:56 UTC (History)
11 users (show)

See Also:
i915 platform: SKL
i915 features: display/backlight


Attachments
Full dmesg output with drm.debug=0x1e log_buf_len=1M (265.10 KB, text/plain)
2016-09-21 06:04 UTC, Dan Sanders
no flags Details
Output of `xrandr --verbose` (14.66 KB, text/plain)
2016-09-21 06:05 UTC, Dan Sanders
no flags Details
Output of `intel_reg dump` (26.50 KB, text/plain)
2016-09-21 06:06 UTC, Dan Sanders
no flags Details
Full dmesg output with i915.enable_dpcd_backlight=1 (160.79 KB, text/plain)
2016-09-21 16:34 UTC, Dan Sanders
no flags Details
Full dmesg output with drm.debug=0x1e log_buf_len=1M (kernel 4.10) (313.46 KB, text/plain)
2017-02-26 06:04 UTC, Dan Sanders
no flags Details
Output of `xrandr --verbose` (kernel 4.10) (9.24 KB, text/plain)
2017-02-26 06:05 UTC, Dan Sanders
no flags Details
Output of `intel_reg dump` (kernel 4.10) (26.34 KB, text/plain)
2017-02-26 06:06 UTC, Dan Sanders
no flags Details
/dev/drm_dp_aux0 from X1 Yoga 2nd gen OLED (1.18 KB, application/gzip)
2018-02-21 09:40 UTC, Benjamin Lorenz
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dan Sanders 2016-09-21 06:04:41 UTC
Created attachment 126688 [details]
Full dmesg output with drm.debug=0x1e log_buf_len=1M

On the OLED version of the Lenovo X1 Yoga, the intel_backlight device reports a range of 0 to 852, but its setting has no effect. (Perhaps not too surprising since this device technically has no backlight.) The display brightness is always (near?) maximum when Linux is booted.

The thinkpad_acpi module does no better at providing brightness controls.

The xrandr --brightness setting is a nearly-adequate workaround, but is occasionally reset while using X.org normally (I have not investigated the cause yet).

Attached logs are from an Ubuntu kernel-ppa image, stamped:
  cod/tip/drm-intel-next/2016-09-20 (6e05f3d3b9298a56d6f1acb474a75cf14a17c31e)

The laptop display is attached to eDP1. There is a second display attached to DP1; I can provide logs without that if requested.

I was not able to create a vbios dump. ("Input/Output error")
Comment 1 Dan Sanders 2016-09-21 06:05:39 UTC
Created attachment 126689 [details]
Output of `xrandr --verbose`
Comment 2 Dan Sanders 2016-09-21 06:06:00 UTC
Created attachment 126690 [details]
Output of `intel_reg dump`
Comment 3 Jani Nikula 2016-09-21 07:30:39 UTC
Shot in the dark without much looking at the logs: please try i915.enable_dpcd_backlight=1 module parameter.
Comment 4 Jani Nikula 2016-09-21 07:31:28 UTC
(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.
Comment 5 Dan Sanders 2016-09-21 16:33:34 UTC
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
Comment 6 Dan Sanders 2016-09-21 16:34:37 UTC
Created attachment 126710 [details]
Full dmesg output with i915.enable_dpcd_backlight=1
Comment 7 Jani Nikula 2016-09-21 18:59:29 UTC
(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?
Comment 8 Dan Sanders 2016-09-22 00:55:39 UTC
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.
Comment 9 Ricardo 2017-02-22 16:17:05 UTC
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
Comment 10 Dan Sanders 2017-02-26 06:00:23 UTC
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.
Comment 11 Dan Sanders 2017-02-26 06:04:00 UTC
Created attachment 129924 [details]
Full dmesg output with drm.debug=0x1e log_buf_len=1M (kernel 4.10)
Comment 12 Dan Sanders 2017-02-26 06:05:03 UTC
Created attachment 129925 [details]
Output of `xrandr --verbose` (kernel 4.10)
Comment 13 Dan Sanders 2017-02-26 06:06:50 UTC
Created attachment 129926 [details]
Output of `intel_reg dump` (kernel 4.10)
Comment 14 Elizabeth 2017-07-26 16:23:49 UTC
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.
Comment 15 Jani Nikula 2017-08-07 07:33:22 UTC
(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.
Comment 16 Elizabeth 2017-10-06 17:31:57 UTC
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.
Comment 17 Dan Sanders 2017-10-08 20:48:22 UTC
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). 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.
Comment 18 Jani Nikula 2017-10-23 13:49:08 UTC
Basically, we don't know how brightness is controlled on this laptop.
Comment 19 Niklas Kielblock 2017-11-14 12:17:17 UTC
(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.
Comment 20 arkonbob 2017-12-11 01:12:07 UTC
(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 :-)
Comment 21 patnel97269-all 2017-12-14 21:41:19 UTC
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.
Comment 22 Marten van Kerkwijk 2017-12-24 21:57:11 UTC
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.
Comment 23 Niklas Kielblock 2017-12-27 01:54:44 UTC
(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?
Comment 24 Elizabeth 2017-12-27 15:41:51 UTC
(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.
Comment 25 Jani Nikula 2018-01-19 15:38:34 UTC
(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.
Comment 26 Marten van Kerkwijk 2018-01-19 17:00:33 UTC
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
Comment 27 Niklas Kielblock 2018-01-19 17:51:00 UTC
(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?
Comment 28 Jani Nikula 2018-02-16 09:40:01 UTC
(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.
Comment 29 Udi Fuchs 2018-02-17 18:24:40 UTC
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.
Comment 30 Benjamin Lorenz 2018-02-21 09:40:16 UTC
Created attachment 137494 [details]
/dev/drm_dp_aux0 from X1 Yoga 2nd gen OLED

(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!
Comment 31 Niklas Kielblock 2018-02-28 22:53:14 UTC
I get the same output on a 1st gen X1 Yoga OLED, except for 0x240-0x248, which change over time.
Comment 32 Ryan Novosielski 2018-03-11 04:41:59 UTC
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.
Comment 33 Udi Fuchs 2018-03-15 02:16:02 UTC
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
Comment 34 Ryan Novosielski 2018-03-20 15:29:20 UTC
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?
Comment 35 Udi Fuchs 2018-03-23 02:54:46 UTC
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.
Comment 36 Jani Saarinen 2018-03-29 07:11:07 UTC
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.
Comment 37 Jani Saarinen 2018-04-23 06:36:45 UTC
Jani any help from you on this?
Comment 38 Jani Nikula 2018-04-23 08:52:39 UTC
(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.
Comment 39 Jani Nikula 2018-04-23 08:56:23 UTC
(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.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.