Due to an influx of spam, we have had to impose restrictions on new accounts. Please see this wiki page for instructions on how to get full permissions. Sorry for the inconvenience.
Admin message
Equinix is shutting down its operations with us on April 30, 2025. They have graciously supported us for almost 5 years, but all good things come to an end.
Given the time frame, it's going to be hard to make a smooth transition of the cluster to somewhere else (TBD). Please expect in the next months some hiccups in the service and probably at least a full week of downtime to transfer gitlab to a different place.
All help is appreciated.
Project 'drm/intel' was moved to 'drm/i915/kernel'. Please update any links and bookmarks that may still have the old path.
Regression: backlight regulation not working after upgrate to 5.15
After upgrading to 5.15, the backlight regulation does not work out of the box as it used to.
Now, to make it work, it is necessary to use the 'i915.enable_dpcd_backlight=0' kernel parameter.
The machine I am using is a laptop XMG Core 15 e21 (Tongfang motherboard), with an intel 10870h and a WQHD 165hz panel running on it via eDP.
Original issue: #5027 (closed) (closed because two issues were overlapping together)
CC: @effeffe [filippo.falezza at outlook dot it]
Tested-by: @effeffe [filippo.falezza at outlook dot it]
Edited
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related.
Learn more.
Could someone finally please handle the regression with the appropriate urgency? Reminder: the original report for the issue was 38 days ago https://bugzilla.kernel.org/show_bug.cgi?id=215553 and there was zero progress up to now. That's not how regressions should be handled.
FWIW, basically nobody in Intel gfx looks at bugzilla.kernel.org. We haven't used it for more than 5 years. The "Video(DRI - Intel)" component has been closed for new bugs; any new bugs get filed at random components. MAINTAINERS file points at freedesktop.org. I don't know what else we could do to stop people from filing bugs at the bugzilla.
It's probably worth mentioning this isn't just an Intel specific issue either, I still get linked to kernel bugzilla issues for nouveau from time to time but no one's actually looking through the kernel bugzilla from our project either - I assume this is the case for quite a number of projects tbh.
It's probably worth mentioning this isn't just an Intel specific issue either, I still get linked to kernel bugzilla issues for nouveau from time to time but no one's actually looking through the kernel bugzilla from our project either - I assume this is the case for quite a number of projects tbh.
But IMHO somebody has to do something about this. I hope I find time for this sooner or later, but I'm just a volunteer doing all the regression tracking in my spare time right now, that's already quite a lot of work. :-/
Dear @jani , please find here attached dmesg_i915_out. The issue persists on 5.16 and on the latest drm-tip, which I have re-downlaoded and compiled yesterday, as some of you requested.
It's possible there might be some issues with enabling backlights on displays with this high of a refresh rate, perhaps we need to have the AC/DC power optimization in place in Intel's HDR backlight interface for this to work correctly…
that being said though - there were some pretty big backlight fixes so you should definitely try the latest drm-tip kernel first to make sure this hasn't already been fixed.
I am trying to explain it as clear as possible. If you have doubts, please tell me.
First, I would like to say that the system seems to recognise the backlight device. For this, see lines 799, 839, and 875 to 879. In particular, at line 875 you can see that the device is recognised as Intel HDR backlight interface version 1.
Carrying on, lines 1049-1050 report registration of the backlight device, and at 1660 you see backlight set at maximum brightness.
From line 6364 on, you can find a cycle from maximum brightness all the way down to 0, and then back up again.
In particular, it should be notes that the brightness value gets written to the backlight device, but then this results in no backlight change at all.
One major change I have noted between my current kernel with i915.enable_dpcd_backlight=0 and the drm-tip whitout it, is that in the former case I get an ACPI error every time I change the brightness, but I don't in the drm-tip.
Here is reported the error I get when i915.enable_dpcd_backlight=0 and drm.debug=0x116 are set:
[19217.537735] i915 0000:00:02.0: [drm:intel_fbc_update [i915]] reserved 29491200 bytes of contiguous stolen space for FBC, limit: 1[19217.537988] i915 0000:00:02.0: [drm:intel_fbc_update [i915]] Enabling FBC on pipe A[19217.540510] i915 0000:00:02.0: [drm:__intel_fbc_disable [i915]] Disabling FBC on pipe A[19217.540579] [drm:drm_atomic_state_default_clear] Clearing atomic state 00000000b4500479[19217.540584] [drm:__drm_atomic_state_free] Freeing atomic state 00000000b4500479[19217.541472] ACPI BIOS Error (bug): Could not resolve symbol [^^^PEG0.PEGP.EDP1], AE_NOT_FOUND (20210930/psargs-330)[19217.541478] ACPI Error: Aborting method \_SB.PCI0.LPCB.EC0._Q14 due to previous error (AE_NOT_FOUND) (20210930/psparse-529)[19217.543983] [drm:intel_backlight_device_update_status [i915]] updating intel_backlight, brightness=90645/120000[19217.544055] i915 0000:00:02.0: [drm:intel_backlight_device_update_status [i915]] set backlight level = 90645[19217.552376] [drm:intel_backlight_device_update_status [i915]] updating intel_backlight, brightness=90645/120000[19217.552441] i915 0000:00:02.0: [drm:intel_backlight_device_update_status [i915]] set backlight level = 90645[19217.559114] [drm:drm_atomic_state_init] Allocated atomic state 000000004aa43b45[19217.559120] [drm:drm_atomic_get_crtc_state] Added [CRTC:51:pipe A] 0000000021fbe972 state to 000000004aa43b45[19217.559124] [drm:drm_atomic_get_plane_state] Added [PLANE:31:plane 1A] 000000003ef36837 state to 000000004aa43b45[19217.559128] i915 0000:00:02.0: [drm:drm_atomic_set_fb_for_plane] Set [FB:108] for [PLANE:31:plane 1A] state 000000003ef36837[19217.559131] [drm:drm_atomic_check_only] checking 000000004aa43b45[19217.559139] i915 0000:00:02.0: [drm:intel_plane_atomic_calc_changes [i915]] [CRTC:51:pipe A] with [PLANE:31:plane 1A] visible 1 -> 1, off 0, on 0, ms 0[19217.559222] i915 0000:00:02.0: [drm:intel_atomic_get_global_obj_state [i915]] Added new global object 00000000e0c6f948 state 00000000e24ee4b8 to 000000004aa43b45[19217.559277] i915 0000:00:02.0: [drm:intel_atomic_get_global_obj_state [i915]] Added new global object 00000000be0e6dd6 state 00000000595b68d6 to 000000004aa43b45[19217.559328] [drm:drm_atomic_nonblocking_commit] committing 000000004aa43b45 nonblocking
Note that the ACPI error is visible, together with a block of messages that gets continuously repeated
To me it looks like with "original kernel" (5.10) and drm-tip + i915.enable_dpcd_backlight=0 backlight control is falling back to standard PWM backlight interface. This seems to work in both cases. @effeffe , did I understood correctly?
Could it be that panel is just improperly advertising HDR backlight control support? @effeffe , could you please provide dmesg log with original kernel? Please add "drm.debug=0x116 log_buf_len=20M" in kernel parameters?
@jhogande, regarding your question, i.e. if 5.10 falls back to the same pwm backlight controller, I think so. I remember when I was trying to debug the issue in January, that it was the same, but the backlight scale was different.
Regarding the wrong advertising of the panel, I have read that one of the commits in 5.15 truncates the panel edid, so that some resolutions are not read by the system. Might it be that this results in wrong panel negotiation? Do you need an edid dump?
Regarding the 5.10 dmesg, you can find it here: dmesg_5.10.90
EDIT: here you can find a copy of the panel edid: edid
It seems to be as I was suspecting. In 5.10 kernel and drm-tip + i915.enable_dpcd_backlight=0 it is using pwm backlight interface which seems to be working with this panel. 5.10 doesn't yet support Intel's HDR backlight control. Now as we have support for Intel HDR backlight control (since v5.11-rc5):
We are trying to use it instead of pwm control as the panel is informing to support it -> Either the panel lies about the support or the driver is broken/incomplete. @lyudess, what do you think?
I will go through our Intel HDR AUX interface documentation and ping people involved in this.
@jhogande, sorry if I wasn't too clear, but I removed the intel related commands when testing 5.10 and drm-tip. Hence, the dmesgs you see are without specifying i915.enable_dpcd_backlight=0 as a kernel parameter. I hope this does not change things
Might it help you debug it, the panel is a 15.6" IPS, 2560×1440@165Hz, 350 cd/m², 95 % sRGB. The model of the panel is NE156QHM-NY2, but no datasheet is available.
If you could find someone at Intel who could help out with this I'd really appreciate it, it's been really difficult getting much info on this backlight interface in general.
Anyway - I am tempted to say that the panel is lying here, but it should be noted that I think this would actually be the first case of a panel lying about the Intel HDR interface that I've seen (typically, most issues with broken dpcd backlight support have been with the VESA interface which is why we tend to treat HDR as the "safe" backlight interface). So, I'd like to try throwing some stuff at this first before considering it broken.
I noticed "acpi=Windows 2015" "acpi_osi=Windows 2015" on your kernel commandline. I don't know if this would make any difference for this issue, but in the past these arguments used to be workarounds for backlight issues when Intel originally started moving away from ACPI backlight controls. I would definitely try the backlight without those kernel arguments, and just remove them if they don't seem to actually be doing anything on your system.
I think a good thing to try would be to make sure we're respecting the backlight off delay with DPCD backlight controls since this panel does appear to have a rather reasonable panel delay:
[ 1.057639] i915 0000:00:02.0: [drm:pps_init_delays [i915]] cur t1_t3 0 t8 0 t9 1 t10 1000 t11_t12 6000[ 1.057705] i915 0000:00:02.0: [drm:pps_init_delays [i915]] vbt t1_t3 5000 t8 550 t9 1000 t10 1000 t11_t12 6000[ 1.057770] i915 0000:00:02.0: [drm:pps_init_delays [i915]] panel power up delay 500, power down delay 100, power cycle delay 600[ 1.057835] i915 0000:00:02.0: [drm:pps_init_delays [i915]] backlight on delay 55, off delay 100
Note with the issue #4170 here this didn't make a difference, but I'm fairly sure that's because I totally missed the fact that Vasily's panel only had a 1ms power on delay. As well, it seems that the panel is power cycled once during boot up so it definitely seems like it'd be worth trying:
You should only need to apply the first two commits to your kernel.
As well: I'm not sure, but I am curious about whether running the display at a reduced resolution would affect the backlight at all. I don't -think- so though? But it's technically not something I've ever tried!
Also if anyone's wondering: I think my theory about the high refresh rate and overdrive settings with the HDR backlight ("overdrive" is just referring to the backlight optimization option that the HDR interface has which is supposed to help with displays that have high refresh rates iirc) probably isn't correct here, as I don't think I see support for that in the HDR backlight caps.
About the possibility of a lying panel, it could be it, but we should also keep in mind that the panel is working correctly under windows. It should also be obvious that HDR can't work, as the panel has a 350nits maximum brightness. Is there a way to analyse if the panel is actually lying?
Regarding the ACPI options, I remember enabling it in the past, way before this issue. I got those values from decompiling the dsdt ACPI table. I have attached DSDT.dsl, in case you wish to analyse it. In particular, see lines 21425-21469.
Regarding ACPI issues, there is one in the dmesg, which I report here for completeness:
[ 114.663900] ACPI BIOS Error (bug): Could not resolve symbol [^^^PEG0.PEGP.EDP1], AE_NOT_FOUND (20210930/psargs-330)[ 114.663918] ACPI Error: Aborting method \_SB.PCI0.LPCB.EC0._Q14 due to previous error (AE_NOT_FOUND) (20210930/psparse-529)
Regarding the proposed patches, I am compiling drm-tip again with them. I will update you as soon as it finishes, and I test it.
On the matter of drm-tip, I had to switch to the commit f443e374ae13 (main linux 5.17), as the main drm-tip is currently failing compilation because of amdgpu driver failing to compile.
Edit: grammar
Edit 2: I have just tested the two patches 1 and 2, and they do not fix the problem.
Edit 3: to answer @lyudess 's question on using other resolutions, it would not work. Mainly because the driver doesn't support any change to the default resolution advertised by the edid, may this be compatible and supported by bandwidth or not. The result is that neither the resolution not the refresh rate can be changed. In particular, refer to #5027 (comment 1264160)
As I feel this might be a factor you would like to consider, I am going to open a further issue to avoid going off-topic like in the original one you can find here the link to this issue #5506 (closed) and merged in #125 (closed).
Yes, I did at the beginning, but I haven't tried with the latest patched I was told to test (e.g. #5284 (comment 1327546)). If there is a specific combination you would like me to try, or if you want another dmesg, I can upload a new one.\
Anyway, just to be safe, I will try another with just loglevel=3 quiet resume=UUID=55fdf45e-5ed7-4b47-96a8-01ed3f70b326 as additional kernel boot options and I will upload a dmesg here.
I see that set backlight is not read back as it was written until with lower values. Not sure where the threshold is, but for 404 - 512 it seems to be reading 400 back:
[ 31.731036] [0m[33mi915 0000:00:02.0[0m: [drm:intel_backlight_device_update_status [i915]] set backlight level = 404
[ 31.731443] [0m[33mi915 0000:00:02.0[0m: [drm:drm_dp_dpcd_write [drm_dp_helper]] AUX A/DDI A/PHY A: 0x00354 AUX <- (ret= 4) 94 01 00 00
[32m[ 31.741154] [0m[33mi915 0000:00:02.0[0m: [drm:drm_dp_dpcd_read [drm_dp_helper]] AUX A/DDI A/PHY A: 0x00344 AUX -> (ret= 1) 10
[32m[ 31.741562] [0m[33mi915 0000:00:02.0[0m: [drm:drm_dp_dpcd_read [drm_dp_helper]] AUX A/DDI A/PHY A: 0x00354 AUX -> (ret= 2) 90 01
[32m[ 31.741582] [0m[33mi915 0000:00:02.0[0m: [drm:intel_backlight_device_get_brightness [i915]] get backlight PWM = 400
For lower values same value is read back:
[32m[ 33.970390] [0m[33mi915 0000:00:02.0[0m: [drm:intel_backlight_device_update_status [i915]] set backlight level = 26
[32m[ 33.970644] [0m[33mi915 0000:00:02.0[0m: [drm:drm_dp_dpcd_write [drm_dp_helper]] AUX A/DDI A/PHY A: 0x00354 AUX <- (ret= 4) 1a 00 00 00
[32m[ 34.741924] [0m[33mi915 0000:00:02.0[0m: [drm:drm_dp_dpcd_read [drm_dp_helper]] AUX A/DDI A/PHY A: 0x00344 AUX -> (ret= 1) 10
[32m[ 34.742355] [0m[33mi915 0000:00:02.0[0m: [drm:drm_dp_dpcd_read [drm_dp_helper]] AUX A/DDI A/PHY A: 0x00354 AUX -> (ret= 2) 1a 00
Currently the driver is using fixed maximum 512 and using that until something else is set by user-space.
Run your test and take dmesg with drm.debug=0x116 log_buf_len=20M and without i915.enable_dpcd_backlight=0.
We have hardcoded 512 as a max value. Obviously this doesn't work with your panel as we see from the logs that readback doesn't match with values above 400. I'm currently suspecting this range should be parsed from EDID. E.g. I have following in my panel (sudo get-edid | edid-decode):
CTA-861 Extension Block Revision 30 native detailed modes11 bytes of CTA data blocks Extended tag: Colorimetry Data Block BT2020RGB Extended tag: HDR Static Metadata Data Block Electro optical transfer functions: Traditional gamma - SDR luminance range SMPTE ST2084 Supported static metadata descriptors: Static metadata type 1 Desired content max luminance: 106 (496.743 cd/m^2) Desired content max frame-average luminance: 106 (496.743 cd/m^2) Desired content min luminance: 36 (0.099 cd/m^2)Checksum: 0x9a
In your EDID this doesn't exist. Maybe we could use values from this extension block as a range in the driver. Lack of extension block could be taken as an indicator that this nits based backlight control can't be used. What do you think @lyudess ?
Could it be? I actually had no idea that there'd be any kind of info on backlight info in the EDID, where did you figure this out?
FWIW, easiest way for me to figure this out would probably be for me to go through the laptops I've got here with Intel HDR backlight controls and see if they have this EDID extension or not
No problem - if they have any idea on any other information regarding EDIDs and Intel's HDR interface please let us know - I've suspected for a while there's sources of information regarding this that we're not probing that I haven't really been able to figure out.
(if it's confidential let me know via email, and I can talk with Red Hat's Intel PMs and figure out how to get the docs to me)
OK - Good news, I tested 5 different laptops - 2 without Intel HDR controls, 3 with. The two laptops without Intel HDR controls did not have this EDID block, the 3 that did have HDR had the EDID block. So, yes! I think you might be on to something here, I can't believe it's literally been this simple the whole time lmao.
Also for reference, I've attached all of the EDIDs i've gathered + a README noting which laptops had HDR and which ones didn't.
I guess we should probably start then by writing up a patch to disable Intel HDR if we can't find this block, and then follow it up with something to actually make use of the values here.
@effeffe, could you please test this patch and share again your dmesg? Keep that "drm.debug=0x116 log_buf_len=20M" in kernel command line. Remove "i915.enable_dpcd_backlight=0"
I think the continuation could be to split out range calculation from drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:update_connector_ext_caps and put it maybe into drivers/gpu/drm/drm_edid.c. This same implementation could be shared by intel_dp_aux_backlight.c. What do you think @lyudess?
Yes!! Also, seriously, huge thanks for actually going through amdgpu and looking at how to extract this - the more cleanups there we get the better!
Anyway - yeah, so long as all of the information that we need for calculating the brightness comes from the EDID I think that drm_edid.c would be a good place to put it, otherwise we might want to put it with the DP helpers. Feel free to Cc me on any patches
@jhogande I am trying to boot the newly compiled kernel at the top of drm-tip. It compiles successfully, but when I boot it hangs while loading the kernel. I have tried removing the quiet option but it outputs nothing.
I am going to try to compile it again with the new commits and see if anything changes.
Unfortunately, when I try to use the patch you linked, the kernel does not load anymore. I have tried to load it on the latest commit and on the 5.17.1 release. I also tried to remove all the additional options, including quiet, but it does not load.
Anyway - yeah, so long as all of the information that we need for calculating the brightness comes from the EDID I think that drm_edid.c would be a good place to put it, otherwise we might want to put it with the DP helpers. Feel free to Cc me on any patches
@lyudess I'm trying really hard to encapsulate EDID parsing to drm_edid.c, and basically I want to prevent anyone from parsing the EDID anywhere else. It's fine if you do further processing on the parsed results (maybe put them in connector->display_info) but parsing raw EDID data is a no-no.
Hi, unfortunately, it is not a compilation issue. To compile, I am using an edited PKGBUILD so that it packages the kernel and I can handle it via pacman. This way, dkms compilations are handled.
I don't think the issue is the kernel compilation, or any like that, I believe that the patch is not enabling my display. I will try to remove all modules from mkinitcpio.conf and see what happens. Without that patch, drm-tip boots fine...
Update: even without the patch, 5.18 does not boot on my machine, I'm going to try 5.17 again
I was able to apply the patch in #5284 (comment 1330624) on kernel 5.17.1 (commit f443e374ae13). It now boots and the backlight seems to work! Here is the dmesg_5.17.1_patched.
I don't know why, but the latest drm-tip (5.18) does not boot on my machine. I am going to try again with and without the patch.
@effeffe it might be that tip actually might be broken. There are some actions ongoing to fix that. Perhaps those issues are causing the same the your system do not boot. I see you have CML-H (i7-10870H) system so closest for that in CI is: https://intel-gfx-ci.01.org/tree/drm-tip/index.html?hosts=cml