[Acer Aspire V5-171] Backlight cannot be adjusted unless passing acpi_backlight=vendor
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Linux |
Fix Released
|
Medium
|
|||
linux (Ubuntu) |
Incomplete
|
Medium
|
Unassigned |
Bug Description
The boot parameter is suggested as a fix for this model by
http://
(so if it would help, I would suggest classing this bug as "confirmed").
ProblemType: Bug
DistroRelease: Ubuntu 13.04
Package: linux-image-
ProcVersionSign
Uname: Linux 3.8.0-19-generic x86_64
ApportVersion: 2.9.2-0ubuntu8
Architecture: amd64
AudioDevicesInUse:
USER PID ACCESS COMMAND
/dev/snd/
Date: Sat Apr 27 19:59:23 2013
InstallationDate: Installed on 2013-04-27 (0 days ago)
InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Release amd64 (20130424)
MachineType: Acer V5-171
MarkForUpload: True
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=
RelatedPackageV
linux-
linux-
linux-firmware 1.106
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 09/14/2012
dmi.bios.vendor: Acer
dmi.bios.version: V2.04
dmi.board.
dmi.board.name: Mimic
dmi.board.vendor: Acer
dmi.board.version: Type2 - Board Version
dmi.chassis.type: 10
dmi.chassis.vendor: Acer
dmi.chassis.
dmi.modalias: dmi:bvnAcer:
dmi.product.name: V5-171
dmi.product.
dmi.sys.vendor: Acer
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#15 |
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#16 |
Created attachment 88181
dmesg output
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#17 |
Hardware is a ThinkPad t430s in UEFI-Mode, theCompatibility Support Module is switched off.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#18 |
well, I guess the problem also exists in 3.3 kernel, right?
it seems that this patch introduces the "regression".
commit fba4e087361605d
Author: Igor Murzov <email address hidden>
Date: Sat Oct 13 04:41:25 2012 +0400
ACPI video: Ignore errors after _DOD evaluation.
There are systems where video module known to work fine regardless
of broken _DOD and ignoring returned value here doesn't cause
any issues later. This should fix brightness controls on some laptops.
Bugzilla: https:/
Signed-off-by: Igor Murzov <email address hidden>
Reviewed-by: Sergey V <email address hidden>
Signed-off-by: Zhang Rui <email address hidden>
But IMO, the ACPI backlight control on your laptop is always broken,
but this commit
commit ea9f8856bd6d4ed
Author: Igor Murzov <email address hidden>
Date: Fri Mar 30 21:32:08 2012 +0400
ACPI video: Harden video bus adding.
It is always better to check return values, so add some new checks and
correct existing ones.
v2: Be consistent and don't mix errors from -E* and AE_* namespaces.
Signed-off-by: Igor Murzov <email address hidden>
Signed-off-by: Len Brown <email address hidden>
happens to make your laptop stop using ACPI backlight control. :)
can you please attach the dmidecode output of your laptop?
so that I can backlist your laptop from ACPI Backlight control.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#19 |
Thank you. I add the output of dmidecode in a few seconds.
You should take also a look at this (Daniel Vetter and someone with a Dell Laptop):
http://
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#20 |
Created attachment 88191
output of dmidecode on a thinkpad t430s, uefi only mode
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#21 |
Adding the parameter "acpi_backlight
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#22 |
I can't confirm that the problem exists in Kernel 3.3 or not, because my first Kernel on that device was a Kernel of the 3.5 series. And with Kernel 3.5 and 3.6 everything worked.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#23 |
I tried the change blacklist.c, but it doesn't work for me. See attachment. I also wonder about the last empty curly braces in the struct (not added by me)?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#24 |
Created attachment 89941
not working modified backlist.c
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#25 |
Question:
$ ls -l
total 0
lrwxrwxrwx 1 root root 0 Dec 30 19:02 acpi_video0 -> ../../devices/
lrwxrwxrwx 1 root root 0 Dec 30 19:02 intel_backlight -> ../../devices/
If I understand your noted patches above, it is *okay* to see both directorie on kernel 3.6 and 3.7. The acpi_video0 just doesn't block intel_backlight on kernel 3.6?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#26 |
Adding following parameters to boot command line seems to be a mostly working workaround:
# first switches of thinkpad_acpi, seconds switches of acpi_video
thinkpad-
* Fn+BrightnessDown, Fn+BrighnessUp works
* GNOME Power-Widget displays change of value through Fn-Keys
* GNOME > System Settings > Brighness works
* ls -l /sys/class/
Only automatic display-dimming through GNOME seems not to work.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#27 |
I have done a git bisect and found the offending commit:
commit a57f7f9175b8ccb
Author: Bob Moore <email address hidden>
Date: Fri Aug 17 10:55:02 2012 +0800
ACPICA: Add Windows8/Server2012 string for _OSI method.
This change adds a new _OSI string, "Windows 2012" for both Windows 8
and Windows Server 2012.
From Microsoft document "How to Identify the Windows Version in ACPI
by Using _OSI", July 13, 2012.
Signed-off-by: Bob Moore <email address hidden>
Signed-off-by: Feng Tang <email address hidden>
Signed-off-by: Len Brown <email address hidden>
Reverting this fixes the issue for me on ThinkPad X230.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#28 |
oh, please attach the acpidump output of your laptop.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#29 |
BTW, does adding kernel parameter acpi_osi="!Windows 2012" help?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#30 |
Created attachment 90681
acpidump output for ThinkPad X230
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#31 |
acpi_osi="!Windows 2012" works, I've been using that instead of the modified kernel.
Thanks.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#32 |
Thats weird! I will test that also and tell you if it works.
Am I right, that this will tell the ACPI based functions of the kernel that the BIOS/UEFI doesn't support Windows 2012?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#33 |
I can confirm that this works!
ls -l /sys/class/
total 0
lrwxrwxrwx 1 root root 0 Jan 8 22:20 acpi_video0 -> ../../devices/
lrwxrwxrwx 1 root root 0 Jan 8 22:20 intel_backlight -> ../../devices/
Booth seem to work, again, adjacent to another.
But the automatic display dimming via GNOME still seems not to work. I wonder why, but it is not really important.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#34 |
I took a look at the ACPI tables from an x230. If the OS says it's Windows 2012 then _BCL gives an alternate table of brightness values to meet an arbitrary requirement of Win8 to have 101 brightness levels [1]. _BCM tries to find a match for the brightness level it's given in the smaller table it uses for non-Win8 OSes. If it doesn't find an exact match then it just returns without applying any brightness change, so of the 101 values that _BCL claims to support only a much smaller subset (16) actually affect a change in the brightness.
[1] http://
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#35 |
I'm not seeing any way to fix this other than doing some sort of quirking for the affected machines.
One option add a quirk to keep the kernel from claiming to be Windows 8. There are other places in the ACPI tables where behavior will be affected, but since folks have been running older kernels successfully on these machines I suspect everything should work okay.
The other option I can think of is to quirk acpi-video so that it will only use the brightness values that actually work. I don't see any way to do this without hard coding firmware implementation details into the driver though, which is ugly.
Any other ideas?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#36 |
I see that _BCM and _BQC only work with the 16 step table (\_SB.PCI0.
When interacting with the backlight through sysfs, brightness node can be set to any value from _BCL, but actual_brightness reports its current value from _BQC. This causes a discrepancy between brightness and actual_brightness where brightness could be 75 but actual_brightness remains at 70.
Gnome uses RandR to change backlight, which reports actual_brightness when available. When Gnome tries to change brightness in reaction to media keys, it tries to do so in 5% increments based on actual_brightness. Now, since 75% is not supported in the BRTW table, stepping up from 70% would never succeed and so Gnome's brightness OSD gets stuck at 75% and cannot go any higher. Same thing happens when trying to step down from 20%.
I have created a test kernel by commenting out the get_brightness entry in acpi_backlight_ops. RandR seems to fallback to the brightness node and everything works fine in Gnome.
Brightness adjustment with media keys in virtual terminals still has no effect. But I have no idea how the brightness keys are handled in VT so I can't comment on that.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#37 |
Sorry, made a mistake in the previous comment:
RandR backlight control doesn't work without a valid actual_brightness node so Gnome falls back to its own backlight helper which uses the brightness node.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#38 |
(In reply to comment #21)
> I see that _BCM and _BQC only work with the 16 step table
> (\_SB.PCI0.
> When interacting with the backlight through sysfs, brightness node can be set
> to any value from _BCL, but actual_brightness reports its current value from
> _BQC. This causes a discrepancy between brightness and actual_brightness
> where
> brightness could be 75 but actual_brightness remains at 70.
Yes, since _BCM only discards the value and doesn't return an error, acpi_video thinks the brightness change was successful and thus updates the cached brightness value. actual_brightness shows that the firmware discarded the value.
> Gnome uses RandR to change backlight, which reports actual_brightness when
> available. When Gnome tries to change brightness in reaction to media keys,
> it
> tries to do so in 5% increments based on actual_brightness. Now, since 75% is
> not supported in the BRTW table, stepping up from 70% would never succeed and
> so Gnome's brightness OSD gets stuck at 75% and cannot go any higher. Same
> thing happens when trying to step down from 20%.
>
> I have created a test kernel by commenting out the get_brightness entry in
> acpi_backlight_ops. RandR seems to fallback to the brightness node and
> everything works fine in Gnome.
We shouldn't expose the backlight to userspace if it isn't going to work properly. So the possible solutions I can think of are quirking to use "!Windows 2012" by default, quirking to disable acpi_video backlight, or quirking somehow to make acpi_video only use the values that actually work.
> Brightness adjustment with media keys in virtual terminals still has no
> effect.
> But I have no idea how the brightness keys are handled in VT so I can't
> comment
> on that.
This depends to some degree on how the firmware behaves. Most of the time a keycode is emitted when you press the brightness keys which userspace needs to respond to. When you're in a VT there's probably no software responding to the brightness keycodes, thus no change in brightness.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#39 |
Created attachment 91091
acpidump of thinkpad t430s with uefi 2.05 in uefi-only mode, without csm
acpidump in uefi-only mode, compatibility-
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#40 |
Created attachment 91311
Disable Windows 8 compatibility for ThinkPad T430s and X230
Here's a patch (based on 3.8-rc3) which disables Windows 8 compatibility for the T430s and X230 in ACPI. Please give it a try.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#41 |
Just a note that I've received a positive verification of the patch on the X230. I'd still like to get someone to verify it works on the T430s.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#42 |
I can't promise it, but I looking forward to test the patch today evening (20.00 o'clock CET).
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#43 |
I'm late. But I'm always late ;-)
The patch works! Thank you!
Also your patch showed me, what was wrong with my own attempt.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#44 |
Created attachment 91381
t530 acpidump uefi only
t530 is also affected.
acpi_osi="!Windows 2012" workaround works.
Here is my acpi dump while in uefi only mode.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#45 |
Created attachment 91391
Disable Windows 8 compatibility for some Lenovo Thinkpads (v2)
Sigh. I wonder how many machines are affected in total. I wonder if we ought to resort to just disabling the acpi_video backlight on these machines instead, but that assumes that every machine with this implementation has another working backlight available.
Anyway, for now here's an updated patch including a quirk for the T530. Please test.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#46 |
I'm afraid all current ThinkPads from 2012. Pretty sure we can safely add add x230t (this time with t), t430(this time without s) and x1 also. I think the best solution is to talk to the people at Lenovo, because I've good experience with the own forums, I decided to open a thread there. Writing to "official" emails addresses seem like a bad idea.
I asked them for a list of models with this "mapping", and as bonus, for how the mapping can be used. Maybe we can profit from that knowledge in future.
btw. To you think Linus will accept the quirks for the upcoming rcs of 3.8? They are small, improve the situation and couldn't harm.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#47 |
I'm already trying to get this information to Lenovo. However at this point it's in the wild and there will always be broken machines, so it would be nice if we had a way to deal with it. Quirking that many machines might not be well received, though any other solution I can think of seems even worse. Unless all the broken machines have some other attribute in common, like the firmware version, that we can use for quirking instead. That would be good.
Fwiw, I suspect the reason it works under Windows is that it must be trying to do a smooth backlight adjustment by writing every brightness value between current_brightness and new_brightness, so you at least end up with the last valid brightness value written.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#48 |
As far as I know, the firmware version 2.0 was introduced to support Windows 8.
# this dmesg is a bit old, my current firmware is 2.05
DMI: LENOVO 2353CTO/2353CTO, BIOS G7ET60WW (2.02 ) 09/11/2012
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#49 |
Running Kernel 3.7.2 on ThinkPad X1 Carbon with Ubuntu 12.10, can confirm this exact bug.
xev shows this when hitting Fn+Brightness Key:
RRNotify event, serial 71, synthetic NO, window 0x4a00001,
subtype XRROutputProper
output LVDS1, property BACKLIGHT, timestamp 1441820, state NewValue
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#50 |
I can confirm this bug on ThinkPad W530 running Arch Linux kernel 3.7.3.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#51 |
I can confirm this bug on ThinkPad X230 running pf-sources 3.7.4 (for whatever that's worth).
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#52 |
Created attachment 92761
Disable Windows 8 compatibility for some Lenovo Thinkpads (v3)
Sorry for not following up sooner. I was hoping to be able to get some information from Lenovo, but so far that hasn't happened.
I also took a look at trying to quirk based on some other criteria like firmware version. I collected dmi information from Launchpad for a bunch of different thinkpad models, and unfortunately the way the bios is versioned across different models doesn't make this a viable option.
So anyway, I'm attaching an updated patch which contains quirks for the four models which have been confirmed as being affected by this bug.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#53 |
Thanks for the quick response! Forgive me if I've misunderstood something, but it seems that the X230 model is not included among the four in your patch. Does this mean that your patch would not fix the issue on an X230 even if you did include a match for the X230?
BTW, minor typo in your code comments - s/behavoir/
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#54 |
(In reply to comment #38)
> Thanks for the quick response! Forgive me if I've misunderstood something,
> but
> it seems that the X230 model is not included among the four in your patch.
> Does
> this mean that your patch would not fix the issue on an X230 even if you did
> include a match for the X230?
My quick response was a lucky coincidence -- I was already getting ready to post the new patch.
I did somehow end up dropping the quirk for the x230 (it was in the first two versions). Not sure how that happened. Thanks for catching it; I'll add it back.
> BTW, minor typo in your code comments - s/behavoir/
Thanks!
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#55 |
Too bad that Lenovo didn't give you more information on that.
I have a "ThinkPad L430" which is also affected by this problem. Would be nice if this model also finds it way into the patch.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#56 |
(In reply to comment #40)
> Too bad that Lenovo didn't give you more information on that.
> I have a "ThinkPad L430" which is also affected by this problem. Would be
> nice
> if this model also finds it way into the patch.
I'll need dmi information to add your machine. Please give me the output from running dmidecode on your machine.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#57 |
Created attachment 92771
dmidecode on a ThinkPad L430
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#58 |
Created attachment 92781
Disable Windows 8 compatibility for some Lenovo Thinkpads (v4)
Another patch, this time re-adding the X230 and adding the L430 as well. Please test.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#59 |
I can confirm that this patch solves the problem on the L430 running Linux 3.7.6.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#60 |
This fourth release of this patch works (of course) still with kernel 3.8-rc7.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#61 |
This patch works on kernel 3.7.7 on ThinkPad X1 Carbon as well.
Great job!
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#62 |
Hmm. I can't seem to find any difference between the behavior before and after the patch. Brightness keys still do not work; /sys/class/
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#63 |
Ugh, never mind. The patch works just fine, I just failed to copy the right kernel image to /boot when testing it... sorry for the noise!
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#64 |
Lenovo released a new BIOS/UEFI, at least for ThinkPad t430s:
http://
Quote:
"- Fixed an issue where the display was corrupted on Linux."
Doesn't sound like it fits to this issue. But I will install it anyway.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#65 |
I've installed the new BIOS/UEFI. Nothing changed, with and without the patch.
Seems like Lenovo added four addidional questions "Do you want really upgrade?" to the installer. I'm not kidding. The installer also ask to keep the "UEFI boot image", sounds like the UEFI bootloader-entries.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#66 |
For what it's worth, I have an X230, with the 2.06 version of the BIOS and the 1.10 version of the firmware, running a 3.8-rc6 kernel plus ext4 development patches (3.8.0-
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#67 |
I have an X230 with BIOS 2.02 and firmware 1.9, and I'm also not using GNOME (just xmonad on bare X). The backlight keys weren't working for me on 3.7 + postfactum's patchset. So I guess it wasn't a GNOME problem, but a kernel problem. (Well, possibly a problem in the patchset, but I doubt it since multiple people presumably not using that patchset were able to duplicate the issue.)
I'm glad to hear it's fixed in 3.8-rc6, though :)
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#68 |
(In reply to comment #52)
> I have an X230 with BIOS 2.02 and firmware 1.9, and I'm also not using GNOME
> (just xmonad on bare X). The backlight keys weren't working for me on 3.7 +
> postfactum's patchset. So I guess it wasn't a GNOME problem, but a kernel
> problem. (Well, possibly a problem in the patchset, but I doubt it since
> multiple people presumably not using that patchset were able to duplicate the
> issue.)
>
> I'm glad to hear it's fixed in 3.8-rc6, though :)
Actually I don't think it's fixed. I just tried on 3.8.0 and it doesn't work. Afair Theodore's x230 doesn't use UEFI mode, and afaict everyone else here does boot using “pure” UEFI and no CSM (but a confirmation would help).
My grub-efi doesn't boot when using CSM (indeed) so I can't tell if it'd work on 3.8+ with CSM but I think it's at least related.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#69 |
(In reply to comment #51)
> For what it's worth, I have an X230, with the 2.06 version of the BIOS and
> the
> 1.10 version of the firmware, running a 3.8-rc6 kernel plus ext4 development
> patches (3.8.0-
> crap
> for me :-), and the brightness keys (Fn-F8/Fn-F9) work just _fine_.
Odd, this bios version isn't listed on Lenovo's website. It is newer than the x230 bios version that I know to have the bug, so perhaps Lenovo fixed the problem. Care to attach your ACPI tables?
It's also possible that it works because you're using a different window manager, so you most likely wouldn't be using gnome-settings-
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#70 |
(In reply to comment #53)
> Actually I don't think it's fixed. I just tried on 3.8.0 and it doesn't work.
> Afair Theodore's x230 doesn't use UEFI mode, and afaict everyone else here
> does
> boot using “pure” UEFI and no CSM (but a confirmation would help).
The L430 is also affected when booting in legacy mode (not UEFI), so I don't think that the boot mode has any influence on this problem.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#71 |
(In reply to comment #54)
> (In reply to comment #51)
> > For what it's worth, I have an X230, with the 2.06 version of the BIOS and
> the
> > 1.10 version of the firmware, running a 3.8-rc6 kernel plus ext4
> development
> > patches (3.8.0-
> crap
> > for me :-), and the brightness keys (Fn-F8/Fn-F9) work just _fine_.
>
> Odd, this bios version isn't listed on Lenovo's website.
Sure it is: http://
Latest is 2.51 and:
2.06 (G2UJ08US) 2.06 (G2ET86WW) 1.10 (G2HT31WW) 01 2012/11/27
> It is newer than the
> x230 bios version that I know to have the bug, so perhaps Lenovo fixed the
> problem. Care to attach your ACPI tables?
I do have the problem with 2.51 (latest version available).
>
> It's also possible that it works because you're using a different window
> manager, so you most likely wouldn't be using gnome-settings-
> could
> check /sys/class/
> values are changing in response to the brightness keys.
I'm using Xfce too, so I'll try to explain how it works to hopefully unconfuse people.
On x230 (and all the 2012 Thinkpads, it seems), before 3.7 brightness keys work just fine independently of any userspace daemon. It works in single user, it works in vt, it works in X at login screen, it just works. However, Xfce needs a bit of tuning in order to indicate xfce4-power-manager it doesn't have to handle brightness keys (KEY_BRIGHTNESS
On 3.7+ and due to the _OSI("Windows 2012") handling, video.ko seems to not handle those anymore, but KEY_BRIGHTNESS{
So in case it's still confusing, I think it's better to test either in a vt or in X with nothing else running (just running X from vt for example).
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#72 |
(In reply to comment #56)
> (In reply to comment #54)
> > (In reply to comment #51)
> > > For what it's worth, I have an X230, with the 2.06 version of the BIOS
> and the
> > > 1.10 version of the firmware, running a 3.8-rc6 kernel plus ext4
> development
> > > patches (3.8.0-
> crap
> > > for me :-), and the brightness keys (Fn-F8/Fn-F9) work just _fine_.
> >
> > Odd, this bios version isn't listed on Lenovo's website.
>
> Sure it is:
> http://
> Latest is 2.51 and:
>
> 2.06 (G2UJ08US) 2.06 (G2ET86WW) 1.10 (G2HT31WW) 01 2012/11/27
It wasn't listed at whatever page I was looking at :-/
> > It is newer than the
> > x230 bios version that I know to have the bug, so perhaps Lenovo fixed the
> > problem. Care to attach your ACPI tables?
>
> I do have the problem with 2.51 (latest version available).
Good to know, thanks.
> > It's also possible that it works because you're using a different window
> > manager, so you most likely wouldn't be using gnome-settings-
> could
> > check /sys/class/
> > values are changing in response to the brightness keys.
>
> I'm using Xfce too, so I'll try to explain how it works to hopefully
> unconfuse
> people.
>
> On x230 (and all the 2012 Thinkpads, it seems), before 3.7 brightness keys
> work
> just fine independently of any userspace daemon. It works in single user, it
> works in vt, it works in X at login screen, it just works. However, Xfce
> needs
> a bit of tuning in order to indicate xfce4-power-manager it doesn't have to
> handle brightness keys (KEY_BRIGHTNESS
> handled, I guess by video.ko) but that's all.
>
> On 3.7+ and due to the _OSI("Windows 2012") handling, video.ko seems to not
> handle those anymore, but KEY_BRIGHTNESS{
> (by /dev/input/even4 which is "Video Bus"). So if xfce4-power-manager is
> configured to handle the keys itself (which is the case by default) it'll
> happily do it (however you'll only have 8 or 9 brightness level instead of
> 15,
> it seems).
To clarify, video.ko does still handle the keys (whether or not it should be doing so is debatable). What happens is that it receives a brightness up/down notification, reads the current brightness via _BQC, selects the next higher/lower brightness level, and writes it via the _BCM. The adjacent levels do not change the brightness though, not even the internal value of the brightness returned by _BQC. So the next time the brightness up/down key is pressed it reads the exact same value as the first time. So no matter how many times you hit the hotkeys you'll never see any change in brightness.
> So in case it's still confusing, I think it's better to test either in a vt
> or
> in X with nothing else running (just running X from vt for example).
That would take X and the desktop out of the picture. What I thought might be different about xfce is that it could be responding to the notifications by changing the brightness via the GPU's backlight device in...
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#73 |
(In reply to comment #57)
> To clarify, video.ko does still handle the keys (whether or not it should be
> doing so is debatable). What happens is that it receives a brightness up/down
> notification, reads the current brightness via _BQC, selects the next
> higher/lower brightness level, and writes it via the _BCM. The adjacent
> levels
> do not change the brightness though, not even the internal value of the
> brightness returned by _BQC. So the next time the brightness up/down key is
> pressed it reads the exact same value as the first time. So no matter how
> many
> times you hit the hotkeys you'll never see any change in brightness.
Thanks for the clarification.
>
> > So in case it's still confusing, I think it's better to test either in a vt
> or
> > in X with nothing else running (just running X from vt for example).
>
> That would take X and the desktop out of the picture. What I thought might be
> different about xfce is that it could be responding to the notifications by
> changing the brightness via the GPU's backlight device instead of
> acpi_video's.
> But you say that isn't happening for you, so it makes me wonder what's
> different about Ted's situation.
I think that Ted might not have changed anything to xfce4-power-manager default setup, so maybe 3.7 actually improved his experience, due to shortcomings in xfpm.
>
> Also I should probably give an update. The short version is that the
> maintainers have requested that I fix the issue by gradually changing the
> brightness instead of using a quirk. Going that route doesn't fix the problem
> I
> just described with the hotkeys, so the approach I've taken is to 1) read
> back
> the brightness after writing and disable use of _BQC if the value doesn't
> match, and 2) by default disable handling brightness notifications within the
> video driver and letting userspace take care of it.
Hmh, that looks like a huge change to me. On a personal note, I prefer this kind of things to be handled in the kernel, so it works just fine wether you're in X, on a vte, with the screen locked or not etc. I know some daemon don't handle this really fine (at least xfpm is a bit confused since it doesn't really detect automatically if he should hands off the brightness), but at least that means a daemon is *not* needed to handle something as close to metal as the brightness handling is.
> That said, here's the link to the patches for those willing to assume the
> risk.
I'll try to test them tomorrow on X230 and report back.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#74 |
It took me a while, but I just tested the patches on top on 3.8.2.
- brightness keys don't work in a tty or when no userspace daemon handles brightness
- evtest /dev/input/event4 (Video Bus) sees KEY_BRIGHTNESS{
- on Xfce with xfce4-power-manager default config
- brightness is correctly changed when brightness keys are used,
- 16 levels (with no smoothing) and OSD is behaving correctly
For comparison, on a 3.8.2 booted with acpi_osi="!Windows 2012" I get:
- brightness keys work in a tty or when no userspace daemon is running (16 levels, no smoothing)
- evtest /dev/input/event4 (Video Bus) sees KEY_BRIGHTNESS{
- on Xfce with xfce4-power-manager default config
- brightness is correctly changed when brightness keys are used
- I only get 9 levels, since brightness is changed both by the kernel and by xfpm
- when disabling xfpm brightness keys handling I get 16 levels back (and I lose the OSD report)
In my opinion the second behavior is better since that means brightness doesn't depend on userspace. And I wonder if KEY_BRIGHTNESS{
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#75 |
(In reply to comment #57)
> To clarify, video.ko does still handle the keys (whether or not it should be
Indeed, but it handles the key only when requested, i.e. a user space program did a sysfs write to the brightness file, then acpi video driver will update the backlight level accordingly; not that it handles the key automatically. So if there is no app reacting to the key, acpi video driver will do nothing.
> doing so is debatable). What happens is that it receives a brightness up/down
> notification, reads the current brightness via _BQC, selects the next
> higher/lower brightness level, and writes it via the _BCM. The adjacent
> levels
I don't think it is working this way.
When user press the Fn+brightness key, usually, the scan code will be sent to user space as an input event; user space apps like g-s-d or acpid will listen for such evens and react accordingly: choosing a level and write it to the sysfs file to change the brightness level. How does the app choose the next level is beyond of my knowledge, and I would very much like to know.
> do not change the brightness though, not even the internal value of the
> brightness returned by _BQC. So the next time the brightness up/down key is
> pressed it reads the exact same value as the first time. So no matter how
> many
> times you hit the hotkeys you'll never see any change in brightness.
Thanks for the information, it helped to understand what is happening here.
>
> > So in case it's still confusing, I think it's better to test either in a vt
> or
> > in X with nothing else running (just running X from vt for example).
>
> That would take X and the desktop out of the picture. What I thought might be
> different about xfce is that it could be responding to the notifications by
> changing the brightness via the GPU's backlight device instead of
> acpi_video's.
That's possible, it all depends on user space app. AFAIK, g-s-d will prefer to use acpi_video's backlight control file, but I don't know how xfce's power management component works.
> But you say that isn't happening for you, so it makes me wonder what's
> different about Ted's situation.
>
> Also I should probably give an update. The short version is that the
> maintainers have requested that I fix the issue by gradually changing the
> brightness instead of using a quirk. Going that route doesn't fix the problem
> I
> just described with the hotkeys, so the approach I've taken is to 1) read
> back
> the brightness after writing and disable use of _BQC if the value doesn't
This might be more complex: current code already handle some broken BIOSes that does not report correct value with _BQC and we would assume the _BQC is retuning an index instead of level value.
> match, and 2) by default disable handling brightness notifications within the
> video driver and letting userspace take care of it.
As I said above, acpi video driver does not handle it automatically. For the normal case, it even doesn't know such a Fn key is pressed; for some other cases, it will get a notification from some EC firmware code and then it will map those notification to standard video brightness Fn keys and send them to user space through ...
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#76 |
Hi Seth,
I'm sorry I think I missed some code in video.c...
Apparently, for the notification case, the driver indeed changed the brightness level. I don't think this is correct, since it will also report this event to user space, like the no notification case. So we should definitely set brightness_
BTW, I've just checked the link you gave, there are several patches. Thanks for the patches.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#77 |
(In reply to comment #60)
> (In reply to comment #57)
> > To clarify, video.ko does still handle the keys (whether or not it should
> be
>
> Indeed, but it handles the key only when requested, i.e. a user space program
> did a sysfs write to the brightness file, then acpi video driver will update
> the backlight level accordingly; not that it handles the key automatically.
> So
> if there is no app reacting to the key, acpi video driver will do nothing.
Well, I'm not sure how generic this comment is, but I kind-of disagree. I can't test without video.ko since nowadays i915 needs it and KMS needs i915, but on my x201s and my x230 pre 3.7 or 3.7+ with acpi_osi="!Windows 2012" I don't need any userspace daemon to handle brightness keys.
(In reply to comment #61)
> Hi Seth,
>
> I'm sorry I think I missed some code in video.c...
>
> Apparently, for the notification case, the driver indeed changed the
> brightness
> level. I don't think this is correct, since it will also report this event to
> user space, like the no notification case. So we should definitely set
> brightness_
> behaviour.
If that means brightness keys won't work anymore if no userspace is running (or if the screen is locked, or noone is logged in, or anything userspace related), I again think this is a bad idea.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#78 |
(In reply to comment #62)
> (In reply to comment #60)
> > (In reply to comment #57)
> > > To clarify, video.ko does still handle the keys (whether or not it should
> be
> >
> > Indeed, but it handles the key only when requested, i.e. a user space
> program
> > did a sysfs write to the brightness file, then acpi video driver will
> update
> > the backlight level accordingly; not that it handles the key automatically.
> So
> > if there is no app reacting to the key, acpi video driver will do nothing.
>
> Well, I'm not sure how generic this comment is, but I kind-of disagree. I
> can't
> test without video.ko since nowadays i915 needs it and KMS needs i915, but on
The acpi video driver can do some things, and backlight control is one of them. I'm talking about backlight control alone here.
> my x201s and my x230 pre 3.7 or 3.7+ with acpi_osi="!Windows 2012" I don't
> need
> any userspace daemon to handle brightness keys.
Right, that is because for your laptop, there will be an acpi notification once the function key is pressed. But this is not the case for all laptops.
>
> (In reply to comment #61)
> > Hi Seth,
> >
> > I'm sorry I think I missed some code in video.c...
> >
> > Apparently, for the notification case, the driver indeed changed the
> brightness
> > level. I don't think this is correct, since it will also report this event
> to
> > user space, like the no notification case. So we should definitely set
> > brightness_
> > behaviour.
>
> If that means brightness keys won't work anymore if no userspace is running
> (or
> if the screen is locked, or noone is logged in, or anything userspace
> related),
> I again think this is a bad idea.
OK, that is debatable :-)
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#79 |
(In reply to comment #59)
> It took me a while, but I just tested the patches on top on 3.8.2.
Thanks for testing.
> - brightness keys don't work in a tty or when no userspace daemon handles
> brightness
> - evtest /dev/input/event4 (Video Bus) sees KEY_BRIGHTNESS{
> - on Xfce with xfce4-power-manager default config
> - brightness is correctly changed when brightness keys are used,
> - 16 levels (with no smoothing) and OSD is behaving correctly
Sounds like it's working as expected.
> For comparison, on a 3.8.2 booted with acpi_osi="!Windows 2012" I get:
>
> - brightness keys work in a tty or when no userspace daemon is running (16
> levels, no smoothing)
> - evtest /dev/input/event4 (Video Bus) sees KEY_BRIGHTNESS{
> - on Xfce with xfce4-power-manager default config
> - brightness is correctly changed when brightness keys are used
> - I only get 9 levels, since brightness is changed both by the kernel and
> by
> xfpm
> - when disabling xfpm brightness keys handling I get 16 levels back (and I
> lose the OSD report)
>
> In my opinion the second behavior is better since that means brightness
> doesn't
> depend on userspace. And I wonder if KEY_BRIGHTNESS{
> at
> all, since job has already been done.
The upstream maintainers requested the first behavior and probably aren't going to take the patch to quirk these machines with ascpi_osi="!Windows 2012". However, nothing prevents you from continuing to boot with this option to get the second behavior.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#80 |
(In reply to comment #64)
> The upstream maintainers requested the first behavior
Out of curiosity, who are the “upstream maintainers” (and why aren't they commenting here, since we're on the kernel bugzilla)
> and probably aren't going
> to take the patch to quirk these machines with ascpi_osi="!Windows 2012".
> However, nothing prevents you from continuing to boot with this option to get
> the second behavior.
Well, I can't test right now but are you sure I'll get that behavior with your patches applied? On top of that, acpi_osi might have other side effects, so it's not really a durable workaround I think.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#81 |
(In reply to comment #65)
> (In reply to comment #64)
> > The upstream maintainers requested the first behavior
>
> Out of curiosity, who are the “upstream maintainers” (and why aren't they
> commenting here, since we're on the kernel bugzilla)
Here's the thread:
http://
And yeah, the term "upstream" was probably misused since we're on b.k.o ;-)
> > and probably aren't going
> > to take the patch to quirk these machines with ascpi_osi="!Windows 2012".
> > However, nothing prevents you from continuing to boot with this option to
> get
> > the second behavior.
>
> Well, I can't test right now but are you sure I'll get that behavior with
> your
> patches applied? On top of that, acpi_osi might have other side effects, so
> it's not really a durable workaround I think.
Actually you also have to pass video.brightnes
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#82 |
(In reply to comment #66)
> (In reply to comment #65)
> > (In reply to comment #64)
> > > The upstream maintainers requested the first behavior
> >
> > Out of curiosity, who are the “upstream maintainers” (and why aren't they
> > commenting here, since we're on the kernel bugzilla)
>
> Here's the thread:
>
> http://
>
> And yeah, the term "upstream" was probably misused since we're on b.k.o ;-)
Thanks for the link. It's somehow weird that Henrique de Moraes Holschuh was not in the loop (I think he's subscribed to linux-acpi, but maybe not). He has a deep knowledge of Thinkpads.
Note that Matthew Garrett is wrong when he says:
> So the problem is that userspace is writing values that don't happen to
> be aligned with the values the hardware reacts to, and so nothing gets
> changed?
Here the value is not written by userspace but by the kernel. Not sure if it matters though.
>
> > > and probably aren't going
> > > to take the patch to quirk these machines with ascpi_osi="!Windows 2012".
> > > However, nothing prevents you from continuing to boot with this option to
> get
> > > the second behavior.
> >
> > Well, I can't test right now but are you sure I'll get that behavior with
> your
> > patches applied? On top of that, acpi_osi might have other side effects, so
> > it's not really a durable workaround I think.
>
> Actually you also have to pass video.brightnes
Good point.
The thing is, every userspace daemon does this differently, and not everyone uses a userspace daemon (nor want to). And userspace daemon only works when it's running. All in all, deffering this to userspace seems to me like a bad workaround. I think the kernel should handle this as much as possible in order for people to get a consistent behavior.
I'm not too sure if Matthew Garrett, Ben Jencks and other people involved in the thread do read this bug, but I'm open to writing this on linux-acpi if needed (I'm not subscribed but I can get a copy of the initial mail if needed).
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#83 |
I'm not competent enough to decide is technial better, but I'm working a lot on the plain terminal. Also other users may use just a Window-manager or something different.
If their is a generic way to change the brigthness (i.e. on top of Systemd, Upstart, SysV-Init) in the userspace it would be fine. At least Systemd already handles such things like LID-Switch-
With a stack from ACPI, Kernelspace, Init-Daemon, X11 to a random choosen Desktop-Enviroment we get a lot of thinks which could break. I remember the broken hot-keys with XINPUT2 in GNOME 3.4 or the missing support for "Inhibit" the power-functions in Systemd till the recent releases of GNOME and KDE. Also X11 and a desktop are not mandatory.
Long story, short conclusion:
It should just works always.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#84 |
*** Bug 55071 has been marked as a duplicate of this bug. ***
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#85 |
While my report #55071 was duplicated into this one, I'd like to state that my backlight issue is of different nature:
- The device is a Dell Inspiron 15R SE (7520) in UEFI mode.
- _BCL reports 102 levels (100, 30, and 1-100).
- I now get 2 acpi_video devices instead of previously 1.
- No matter what I set via writing to 'brightness' in either acpi_video device, reading it always yields '99'. This is - unlike the Thinkpads - also the case for values contained in the _BCL table for the non-Windows 8 case.
I can upload acpidump output again if desired.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#86 |
(In reply to comment #70)
> While my report #55071 was duplicated into this one, I'd like to state that
> my
> backlight issue is of different nature:
OK, understand.
Please feel free to describe your specific problem in the original bug page, and I hope we can have a central place to track all acpi video backlight issues related to win8 here. Thanks.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#87 |
Created attachment 97201
dmidecode on thinkpad x201
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#88 |
Created attachment 97211
acpidump on x201
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#89 |
Hi Alice,
Can you please let us know what is your problem? From your acpidump, I don't see you have the same problem(no win8 OSI and BCL does not claim 102 levels). Thanks.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#90 |
yes i was using the thinkpad x201 by remote and i tried it only after attaching and actually there is no problem with brightness so is just for give more information
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#91 |
Created attachment 99751
Disable ACPI backlight for broken ThinkPads
I'm attaching a new patch with a different take on this problem. It just disables the ACPI backlight control on these machines whenever the kernel has indicated Windows 8 compatibility via _OSI.
Most machines should fall back to using a secondary backlight control, but it's possible that a few machines won't have another control. It's also likely that brightness changes on VTs using the hotkeys will be broken. In either of these cases it will be necessary to use acpi_osi="!Windows 2012", and I'd appreciate it if someone could test this case to verify the acpi_video backlight works as before with the new patch.
Please give it a whirl and let me know your results. I've included quirks for every machine I'm aware of which is broken, but if I've missed any please let me know and include DMI information.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#92 |
Re: #76 patch:
Unfortunately, just setting acpi_backlight=
1. It causes _BCL not to be called, so the firmware won't generate ACPI events for the keypresses. Instead, the firmware will handle them entirely internally, changing the brightness. (See [1])
2. thinkpad_acpi will not mask the brightness keys, so we get hotkey events through that, in addition to the firmware's internal brightness changes.
3. thinkpad_acpi creates its "thinkpad_screen" sysfs device, which userspace prefers to the intel_backlight device that we want to be using.
I hacked up my kernel to do what I want on my machine, and I had to have acpi_video_
Another alternative would be to allow acpi_video0 to load normally, but prefer intel_backlight from userspace (Intel's xorg driver, xf86-video-
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#93 |
So for optimal experience, intel_backlight interface + acpi notification event handling should be used. I need to think about this.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#94 |
(In reply to comment #77)
> Unfortunately, just setting acpi_backlight=
> to
> completely solve the problem:
> 1. It causes _BCL not to be called, so the firmware won't generate ACPI
> events
> for the keypresses. Instead, the firmware will handle them entirely
> internally,
> changing the brightness. (See [1])
Is it possible for thinkpad-acpi module to control this behaviour? I mean, on hotkey press, do not handle backlight internally, just send out event.
> 2. thinkpad_acpi will not mask the brightness keys, so we get hotkey events
> through that, in addition to the firmware's internal brightness changes.
I don't see anywhere backlight gets changed internally. Is it done by some HKEY function?
> 3. thinkpad_acpi creates its "thinkpad_screen" sysfs device, which userspace
> prefers to the intel_backlight device that we want to be using.
Does that interface work or not?
Thanks.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#95 |
(In reply to comment #79)
> (In reply to comment #77)
> > Unfortunately, just setting acpi_backlight=
> to
> > completely solve the problem:
> > 1. It causes _BCL not to be called, so the firmware won't generate ACPI
> events
> > for the keypresses. Instead, the firmware will handle them entirely
> internally,
> > changing the brightness. (See [1])
>
> Is it possible for thinkpad-acpi module to control this behaviour? I mean, on
> hotkey press, do not handle backlight internally, just send out event.
I see a call to _BCL in thinkpad_acpi, but it doesn't seem to be getting called for some reason when acpi_backlight=
> > 2. thinkpad_acpi will not mask the brightness keys, so we get hotkey events
> > through that, in addition to the firmware's internal brightness changes.
>
> I don't see anywhere backlight gets changed internally. Is it done by some
> HKEY
> function?
It's in \_SB.PCI0.
> > 3. thinkpad_acpi creates its "thinkpad_screen" sysfs device, which
> userspace
> > prefers to the intel_backlight device that we want to be using.
>
> Does that interface work or not?
It doesn't appear to, for either reading or writing. I booted an unmodified kernel with acpi_backlight=
The brightness keys do work through the firmware, but the actual brightness has no effect on the values thinkpad_screen returns. By default, the hotkeys are unmasked, so I get a useless on-screen-display of brightness failing to change. Masking the hotkeys takes both kernel and userspace out of the picture, so there's no OSD.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Alan Jenkins (aj504) wrote : | #1 |
- AlsaInfo.txt Edit (26.7 KiB, text/plain; charset="utf-8")
- BootDmesg.txt Edit (63.2 KiB, text/plain; charset="utf-8")
- CRDA.txt Edit (257 bytes, text/plain; charset="utf-8")
- CurrentDmesg.txt Edit (7.9 KiB, text/plain; charset="utf-8")
- Dependencies.txt Edit (2.6 KiB, text/plain; charset="utf-8")
- IwConfig.txt Edit (508 bytes, text/plain; charset="utf-8")
- Lspci.txt Edit (9.9 KiB, text/plain; charset="utf-8")
- Lsusb.txt Edit (530 bytes, text/plain; charset="utf-8")
- ProcCpuinfo.txt Edit (3.7 KiB, text/plain; charset="utf-8")
- ProcEnviron.txt Edit (106 bytes, text/plain; charset="utf-8")
- ProcInterrupts.txt Edit (2.4 KiB, text/plain; charset="utf-8")
- ProcModules.txt Edit (3.3 KiB, text/plain; charset="utf-8")
- PulseList.txt Edit (16.3 KiB, text/plain; charset="utf-8")
- RfKill.txt Edit (190 bytes, text/plain; charset="utf-8")
- UdevDb.txt Edit (136.0 KiB, text/plain; charset="utf-8")
- UdevLog.txt Edit (317.1 KiB, text/plain; charset="utf-8")
- WifiSyslog.txt Edit (903.8 KiB, text/plain; charset="utf-8")
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Brad Figg (brad-figg) wrote : Status changed to Confirmed | #2 |
This change was made by a bot.
Changed in linux (Ubuntu): | |
status: | New → Confirmed |
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#96 |
*** Bug 57131 has been marked as a duplicate of this bug. ***
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#97 |
(In reply to comment #76)
> Created an attachment (id=99751) [details]
> Disable ACPI backlight for broken ThinkPads
>
> I'm attaching a new patch with a different take on this problem. It just
> disables the ACPI backlight control on these machines whenever the kernel has
> indicated Windows 8 compatibility via _OSI.
>
> Most machines should fall back to using a secondary backlight control, but
> it's
> possible that a few machines won't have another control. It's also likely
> that
> brightness changes on VTs using the hotkeys will be broken. In either of
> these
> cases it will be necessary to use acpi_osi="!Windows 2012", and I'd
> appreciate
> it if someone could test this case to verify the acpi_video backlight works
> as
> before with the new patch.
>
> Please give it a whirl and let me know your results. I've included quirks for
> every machine I'm aware of which is broken, but if I've missed any please let
> me know and include DMI information.
I test you patch on ThinkPad X230 (2320-5NG) and nothing changes
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#98 |
Created attachment 100281
acpidump from thinkpad x230 (2320-5NG)
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Joseph Salisbury (jsalisbury) wrote : Re: Acer V5-171 laptop: backlight cannot be adjusted unless passing acpi_backlight=vendor | #3 |
Would it be possible for you to test the latest upstream kernel? Refer to https:/
If this bug is fixed in the mainline kernel, please add the following tag 'kernel-
If the mainline kernel does not fix this bug, please add the tag: 'kernel-
If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".
Thanks in advance.
[0] http://
Changed in linux (Ubuntu): | |
importance: | Undecided → Medium |
status: | Confirmed → Incomplete |
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Alan Jenkins (aj504) wrote : | #4 |
Thanks! Booted vmlinuz-
Changed in linux (Ubuntu): | |
status: | Incomplete → Confirmed |
tags: | added: kernel-bug-exists-upstream |
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#99 |
I try to add acpi_osi="!Windows 2012", but backlight not working correctly.
Add acpi_osi=Linux acpi_backlight=
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#100 |
Did you removed the patch #76? The option acpi_osi="!Windows 2012" should work fine.
Anyway I just stayed with the patch "v4", which does the same.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#101 |
(In reply to comment #85)
> Did you removed the patch #76? The option acpi_osi="!Windows 2012" should
> work
> fine.
>
> Anyway I just stayed with the patch "v4", which does the same.
I tested option in vanilla kernel...
Patch v4 I will try to test tomorrow.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#102 |
(In reply to comment #76)
> Created an attachment (id=99751) [details]
> Disable ACPI backlight for broken ThinkPads
>
> I'm attaching a new patch with a different take on this problem. It just
> disables the ACPI backlight control on these machines whenever the kernel has
> indicated Windows 8 compatibility via _OSI.
>
> Most machines should fall back to using a secondary backlight control, but
> it's
> possible that a few machines won't have another control. It's also likely
> that
> brightness changes on VTs using the hotkeys will be broken. In either of
> these
> cases it will be necessary to use acpi_osi="!Windows 2012", and I'd
> appreciate
> it if someone could test this case to verify the acpi_video backlight works
> as
> before with the new patch.
>
> Please give it a whirl and let me know your results. I've included quirks for
> every machine I'm aware of which is broken, but if I've missed any please let
> me know and include DMI information.
Patch works to regulate backlight, but xbacklight always return 0.
# tree /sys/class/
/sys/class/
|-- intel_backlight -> ../../devices/
`-- thinkpad_screen -> ../../devices/
# xbacklight
0.000000
# cat /sys/class/
7
# cat /sys/class/
0
But real backlight is 100%.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#103 |
Hi All,
Matthew has proposed a patchset to solve this problem:
https:/
https:/
https:/
Please give it a test, thanks.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#104 |
(In reply to comment #88)
> Hi All,
>
> Matthew has proposed a patchset to solve this problem:
> https:/
> https:/
> https:/
>
> Please give it a test, thanks.
Yep. This patches fixes my problem.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#105 |
I've tried to apply the patchset to git master and it doesn't seem to completely fine on my ThinkPad x230.
Brightness keys still don't work on console on pure X. If a power manager is running (xfce4-
Here's some more info:
root@balvenie:~# dmesg |grep backlight
[ 32.283005] thinkpad_acpi: This ThinkPad has standard ACPI backlight brightness control, supported by the ACPI video driver
[ 32.288788] thinkpad_acpi: Standard ACPI backlight interface available, not loading native one
root@balvenie:~# dmesg |grep i915
[ 0.625098] i915 0000:00:02.0: enabling device (0006 -> 0007)
[ 0.625750] i915 0000:00:02.0: setting latency timer to 64
[ 0.638679] i915 0000:00:02.0: irq 43 for MSI/MSI-X
[ 0.738217] [drm] GMBUS [i915 gmbus dpb] timed out, falling back to bit banging on pin 5
[ 1.590831] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
[ 1.590833] i915 0000:00:02.0: registered panic notifier
[ 1.616220] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
tree /sys/class/
/sys/class/
`-- intel_backlight -> ../../devices/
root@balvenie:~# cat /sys/class/
4438
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#106 |
(In reply to comment #90)
> One things changes though, is that the
> lower brightness level really shuts the screen down.
That's because ACPI and the intel driver have different understandings what exactly 0 brightness is supposed to mean.
See the mail thread in [1] for some discussion around this. As KDE dims down to 0, it's probably even more noticable for KDE users. I sent a patch to them as well ([2]), but interest in merging it seems low.
[1] http://
[2] https:/
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#107 |
(In reply to comment #90)
> I've tried to apply the patchset to git master and it doesn't seem to
> completely fine on my ThinkPad x230.
>
> Brightness keys still don't work on console on pure X. If a power manager is
Right, we have no way to make it work I'm afraid. The current mechanism is to let intel_backlight handle the brightness change and ACPI video handle hotkey event delivery. So when the event is sent out, if no user space tool reacts to it, then nothing would happen.
> running (xfce4-
> I'm
I don't understand how v3.9 could work? Are you already using some xorg.conf to specify which backlight interface to use(i.e. intel_backlight in this case)?
> not sure it's really an improvement. One things changes though, is that the
> lower brightness level really shuts the screen down.
As Danny explained, this is the behavior of intel_backlight...
Thanks for testing out.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#108 |
(In reply to comment #92)
> (In reply to comment #90)
> > I've tried to apply the patchset to git master and it doesn't seem to
> > completely fine on my ThinkPad x230.
> >
> > Brightness keys still don't work on console on pure X. If a power manager
> is
>
> Right, we have no way to make it work I'm afraid. The current mechanism is to
> let intel_backlight handle the brightness change and ACPI video handle hotkey
> event delivery. So when the event is sent out, if no user space tool reacts
> to
> it, then nothing would happen.
Can't the acpi part handling the hotkey even pass the message to intel_backlight?
>
> > running (xfce4-
> I'm
>
> I don't understand how v3.9 could work? Are you already using some xorg.conf
> to
> specify which backlight interface to use(i.e. intel_backlight in this case)?
I'm not. I need to double check I'm not doing anything fancy. I tested using the Debian kernel so maybe there are some patches (although it seems unlikely).
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#109 |
(In reply to comment #93)
> (In reply to comment #92)
> > (In reply to comment #90)
> > > I've tried to apply the patchset to git master and it doesn't seem to
> > > completely fine on my ThinkPad x230.
> > >
> > > Brightness keys still don't work on console on pure X. If a power manager
> is
> >
> > Right, we have no way to make it work I'm afraid. The current mechanism is
> to
> > let intel_backlight handle the brightness change and ACPI video handle
> hotkey
> > event delivery. So when the event is sent out, if no user space tool reacts
> to
> > it, then nothing would happen.
>
> Can't the acpi part handling the hotkey even pass the message to
> intel_backlight?
I'll not do this decision making thing, and you are welcome to give your ideas in the mailing list on this topic:
https:/
> >
> > > running (xfce4-
> so I'm
> >
> > I don't understand how v3.9 could work? Are you already using some
> xorg.conf to
> > specify which backlight interface to use(i.e. intel_backlight in this
> case)?
>
> I'm not. I need to double check I'm not doing anything fancy. I tested using
> the Debian kernel so maybe there are some patches (although it seems
> unlikely).
If no changes are made, the ACPI video backlight interface will be picked up by user space and since it is broken, I don't see why 3.9 would work...Did you add any kernel command line like the !Windows 2012?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#110 |
(In reply to comment #94)
> (In reply to comment #93)
> > Can't the acpi part handling the hotkey even pass the message to
> > intel_backlight?
>
> I'll not do this decision making thing, and you are welcome to give your
> ideas
> in the mailing list on this topic:
> https:/
Ok, will try to write to the thread.
> If no changes are made, the ACPI video backlight interface will be picked up
> by
> user space and since it is broken, I don't see why 3.9 would work...Did you
> add
> any kernel command line like the !Windows 2012?
Ok, I've just tried on vanilla 3.9.7 (will attach dmesg and config just in case). Using /sys/class/
Not to sure what xfpm uses, I can check if needed.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#111 |
Created attachment 105621
dmesg with vanilla 3.9.7
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#112 |
Created attachment 105631
config for 3.9.7
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#113 |
(In reply to comment #95)
> (In reply to comment #94)
> > (In reply to comment #93)
> > > Can't the acpi part handling the hotkey even pass the message to
> > > intel_backlight?
> >
> > I'll not do this decision making thing, and you are welcome to give your
> ideas
> > in the mailing list on this topic:
> > https:/
>
> Ok, will try to write to the thread.
>
> > If no changes are made, the ACPI video backlight interface will be picked
> up by
> > user space and since it is broken, I don't see why 3.9 would work...Did you
> add
> > any kernel command line like the !Windows 2012?
>
> Ok, I've just tried on vanilla 3.9.7 (will attach dmesg and config just in
> case). Using /sys/class/
> /s/c/b/
>
> Not to sure what xfpm uses, I can check if needed.
1. Need 3.10 kernel
2. /sys/class/
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#114 |
(In reply to comment #98)
> 1. Need 3.10 kernel
> 2. /sys/class/
I think you missed something. The point was to say, using 3.9.7, acpi_video *does* work on my x230.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#115 |
(In reply to comment #99)
> (In reply to comment #98)
> > 1. Need 3.10 kernel
> > 2. /sys/class/
>
> I think you missed something. The point was to say, using 3.9.7, acpi_video
> *does* work on my x230.
Provide
# cat /sys/class/
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#116 |
grep . /sys/class/
/sys/class/
/sys/class/
/sys/class/
egrep: /sys/class/
/sys/class/
egrep: /sys/class/
egrep: /sys/class/
/sys/class/
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#117 |
(In reply to comment #101)
> grep . /sys/class/
> /sys/class/
> /sys/class/
> /sys/class/
> egrep: /sys/class/
> /sys/class/
> egrep: /sys/class/
> egrep: /sys/class/
> /sys/class/
yep. you have this bug.
>max_brightness:100
not all values work. I'm right ?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#118 |
(In reply to comment #102)
> (In reply to comment #101)
> > grep . /sys/class/
> > /sys/class/
> > /sys/class/
> > /sys/class/
> > egrep: /sys/class/
> > /sys/class/
> > egrep: /sys/class/
> > egrep: /sys/class/
> > /sys/class/
> yep. you have this bug.
> >max_brightness:100
> not all values work. I'm right ?
Yes. Working values are:
- every 5 from 5 to 70
- every 10 from 70 to 100
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#119 |
(In reply to comment #103)
> (In reply to comment #102)
> > (In reply to comment #101)
> > > grep . /sys/class/
> > > /sys/class/
> > > /sys/class/
> > > /sys/class/
> > > egrep: /sys/class/
> > > /sys/class/
> > > egrep: /sys/class/
> > > egrep: /sys/class/
> > > /sys/class/
> > yep. you have this bug.
> > >max_brightness:100
> > not all values work. I'm right ?
>
> Yes. Working values are:
>
> - every 5 from 5 to 70
> - every 10 from 70 to 100
Then this is a problem for people relying on GUI to do the automatic brightness adjustment, it can prevent brightness getting downwards.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#120 |
(In reply to comment #104)
> Then this is a problem for people relying on GUI to do the automatic
> brightness
> adjustment, it can prevent brightness getting downwards.
Well, that's why my position is that the kernel should handle everything itself (but I need to raise that on the mailing list)
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#121 |
I'm a little bit out-of-date, do I sume up correctly?
The past:
ACPI in-kernel handles hotkeys and passes it events to ACPI_BACKLIGHT (other drivers didn't work in this way) or userspace
The future:
ACPI in-kernel handles hotkeys and passes it events to userspace, which passes it to $RANDOM_DRIVER
If that is correct: Could probably Systemd provide a hook for brightness, similiar to HANDLELIDSWITCH?
see here: https:/
NAME could be:
HANDLEBRIGHTNESS (without the extension KEY or KEYS, maybe it is a sensor or whatever...)
This would allow for a environment agnositic approach, i.e. it works out-of-the box with the TTY, X11, Wayland and the different desktops. The backlight brigthness would be modifiable with the hotkeys always. If GNOME, KDE or XFCE handles the hotkeys itself, it could "inhibit" the HANDLE and uses it own facilities for power-management.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#122 |
Hi Peter,
(In reply to comment #106)
> I'm a little bit out-of-date, do I sume up correctly?
Yes, almost :-)
>
> The past:
> ACPI in-kernel handles hotkeys and passes it events to ACPI_BACKLIGHT (other
> drivers didn't work in this way) or userspace
The event is always sent to user space no matter if ACPI video driver will handle the event or not. So if ACPI video driver handles this event and user space also handles this event, the brightness level will go more steps on one hotkey press.
> The future:
> ACPI in-kernel handles hotkeys and passes it events to userspace, which
> passes
> it to $RANDOM_DRIVER
Yes, at least this is the case here. Since ACPI video's backlight interface is removed, the video driver will not handle brightness change on receiving an event.
>
> If that is correct: Could probably Systemd provide a hook for brightness,
> similiar to HANDLELIDSWITCH?
> see here: https:/
>
> NAME could be:
> HANDLEBRIGHTNESS (without the extension KEY or KEYS, maybe it is a sensor or
> whatever...)
>
> This would allow for a environment agnositic approach, i.e. it works
> out-of-the
> box with the TTY, X11, Wayland and the different desktops. The backlight
> brigthness would be modifiable with the hotkeys always. If GNOME, KDE or XFCE
> handles the hotkeys itself, it could "inhibit" the HANDLE and uses it own
> facilities for power-management.
I think this is a good idea.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#123 |
Hello Aaron!
Thank you for your help and clarification!
I've proposed this to Systemd:
https:/
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#124 |
Hi,
Rafael has revised the patches and now the following two patches are available:
https:/
https:/
Please give it a test, thanks. Hopefully, this is the last update to this problem.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#125 |
Should we apply against 3.10 or mainline?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#126 |
3.10 should be fine although they are against the mainline technically.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#127 |
(In reply to Aaron Lu from comment #109)
> Hi,
>
> Rafael has revised the patches and now the following two patches are
> available:
> https:/
> https:/
>
> Please give it a test, thanks. Hopefully, this is the last update to this
> problem.
Ok, so I've tried those patches on top of 3.10.1 and it seems to work just fine for me. It seems that I have brightness keys working as soon as i915 is loaded (so even before X is even started, not to mention any desktop environment power management daemon).
In /sys/class/
grep -r . /sys/class/
/sys/class/
/sys/class/
/sys/class/
/sys/class/
/sys/class/
/sys/class/
/sys/class/
grep: /sys/class/
/sys/class/
/sys/class/
/sys/class/
/sys/class/
/sys/class/
/sys/class/
Although I now have warnings from thinkpad_acpi about unhandled key events:
Jul 16 13:54:36 balvenie kernel: [ 419.375753] thinkpad_acpi: unknown possible thermal alarm or keyboard event received
Jul 16 13:54:36 balvenie kernel: [ 419.375756] thinkpad_acpi: unhandled HKEY event 0x6050
Jul 16 13:54:36 balvenie kernel: [ 419.375758] thinkpad_acpi: please report the conditions when this event happened to <email address hidden>
each time I press one button. As far as I can tell they're harmless but Henrique would be better placed than me to assess that.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#128 |
Gosh, I wonder what's going on here. Henrique?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#129 |
So no "unhanded key events" messages with 3.10.1 but after applying the two patches on top of v3.10.1, they appeared, right?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#130 |
That means _BCL was never called, so the firmware is handling the brightness changes totally internally, and not reporting the keypress events to acpi video at all. See the message linked in Comment #77, excerpted here:
> When a brightness key is pressed:
> If the key is unmasked:
> Report the key to thinkpad-acpi
> If _BCL has been called:
> Report the key (video event) to acpi video
> Else:
> Adjust the brightness
> Report event 0x6050 to thinkpad-acpi
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#131 |
(In reply to Aaron Lu from comment #114)
> So no "unhanded key events" messages with 3.10.1 but after applying the two
> patches on top of v3.10.1, they appeared, right?
I didn't try with 3.10.1 without patch yet, i'll do that now
(In reply to Ben Jencks from comment #115)
> That means _BCL was never called, so the firmware is handling the brightness
> changes totally internally, and not reporting the keypress events to acpi
> video at all. See the message linked in Comment #77, excerpted here:
>
> > When a brightness key is pressed:
> > If the key is unmasked:
> > Report the key to thinkpad-acpi
> > If _BCL has been called:
> > Report the key (video event) to acpi video
> > Else:
> > Adjust the brightness
> > Report event 0x6050 to thinkpad-acpi
Oh, then I guess it's not good for you guys? Having it handled by the firmware is fine by me though :)
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#132 |
(In reply to Yves-Alexis Perez from comment #112)
> (In reply to Aaron Lu from comment #109)
> Although I now have warnings from thinkpad_acpi about unhandled key events:
>
> Jul 16 13:54:36 balvenie kernel: [ 419.375753] thinkpad_acpi: unknown
> possible thermal alarm or keyboard event received
> Jul 16 13:54:36 balvenie kernel: [ 419.375756] thinkpad_acpi: unhandled
> HKEY event 0x6050
> Jul 16 13:54:36 balvenie kernel: [ 419.375758] thinkpad_acpi: please report
> the conditions when this event happened to
> <email address hidden>
>
> each time I press one button. As far as I can tell they're harmless but
> Henrique would be better placed than me to assess that.
Does this additional patch from Matthew Garrett help:
http://
?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#133 |
On Tue, 16 Jul 2013, <email address hidden> wrote:
> Although I now have warnings from thinkpad_acpi about unhandled key events:
>
> Jul 16 13:54:36 balvenie kernel: [ 419.375753] thinkpad_acpi: unknown
> possible
> thermal alarm or keyboard event received
> Jul 16 13:54:36 balvenie kernel: [ 419.375756] thinkpad_acpi: unhandled HKEY
> event 0x6050
> Jul 16 13:54:36 balvenie kernel: [ 419.375758] thinkpad_acpi: please report
> the conditions when this event happened to
> <email address hidden>
>
> each time I press one button. As far as I can tell they're harmless but
> Henrique would be better placed than me to assess that.
They're utterly harmless.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#134 |
OK, good to know, thanks.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#135 |
(In reply to Ben Jencks from comment #115)
> That means _BCL was never called, so the firmware is handling the brightness
> changes totally internally, and not reporting the keypress events to acpi
> video at all.
I don't get this, isn't the following code path has a call to _BCL?
thinkpad_
-> tpacpi_
-> tpacpi_
-> tpacpi_
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#136 |
The tpacpi_
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#137 |
Oh, and I can confirm proper behavior (intel_backlight present, acpi_video absent, hotkeys handled by userspace through intel_backlight) with the two patchwork links above plus Matthew's additional patch.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#138 |
(In reply to Rafael J. Wysocki from comment #117)
> (In reply to Yves-Alexis Perez from comment #112)
> > (In reply to Aaron Lu from comment #109)
>
> > Although I now have warnings from thinkpad_acpi about unhandled key events:
> >
> > Jul 16 13:54:36 balvenie kernel: [ 419.375753] thinkpad_acpi: unknown
> > possible thermal alarm or keyboard event received
> > Jul 16 13:54:36 balvenie kernel: [ 419.375756] thinkpad_acpi: unhandled
> > HKEY event 0x6050
> > Jul 16 13:54:36 balvenie kernel: [ 419.375758] thinkpad_acpi: please
> report
> > the conditions when this event happened to
> > <email address hidden>
> >
> > each time I press one button. As far as I can tell they're harmless but
> > Henrique would be better placed than me to assess that.
>
> Does this additional patch from Matthew Garrett help:
>
> http://
>
> ?
Ok, besides the fact that I guess it'll break (as intended) backlight keys without userspace daemon, it actually breaks more than that. It's not a panic as far as I can tell, however the system is locked up and I can't do anything. It can't save the logs in syslog so I can't copy/paste. I've tried pstore but nothing shows up there either. I've taken a snapshot with my phone but I'm not sure it's really readable. As I can't upload the file (even though it's under size limit), it's available there: http://
After that screen there's some more logs printed but I can't really take everything.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#139 |
Please try the following patch. After Matthew's patch, the device->brightness is not NULL anymore, so a NULL pointer access occured in acpi_video_
diff --git a/drivers/
index 95fa76e..4a1bb47 100644
--- a/drivers/
+++ b/drivers/
@@ -1332,7 +1332,7 @@ acpi_video_
int result = -EINVAL;
/* no warning message if acpi_backlight=
- if (!acpi_
+ if (!acpi_
if (!device-
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#140 |
OK, so we need to rework this again.
I think acpi_video_
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#141 |
(In reply to Ben Jencks from comment #121)
> The tpacpi_
> tpacpi_
I don't see why it failed...There are at least two ACPI devices that should have VIDEO HID: \_SB.PCI0.VID and \_SB.PCI0.PEG.VID. Don't know what's going wrong.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#142 |
Created attachment 106901
ACPI / video: Remove brightness object if we're not going to use it
Yves-Alexis, can you please try this patch on top of the Matthew's one?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#143 |
(In reply to Rafael J. Wysocki from comment #127)
> Created attachment 106901 [details]
> ACPI / video: Remove brightness object if we're not going to use it
>
> Yves-Alexis, can you please try this patch on top of the Matthew's one?
I'm not too sure here. Should I try:
- 3.10
+ two patches from comment #109
+ patch from comment #124
+ patch from comment #127
?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#144 |
I think Rafael means:
- 3.10
+ two patches from comment #109
+ patch from Matthew: http://
+ patch from comment #127
Thanks.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#145 |
(In reply to Aaron Lu from comment #129)
> I think Rafael means:
> - 3.10
> + two patches from comment #109
> + patch from Matthew: http://
> + patch from comment #127
> Thanks.
Ok, with those, I don't have the recursive fault nor the thinkpad-acpi warnings.
I get the “crippled” behavior: no brightness keys without userspace daemon. With a userspace daemon (xfce4-
I still get a warning in the logs though:
Jul 17 15:16:51 balvenie kernel: [ 182.606930] ACPI: Failed to switch the brightness
which I guess is expected since ACPI doesn't handle the brightness.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#146 |
With an additional patch in comment #124, I think that warning will go away. Possible to give it a test?
Rafael, what do you think of the patch in comment #124? If you think it is worth, it can be merged into your patch which introduced the acpi_video_
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#147 |
Yeah, makes sense. I'll fold in into https:/
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#148 |
Patches in Linus' tree.
commit 8c5bd7adb2ce47e
Author: Rafael J. Wysocki <email address hidden>
Date: Thu Jul 18 02:08:06 2013 +0200
ACPI / video / i915: No ACPI backlight if firmware expects Windows 8
commit c04c697cf1fe8f0
Author: Matthew Garrett <email address hidden>
Date: Tue Jul 16 17:08:16 2013 +0000
ACPI / video: Always call acpi_video_
commit 242b2287cd7f275
Author: Aaron Lu <email address hidden>
Date: Tue Jul 2 21:59:10 2013 +0800
ACPICA: expose OSI version
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#149 |
Alternatively, I suppose by using the Xorg.conf to specify backlight interface should also work(for GUI environment only)?
$ cat /etc/Xorg/Xorg.conf
Section "Device"
Option "Backlight" "intel_backlight"
Identifier "Card0"
Driver "intel"
BusID "PCI:0:2:0"
EndSection
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#150 |
Commit 8c5bd7adb2ce47e
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#151 |
I think it's pretty clear we need to go for the initial approach right now (blacklisting machines to boot with !Windows 2012).
It has been several months that backlight is broken, and there's no point in waiting many more for the "perfect" solution.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#152 |
I created a new bug report (bug 60682) with a blacklist patch, not only Thinkpads are affected by this.
This is the list I've gathered so far:
* ASUS Zenbook Prime UX31A
* ASUS N56VZ
* Lenovo ThinkPad L430
* Lenovo ThinkPad T430s
* Lenovo ThinkPad T530
* Lenovo ThinkPad W530
* Lenovo ThinkPad X1 Carbon
* Lenovo ThinkPad X230
* Lenovo ThinkPad Edge E330
If your machine works correctly with acpi_osi="!Windows 2012", and doesn't otherwise, comment with the name of the laptop, plus the output of this command:
% dmesg | grep DMI
Add a comment in bug 60682.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
penalvch (penalvch) wrote : | #5 |
Alan Jenkins, as per http://
If not, could you please both specify what happened, and provide the output of the following terminal command:
sudo dmidecode -s bios-version && sudo dmidecode -s bios-release-date
Thank you for your understanding.
tags: |
added: bios-outdated-2.15 kernel-bug-exists-upstream-v3.9 needs-upstream-testing removed: kernel-bug-exists-upstream |
summary: |
- Acer V5-171 laptop: backlight cannot be adjusted unless passing + [Acer Aspire V5-171] Backlight cannot be adjusted unless passing acpi_backlight=vendor |
Changed in linux (Ubuntu): | |
status: | Confirmed → Incomplete |
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Alan Jenkins (aj504) wrote : | #6 |
Sorry I've been neglecting this (and my original report may have fluffed the detail).
This is Windows 8 hardware. Manually poking the intel_backlight driver in sysfs (echo 100 | sudo tee /sys/class/
http://
(I first saw this referred to when it was reverted in 3.11-rc3. Linus' release announcement says "But never fear, we have top people looking at it").
That should be nice & easy to test compared to the _other_ bug I'm tracking on this laptop. So I'll see if I can get there & feedback to upstream.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Alan Jenkins (aj504) wrote : | #7 |
That is, I'm hoping the brightness keys will work (e.g. under KDE) when using the commit "ACPI / video / i915: No ACPI backlight if firmware expects Windows 8". With the non-working acpi_backlight removed, KDE would use the working intel_backlight instead.
tags: | added: regression-potential |
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Alan Jenkins (aj504) wrote : | #8 |
Sorry, I don't think the backlight problem on the V5-171 is a regression. I've never had it work as expected.
I've now tried the acpi_osi="!Windows 2012" test, to see if this machine could be added to the temporary blacklist. I.e. whether my bug was a regression caused when Linux added the "Windows 2012" OSI string.[1] Unfortunately that boot option didn't help.
[1] https:/
The result from testing v3.11-rc2 is that it does fix the problem. And as expected, the revert in v3.11-rc3 breaks it again.
To answer the question about firmware upgrades, I'm not going to try that unless it helps upstream. It's not worth reflashing "at my own risk" just to avoid passing acpi_backlight=
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#153 |
FYI, patches posted to:
https:/
I have a branch for it:
https:/
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#154 |
Maybe I can test the patches within the next days. But I can't promise. Is it possible, that we can see this patches in kernel 3.13? Merge window for 3.12 already passed.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#155 |
(In reply to Peter Weber from comment #139)
> Maybe I can test the patches within the next days. But I can't promise. Is
> it possible, that we can see this patches in kernel 3.13? Merge window for
> 3.12 already passed.
That depends on if it causes regressions for other working systems.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#156 |
Thanks. Can you add the patches to this bug as attachment?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#157 |
Created attachment 111191
ACPI video backlight win8 patches
v5 of the patchset that is sent to LKML:
http://
Please give it a test and if the video.use_
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#158 |
Created attachment 111581
dmidecode video.use_
kernel 3.12.0-rc5 with patch_set_v5
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#159 |
Created attachment 111591
dmidecode video.use_
kernel 3.12.0-rc5 with patch_set_v5
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#160 |
Created attachment 111601
kernel config, kernel 3.12.0-rc5 with patch_set_v5
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#161 |
Thanks for your work on this Aaron! I've upgraded to kernel 3.12.0-rc5 and applied the patches. When I set video.use_
* everything works fine!
* /sys/class/
* there seem to be 21 brightness-levels available with gnome-power-manager
* the lowest level turns the backlight completely off (this doesn't happend with acpi_osi="!Windows 2012"), is this intentional?
* as already expected it is not longer possible to tune the brightness-level with the Fn+Keys, while working on a virtual-terminal
* thinkpad_acpi seem unhappy about the brightness-
> thinkpad_acpi: http://
> thinkpad_acpi: Unsupported brightness interface, please contact
> <email address hidden>
Looks good.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#162 |
Created attachment 111611
dmesg with complain from thinkpad_acpi about brightness interface
unsupported brightness interface
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#163 |
Peter: Can you change this bug from NEEDINFO to UNCONFIRMED or CONFIRMED? I don't know for sure; but, due to the high traffic, the assigned person might miss your responses if the bug doesn't appear back in his list. It might be the possibility that only the assigned person can change, in which case never mind...
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#164 |
Ohhhh. I thought the active developers change that if appropriate. I changed the status to VERIFIED, because there is no CONFIRMED available.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#165 |
Eh, VERIFIED is usually a status to mark it resolved and verified by QA; you'll not want to pick that one, see https:/
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#166 |
The naming is pretty weird, isn't it? I don't have the canconfirm-
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#167 |
Thanks Peter for the test. If you show me your dmi info, I can add your system into a list so that the mentioned param will be automatically set for you.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#168 |
I can confirm that I also need video.use_
Handle 0x000F, DMI type 1, 27 bytes
System Information
Product Name: 2352CTO
Version: ThinkPad T430s
Wake-up Type: Power Switch
SKU Number: LENOVO_MT_2352
Family: ThinkPad T430s
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#169 |
Created attachment 111821
Add Thinkpad T430s into the list
For Thinkpad T430s, apply on top of the existing v5 patchset.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#170 |
(In reply to Aaron Lu from comment #152)
> Thanks Peter for the test. If you show me your dmi info, I can add your
> system into a list so that the mentioned param will be automatically set for
> you.
Theodore posted it in meanwhile :-)
You can find the complete output in comment 143. I will add the patch on top of v5 within the next days, but doesn't expect any surprise.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#171 |
Created attachment 112141
fixed typo, ThinkPad is written in camelCase, Thinkpad -> ThinkPad
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#172 |
Created attachment 112151
fixed typo, Thinkpad -> ThinkPad
ThinkPad brand name is written in CamelCaseas, as reported by "dmidecode -t 1".
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#173 |
Great! I'm myself not able to type CamelCase without a typo. To be clear, is necessary to change it to "ThinkPad" to make it working!
By the way, let me be pedantic :-)
0003-ACPI-
Line 54:
- * For Windows 8 systems: if set ture and the GPU driver has
+ * For Windows 8 systems: if set true and the GPU driver has
Thank you! Good night!
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#174 |
I tried the v5 patchset on 3.12.0-rc5 on my Lenovo Yoga 13, and video.use_
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#175 |
*** Bug 63811 has been marked as a duplicate of this bug. ***
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#176 |
*** Bug 67031 has been marked as a duplicate of this bug. ***
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#177 |
*** Bug 68751 has been marked as a duplicate of this bug. ***
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#178 |
*** Bug 62941 has been marked as a duplicate of this bug. ***
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#179 |
commit 1811fcb029fa3ec
Author: Aaron Lu <email address hidden>
Date: Tue Feb 18 13:54:20 2014 +0800
ACPI / video: Add systems that should favour native backlight interface
has entered Rafael's linux-next tree.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#180 |
Hi,
Thinkpad T430 here (without the s), I'm using linux 3.13.4 and systemd 208 from arch linux booting in bios mode with the last bios update (2.62).
The bug seems the same as for T430s and I can "fix" it with acpi_osi='!Windows 2012' or using video.use_
It works kinda well with video.use_
[ 9.226063] thinkpad_acpi: Unsupported brightness interface, please contact <email address hidden>
System Information
Product Name: 2349KDG
Version: ThinkPad T430
(...)
Wake-up Type: Power Switch
SKU Number: LENOVO_MT_2349
Family: ThinkPad T430
It is because of so many levels of backlight that I have in KDE this behavior switching brightness with the keys:
from 0 to 100: 0-10-20-
from 100 to 0: 100-89-79-69...etc.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#181 |
(In reply to edm from comment #165)
> Hi,
> Thinkpad T430 here (without the s), I'm using linux 3.13.4 and systemd 208
> from arch linux booting in bios mode with the last bios update (2.62).
>
> The bug seems the same as for T430s and I can "fix" it with
> acpi_osi='!Windows 2012' or using video.use_
> command line in grub.
>
> It works kinda well with video.use_
> 4437 level of brightness in /sys/class/
> reported by Weber, systemd complains about this:
>
> [ 9.226063] thinkpad_acpi: Unsupported brightness interface, please
> contact <email address hidden>
This is harmless, I'll send a patch to fix this.
>
>
> System Information
> Manufacturer: LENOVO
> Product Name: 2349KDG
> Version: ThinkPad T430
> (...)
> Wake-up Type: Power Switch
> SKU Number: LENOVO_MT_2349
> Family: ThinkPad T430
>
> It is because of so many levels of backlight that I have in KDE this
> behavior switching brightness with the keys:
> from 0 to 100: 0-10-20-
> from 100 to 0: 100-89-79-69...etc.
I'll prepare a new patch for your laptop later(together with some other model once that model is confirmed to work well with video.use_
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#182 |
commit 0e9f81d3b7cd064
Author: Aaron Lu <email address hidden>
Date: Tue Feb 18 13:54:20 2014 +0800
ACPI / video: Add systems that should favour native backlight interface
entered Linus' tree as v3.14 material.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#183 |
BTW, edm, please also attach your acpidump here, thanks.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#184 |
Created attachment 127991
acpidump T430
Output of
# acpidump > acpidump-T430.txt
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#185 |
Just a stupid question: does it make any difference doing "acpidump" with or without acpi_osi="!Windows 2012" as boot option?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#186 |
(In reply to edm from comment #170)
> Just a stupid question: does it make any difference doing "acpidump" with or
> without acpi_osi="!Windows 2012" as boot option?
No difference.
I'll add your system into the table shortly, sorry for the long delay.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#187 |
Created attachment 131691
acpi dump for ThinkPad Helix (UEFI)
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#188 |
Created attachment 131701
dmidecode dump for ThinkPad Helix
That should be all the information you need on the Helix regarding the patch I submitted ( https:/
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Jonatã Bolzan Loss (jbopen) wrote : | #9 |
Bug still present in Ubuntu 14.04
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
penalvch (penalvch) wrote : | #10 |
jonata, thank you for your comment. So your hardware and problem may be tracked, could you please file a new report with Ubuntu by executing the following in a terminal while booted into a Ubuntu repository kernel (not a mainline one) via:
ubuntu-bug linux
For more on this, please read the official Ubuntu documentation:
Ubuntu Bug Control and Ubuntu Bug Squad: https:/
Ubuntu Kernel Team: https:/
Ubuntu Community: https:/
When opening up the new report, please feel free to subscribe me to it.
Thank you for your understanding.
Helpful bug reporting tips:
https:/
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#189 |
(In reply to Aaron Lu from comment #171)
> (In reply to edm from comment #170)
> > Just a stupid question: does it make any difference doing "acpidump" with
> or
> > without acpi_osi="!Windows 2012" as boot option?
>
> No difference.
> I'll add your system into the table shortly, sorry for the long delay.
Matthew sent out a patch to enable native backlight control interface by default for win8 systems so that we do not need to add more systems into the DMI table:
http://
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Nils Sabelstrom (nilssab) wrote : | #11 |
Bug can be confirmed present in 14.04 with standard LTS kernel and 3.15rc2 kernel from ubuntu mainline kernel-ppa, daily build for april 24th (latest marked trusty at the time, now nonexistent, should I try a newer kernel even if marked utopic?)
I tried upgrading to bios version 2.21, but there was only an installer for win 8, and using it removes the ubuntu boot loader. Will post after getting my computer to boot ubuntu again.. (I would not recommend users without good knowledge of how UEFI bootloaders work to try upgrading the bios)
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Nils Sabelstrom (nilssab) wrote : | #13 |
will do, as soon as I get it booting into ubuntu again.
Apparently update-grub (or rather grub-probe) doesn't work when chrooting into a root partition if it's btrfs, so I'm gonna try booting through a efi booter from another computer running the same kernelversion of 14.04..
I'm quite pissed at myself for not backing up the EFI partition before doing a BIOS update from windows... <_<
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Nils Sabelstrom (nilssab) wrote : | #14 |
added a duplicate bug generated by ubuntu-bug.
is there a way to make it upload the information to a specific bug and not make a new bug entry? or is it fine to just make duplicates? should I also make one using the newest kernel?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#190 |
Created attachment 137791
Dell XPS13 9333 acpidump
I attached the acpidump of my Dell XPS13 9333.
If video.use_
With video.use_
System Information
Product Name: XPS13 9333
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#191 |
Created attachment 140631
ThinkPad T530 use native backlight patch
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#192 |
The backlight keys do not work properly with kernel 3.15.1 and ThinkPad T530 (with Intel integrated graphics). Only 2 brightness levels are available.
I noticed that using native backlight option for Thinkpad T530 fixes the issue:
see attachment 140631
After applying the above patch 11 brightness levels + blank can be set (I am using an Xfce 4.10 desktop).
Weirdly, in pre 3.15 kernel versions adding the use native backlight option caused my monitor to become unresponsive (stay blank) after a screen lock followed by a suspend screen. I no longer get that behavior with kernel version 3.15.1. Should you need any more information I can happily provide it.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#193 |
So I just got the 3.16 kernel with the changes for all Windows 8 laptops.
And while I bought this laptop (Thinkpad x201s) in 2010, it seems a BIOS update added the “support” for Windows 8 (at least that's a guess from http://
So this laptop where brightness keys where working perfectly using ACPI, has now the same issue, and I need to have something in userspace doing the job.
That's really a regression for me.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#194 |
Hi Perez,
I believe commit 5f24079b021cd31
commit 5f24079b021cd31
Author: Hans de Goede <email address hidden>
Date: Thu Aug 28 10:20:46 2014 +0200
ACPI / video: Add a disable_
Some laptops have a working acpi_video backlight control, and using native
backlight on these causes a regression where backlight control does not work
when userspace is not handling brightness key events. Disable native_backlight
on these to fix this.
Link: https:/
Reported-
Cc: 3.16+ <email address hidden> # 3.16+
Signed-off-by: Hans de Goede <email address hidden>
Signed-off-by: Rafael J. Wysocki <email address hidden>
Feel free to submit a patch to add your model into the video_dmi_table to disable native backlight control.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#195 |
(In reply to Aaron Lu from comment #179)
> Hi Perez,
>
> I believe commit 5f24079b021cd31
> such problems:
>
> commit 5f24079b021cd31
> Author: Hans de Goede <email address hidden>
> Date: Thu Aug 28 10:20:46 2014 +0200
>
> ACPI / video: Add a disable_
>
> Some laptops have a working acpi_video backlight control, and using
> native
> backlight on these causes a regression where backlight control does not
> work
> when userspace is not handling brightness key events. Disable
> native_backlight
> on these to fix this.
>
> Link: https:/
> Reported-
> Cc: 3.16+ <email address hidden> # 3.16+
> Signed-off-by: Hans de Goede <email address hidden>
> Signed-off-by: Rafael J. Wysocki <email address hidden>
>
> Feel free to submit a patch to add your model into the video_dmi_table to
> disable native backlight control.
Thanks. So the “DMI table” approach was considered bad because not sustainable for this bug, but ok for bug #81691 ?
Anyway, will provide the correct DMI information on that bug.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#196 |
(In reply to Yves-Alexis Perez from comment #180)
> (In reply to Aaron Lu from comment #179)
> > Hi Perez,
> >
> > I believe commit 5f24079b021cd31
> > such problems:
> >
> > commit 5f24079b021cd31
> > Author: Hans de Goede <email address hidden>
> > Date: Thu Aug 28 10:20:46 2014 +0200
> >
> > ACPI / video: Add a disable_
> >
> > Some laptops have a working acpi_video backlight control, and using
> > native
> > backlight on these causes a regression where backlight control does not
> > work
> > when userspace is not handling brightness key events. Disable
> > native_backlight
> > on these to fix this.
> >
> > Link: https:/
> > Reported-
> > Cc: 3.16+ <email address hidden> # 3.16+
> > Signed-off-by: Hans de Goede <email address hidden>
> > Signed-off-by: Rafael J. Wysocki <email address hidden>
> >
> > Feel free to submit a patch to add your model into the video_dmi_table to
> > disable native backlight control.
>
> Thanks. So the “DMI table” approach was considered bad because not
> sustainable for this bug, but ok for bug #81691 ?
The systems that claim to be Win8 but have a working ACPI video interface are supposed to be not common(hopefully this is true), so should be OK to keep a DMI table for them. While the systems that claim to be Win8 and don't have a working ACPI video interface are supposed to be the common case, so keeping a DMI table for all of them is not feasible.
>
> Anyway, will provide the correct DMI information on that bug.
OK, thanks.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#197 |
With this patch (not sure yet whether it's relevant) in place:
... http://
diff --git a/gdb/testsuite
Exp https:/
index a2cc80f28d.
--- a/gdb/testsuite
+++ b/gdb/testsuite
@@ -451,8 +451,10 @@ proc gdbserver_exit { is_mi } { https:/
# We use expect rather than gdb_expect because
# we want to suppress printing exception messages, otherwise, http://
# remote_expect, invoked by gdb_expect, prints the exceptions.
+ set read_prompt 0
expect { http://
-i "$gdb_spawn_id" -re "$gdb_prompt $" {
+ set read_prompt 1 http://
}
-i "$server_spawn_id" eof { http://
@@ -463,6 +465,7 @@ proc gdbserver_exit { is_mi } {
}
}
+ gdb_assert {$read_prompt}
}
} http://
close_
...
and running in parallel with:
...
$ stress -c 5 http://
...
I ran into:
...
(gdb) PASS: gdb.multi/
Remote debugging from host ::1, port 34088^M
Process build/gdb/
monitor exit^M
(gdb) Killing process(es): 8649^M http://
#9 0x16a2c57 in pop_all_
#10 0x1442749 in remote_
#11 0x1458c16 in remote_
#12 0x145b25b in remote_
Changed in linux: | |
importance: | Unknown → Medium |
status: | Unknown → Fix Released |
Created attachment 88171
config of kernel 3.7.0-rc7
Hello!
The backlight keys (Fn+F8, Fn+F9) stopped working with Kernel 3.7.0-rc7. It works with the current stable Kernel 3.6.8. I can still change the backlight brightness via "System Settings" > "Brightness & Lock" in GNOME. I can't see any message about not working keys in dmesg or the syslog.
I should note, that the brightness- indicator of GNOME shows if I press one of the keys and it moves the progress-bar a ittle bit. After I changedthe brigthness via "System Settings" it is possible to use the keys to change the brightness over a wider range, but not the complete range. Seems to be some side effect.
Maximal movement of of brightness, visuallay:
Default:
[ x x x x x x x - ]
After I changed the brightness to the middle, via "System Settings":
[ x x - - - - x x ]
Sorry for the weird report.
Thank you.