bisected: Dell XPS 17 ignores ACPI intel_backlight sysfs values greater than 1

Summary

In the following regression, values of /sys/class/backlight/intel_backlight/brightness no longer correspond with my screen brightness.

The offending commit (for my system) is 98e497e203a5, "[1/2] drm/i915/dpcd_bl: uncheck PWM_PIN_CAP when detect eDP backlight capabilities". This affects the 5.11 branch in stable, which affected me when I upgraded from 5.10.16.arch1-1 to 5.11.2-arch1-1. As of the current mainline 5.12-rc2 (which I just tested) the problem is not resolved.

How to reproduce:

Change the value of /sys/class/backlight/intel_backlight/brightness to an integer from 0-255 (where 255 is the max_brightness).

• Expected result: At value 0, the screen is off, and at values 1-255, the screen gradually goes from dim to full brightness.
• Actual result: At value 0, the screen is off, and at values 1-255, the screen is the same brightness.

System information:

Dell XPS 17 9700 with an NVIDIA Optimus graphics hardware. The optimus setup uses i915 for the intel modesetting and nvidia for the main nvidia setting.

• dmesg.txt
• lspci.txt
• systemd-boot_arch.conf.txt
• xrandr_verbose.txt

Workaround

@jani has suggested the workaround to set i915.enable_dpcd_backlight=0 instead of i915.enable_dpcd_backlight=1 in my kernel parameters. I have done this, and indeed it is a valid workaround. With this new kernel parameter, there are a number of errors and warnings from ACPI; see my dmesg_after_enable_dpcd_backlight_eq_0.txt.

changed the description

changed the description

changed the description

Can you get me another log with drm.debug=0x116 log_buf_len=5M from after you boot with i915.enable_dpcd_backlight set to it's default value?

@lyudess :

I couldn't tell if by "i915.enable_dpcd_backlight set to it's default value" you meant i915.enable_dpcd_backlight=1 or just removing that parameter completely. So I did both.

i915.enable_dpcd_backlight=1

• arch.conf showing the kernel params I used
• dmesg after booting into a system running Linux 5.11.4-arch1-1 x86_64.
• Note: it exhibits the broken behavior in this state. Brightness doesn't work, as described by the bug report.

Removing the i915.enable_dpcd_backlight parameter completely

• arch.conf showing the kernel params I used
• dmesg.txt after booting into a system running Linux 5.11.4-arch1-1 x86_64.
• Note: it exhibits the correct behavior in this state, though there are ACPI errors at boot (see dmesg.txt above).

