Bug 81515

Created attachment 103071 [details]
Xorg.0.log with kernel 3.16-rc5

Created attachment 103072 [details]
dmesg for kernel 3.15.5

This is how dmesg for kernel 3.15.5 looks like. If you need any additional info, please, let me know.

Just forgot to mention that I tried to use command line option
"video.use_native_backlight=1" but without any effect.

Try video.use_vendor_backlight=1.

Also "i915.i915_enable_rc6=7 i915.i915_enable_fbc=1 i915.lvds_downclock=1" is completely useless and more often dangerous. Fortunately for you the dangerous options in there do not match the module parameters.

If you look at the old kernel (best shown by the Xorg.log for 3.15) I guess it is using the acpi backlight.

(In reply to comment #3)
> Try video.use_vendor_backlight=1.
> 
> Also "i915.i915_enable_rc6=7 i915.i915_enable_fbc=1 i915.lvds_downclock=1"
> is completely useless and more often dangerous. Fortunately for you the
> dangerous options in there do not match the module parameters.
> 
> If you look at the old kernel (best shown by the Xorg.log for 3.15) I guess
> it is using the acpi backlight.

Hello, Chris. Thanks you for your reply.

As you suggested I removed those kernel parameters. Also I tried "video.use_vendor_backlight=1" and it did not help. According to dmesg this is unknown parameter (see attached dmesg).

Also in 3.15.5 kernel my /sys/classs/backlight folder has three subfolders:
acpi_video0
acpi_video1
intel_backlight

So is there anything else I can try?

Created attachment 103111 [details]
dmesg for kernel 3.16-rc5 with video.use_vendor_backlight=1

dmesg for kernel 3.16-rc5 with video.use_vendor_backlight=1

The bug is still there with kernel 3.16-rc6.

Hello, Chris.

Finally I found a workaround ( had to go and see the code for an appropriate kernel parameter). So with video.use_native_backlight=-1 (not sure what it really means) the backlight works as before. The /sys/class/backlight folder also contains:
acpi_video0  acpi_video1  intel_backlight.

As far as I understand in 3.16-rc1 the default value for use_native_backlight was set to 1.

Just for reference:
linux@linux:/sys/class/backlight> grep '.*' /sys/class/dmi/id/*_* 2> /dev/null
/sys/class/dmi/id/bios_date:01/02/2013
/sys/class/dmi/id/bios_vendor:Insyde
/sys/class/dmi/id/bios_version:F.0B
/sys/class/dmi/id/board_asset_tag:Type2 - Board Asset Tag
/sys/class/dmi/id/board_name:1851
/sys/class/dmi/id/board_vendor:Hewlett-Packard
/sys/class/dmi/id/board_version:59.14
/sys/class/dmi/id/chassis_asset_tag:CNU229926N
/sys/class/dmi/id/chassis_type:10
/sys/class/dmi/id/chassis_vendor:Hewlett-Packard
/sys/class/dmi/id/chassis_version:Chassis Version
/sys/class/dmi/id/product_name:HP ENVY 15 Notebook PC
/sys/class/dmi/id/product_version:078F110000204810000620100
/sys/class/dmi/id/sys_vendor:Hewlett-Packard

So should I open new bug report against ACPI? Or what is the real problem?

Created attachment 103666 [details]
dmesg for kernel 3.16-rc7 with video.use_vendor_backlight=-1

Afaics the acpi backlight module would be selected automatically based on your machine's ACPI capability information. Not sure why this doesn't happen, passing the bug to Jani.

I can provide more info if needed. Just let me know.

(In reply to comment #7)
> Finally I found a workaround ( had to go and see the code for an appropriate
> kernel parameter). So with video.use_native_backlight=-1 (not sure what it
> really means) the backlight works as before. The /sys/class/backlight folder
> also contains:
> acpi_video0  acpi_video1  intel_backlight.

CC Aaron, seems like acpi backlight is required on this one.

Do we understand why the intel_backlight interface do not work for this machine?

BTW, please attach your acpidump:
# acpidump > acpidump.txt

Thanks.

Created attachment 104855 [details]
acpidump.txt

The attached is acpidump.txt with kernel 3.16.1 which is also affected by this bug.

The ACPI backlight setting is done through EC, the fact that ACPI interface works while GPU doesn't suggests that the hardware circuit for backlight setting is hooked into EC instead of the GPU? And this is a Win8 laptop...

Hi, Aaron. Thank you for looking into this bug. I'm not sure what you're referring as EC. But as for the laptop, I bought it in the beginning of July, 2012 and it had preinstalled Win7. So I'm not sure that it is a Win8 laptop.

EC is abbreviated for embedded controller, wikipedia has explanation for it if you are interested. For win8, I mean its ACPI table has a query of _OSI("Windows 2012"), which means the BIOS is Win8 aware, though it doesn't necessarily mean the laptop is actually running Win8.

We have believed for Win8 aware BIOS, it will not have a working backlight interface and the GPU's raw interface will do the job. So we are disabling the ACPI backlight interface if the BIOS is Win8 aware since v3.16. This is not the case for your laptop and that's because your laptop is actually a Win7 one but your BIOS somehow has the _OSI("Windows 2012") call.

Thanks for the explanation. So what would be the proper solution? Add quirk for my model and similar laptops? I don't think HP will update BIOS for my laptop.

Perhaps revert the following patch:

commit 751109aad5834375ca9ed0dcfcd85a00cbf872b5
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Thu Jun 5 22:47:35 2014 +0200

    ACPI / video: Change the default for video.use_native_backlight to 1

I'll ask Rafael about this.

Aaron, I thought we should default to native only for Win8 based machines?

Yes we already did that. Hohahiu's laptop also claims to be Win8 in that its ACPI table has a _OSI("Windows 2012") query, that's all what we can judge. We don't really know if OEM has put a Win7 or a Win8 in it. If we know that, that would be a better hint than the _OSI query.

(In reply to comment #20)
> Yes we already did that. Hohahiu's laptop also claims to be Win8 in that its
> ACPI table has a _OSI("Windows 2012") query, that's all what we can judge.
> We don't really know if OEM has put a Win7 or a Win8 in it. If we know that,
> that would be a better hint than the _OSI query.

I tihnk we need to create a list of machines which need to not use native-backlight even though they claim to be win8 ready, iow start a quirk list which is the opposite of the one we've had until now.

This list should be considerably smaller, and thus less work to maintain. Hohahiu's laptop would be the first one on it, and the only one we know about sofar AFAIK.

Created attachment 105336 [details]
Set of patches fixinf this regression.

Hi Hohahiu,

Here is a set of patches which should fix the regression you are seeing. You only need patches 1 - 3, but for completeness sake I've put the complete set of patches I'm working on in a tarbal.

Can you please build a 3.16 or 3.17 kernel with patches 1 - 3 applied, and then boot that without any special kernel commandline parameters, after this things should work the same as they did in 3.15.

Thanks & Regards,

Hans

Hello, Hans,

Thank you for your effort!
I applied your patches (1-4) on top of my distro kernel 3.16.1 (OpenSUSE kernel:stable repository just for reference). First 3 patches applied cleanly, the fourth one had two hunks and finally failed. So I compiled the kernel with first 3 patches only. The backlight now works as in kernel 3.15.x (it has acpi_videox entries in /sys/class/backlight). So for the first 3 patches you can use my Tested-by.

Is there a chance that these patches can go to 3.17?

Thanks

PS. If you need additional testing just let me know.

Thanks for the testing, I've submitted the patchset upstream with a CC: stable for 3.16+

This is good news! Thank you for your work!

(In reply to comment #24)
> Thanks for the testing, I've submitted the patchset upstream with a CC:
> stable for 3.16+

The fix is in ACPI, so I'm closing this bug now. If the problem persists with the patches merged upstream, please file a new bug against ACPI at https://bugzilla.kernel.org/enter_bug.cgi?product=ACPI

Thanks for the report.

Closing 2 years old resolved+notourbug.