Bug 70231

Created attachment 125081 [details]
acpidump from the machine

I'm a little confused, so let me get it clear :-)
1 Does acpi_video0 work or not?
2 'After resuming from system sleep the backlight seems to get the ACPI video values and not the values in the Intel driver.' I don't quite get this, since you are using the backlight sysfs interface directly, how can the acpi_video0's value gets used? What's the value range for both acpi_video0 and intel_backlight?

(In reply to Aaron Lu from comment #2)
> I'm a little confused, so let me get it clear :-)
> 1 Does acpi_video0 work or not?

It does.

> 2 'After resuming from system sleep the backlight seems to get the ACPI
> video values and not the values in the Intel driver.' I don't quite get
> this, since you are using the backlight sysfs interface directly, how can
> the acpi_video0's value gets used? What's the value range for both
> acpi_video0 and intel_backlight?

I mean that when I tune the backlight from the intel_backglight interface, after resume the values get back to original (I think this is because ACPI driver restores its own value or something like that). Hope that clears it up.

Range for acpi_video0 is 0-20 and for intel_backlight it is 0-651.

(In reply to Mika Westerberg from comment #3)
> (In reply to Aaron Lu from comment #2)
> > I'm a little confused, so let me get it clear :-)
> > 1 Does acpi_video0 work or not?
> 
> It does.
> 
> > 2 'After resuming from system sleep the backlight seems to get the ACPI
> > video values and not the values in the Intel driver.' I don't quite get
> > this, since you are using the backlight sysfs interface directly, how can
> > the acpi_video0's value gets used? What's the value range for both
> > acpi_video0 and intel_backlight?
> 
> I mean that when I tune the backlight from the intel_backglight interface,
> after resume the values get back to original (I think this is because ACPI
> driver restores its own value or something like that). Hope that clears it
> up.

OK, that's clear, thanks.
It seems that the ACPI video driver does one thing that it probably shouldn't: restore the backlight setting on resume. Since it is well possible users are not using it as the backlight control interface so doing that will confuse users, as is the case here. I'll need to think about what to do, but disable that working interface isn't the right thing to me, that DMI table is meant for systems that have broken ACPI backlight control firmware, which isn't the case here.

Well, it fixes the problem on my machine but, like you said, it is probably not the right thing to do. I also discussed with Jani Nikula yesterday and he mentioned that windows 8 machines are using the native backlight and not the firmware provided one. Not sure if that's the case here (the machine had windows 8 though).

Anyway, I'm more than happy testing any patches you come up :)

We have tried to make Win8 machines expose only the GPU's interface, but failed due to some reports about broken GPU interface. Passing video.use_native_backlight=1 should work for you.

The problem with Win8 machines is that, maintainers have different opinions on how to address it and no progress is made so far.

BTW, is there a reason you prefer intel_backlight over acpi_video0 since acpi_video0 works well for your laptop?

The story is this. When I got this machine, the backlight didn't work properly and then I found your patches floating on linux-acpi, probably few releases back. They fixed the backlight for me at the time. Also after your patches applied there was only intel_backlight (as they disabled acpi_video0).

I then wrote my backlight tuning scripts against that interface.

However, when your patches were merged, they were a bit different than the ones I tested and acpi_video0 appeared again making my scripts non-working again. I then noticed that setting video.use_native_backlight=1 solved my problem. And it was working fine, until 3.14-rc1 where suddenly acpi_video0 is there again! Even with the command line parameter (IIRC).

That's why I decided to fix the problem by adding the machine entry to the blacklist.

(In reply to Mika Westerberg from comment #8)
> And it was working fine, until 3.14-rc1 where suddenly acpi_video0
> is there again! Even with the command line parameter (IIRC).

That is definitely a bug somewhere. Can you please test this again with the cmdline param?

OK, I have this in the kernel command line: 'video.use_native_backlight=1'. Then checking the backlight devices:

% ls /sys/class/backlight/
acpi_video0@  intel_backlight@

Do you want me to add some debug somewhere?

This is vanilla 3.14-rc1 kernel.

I added some debug to acpi_video_verify_backlight_support() so that it prints all the conditions used in that function:

[    8.306497] ACPI/Video: acpi_osi_is_win8(): 0
[    8.306548] ACPI/Video: use_native_backlight: 1
[    8.306601] ACPI/Video: backlight_device_registered: 1

Looks like acpi_os_is_win8() is the one that causes check to fail.

That probably because your system is in the disable_win8 DMI blacklist... What's your DMI info?

Hmm, what does that mean? Under /sys/class/dmi/id I can see things like:

board_vendor:Hewlett-Packard
product_name:HP EliteBook Revolve 810 G1
product_version:A1029F1103

Is that what you mean? What entries you would like to see?

That's enough.

I checked the git log, your system is blacklisted for win8 by:

commit 2d4054d8422462cb2771fdb4eb1925df55d2b320
Author:	Takashi Iwai <tiwai@suse.de>  Fri Dec 20 00:09:12 2013
Committer:	Rafael J. Wysocki <rafael.j.wysocki@intel.com>  Fri Dec 20 22:50:56 2013

ACPI: Blacklist Win8 OSI for some HP laptop 2013 models

The BIOS on recent HP laptops behaves differently with Win8 OSI,
e.g. no backlight control and no rfkill are available.  List them in
the blacklist as a workaround.

This patch tries to reduce the added items by matching "G1" suffix,
e.g. machines are named like "HP ProBook 430 G1".

References: https://bugzilla.novell.com/show_bug.cgi?id=856294
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

I think you can just use acpi_video interface and the problem would be gone.