(I will look at this week btw, just letting you know I haven't forgotten about this bug)

I think it's probably going to be safer for us to just disable VESA backlight interfaces unless they're mentioned in the VBT for now, so could you try this patch to see if it fixes your issue?

test.patch

Also - in the future would you be willing to try future patches to see if we can get the DPCD backlight interface working on your machine correctly? Just in case this turns out to be a default behavior we actually want to change in the future

Hey there, @lyudess . Of course, glad to help out with the testing in the future.

What branch / commit should I apply this to?

@lyudess I've applied this patch to drm-tip and it does not seem to fix the issue described by my bug report, unfortunately. Both with and without kernel param i915.enable_dpcd_backlight=1. I double-checked drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c:43 to make sure the try_vesa_interface = true; line is removed, and it is.

I see @Ma had good results with this patch with i915.enable_dpcd_backlight=0! I actually didn't try it with that parameter because in fact it already works on mainline with that parameter (and with the parameter completely removed) right now (see above). So the patch is not necessary for that behavior, in my case.

In which case, I guess we can say the regression here is simply a change in the need to use i915.enable_dpcd_backlight=1 kernel parameter, and make it =0 (or removed completely) instead.

There is about 50 lines of backlight errors in my dmesg you may see that are showing upon bootup now, but that may be a different issue.

@brandon.arnold sorry it took me so long to respond! Somehow I misread your comments and thought that this had fixed your issues. Could you get a copy of your vbios from /sys/kernel/debug/dri/0/i915_vbt ? Also, another dmesg from a kernel with the patch applied with no i915.enable_dpcd_backlight parameter set + drm.debug=0x116 log_buf_len=5M

Also JFYI - the purpose of this patch is to make the default behavior on machines like yours =0, we really can't set this as the default behavior for all systems because there are actual systems out there that do need this enabled by default (and we don't want to make users specify modparams wherever possible, they're mostly just there for workarounds or debugging issues like this?

Hey there, @lyudess ! Sorry for the delay. Here are the outputs you asked for, after booting to the version of the kernel with your above patch applied:

kernel parameters /sys/kernel/debug/dri/0/i915_vbt dmesg.txt

mentioned in issue #3158 (closed)

I take it this is now fixed in drm-tip with commit 9e2eb6d5380e ("drm/i915/dpcd_bl: Don't try vesa interface unless specified by VBT")?

Unfortunately, no, it had no effect on my experience.

Ok, so the commit references this bug, though it actually fixes #3158 (closed). Oops.

Ok - this is weird to me, because if the commit you're mentioning here (98e497e203a5, "[1/2] drm/i915/dpcd_bl: uncheck PWM_PIN_CAP when detect eDP backlight capabilities") is what you bisected this issue to, then I'm pretty sure your issue should have been fixed.

Could you post a copy of your vbios? You should be able to find it in /sys/kernel/debug/dri/0/i915_vbt (try replacing 0 with 1 if you don't find this on your system)

Hey there, @lyudess, scroll up a little, I posted the vbios about a week back in the little thread above.

whoops! that you did, I completely forgot to look :)

oh no, your panel appears to be the first I've encountered so far where it looks like the Intel backlight interface isn't working. but - that might also be a good thing, as it might just mean we're not setting something up with the interface properly. I have another backlight issue from someone I need to look at tomorrow anyway, so I think my next steps from here are going to be to dig through my laptops, find the ones with the intel backlight interface that use PWM controls and see what the difference between those machines and yours is. That'll probably give me a couple of ideas to try (feel free to bug me if I don't get back to you in the next few days though! it's encouraged, even)

@lyudess great to know, thanks for the update. Well if you want to try a patch out don't hesitate to @ me, I'll try it out and give you more info to aid the debugging.

@brandon.arnold ok - I did some investigation but I'm not seeing anything obvious that we're doing wrong so far. I'm going to try to get my contacts from Dell to take a look at this to see if we can figure out what might be going on here). It's very strange to me that we can turn the backlight on/off with this but we can't control the brightness...

Some other info I could definitely use from you now that I've had a closer look at this:

• The EDID blob for your display, mostly to help Dell know what specific display panel this laptop is equipped with
• I assume this is still true, but can you confirm that i915.enable_dpcd_backlight=0 still works for you on drm-tip? I mostly ask because if it does, we at least know it's not writing the source OUI to the panel that's breaking your backlight controls

@jani if you could also poke the person you talked to about probing for Intel's backlight interface and ask which bits in 0x340-344 they're checking to look for support, and additionally if there's any other regs we should be checking (and which bits they're checking in those) that'd be appreciated.

@brandon.arnold could you try to revert commit f12110afee058a2e6 ("drm/i915/dp: Program source OUI on eDP panels"), then the default backlight dpcd control might work.

@lyudess I think the magic OUI number did this trick. also I am confused you patch didn't work, that means PWM is totally not working.

man this will be seriously nightmarish if it's the source OUI that's breaking this. that's why I asked them to see if this still worked with i915.enable_dpcd_backlight=0 jfyi

@Ma / @lyudess could either of you provide a patch of the revert commit Aaron is asking for? I created revert-f12110afee058a2e6.patch as my fleeting attempt to handle merge conflicts created by git revert f12110afee058a2e6 on the latest drm-tip, but it did not go well.

lyudess/linux@5de734b6 here, this should work. BTW - it'd still be helpful if you could get the EDID info I asked for since we have Dell looking at this now too.

Also cool tip for reverting stuff that made the conflict for this revert a lot simpler: git revert $SOME_COMMIT -Xpatience

@brandon.arnold

mentioned in commit nouveau@11664169

added feature: display/backlight label

@Ma / @lyudess / @jani I am really sorry, it looks like Lyude's original fix actually did the trick. It is on master at this point, right?

I just noticed that the reason I mistook it last time is because I had a very small difference in brightness level change, when I lowered and raised it. I didn't notice this until I tried the f12110afee058a2e6 revert, and noticed that it worked. But it made me suspect that I was wrong originally, so I tried to perform Lyude's original patch, and found that it had already landed. So I booted to drm-tip without any patches and it seems to work with the i915.enable_dpcd_backlight=1 setting.

Really sorry to Lyude for causing you the extra headache! And thanks so much for hanging in there with me, I'm kicking myself.

haha, no problem! Issues where I don't have to do much to fix them are my favorite kind of fixes :).

closed