My HP Pavilion dv6-3182 laptop shows three interfaces in /sys/class/backlight: acpi_video0, acpi_video1 and radeon_bl0. radeon_bl0 only appears when the radeon driver is used (i.e. not if fglrx is used). Both acpi_video0 and radeon_bl0 control the brightness of the screen, but acpi_video0 has 11 brightness levels whilst radeon_bl0 has 256. As far as I know, acpi_video1 has no purpose. Writing to its brightness file doesn't do anything, but it causes problems to desktop environments that choose it over the other options.
(In reply to ntrrgc@gmail.com from comment #0) > As far as I know, acpi_video1 has no purpose. Writing to its brightness file > doesn't do anything, but it causes problems to desktop environments that > choose it over the other options. Normally, acpi_video0 is for the integrated GPU and acpi_video1 is for the dedicated one; it's beyond my understanding why firmware writer would provide an non-working interface for the dedicated one... BTW, does the GUI choose acpi_video1 by default? Please also attach acpidump.
This laptop has an Intel Core i7 Q720m, which as far as I know lacks an integrated video card. Slightly different models of this laptop have both an integrated GPU and a discrete one. Maybe they used the same or very similar DSDT for several models? Anyway, the brightness interface works correctly in a fresh non-OEM Windows system without installing additional drivers, offering 256 brightness levels. They must be figuring somehow the correct interface. > BTW, does the GUI choose acpi_video1 by default? These additional interfaces have caused lots of trouble for desktop environments. The choice of the interface is dependent on the desktop environment: they have an ordered list of possible interface names and the pick the first one that exists, which in my case, more often than not, happened to be the wrong one. `acpi_video1` (the wrong one in my case, but maybe the correct one in many other cases) takes preference over `acpi_video0`. Furthermore, in the case of this laptop, pressing the brightness keys is handled both in hardware and software, even in the GUI. In consequence, when the software brightness interface works, pressing the brightness key once triggers two brightness changes. Often the brightness is reset in the process. Additionally, the brightness value is not saved from one boot to the next.
Created attachment 150431 [details] `acpidump` output
(In reply to ntrrgc@gmail.com from comment #2) > This laptop has an Intel Core i7 Q720m, which as far as I know lacks an > integrated video card. > > Slightly different models of this laptop have both an integrated GPU and a > discrete one. Maybe they used the same or very similar DSDT for several > models? Very likely. > > Anyway, the brightness interface works correctly in a fresh non-OEM Windows > system without installing additional drivers, offering 256 brightness > levels. They must be figuring somehow the correct interface. > > > BTW, does the GUI choose acpi_video1 by default? > > These additional interfaces have caused lots of trouble for desktop > environments. The choice of the interface is dependent on the desktop > environment: they have an ordered list of possible interface names and the > pick the first one that exists, which in my case, more often than not, > happened to be the wrong one. `acpi_video1` (the wrong one in my case, but > maybe the correct one in many other cases) takes preference over > `acpi_video0`. OK I see. > > Furthermore, in the case of this laptop, pressing the brightness keys is > handled both in hardware and software, even in the GUI. In consequence, when > the software brightness interface works, pressing the brightness key once > triggers two brightness changes. Often the brightness is reset in the > process. Possible to test a v3.17-rcX kernel? The following commit(merged since v3.17-rc1) may fix this issue: commit 8ab58e8e7e097bae5fe39cbc67eb93a91f7134b7 Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Fri Jul 18 14:32:51 2014 +0200 ACPI / video: Fix backlight taking 2 steps on a brightness up/down keypress > > Additionally, the brightness value is not saved from one boot to the next. This seems to satisfy your requirement: https://wiki.archlinux.org/index.php/backlight#Udev_rule
Created attachment 150841 [details] Do not create backlight interface for output device that is not in the _DOD list Please test this patch, apply on top of Linus' latest git tree, thanks.
Please also attach dmesg with this kernel.
Sorry, I have been busy lately. I'll try it soon.
I have tried v3.17-rc1. The backlight no longer takes two steps, although it acts strange when the brightness keys are hold down for some time. It looks like someone (gnome-power?) is buffering up or down requests and sending them even when the brightness is at its minimum or maximum, leading to strange behavior like lag when the brightness keys are hold down, specially if up and down key presses are alternated (e.g. first set brightness to the minimum, then raise 2 levels). Resetting also still happens, like the power daemon is not aware of the real current brightness level. This is a video reproducing the issue: https://drive.google.com/file/d/0B20m7rn2a_TwbFhPaUpiTm84Qlk/edit?usp=sharing Later, I tried your patch, but there are still the same three brightness interfaces.
Created attachment 151221 [details] Do not create backlight interface for output device that is not in the _DOD list, v2 Please try this one, I've added more debug messages and please attach dmesg with this patch applied.
That worked, thanks. Two interfaces are shown now: acpi_video0 (11 levels) and radeon_bl0 (256 levels). I'm attaching the dmesg with `acpi.debug_layer=0x10000000 acpi.debug_level=4`. May I ask why radeon has its own brightness interface?
Created attachment 151621 [details] dmesg with second patch
commit 0b8db271f1592e118feef7300f6da85bea9366da Author: Aaron Lu <aaron.lu@intel.com> Date: Tue Sep 30 14:10:17 2014 +0800 ACPI / video: check _DOD list when creating backlight devices
This commit causes a regression with ASUS backlight Fn buttons. The stop working even with acpi_osi parameter.
Does the below patch solve your problem? commit 35d0565b95547ec12d025dc9b1394f22968d113d Author: Aaron Lu <aaron.lu@intel.com> Date: Mon Dec 1 02:09:18 2014 +0100 ACPI / video: update condition to check if device is in _DOD list https://lkml.org/lkml/2014/11/29/158