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")
Created attachment 126689 [details] Output of `xrandr --verbose`
Created attachment 126690 [details] Output of `intel_reg dump`
Shot in the dark without much looking at the logs: please try i915.enable_dpcd_backlight=1 module parameter.
(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.
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
Created attachment 126710 [details] Full dmesg output with i915.enable_dpcd_backlight=1
(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?
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.
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
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.
Created attachment 129924 [details] Full dmesg output with drm.debug=0x1e log_buf_len=1M (kernel 4.10)
Created attachment 129925 [details] Output of `xrandr --verbose` (kernel 4.10)
Created attachment 129926 [details] Output of `intel_reg dump` (kernel 4.10)
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.
(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.
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.
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.
Basically, we don't know how brightness is controlled on this laptop.
(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.
(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 :-)
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.
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.
(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?
(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.
(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.
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
(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?
(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.
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.
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!
I get the same output on a 1st gen X1 Yoga OLED, except for 0x240-0x248, which change over time.
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.
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
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?
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.
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 any help from you on this?
(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.
(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.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/intel/issues/28.
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.