Le samedi 19 octobre 2013 à 18:49 +0100, Ben Hutchings a écrit : > 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.
Ah, I see. I just checked Xorg.0.log, I get this though: [ 5.080] (--) intel(0): found backlight control interface acpi_video0 (type 'firmware') So it seems even Xorg is telling me that the backlight control interface which will handle my Intel graphic card is acpi_video0 and not intel_backlight… strange given its behavior! > > > 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). Ok, thanks a lot Ben for your time! Btw, do you know if linux-acpi guys are reluctant to receive a bug report from a distro specific BTS, because I'm tempted to Cc them? > > Ben. > -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1382213378.10433.46.camel@lamella
