On Sat, 2013-10-19 at 19:20 +0200, Vincent Blut wrote: > fixed 702188 3.11-1~exp1 > thanks > > Le dimanche 03 mars 2013 à 19:08 +0100, Vincent Blut a écrit : > > Package: src:linux > > Version: 3.8-1~experimental.1 > > Severity: important > > > > Hi, > > > > In kernel prior to 3.7 I used to control the brightness through > > gnome-control-center (or writing a value in /sys/class/acpi_video0), but > > since > > 3.7 this is broken (ditto for the brightness function keys which are > > supported > > since this version), unless I boot with the '!Windows 2012' kernel > > parameter. I guess commit a57f7f9175b8 is the culprit, however I didn't > > try to boot with it reverted yet. > > > > Apart booting with the above kernel parameter, I guess it would be > > possible to blacklist the "video" module in order to make the backlight > > control fallback to intel_backlight. > > > > Anyway, I don't know if this issue is exclusively the kernel fault or if > > the firmware is at fault too. Also I didn't check if there was a > > possibility to add a quirk for this system to avoid it to boot with > > the Windows 2012 _OSI deleted. > > > > Well this seems to be fixed in Linux 3.11, I mean I do not need > 'acpi_osi="!Windows 2012"' on the Linux kernel command line to change > the backlight level. *However* if I boot with/out this kernel parameter, > the kernel reports that I'm using the ACPI backlight interface: > > $dmesg | grep -i backlight > [ 1.785468] asus_wmi: Backlight controlled by ACPI video driver > […] > > I heavily doubt that's the case because the number of possible backlight > levels is clearly different if I set the above kernel parameter or not:
Well, I suppose what it means is that asus_wmi is not taking control of the backlight. > With acpi_osi="!Windows 2012" → the backlight control interface exposes > 6 levels IIRC. > > Without acpi_osi="!Windows 2012" → 18 backlight levels where 0 = > backlight turned off, to me that looks like the Intel backlight > interface behavior despite the kernel tells me it's the ACPI one. > > So when the kernel exposes two backlight control interfaces, is there a > way to know which one is in use? Don't know. > Finally I need to find time to bisect to know which commit fixed this > stuff because there are a lot of heated discussions around the backlight > control interfaces, especially around the ASUS UX31A¹ that I'm using. > > ¹https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=cb7a386c6c25e85c2710cdb1a498a73794cda660 > [merged in 3.12-rc1] > > To me this commit becomes, de facto, useless because the kernel seems to > correctly falls back to the Intel backlight control interface but I may > be wrong! > > Ben, sorry to bother you, I was thinking that you might have cherry > picked commit cb7a386c6c25 in 3.11-1~exp1, is this the case? I haven't cherry-picked this change, and it has not been included in a 3.11.y stable update (yet). Ben. -- Ben Hutchings Time is nature's way of making sure that everything doesn't happen at once.
signature.asc
Description: This is a digitally signed message part
