Bug 151731

Neither does video.use_bios_initial_backlight=1 btw.

Just tried video.use_native_backlight=0 but that doesn't help either. There is still no acpi_video0 device, only intel_backlight.

The bugreference is to freedesktop bugtracker, my apologies https://bugs.freedesktop.org/show_bug.cgi?id=76276

I finally managed to fix the problem by reintroducing the quickhack mentioned in comment #15 https://bugs.freedesktop.org/show_bug.cgi?id=76276#c15

i.e. hard-disable intel_panel_setup_backlight in intel_panel.c

(In reply to Martin from comment #0)
> Kernel 4.7 (re)introduces the problem that looks like bug 76276 for me. I
> have a Dell XPS13 that works correctly under 4.6, showing an acpi_video0
> device under /sys/class/backlight that is of type "firmware".
> 
> When booting 4.7 this is replaced by intel_backlight of type "raw" and the
> backlight slowly (aprox. 1 Hz) pulsates. Passing
> video.use_bios_initial_backlight=0 kernel parameter does not help.

That cmdline option isn't used to decide which backlight interface to use.

I don't see XPS13 in the video's quirk table so I don't think ACPI plays any magic with this model.

Did you use any cmdline option in the working v4.6 kernel? If not, I don't see why intel_backlight didn't show up in v4.6.

The only commandline I use in 4.6 and 4.7 is i915.enable_rc6=7.
I reported the problem on freedestkop here:

https://bugs.freedesktop.org/show_bug.cgi?id=97295

Funny to see how freedesktop i915 developer deflects accusations as well ;)

Funny how I'm here too.

Please either try v4.8-rc1 or do a git bisect to find the regressing commit.

That remark was in jest, it was not my intention to offend you!

I just tested 4.8-rc1 and it exhibits the exact same problem.
Will start bisect ASAP, don't expect miracles.

I get stuck in 4.6.0-rc3+ land which leaves i915 in unusable state (boots to black screen, no way of telling what backlight driver won). I  skipped many revisions and even tried to skip 4.6.0-rc3 completely by using "git skip v4.6.0-rc3 v4.6.0-rc4" but even that resulted in a 4.6.0-rc3+ kernel (how?) that was unusable.

Any tips on how to circumvent v4.6.0-rc3?

BTW, since you mentioned bug 76276, I went there but got:
Bug #76276 does not exist

Typo perhaps?

(In reply to Martin from comment #3)
> The bugreference is to freedesktop bugtracker, my apologies
> https://bugs.freedesktop.org/show_bug.cgi?id=76276

Oh I see.

It looks like adding drm.debug=0xe to kernel cmdline on the broken v4.7 kernel may give us some hint. Please do that and attach dmesg, thanks.

Created attachment 228661 [details]
dmesg of 4.7 booting with intel_backlight device

dmesg drm debug output of kernel 4.7 booting with faulty intel_backlight device.

Forgot to say: also need the dmesg of the working v4.6 to compare. The drm.debug=0xe is still need with v4.6. Thanks.

Created attachment 228691 [details]
dmesg output 4.6.6 with acpi_video0

drm debug dmesg output of 4.6.6 with functional acpi_video0 device

OK, that clears the mystery why intel_backlight is back.

dmesg_4.6.6_acpi_video0.log:[    0.643470] [drm:parse_lfp_backlight] PWM backlight not present in VBT (type 0)

dmesg_4.7.0_intel_backlight.log:[    0.765087] [drm:parse_lfp_backlight] VBT backlight PWM modulation frequency 10000 Hz, active high, min brightness 0, level 255


Jani,
Any ideas?

Created attachment 230861 [details]
fix backlight regression on xps 13 l332x

I run in the same regression since v4.7, this seems to have fixed it.

Although the patch does not apply cleanly on 4.7.2 (dev_priv was renamed dev recently?), making the exception for IVB in intel_opregion_get_panel_type as well fixes the problem. Result is a correctly working acpi_video0 backlight device, just like the quickhack.

Please follow this bug at the freedesktop bugzilla page as it's not related to ACPI as comment #16 showed.