[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#702188: src:linux: [3.6 -> 3.7 regression] : Brightness control became ineffective



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.
> 


Reply to: