Created attachment 125091 [details] acpidump Backlit hotkays do not work on Asus UX302LA until "acpi_osi=" (acpi_osi without arguments). Probably it affects more then just backlight, for example blank screen issue. according to this part: Method (_INI, 0, NotSerialized) // _INI: Initialize { Store (0x07DC, OSYS) If (CondRefOf (\_OSI, Local0)) { If (_OSI ("Linux")) ... If (_OSI ("Windows 2012")) { Store (0x07DC, OSYS) } If (_OSI ("Windows 2013")) { Store (0x07DD, OSYS) } ... setting osi to NULL should be same as setting it to "Windows 2012", but for some reasons acpi_osi="Windows 2012" didn't worked for me. In both cases ACPI video driver doing the job, so i assume. this driver has some windows_8 check which is not triggered by osi=NULL.
Do I understand correctly that without any backlight related kernel cmdline options, on the v3.14 kernel, the backlight hotkey doesn't work under a GUI environment? If so, does manually echo some values to /sys/class/backlight/acpi_video0/brightness work?
(In reply to Aaron Lu from comment #1) > Do I understand correctly that without any backlight related kernel cmdline > options, on the v3.14 kernel, the backlight hotkey doesn't work under a GUI > environment? yes > If so, does manually echo some values to > /sys/class/backlight/acpi_video0/brightness work? yes, it is working.
Hm.. should it be controlled by some user space program?
(In reply to Oleksij Rempel from comment #3) > Hm.. should it be controlled by some user space program? Yes, normally your GUI should handle that. You are using a GUI, right?
Please run acpi_listen and then press the hotkey, let's see if the event is actually omitted.
I run Ubuntu 14.04 with Unity. (In reply to Aaron Lu from comment #5) > Please run acpi_listen and then press the hotkey, let's see if the event is > actually omitted. No, they are not omitted as acpi events if no kernel options are used. I ask my self, how user space can recognize which keys are brightness without adding extra quirks? If i use acpi_osi=NULL, acpi events are ommited and this hotkeys are working. Hmm... how is it done on windows 8?
Is the v3.14 kernel built by you or provided by Ubuntu?
By me. I use latest git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
The events are omitted by UPBL and DWBL: Method (UPBL, 0, NotSerialized) { If (BRNC) { Notify (LCDD, 0x86) // the ACPI video driver will receive // this event and send it to user space } } While UPBL and DWBL is called in _Q0F and _Q0E, which are two EC query functions that get called when you press the hotkey.
Created attachment 125251 [details] Add some debug message to video module Please apply this patch on top of Rafael's linux-next branch and grab the dmesg after you pressed the backlight hotkey.
Created attachment 125261 [details] dmesg with debug patch
There are no events in dmesg if i press brightness hot keys.
Created attachment 125301 [details] dmesg with debug patch and acpi_osi=NULL With acpi_osi=NULL i get this output from acpi_listen: PNP0C14:00 000000ff 00000000 video/brightnessup BRTUP 00000086 00000000 K PNP0C14:00 000000ff 00000000 video/brightnessup BRTUP 00000086 00000000 K PNP0C14:00 000000ff 00000000 video/brightnessdown BRTDN 00000087 00000000 K PNP0C14:00 000000ff 00000000 video/brightnessdown BRTDN 00000087 00000000 K
Adding acpi_osi= to kernel cmdline should make CondRefOf (\_OSI, Local0) returning false, which is not the same as adding acpi_osi="Windows 2012". Since CondRefOf (\_OSI, Local0) returns false, the: If (MCTH (_OS, "Microsoft Windows NT")) { Store (0x07D0, OSYS) } would succeed and firmware would assume this is a Windows Me OS. As I've said in comment #9, the UPBL and DWBL are only called when the OS version is above or equal to vista: If (LGreaterEqual (MSOS (), OSVT)) { Store (LBTN, Local0) If (^^^GFX0.PRST) { If (LNotEqual (^^^GFX0.LCDD._DCS, 0x1F)) { Return (One) } ^^^GFX0.UPBL () Store (One, ASBN) } so it's not clear to me why adding acpi_osi= to kernel cmdline would make event work. Did the dmesg you attached in comment #13 after you press the backlight hotkey? If so, since I didn't see any backlight event related message dumped out, I would say the firmware doesn't generate events through ACPI EC but directly send out the event to user space as key code. The reason why it doesn't work by default is that the _DCS control method returned 0x1d instead of 0x1f, which makes the following GFX0.UPBL not called. Why _DCS returns 0x1d needs investigation. Just in case, did you do any display switch? Please also attach your DMI info for reference purpose: # dmidecode > dmi.info
Please attach the output file sanv of the following cmd: # dd if=/dev/mem of=sanv bs=1 count=$((0x200)) skip=$((0xDAB10E18))
(In reply to Aaron Lu from comment #14) > so it's not clear to me why adding acpi_osi= to kernel cmdline would make > event work. Did the dmesg you attached in comment #13 after you press the > backlight hotkey? Yes . > The reason why it doesn't work by default is that the _DCS control method > returned 0x1d instead of 0x1f, which makes the following GFX0.UPBL not > called. Why _DCS returns 0x1d needs investigation. Just in case, did you do > any display switch? Do you mean hotkey for display switch? No. And there is only one attached display.
Created attachment 125491 [details] dmidecode
Created attachment 125501 [details] sanv: memory dump.
Created attachment 125571 [details] Work around buggy firmware that provides more than 8 output devices The firmware is buggy, it provides more than 8 output devices. Please apply the test patch on top of v3.14-rc2 and attach dmesg, thanks.
Created attachment 125581 [details] dmesg with workaround patch Thank you. It works!
I noticed there are some more not working hotkeys in windows 8 mode. Should i open new bug for it?
Which are those hotkeys? Does disable Win8 mode by adding acpi_osi="!Windows 2012" solve the problem?
F8 (video switch) and F2 (wlan swithc). They work with acpi_osi=NULL: acpi_listen PNP0C14:00 000000ff 00000000 video/switchmode VMOD 00000080 00000000 K PNP0C14:00 000000ff 00000000 video/switchmode VMOD 00000080 00000000 K PNP0C14:00 000000ff 00000000 button/wlan WLAN 00000080 00000000 K PNP0C14:00 000000ff 00000000 button/wlan WLAN 00000080 00000000 K PNP0C14:00 000000ff 00000000 PNP0C14:00 000000ff 00000000 Beside there is one more key for ambient light sensor, but so far i know this driver is still not upstream. Are there any hope to have this driver in linux?
Do I understand correctly the above hotkeys do not work with acpi_osi="!Windows 2012"?
Correct. Only acpi_osi=NULL
I can also confirm that adding "acpi_osi=" on my UX302LA fixes the brightness keys (F5 & F6), and WLAN toggle (F2). I have not had time to test the above patch, but if I follow the comments correctly it appears to only fix the brightness keys and not the other keys? I am also having suspend to RAM issues on the UX302LA and wanted to see if this was somehow related, but this workaround does not change that behavior (on resume, it wakes, but there is no video and I have to CTL+ALT+F2 then CTL+ALT+DEL to shut down). I will file another bug for this unless something shakes loose. Feel free to contact if you want me to test something.
acpi_osi= has no effect for me on ux302lg In my case, /sys/class/backlight/ is empty
Then it will be better to create separate bug report for ux302lg.
The patch is deemed too hacky and will not make it into mainline I'm afraid. It's not clear why firmware would declare 16 output devices while the SPEC only allow 8. I don't see how we can proceed here, I suppose you will have to continue to use acpi_osi= cmdline option for the time being unless we found something new later.
On my Asus UX303LA, "acpi_osi=" in my grub settings fixes the brightness keys (F5 & F6), and F2 (WLAN/BT) bug (Ubuntu 14.04.1 with Kernel 3.13.0 x86_64).
A lot of new ASUS laptops this firmware 'bug or a feature' is present. What about adding some models to drivers/acpi/blacklist.c with acpi_osi=NULL? For instance ASUS X200MA and some others enable Fn+F5, F6 only with this boot parameter.
LV, What's the semantics of acpi_osi=NULL? or acpi_osi=? Are the two things the same? Possible to add quirks for machines that require acpi_osi=NULL in drivers/acpi/blacklist.c?
Oleksij and others, When you use acpi_osi= that made the backlight hotkey work, is there a indicator in your GUI environment that shows the backlight is adjusted when you press the hotkey or the press of the hotkey simply changes the backlight without letting the OS/GUI knows this event?
(In reply to Aaron Lu from comment #33) > Oleksij and others, > > When you use acpi_osi= that made the backlight hotkey work, is there a > indicator in your GUI environment that shows the backlight is adjusted when > you press the hotkey or the press of the hotkey simply changes the backlight > without letting the OS/GUI knows this event? GUI environment shows that backlight is adjusted.
Just to confirm, can you please run acpi_listen and then press the backlight hotkey, see if any output is printed?
acpi_listen video/brightnessup BRTUP 00000086 00000000 K PNP0C14:00 000000ff 00000000 video/brightnessdown BRTDN 00000087 00000000 K PNP0C14:00 000000ff 00000000 video/brightnessup BRTUP 00000086 00000000 K PNP0C14:00 000000ff 00000000 video/brightnessup BRTUP 00000086 00000000 K PNP0C14:00 000000ff 00000000 video/brightnessdown BRTDN 00000087 00000000 K PNP0C14:00 000000ff 00000000 video/brightnessdown BRTDN 00000087 00000000 K PNP0C14:00 000000ff 00000000
And with acpi_osi= in your cmdline, other hotkeys also work? Does it have any negative effect? If not, I wonder this is a better solution than the posted patch that only works around the backlight hotkey problem?
All hotkeys are working. Except automatic keyboard backlight, but there is no driver upstream. I use this setting for 10 month, without noticeable problems.
Good, looks like this is a better fix than the work around patch. I have no idea why this is working though. Bug #88941 seems to be the same, I'm waiting for that reporter's information before putting these things into a quirk patch.
Aaron, I confirm this. acpi_osi= has no negative effect. But with you DOD commit it stops working.
(In reply to Dmitry Tunin from comment #40) > Aaron, > > I confirm this. acpi_osi= has no negative effect. > But with you DOD commit it stops working. Thanks for the confirm. What about the fix patch? Does it solve the problem? commit 35d0565b95547ec12d025dc9b1394f22968d113d Author: Aaron Lu <aaron.lu@intel.com> Date: Mon Dec 1 02:09:18 2014 +0100 ACPI / video: update condition to check if device is in _DOD list
(In reply to Aaron Lu from comment #41) > (In reply to Dmitry Tunin from comment #40) > > Aaron, > > > > I confirm this. acpi_osi= has no negative effect. > > But with you DOD commit it stops working. > > Thanks for the confirm. > What about the fix patch? Does it solve the problem? > > commit 35d0565b95547ec12d025dc9b1394f22968d113d > Author: Aaron Lu <aaron.lu@intel.com> > Date: Mon Dec 1 02:09:18 2014 +0100 > > ACPI / video: update condition to check if device is in _DOD list I am building the kernel. I will confirm soon. But I have doubts.
In case it doesn't work, please add "acpi.debug_layer=0x10000000 acpi.debug_level=4" to kernel cmdline so that I can see what _DOD returns. Thanks.
Am... should i test it too?
(In reply to Aaron Lu from comment #41) > (In reply to Dmitry Tunin from comment #40) > > Aaron, > > > > I confirm this. acpi_osi= has no negative effect. > > But with you DOD commit it stops working. > > Thanks for the confirm. > What about the fix patch? Does it solve the problem? > > commit 35d0565b95547ec12d025dc9b1394f22968d113d > Author: Aaron Lu <aaron.lu@intel.com> > Date: Mon Dec 1 02:09:18 2014 +0100 > > ACPI / video: update condition to check if device is in _DOD list I installed 3.18. It has your last DOD commit. Buttons do not work. pilot6@X200MA:~$ dmesg | grep acpi [ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-3.18.0-031800-generic root=UUID=8b0c6000-31d7-4e41-bfbf-4149ad0122d4 ro quiet splash acpi_osi= acpi.debug_layer=0x10000000 acpi.debug_level=4 vt.handoff=7 [ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] high dfl lint[0x97]) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x02] low edge lint[0xbb]) [ 0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.18.0-031800-generic root=UUID=8b0c6000-31d7-4e41-bfbf-4149ad0122d4 ro quiet splash acpi_osi= acpi.debug_layer=0x10000000 acpi.debug_level=4 vt.handoff=7 [ 0.150585] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 [ 0.627517] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI] [ 0.627611] acpi PNP0A08:00: _OSC failed (AE_ERROR); disabling ASPM [ 1.084836] Switched to clocksource acpi_pm
Created attachment 160021 [details] ACPI log Last fix does not help.
(In reply to Aaron Lu from comment #32) > LV, > > What's the semantics of acpi_osi=NULL? or acpi_osi=? Are the two things the > same? Possible to add quirks for machines that require acpi_osi=NULL in > drivers/acpi/blacklist.c? Here is the patch for "acpi_osi=" quirk https://lkml.org/lkml/2014/12/7/64
Hi, Aaron (In reply to Aaron Lu from comment #32) > LV, > > What's the semantics of acpi_osi=NULL? or acpi_osi=? Are the two things the > same? Possible to add quirks for machines that require acpi_osi=NULL in > drivers/acpi/blacklist.c? _OSI is a control method created by OSPM not BIOS to negotiate OSPM capabilities with the BIOS. "acpi_osi=" means: OSPM will not create _OSI control method in the namespace, so that CondRefOf(\_OSI,Local0) returns FALSE. I haven't tried to pass acpi_osi=NULL as a kernel boot parameter, it might be same as "acpi_os=". acpi_osi_setup() can be used to generate the quirk mechanism, for which, passing "NULL" makes senses. Thanks and best regards -Lv
(In reply to Dmitry Tunin from comment #47) > (In reply to Aaron Lu from comment #32) > > LV, > > > > What's the semantics of acpi_osi=NULL? or acpi_osi=? Are the two things the > > same? Possible to add quirks for machines that require acpi_osi=NULL in > > drivers/acpi/blacklist.c? > > Here is the patch for "acpi_osi=" quirk > > https://lkml.org/lkml/2014/12/7/64 This can be used as the quirk mechanism to stop creating _OSI in the ACPI namespace. I'm not sure if our strategy should be "always specifying a particular OSI for the given platform". So if we want to force a "Windows 2012" _OSI, we may: acpi_osi_setup("!"); acpi_osi_setup("Windows 2012"); Maybe this can not feed all of the requirement for the practical solutions. Thanks and best regards -Lv
Oleksij, Do you see any problem with v3.18 kernel? Backlight hotkey stops working for Dmitry with v3.18 even with acpi_osi= in kernel cmdline, can you please verify this too? Thanks.
Same here. Backlight hotkey stops working with v3.18 even with acpi_osi=.
(In reply to Oleksij Rempel from comment #51) > Same here. Backlight hotkey stops working with v3.18 even with acpi_osi=. I see, the problem would occur as long as the firmware claims more than 8 output devices. Bug re-opened.
*** Bug 88941 has been marked as a duplicate of this bug. ***
*** Bug 89401 has been marked as a duplicate of this bug. ***
Created attachment 160301 [details] Update condition for acpi_video_device_in_dod for firmware that specifies more than 8 output devices We have a problem in current operation region code that deals with video output devices if the number exceeds 8. Jani has a branch that is meant to solve this problem but the immediate test doesn't seem to solve the problem. Since this is a regression, I would like to solve it as quick as possible and by small changes. Please test this patch, on top of v3.18, and please attach your dmesg with this patch applied. Thanks.
Created attachment 160311 [details] dmesg output with patch
I get the same output with acpi_osi="" and without it
Created attachment 160321 [details] dmesg with debug patch, UX302LA
Do the Fn+F5 and F6 create events in acpi_listen? I am building the image, but unable to test it now.
I get empty acpi_listen when I press the brightness keys FnF5 F6
With acpi_osi= as well?
With acpi_osi= F5 F6 are ok, and generate acpi events.
(In reply to Oleksij Rempel from comment #62) > With acpi_osi= F5 F6 are ok, and generate acpi events. This is what the patch meant to do: it restore the previous functionality with acpi_osi=, it can't solve the problem when acpi_osi= is not specified.
(In reply to Jimbo from comment #60) > I get empty acpi_listen when I press the brightness keys FnF5 F6 Does the acpi_video0 re-appear under /sys/class/backlight?
(In reply to Aaron Lu from comment #63) > (In reply to Oleksij Rempel from comment #62) > > With acpi_osi= F5 F6 are ok, and generate acpi events. > > This is what the patch meant to do: it restore the previous functionality > with acpi_osi=, it can't solve the problem when acpi_osi= is not specified. BTW, for acpi_osi= to be omitted, we will need Jani's didl work: git://people.freedesktop.org/~jani/drm didl Dmitry said it doesn't work, I haven't taken a look at those code yet and I suppose that would take some more time.
I confirm that the patch solves the problem, if use 'acpi_osi=' quirk. Now I applied it to Jani's drm and see if it works. The last time it event could be blocked by the problematic commit.
Forgot to add that acpi_video0 re-appeared.
nothing appear under /sys/class/backlight with and without acpi_osi=
btw i'm using 3.18.0
Aaron, Jani's drm didl fix completely solves the problem. I appied both patches: the one yours, which is already in 3.18, and the last one from this thread. It is because he has still rc7. But his patches need some polish though. The brightness buttons work without 'acpi_osi=' quirk. That is good. But still, I guess, you need to find a way to get rid of acpi_video0 in a safe way. @Jimbo, If you use vanilla 3.18, that is why the buttons do not work and you do not have acpi_video0. We are talking about a patched kernel.
sorry, I'm using vainilla but with the patch Aaron proposed. I meant that I was using version 3.18
Jimbo, Are you sure you have applied the patch in a right way and built it with the patch. If you built using debian/rules, then you need to "debian/rules clean' first. If you made it in a right way, then sry. We need to find why it works for me and Oleksij and does not for you. But that is not very probable.
I changed kernel/drivers/acpi/video.c and do7 make oldconfig make prepare make scripts make M=kernel/drivers/gpu/drm/i915/i915.ko or something like that
and then i made cp kernel/drivers/gpu/drm/i915/i915.ko /lib/modules/3.18.0.../kernel/drivers/gpu/drm/i915/i915.ko
Perhaps that's not doing anything :S
Jimbo, That is all wrong. Not only i915 should be built.
Oh... now not only one of the Fn keys works :S so something did change
sorry, I built kernel/drivers/acpi/video.ko
(In reply to Jimbo from comment #78) > sorry, I built kernel/drivers/acpi/video.ko please stop spamming.
(In reply to Dmitry Tunin from comment #70) > Aaron, > > Jani's drm didl fix completely solves the problem. I appied both patches: > the one yours, which is already in 3.18, and the last one from this thread. > It is because he has still rc7. > But his patches need some polish though. > > The brightness buttons work without 'acpi_osi=' quirk. That is good. I don't quite understand why Jani's branch can solve the problem without acpi_osi= quirk. For events to be emitted without acpi_osi= quirk, the _DCS control method of the LCDD device must return 0x1f, that would require one of the CADL entry must be 0x0400. But since we are blindly setting CADL with the first 8 DIDL number(the LCDD's 0x0400 is the 9th one in the DIDL list), it doesn't seem possible for any of the CADL entry to have this value. Can you please attach the gvns memory dump and i915_opregion again in this situation? Jani, Do I understand your code correctly that the CADL list is not changed anyway by your branch? ie. it still gets populated from the first 8 DIDL numbers? > But still, I guess, you need to find a way to get rid of acpi_video0 in a > safe way. Yes. I would like to send out the patch in comment #55 to avoid causing pains for other people with similar firmwares. That patch can at least restore previous behavior.
Aaron, Sry to confuse things up. Jani's branch does not help either. Now it does not. Probably I made some mistake, when testing. Like did not update-grub. Or boot a wrong kernel. So my comment #70 is wrong.
Aaron, correct, CADL does not change. Here's a thought, on top of vanilla 3.18. diff --git a/drivers/gpu/drm/i915/intel_opregion.c b/drivers/gpu/drm/i915/intel_opregion.c index d8de1d5140a7..9175584386f4 100644 --- a/drivers/gpu/drm/i915/intel_opregion.c +++ b/drivers/gpu/drm/i915/intel_opregion.c @@ -633,6 +633,8 @@ static void intel_didl_outputs(struct drm_device *dev) u32 temp; int i = 0; + goto blind_set; + handle = ACPI_HANDLE(&dev->pdev->dev); if (!handle || acpi_bus_get_device(handle, &acpi_dev)) return;
(In reply to Jani Nikula from comment #82) Nope. This patch does not help. I applied both this patch and the one from #55. Still no events.
(In reply to Dmitry Tunin from comment #83) > Nope. This patch does not help. I applied both this patch and the one from > #55. Did you try patch from comment #82 *without* other patches?
Method (_DOD, 0, NotSerialized) // _DOD: Display Output Devices { Store (Zero, NDID) If (LNotEqual (DIDL, Zero)) { Store (SDDL (DDL2), DID1) } If (LNotEqual (DDL2, Zero)) { Store (SDDL (DIDL), DID2) } ... ... } Method (SDDL, 1, NotSerialized) { Increment (NDID) Store (And (Arg0, 0x0F0F), Local0) Or (0x80000000, Local0, Local1) If (LEqual (DIDL, Local0)) { Return (Local1) } If (LEqual (DDL2, Local0)) { Return (Local1) } ... ... } From the two methods above, it seems the firmware doesn't expect the DIDL numbers to have the (1<<31) set, since it is comparing DIDL with Local0 which is got from DIDL & 0x0f0f. This is clearly a violation of the spec but... Previously the DIDL is populated from individual output device's _ADR, which doesn't have the upper 16bits set.
Aaron, please also see commit 3143751ff51a163b77f7efd389043e038f3e008e Author: Zhang Rui <rui.zhang@intel.com> Date: Mon Mar 29 15:12:16 2010 +0800 drm/i915: set DIDL using the ACPI video output device _ADR method return. I think we should probably populate DIDL based on the *actual* outputs we have in DRM, like it was before the above comment, *but* it looks like we should use the IDs from _ADR somehow. I don't know how we can map these two. We'd need such a mapping to modify CADL sensibly as outputs are activated/deactivated.
(In reply to Jani Nikula from comment #84) > (In reply to Dmitry Tunin from comment #83) > > Nope. This patch does not help. I applied both this patch and the one from > > #55. > > Did you try patch from comment #82 *without* other patches? I tested both ways, but with the 2 patches it is more informative. But you already got that it is not that simple.
I have sent the patch in comment #55 to mailing list with all of you CC-ed.
Aaron, What do you think regarding addition of 'acpi_osi=' quirks until the problem is solved in a better way.
(In reply to Dmitry Tunin from comment #89) > Aaron, > > What do you think regarding addition of 'acpi_osi=' quirks until the problem > is solved in a better way. I think that's a good idea for now. I'll take a look at how to do this, in the meantime, if any of you knows that, feel free to submit a patch and let me know, thanks.
Aaron, I already made a patch. It is in https://bugzilla.kernel.org/show_bug.cgi?id=70241#c47
Created attachment 161511 [details] attachment-18884-0.html Aaron's patch from comment 55 restores previous functionality for me on UX302LA, so with this patch and still using cmd line param acpi_osi=, F5 F6 are properly functioning to control screen brightness. https://bugzilla.kernel.org/show_bug.cgi?id=70241#c55 Dmitry's blacklist qurik patch in comment 47 by itself did not work for me, even after adding my model specific descriptions. It doesn't appear to have worked for others either, so this must not be the same issue. I am far from fully understanding the underlying issue (especially when it comes to backward compat for all), but it seems that perhaps the safest way to handle this, if it can't by handled dynamically and safely in the short term, would be to create a new specific kernel cmd line parameter value that provides the same functionality and pathway as does acpi_osi= (acpi_osi=blahblahblah). This way, at least the parameter would make sense, the need for it can be properly described, and we would be passing a real parameter value that made sense. In the short term, and until a proper dynamic and safe fix can be made, this should be safe because the code would only be executed for those of us that have this specific issue. On Tue, Dec 16, 2014 at 4:59 AM, <bugzilla-daemon@bugzilla.kernel.org> wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=70241 > > --- Comment #91 from Dmitry Tunin <hanipouspilot@gmail.com> --- > Aaron, > > I already made a patch. It is in > https://bugzilla.kernel.org/show_bug.cgi?id=70241#c47 > > -- > You are receiving this mail because: > You are on the CC list for the bug. >
My patch does the same as "acpi_osi=" as a boot option. It does not work without the patch from #55.
Created attachment 161581 [details] attachment-21992-0.html Thanks Dmitry, now I understand which two patches I needed to have together. I am in agreement with you after testing. Patch 1 fixes regression (Aaron post 55) - good Patch 2 acpi_osi= quirk patch (Dmitry) makes this param no longer needed - best See my raw commit here where I fix 3 known affected laptops (X200MA, UX302LA, and UX302LG) https://bitbucket.org/motley/kernel_asus_ux302_custom/commits/817e71fd14213d8f484c1050ee8440c61dfa61f0/raw/ Thanks guys On Sun, Dec 21, 2014 at 3:10 AM, <bugzilla-daemon@bugzilla.kernel.org> wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=70241 > > --- Comment #93 from Dmitry Tunin <hanipouspilot@gmail.com> --- > My patch does the same as "acpi_osi=" as a boot option. > It does not work without the patch from #55. > > -- > You are receiving this mail because: > You are on the CC list for the bug. >
This quirk won't be applied upstream. It is a hacky solution. We shall wait till a real solution is done.
commit b4df463678fb9c6dae9548dbb7545993779fd416 Author: Aaron Lu <aaron.lu@intel.com> Date: Mon Dec 15 16:01:29 2014 +0800 ACPI / video: update the skip case for acpi_video_device_in_dod() entered Linus' tree. For the problem of dealing with 8+ video output devices, please follow this bug: https://bugs.freedesktop.org/show_bug.cgi?id=81762
I know nothing about kernel internals (just a normal user!) but my Asus N550LF backlight keys have stopped working since 3.18. They worked perfectly until then with the acpi_osi= paramater. Other keys such as keyboard backlight and volume work perfectly. I get a lot of output in dmesg: [ 0.000000] ACPI: MCFG 0x00000000C9EB6DB0 00003C (v01 _ASUS_ Notebook 01072009 MSFT 00000097) [ 0.000000] ACPI: SSDT 0x00000000C9EB6DF0 00306D (v01 DptfTa DptfTabl 00001000 INTL 20120711) [ 0.000000] ACPI: HPET 0x00000000C9EB9E60 000038 (v01 _ASUS_ Notebook 01072009 AMI. 00000005) [ 0.000000] ACPI: SSDT 0x00000000C9EB9E98 000298 (v01 SataRe SataTabl 00001000 INTL 20120711) [ 0.000000] ACPI: SSDT 0x00000000C9EBA130 003EDA (v01 SaSsdt SaSsdt 00003000 INTL 20091112) [ 0.000000] ACPI: SSDT 0x00000000C9EBE010 000B3E (v01 SgRef SgPch 00001000 INTL 20120711) [ 0.000000] ACPI: SSDT 0x00000000C9EBEB50 001989 (v01 OptRef OptTabl 00001000 INTL 20120711) [ 0.000000] ACPI: MSDM 0x00000000C9AFDE18 000055 (v03 _ASUS_ Notebook 00000000 ASUS 00000001) [ 0.000000] ACPI: Local APIC address 0xfee00000 [ 0.000000] No NUMA configuration found [ 0.000000] Faking a node at [mem 0x0000000000000000-0x000000022f1fffff] [ 0.000000] NODE_DATA(0) allocated [mem 0x22f1f5000-0x22f1f8fff] [ 0.000000] [ffffea0000000000-ffffea0008bfffff] PMD -> [ffff880226800000-ffff88022e7fffff] on node 0 [ 0.000000] Zone ranges: [ 0.000000] DMA [mem 0x00001000-0x00ffffff] [ 0.000000] DMA32 [mem 0x01000000-0xffffffff] [ 0.000000] Normal [mem 0x100000000-0x22f1fffff] [ 0.000000] Movable zone start for each node [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x00001000-0x00057fff] [ 0.000000] node 0: [mem 0x00059000-0x0009efff] [ 0.000000] node 0: [mem 0x00100000-0xb9826fff] [ 0.000000] node 0: [mem 0xb982e000-0xba08afff] [ 0.000000] node 0: [mem 0xba30e000-0xc98ebfff] [ 0.000000] node 0: [mem 0xc9b00000-0xc9e1afff] [ 0.000000] node 0: [mem 0xcafff000-0xcaffffff] [ 0.000000] node 0: [mem 0x100000000-0x22f1fffff] [ 0.000000] Initmem setup node 0 [mem 0x00001000-0x22f1fffff] [ 0.000000] On node 0 totalpages: 2067227 [ 0.000000] DMA zone: 64 pages used for memmap [ 0.000000] DMA zone: 26 pages reserved [ 0.000000] DMA zone: 3997 pages, LIFO batch:0 [ 0.000000] DMA32 zone: 12838 pages used for memmap [ 0.000000] DMA32 zone: 821630 pages, LIFO batch:31 [ 0.000000] Normal zone: 19400 pages used for memmap [ 0.000000] Normal zone: 1241600 pages, LIFO batch:31 [ 0.000000] Reserving Intel graphics stolen memory at 0xcbe00000-0xcfdfffff [ 0.000000] ACPI: PM-Timer IO Port: 0x1808 [ 0.000000] ACPI: Local APIC address 0xfee00000 [ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x01] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1]) [ 0.000000] ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0]) [ 0.000000] IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-39 [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) [ 0.000000] ACPI: IRQ0 used by override. [ 0.000000] ACPI: IRQ9 used by override. [ 0.000000] Using ACPI (MADT) for SMP configuration information [ 0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000 [ 0.000000] smpboot: Allowing 4 CPUs, 0 hotplug CPUs [ 0.000000] PM: Registered nosave memory: [mem 0x00000000-0x00000fff] [ 0.000000] PM: Registered nosave memory: [mem 0x00058000-0x00058fff] [ 0.000000] PM: Registered nosave memory: [mem 0x0009f000-0x0009ffff] [ 0.000000] PM: Registered nosave memory: [mem 0x000a0000-0x000fffff] [ 0.000000] PM: Registered nosave memory: [mem 0xb9827000-0xb982dfff] [ 0.000000] PM: Registered nosave memory: [mem 0xba08b000-0xba30dfff] [ 0.000000] PM: Registered nosave memory: [mem 0xc98ec000-0xc9afffff] [ 0.000000] PM: Registered nosave memory: [mem 0xc9e1b000-0xcab28fff] [ 0.000000] PM: Registered nosave memory: [mem 0xcab29000-0xcaf57fff] [ 0.000000] PM: Registered nosave memory: [mem 0xcaf58000-0xcaffefff] [ 0.000000] PM: Registered nosave memory: [mem 0xcb000000-0xcbbfffff] [ 0.000000] PM: Registered nosave memory: [mem 0xcbc00000-0xcfdfffff] [ 0.000000] PM: Registered nosave memory: [mem 0xcfe00000-0xf7ffffff] [ 0.000000] PM: Registered nosave memory: [mem 0xf8000000-0xfbffffff] [ 0.000000] PM: Registered nosave memory: [mem 0xfc000000-0xfebfffff] [ 0.000000] PM: Registered nosave memory: [mem 0xfec00000-0xfec00fff] [ 0.000000] PM: Registered nosave memory: [mem 0xfec01000-0xfecfffff] [ 0.000000] PM: Registered nosave memory: [mem 0xfed00000-0xfed03fff] [ 0.000000] PM: Registered nosave memory: [mem 0xfed04000-0xfed1bfff] [ 0.000000] PM: Registered nosave memory: [mem 0xfed1c000-0xfed1ffff] [ 0.000000] PM: Registered nosave memory: [mem 0xfed20000-0xfedfffff] [ 0.000000] PM: Registered nosave memory: [mem 0xfee00000-0xfee00fff] [ 0.000000] PM: Registered nosave memory: [mem 0xfee01000-0xfeffffff] [ 0.000000] PM: Registered nosave memory: [mem 0xff000000-0xffffffff] [ 0.000000] e820: [mem 0xcfe00000-0xf7ffffff] available for PCI devices [ 0.000000] Booting paravirtualized kernel on bare hardware [ 0.000000] setup_percpu: NR_CPUS:128 nr_cpumask_bits:128 nr_cpu_ids:4 nr_node_ids:1 [ 0.000000] PERCPU: Embedded 30 pages/cpu @ffff88022ee00000 s82880 r8192 d31808 u524288 [ 0.000000] pcpu-alloc: s82880 r8192 d31808 u524288 alloc=1*2097152 [ 0.000000] pcpu-alloc: [0] 0 1 2 3 [ 0.000000] Built 1 zonelists in Node order, mobility grouping on. Total pages: 2034899 [ 0.000000] Policy zone: Normal [ 0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-linux root=UUID=2aab7f30-c8db-464f-bcb1-d1f1a13bd1a0 rw quiet acpi_osi= [ 0.000000] ACPI: _OSI method disabled [ 0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes) [ 0.000000] xsave: enabled xstate_bv 0x7, cntxt size 0x340 using standard form [ 0.000000] AGP: Checking aperture... [ 0.000000] AGP: No AGP bridge found [ 0.000000] Calgary: detecting Calgary via BIOS EBDA area [ 0.000000] Calgary: Unable to locate Rio Grande table in EBDA - bailing! [ 0.000000] Memory: 7858080K/8268908K available (5478K kernel code, 908K rwdata, 1720K rodata, 1160K init, 1184K bss, 410828K reserved) [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 [ 0.000000] Preemptible hierarchical RCU implementation. [ 0.000000] RCU dyntick-idle grace-period acceleration is enabled. [ 0.000000] Dump stacks of tasks blocking RCU-preempt GP. [ 0.000000] RCU restricting CPUs from NR_CPUS=128 to nr_cpu_ids=4. [ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4 [ 0.000000] NR_IRQS:8448 nr_irqs:728 0 [ 0.000000] Console: colour dummy device 80x25 [ 0.000000] console [tty0] enabled [ 0.000000] allocated 33554432 bytes of page_cgroup [ 0.000000] please try 'cgroup_disable=memory' option if you don't want memory cgroups [ 0.000000] hpet clockevent registered [ 0.000000] tsc: Fast TSC calibration using PIT [ 0.000000] tsc: Detected 2394.430 MHz processor [ 0.000039] Calibrating delay loop (skipped), value calculated using timer frequency.. 4790.39 BogoMIPS (lpj=7981433) [ 0.000042] pid_max: default: 32768 minimum: 301 [ 0.000049] ACPI: Core revision 20140926 [ 0.032818] ACPI: All ACPI Tables successfully acquired [ 0.035564] Security Framework initialized [ 0.035571] Yama: becoming mindful. [ 0.036234] Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes) [[ 7.712949] wlp3s0: send auth to 00:08:30:a7:0d:e1 (try 1/3) [ 7.718951] wlp3s0: authenticated [ 7.720764] wlp3s0: associate with 00:08:30:a7:0d:e1 (try 1/3) [ 7.732211] wlp3s0: RX AssocResp from 00:08:30:a7:0d:e1 (capab=0x421 status=0 aid=7) [ 7.733233] wlp3s0: associated [ 7.733281] cfg80211: Calling CRDA to update world regulatory domain [ 7.878866] wlp3s0: Limiting TX power to 14 dBm as advertised by 00:08:30:a7:0d:e1 [ 20.758693] fuse init (API version 7.23) [ 25.319772] ACPI Error: Method parse/execution failed [\_SB_.PCI0.GFX0.GCBL] (Node ffff88022647e988), AE_AML_UNINITIALIZED_ELEMENT (20140926/psparse-536) [ 25.319794] ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.EC0_.SBRN] (Node ffff880226448348), AE_AML_UNINITIALIZED_ELEMENT (20140926/psparse-536) [ 25.319805] ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.EC0_._Q0F] (Node ffff880226448398), AE_AML_UNINITIALIZED_ELEMENT (20140926/psparse-536) [ 26.244460] ACPI Error: Method parse/execution failed [\_SB_.PCI0.GFX0.GCBL] (Node ffff88022647e988), AE_AML_UNINITIALIZED_ELEMENT (20140926/psparse-536) [ 26.244471] ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.EC0_.SBRN] (Node ffff880226448348), AE_AML_UNINITIALIZED_ELEMENT (20140926/psparse-536) [ 26.244477] ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.EC0_._Q0E] (Node ffff880226448370), AE_AML_UNINITIALIZED_ELEMENT (20140926/psparse-536) [ 26.521052] ACPI Error: Method parse/execution failed [\_SB_.PCI0.GFX0.GCBL] (Node ffff88022647e988), AE_AML_UNINITIALIZED_ELEMENT (20140926/psparse-536) [ 26.521072] ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.EC0_.SBRN] (Node ffff880226448348), AE_AML_UNINITIALIZED_ELEMENT (20140926/psparse-536) [ 26.521083] ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.EC0_._Q0E] (Node ffff880226448370), AE_AML_UNINITIALIZED_ELEMENT (20140926/psparse-536) [ 26.972724] ACPI Error: Method parse/execution failed [\_SB_.PCI0.GFX0.GCBL] (Node ffff88022647e988), AE_AML_UNINITIALIZED_ELEMENT (20140926/psparse-536) [ 26.972733] ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.EC0_.SBRN] (Node ffff880226448348), AE_AML_UNINITIALIZED_ELEMENT (20140926/psparse-536) [ 26.972739] ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.EC0_._Q0F] (Node ffff880226448398), AE_AML_UNINITIALIZED_ELEMENT (20140926/psparse-536) [ 27.153684] ACPI Error: Method parse/execution failed [\_SB_.PCI0.GFX0.GCBL] (Node ffff88022647e988), AE_AML_UNINITIALIZED_ELEMENT (20140926/psparse-536) [ 27.153705] ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.EC0_.SBRN] (Node ffff880226448348), AE_AML_UNINITIALIZED_ELEMENT (20140926/psparse-536) [ 27.153717] ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.EC0_._Q0F] (Node ffff880226448398), AE_AML_UNINITIALIZED_ELEMENT (20140926/psparse-536) [ 27.286490] ACPI Error: Method parse/execution failed [\_SB_.PCI0.GFX0.GCBL] (Node ffff88022647e988), AE_AML_UNINITIALIZED_ELEMENT (20140926/psparse-536) [ 27.286512] ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.EC0_.SBRN] (Node ffff880226448348), AE_AML_UNINITIALIZED_ELEMENT (20140926/psparse-536) [ 27.286523] ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.EC0_._Q0F] (Node ffff880226448398), AE_AML_UNINITIALIZED_ELEMENT (20140926/psparse-536) [ 27.541524] ACPI Error: Method parse/execution failed [\_SB_.PCI0.GFX0.GCBL] (Node ffff88022647e988), AE_AML_UNINITIALIZED_ELEMENT (20140926/psparse-536) [ 27.541539] ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.EC0_.SBRN] (Node ffff880226448348), AE_AML_UNINITIALIZED_ELEMENT (20140926/psparse-536) [ 27.541547] ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.EC0_._Q0E] (Node ffff880226448370), AE_AML_UNINITIALIZED_ELEMENT (20140926/psparse-536) [ 27.817902] ACPI Error: Method parse/execution failed [\_SB_.PCI0.GFX0.GCBL] (Node ffff88022647e988), AE_AML_UNINITIALIZED_ELEMENT (20140926/psparse-536) [ 27.817912] ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.EC0_.SBRN] (Node ffff880226448348), AE_AML_UNINITIALIZED_ELEMENT (20140926/psparse-536) [ 27.817917] ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.EC0_._Q0F] (Node ffff880226448398), AE_AML_UNINITIALIZED_ELEMENT (20140926/psparse-536) [ 28.014573] ACPI Error: Method parse/execution failed [\_SB_.PCI0.GFX0.GCBL] (Node ffff88022647e988), AE_AML_UNINITIALIZED_ELEMENT (20140926/psparse-536) [ 28.014582] ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.EC0_.SBRN] (Node ffff880226448348), AE_AML_UNINITIALIZED_ELEMENT (20140926/psparse-536) [ 28.014588] ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.EC0_._Q0F] (Node ffff880226448398), AE_AML_UNINITIALIZED_ELEMENT (20140926/psparse-536) [ 28.280375] ACPI Error: Method parse/execution failed [\_SB_.PCI0.GFX0.GCBL] (Node ffff88022647e988), AE_AML_UNINITIALIZED_ELEMENT (20140926/psparse-536) [ 28.280386] ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.EC0_.SBRN] (Node ffff880226448348), AE_AML_UNINITIALIZED_ELEMENT (20140926/psparse-536) [ 28.280391] ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.EC0_._Q0E] (Node ffff880226448370), AE_AML_UNINITIALIZED_ELEMENT (20140926/psparse-536) [ 28.557678] ACPI Error: Method parse/execution failed [\_SB_.PCI0.GFX0.GCBL] (Node ffff88022647e988), AE_AML_UNINITIALIZED_ELEMENT (20140926/psparse-536) [ 28.557688] ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.EC0_.SBRN] (Node ffff880226448348), AE_AML_UNINITIALIZED_ELEMENT (20140926/psparse-536) [ 28.557693] ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.EC0_._Q0F] (Node ffff880226448398), AE_AML_UNINITIALIZED_ELEMENT (20140926/psparse-536) [ 28.790736] ACPI Error: Method parse/execution failed [\_SB_.PCI0.GFX0.GCBL] (Node ffff88022647e988), AE_AML_UNINITIALIZED_ELEMENT (20140926/psparse-536) [ 28.790746] ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.EC0_.SBRN] (Node ffff880226448348), AE_AML_UNINITIALIZED_ELEMENT (20140926/psparse-536) [ 28.790751] ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.EC0_._Q0E] (Node ffff880226448370), AE_AML_UNINITIALIZED_ELEMENT (20140926/psparse-536) can post a full dmesg if required.
Problem's still present in 3.19-rc7
On a similar, more recent model (Asus Zenbook UX303LA DS51T) running kernel 4.0, the brightness keys are non-responsive regardless of the acpi_osi parameter passed at boot (tried NULL, boot and !Windows2012). acpi_listen doesn't output anything for those keys (other Function keys work as expected)
Tom, Please attach your acpidump if you still have the problem. Mathieu, Can you please try using an older kernel, say v3.17 and see if things are different? And please also attach your acpidump. Thanks.
Created attachment 174751 [details] acpidump.3.17 On 04/21/2015 07:26 PM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=70241 > > --- Comment #100 from Aaron Lu <aaron.lu@intel.com> --- > Tom, > Please attach your acpidump if you still have the problem. > > Mathieu, > Can you please try using an older kernel, say v3.17 and see if things are > different? And please also attach your acpidump. > > Thanks. > I have tried with kernel 3.17 and the problem is still present. Directly echoing values into /sys/class/backlight/intel_backlight/device/intel_backlight/brightness does work in both kernels. I have attached the acpidump produced with kernel 3.17. When trying to run acpidump on 4.0 I et an error message about not being able to open /dev/mem: Cannot open /dev/mem Could not get ACPI tables, AE_NOT_FOUND I had a similar error message when trying to run dmidecode.
(In reply to Mathieu Comandon from comment #101) > Created attachment 174751 [details] > acpidump.3.17 > > On 04/21/2015 07:26 PM, bugzilla-daemon@bugzilla.kernel.org wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=70241 > > > > --- Comment #100 from Aaron Lu <aaron.lu@intel.com> --- > > Tom, > > Please attach your acpidump if you still have the problem. > > > > Mathieu, > > Can you please try using an older kernel, say v3.17 and see if things are > > different? And please also attach your acpidump. > > > > Thanks. > > > I have tried with kernel 3.17 and the problem is still present. Directly With acpi_osi= I suppose? If that is the case, then it should be a different problem, please open a new bug for it. Thanks.
Hi! I'm still having the problem in 4.1.0. Was the patch applied in the kernel? I remmember the patch worked. Wasn't it accepted?
My patch has not been accepted. There is some work done. But no positive result so far.
Oh ok! you are still working on it =) I thought this bug was forgotten
Hello, I'm facing a similar problem here on a Schenker XMG A506, which is based on a Clevo barebone (dmi_product_name = N15_17RD). I've tested this with vanilla-4.3.2 and a recent drm-intel-nightly, based on 4.4.0-rc4, all with the same result: Fn+F8 and Fn+F9 neither produce a keyboard event nor any ACPI event. I went ahead and dump and disassembled DSDT and SSDT2 and identified the ACPI methods beloning to the hotkeys as _Q11 and _Q12. You can find the tables here: https://www.math.uni-bielefeld.de/~tjakobi/archive/acpi-dumps.tar.xz Further inspection and a bit of Googling then lead me to this Gist by Carlo Caione: https://gist.github.com/carlocaione/c7da231e27db32870b20 Which in turn brought me here. Surprising since apparantly this bug is closed with a code fix? Anyway, applying the workaround by Aaron to vanilla-4.3.2 restores the generation of ACPI events when the hotkeys are pressed. I've also forwarded this to Schenker, so maybe they can make Clevo aware of this and Clevo in turn can fix their deployed firmware.