|Summary:||Resuming from system sleep the ACPI backlight settings take over the native Intel video backlight|
|Product:||ACPI||Reporter:||Mika Westerberg (mika.westerberg)|
|Component:||Power-Video||Assignee:||Aaron Lu (aaron.lu)|
Dmesg from the machine after resume
acpidump from the machine
Description Mika Westerberg 2014-02-07 10:10:54 UTC
Created attachment 125071 [details] Dmesg from the machine after resume I'm using /sys/class/backlight/intel_backlight to tune the backlight brightness on HP revolve 810 laptop. After resuming from system sleep the backlight seems to get the ACPI video values and not the values in the Intel driver. I typically use the backlight sysfs interface directly as I'm running DWM as my window manager (there is no way to tune it from DWM). Switching to gnome seems work but my guess is that it just picks the first backlight device and it happens to be acpi_video0. The patch I've been using to fix this is here: http://lkml.indiana.edu/hypermail/linux/kernel/1402.0/00521.html Which basically blacklists the ACPI driver so that I only have the native intel_backlight.
Comment 1 Mika Westerberg 2014-02-07 10:11:30 UTC
Created attachment 125081 [details] acpidump from the machine
Comment 2 Aaron Lu 2014-02-08 01:52:23 UTC
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?
Comment 3 Mika Westerberg 2014-02-08 06:47:18 UTC
(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.
Comment 4 Aaron Lu 2014-02-08 07:00:38 UTC
(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.
Comment 5 Mika Westerberg 2014-02-08 13:28:35 UTC
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 :)
Comment 6 Aaron Lu 2014-02-10 01:22:22 UTC
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.
Comment 7 Aaron Lu 2014-02-10 05:31:41 UTC
BTW, is there a reason you prefer intel_backlight over acpi_video0 since acpi_video0 works well for your laptop?
Comment 8 Mika Westerberg 2014-02-10 08:58:10 UTC
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.
Comment 9 Aaron Lu 2014-02-10 09:06:49 UTC
(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?
Comment 10 Mika Westerberg 2014-02-10 09:28:23 UTC
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.
Comment 11 Mika Westerberg 2014-02-10 10:43:13 UTC
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.
Comment 12 Aaron Lu 2014-02-11 00:35:33 UTC
That probably because your system is in the disable_win8 DMI blacklist... What's your DMI info?
Comment 13 Mika Westerberg 2014-02-11 09:57:55 UTC
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?
Comment 14 Aaron Lu 2014-02-12 02:23:16 UTC
That's enough. I checked the git log, your system is blacklisted for win8 by: commit 2d4054d8422462cb2771fdb4eb1925df55d2b320 Author: Takashi Iwai <email@example.com> Fri Dec 20 00:09:12 2013 Committer: Rafael J. Wysocki <firstname.lastname@example.org> 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 <email@example.com> Signed-off-by: Rafael J. Wysocki <firstname.lastname@example.org> I think you can just use acpi_video interface and the problem would be gone.