Bug 70241 - Asus UX302LA: Backlight hotkays need acpi_osi=NULL workaround
Summary: Asus UX302LA: Backlight hotkays need acpi_osi=NULL workaround
Status: CLOSED CODE_FIX
Alias: None
Product: ACPI
Classification: Unclassified
Component: Power-Video (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Aaron Lu
URL:
Keywords:
: 88941 89401 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-02-07 11:41 UTC by Oleksij Rempel
Modified: 2016-03-17 17:44 UTC (History)
12 users (show)

See Also:
Kernel Version: 3.14
Subsystem:
Regression: No
Bisected commit-id:


Attachments
acpidump (605.76 KB, application/octet-stream)
2014-02-07 11:41 UTC, Oleksij Rempel
Details
Add some debug message to video module (1.41 KB, patch)
2014-02-08 09:12 UTC, Aaron Lu
Details | Diff
dmesg with debug patch (61.08 KB, text/plain)
2014-02-08 09:47 UTC, Oleksij Rempel
Details
dmesg with debug patch and acpi_osi=NULL (61.86 KB, text/plain)
2014-02-08 13:44 UTC, Oleksij Rempel
Details
dmidecode (9.80 KB, text/plain)
2014-02-10 09:39 UTC, Oleksij Rempel
Details
sanv: memory dump. (512 bytes, application/octet-stream)
2014-02-10 09:39 UTC, Oleksij Rempel
Details
Work around buggy firmware that provides more than 8 output devices (1.28 KB, patch)
2014-02-11 09:12 UTC, Aaron Lu
Details | Diff
dmesg with workaround patch (61.85 KB, text/plain)
2014-02-11 09:43 UTC, Oleksij Rempel
Details
ACPI log (8.95 KB, text/x-log)
2014-12-08 09:31 UTC, Dmitry Tunin
Details
Update condition for acpi_video_device_in_dod for firmware that specifies more than 8 output devices (1.18 KB, patch)
2014-12-10 02:49 UTC, Aaron Lu
Details | Diff
dmesg output with patch (1.57 KB, text/plain)
2014-12-10 07:22 UTC, Jaime Pérez
Details
dmesg with debug patch, UX302LA (63.89 KB, text/plain)
2014-12-10 07:28 UTC, Oleksij Rempel
Details
attachment-18884-0.html (2.40 KB, text/html)
2014-12-21 01:12 UTC, motley
Details
attachment-21992-0.html (1.89 KB, text/html)
2014-12-21 18:54 UTC, motley
Details
acpidump.3.17 (709.68 KB, text/plain)
2015-04-22 02:55 UTC, Mathieu Comandon
Details

Description Oleksij Rempel 2014-02-07 11:41:21 UTC
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.
Comment 1 Aaron Lu 2014-02-08 07:37:54 UTC
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?
Comment 2 Oleksij Rempel 2014-02-08 07:47:07 UTC
(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.
Comment 3 Oleksij Rempel 2014-02-08 07:48:33 UTC
Hm..  should it be controlled by some user space program?
Comment 4 Aaron Lu 2014-02-08 07:49:31 UTC
(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?
Comment 5 Aaron Lu 2014-02-08 07:50:28 UTC
Please run acpi_listen and then press the hotkey, let's see if the event is actually omitted.
Comment 6 Oleksij Rempel 2014-02-08 08:20:36 UTC
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?
Comment 7 Aaron Lu 2014-02-08 08:29:02 UTC
Is the v3.14 kernel built by you or provided by Ubuntu?
Comment 8 Oleksij Rempel 2014-02-08 08:31:26 UTC
By me. I use latest git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Comment 9 Aaron Lu 2014-02-08 08:44:40 UTC
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.
Comment 10 Aaron Lu 2014-02-08 09:12:18 UTC
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.
Comment 11 Oleksij Rempel 2014-02-08 09:47:30 UTC
Created attachment 125261 [details]
dmesg with debug patch
Comment 12 Oleksij Rempel 2014-02-08 09:50:27 UTC
There are no events in dmesg if i press brightness hot keys.
Comment 13 Oleksij Rempel 2014-02-08 13:44:33 UTC
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
Comment 14 Aaron Lu 2014-02-10 02:55:27 UTC
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
Comment 15 Aaron Lu 2014-02-10 05:43:15 UTC
Please attach the output file sanv of the following cmd:
# dd if=/dev/mem of=sanv bs=1 count=$((0x200)) skip=$((0xDAB10E18))
Comment 16 Oleksij Rempel 2014-02-10 09:38:18 UTC
(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.
Comment 17 Oleksij Rempel 2014-02-10 09:39:13 UTC
Created attachment 125491 [details]
dmidecode
Comment 18 Oleksij Rempel 2014-02-10 09:39:49 UTC
Created attachment 125501 [details]
sanv: memory dump.
Comment 19 Aaron Lu 2014-02-11 09:12:50 UTC
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.
Comment 20 Oleksij Rempel 2014-02-11 09:43:22 UTC
Created attachment 125581 [details]
dmesg with workaround patch

Thank you. It works!
Comment 21 Oleksij Rempel 2014-02-12 08:34:54 UTC
I noticed there are some more not working hotkeys in windows 8 mode. Should i open new bug for it?
Comment 22 Aaron Lu 2014-02-12 08:36:47 UTC
Which are those hotkeys? Does disable Win8 mode by adding acpi_osi="!Windows 2012" solve the problem?
Comment 23 Oleksij Rempel 2014-02-12 08:49:33 UTC
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?
Comment 24 Aaron Lu 2014-02-12 09:14:43 UTC
Do I understand correctly the above hotkeys do not work with acpi_osi="!Windows 2012"?
Comment 25 Oleksij Rempel 2014-02-12 09:21:40 UTC
Correct. Only acpi_osi=NULL
Comment 26 motley 2014-02-21 13:15:19 UTC
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.
Comment 27 bdecherf 2014-02-21 20:54:55 UTC
acpi_osi= has no effect for me on ux302lg
In my case, /sys/class/backlight/ is empty
Comment 28 Oleksij Rempel 2014-02-21 22:37:22 UTC
Then it will be better to create separate bug report for ux302lg.
Comment 29 Aaron Lu 2014-03-17 03:09:40 UTC
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.
Comment 30 Guillaume Desclaux 2014-09-21 22:57:57 UTC
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).
Comment 31 Dmitry Tunin 2014-12-07 09:34:28 UTC
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.
Comment 32 Aaron Lu 2014-12-08 02:07:01 UTC
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?
Comment 33 Aaron Lu 2014-12-08 02:11:22 UTC
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?
Comment 34 Oleksij Rempel 2014-12-08 07:32:44 UTC
(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.
Comment 35 Aaron Lu 2014-12-08 08:14:51 UTC
Just to confirm, can you please run acpi_listen and then press the backlight hotkey, see if any output is printed?
Comment 36 Oleksij Rempel 2014-12-08 08:17:31 UTC
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
Comment 37 Aaron Lu 2014-12-08 08:23:29 UTC
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?
Comment 38 Oleksij Rempel 2014-12-08 08:28:31 UTC
All hotkeys are working. Except automatic keyboard backlight, but there is no driver upstream.
I use this setting for 10 month, without noticeable problems.
Comment 39 Aaron Lu 2014-12-08 08:32:52 UTC
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.
Comment 40 Dmitry Tunin 2014-12-08 08:34:45 UTC
Aaron,

I confirm this. acpi_osi= has no negative effect.
But with you DOD commit it stops working.
Comment 41 Aaron Lu 2014-12-08 08:36:59 UTC
(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
Comment 42 Dmitry Tunin 2014-12-08 08:57:31 UTC
(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.
Comment 43 Aaron Lu 2014-12-08 09:03:01 UTC
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.
Comment 44 Oleksij Rempel 2014-12-08 09:03:39 UTC
Am... should i test it too?
Comment 45 Dmitry Tunin 2014-12-08 09:25:51 UTC
(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
Comment 46 Dmitry Tunin 2014-12-08 09:31:34 UTC
Created attachment 160021 [details]
ACPI log

Last fix does not help.
Comment 47 Dmitry Tunin 2014-12-08 10:37:45 UTC
(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
Comment 48 Lv Zheng 2014-12-09 00:24:38 UTC
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
Comment 49 Lv Zheng 2014-12-09 00:32:09 UTC
(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
Comment 50 Aaron Lu 2014-12-09 03:00:57 UTC
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.
Comment 51 Oleksij Rempel 2014-12-09 10:18:29 UTC
Same here. Backlight hotkey stops working with v3.18 even with acpi_osi=.
Comment 52 Aaron Lu 2014-12-10 02:01:07 UTC
(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.
Comment 53 Aaron Lu 2014-12-10 02:01:34 UTC
*** Bug 88941 has been marked as a duplicate of this bug. ***
Comment 54 Aaron Lu 2014-12-10 02:01:47 UTC
*** Bug 89401 has been marked as a duplicate of this bug. ***
Comment 55 Aaron Lu 2014-12-10 02:49:33 UTC
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.
Comment 56 Jaime Pérez 2014-12-10 07:22:13 UTC
Created attachment 160311 [details]
dmesg output with patch
Comment 57 Jaime Pérez 2014-12-10 07:26:40 UTC
I get the same output with acpi_osi="" and without it
Comment 58 Oleksij Rempel 2014-12-10 07:28:36 UTC
Created attachment 160321 [details]
dmesg with debug patch, UX302LA
Comment 59 Dmitry Tunin 2014-12-10 07:28:53 UTC
Do the Fn+F5 and F6 create events in acpi_listen?
I am building the image, but unable to test it now.
Comment 60 Jaime Pérez 2014-12-10 07:31:14 UTC
I get empty acpi_listen when I press the brightness keys FnF5 F6
Comment 61 Dmitry Tunin 2014-12-10 07:32:31 UTC
With acpi_osi= as well?
Comment 62 Oleksij Rempel 2014-12-10 07:38:47 UTC
With acpi_osi= F5 F6 are ok, and generate acpi events.
Comment 63 Aaron Lu 2014-12-10 07:40:40 UTC
(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.
Comment 64 Aaron Lu 2014-12-10 07:40:57 UTC
(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?
Comment 65 Aaron Lu 2014-12-10 07:48:43 UTC
(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.
Comment 66 Dmitry Tunin 2014-12-10 13:36:18 UTC
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.
Comment 67 Dmitry Tunin 2014-12-10 13:47:16 UTC
Forgot to add that acpi_video0 re-appeared.
Comment 68 Jaime Pérez 2014-12-10 13:58:00 UTC
nothing appear under /sys/class/backlight with and without acpi_osi=
Comment 69 Jaime Pérez 2014-12-10 14:00:15 UTC
btw i'm using 3.18.0
Comment 70 Dmitry Tunin 2014-12-10 14:07:56 UTC
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.
Comment 71 Jaime Pérez 2014-12-10 14:10:33 UTC
sorry, I'm using vainilla but with the patch Aaron proposed. I meant that I was using version 3.18
Comment 72 Dmitry Tunin 2014-12-10 14:14:02 UTC
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.
Comment 73 Jaime Pérez 2014-12-10 14:22:27 UTC
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
Comment 74 Jaime Pérez 2014-12-10 14:23:55 UTC
and then i made cp kernel/drivers/gpu/drm/i915/i915.ko /lib/modules/3.18.0.../kernel/drivers/gpu/drm/i915/i915.ko
Comment 75 Jaime Pérez 2014-12-10 14:24:14 UTC
Perhaps that's not doing anything :S
Comment 76 Dmitry Tunin 2014-12-10 14:26:44 UTC
Jimbo,

That is all wrong. Not only i915 should be built.
Comment 77 Jaime Pérez 2014-12-10 14:28:43 UTC
Oh... now not only one of the Fn keys works :S so something did change
Comment 78 Jaime Pérez 2014-12-10 14:29:17 UTC
sorry, I built kernel/drivers/acpi/video.ko
Comment 79 Oleksij Rempel 2014-12-10 14:30:11 UTC
(In reply to Jimbo from comment #78)
> sorry, I built kernel/drivers/acpi/video.ko

please stop spamming.
Comment 80 Aaron Lu 2014-12-11 07:32:04 UTC
(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.
Comment 81 Dmitry Tunin 2014-12-11 09:26:07 UTC
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.
Comment 82 Jani Nikula 2014-12-11 09:33:18 UTC
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;
Comment 83 Dmitry Tunin 2014-12-11 17:42:28 UTC
(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.
Comment 84 Jani Nikula 2014-12-12 08:35:15 UTC
(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?
Comment 85 Aaron Lu 2014-12-12 08:49:35 UTC
            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.
Comment 86 Jani Nikula 2014-12-12 09:37:39 UTC
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.
Comment 87 Dmitry Tunin 2014-12-12 09:56:41 UTC
(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.
Comment 88 Aaron Lu 2014-12-15 08:02:38 UTC
I have sent the patch in comment #55 to mailing list with all of you CC-ed.
Comment 89 Dmitry Tunin 2014-12-15 09:51:48 UTC
Aaron,

What do you think regarding addition of 'acpi_osi=' quirks until the problem is solved in a better way.
Comment 90 Aaron Lu 2014-12-16 03:24:38 UTC
(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.
Comment 91 Dmitry Tunin 2014-12-16 09:59:33 UTC
Aaron,

I already made a patch. It is in https://bugzilla.kernel.org/show_bug.cgi?id=70241#c47
Comment 92 motley 2014-12-21 01:12:17 UTC
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.
>
Comment 93 Dmitry Tunin 2014-12-21 08:10:44 UTC
My patch does the same as "acpi_osi=" as a boot option.
It does not work without the patch from #55.
Comment 94 motley 2014-12-21 18:54:21 UTC
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.
>
Comment 95 Dmitry Tunin 2014-12-21 21:18:00 UTC
This quirk won't be applied upstream. It is a hacky solution.
We shall wait till a real solution is done.
Comment 96 Aaron Lu 2014-12-22 05:53:57 UTC
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
Comment 97 Tom B 2015-01-20 10:19:26 UTC
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.
Comment 98 Jaime Pérez 2015-02-03 08:56:09 UTC
Problem's still present in 3.19-rc7
Comment 99 Mathieu Comandon 2015-04-22 02:08:40 UTC
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)
Comment 100 Aaron Lu 2015-04-22 02:26:17 UTC
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.
Comment 101 Mathieu Comandon 2015-04-22 02:55:31 UTC
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.
Comment 102 Aaron Lu 2015-04-22 02:57:46 UTC
(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.
Comment 103 Jaime Pérez 2015-07-01 15:02:46 UTC
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?
Comment 104 Dmitry Tunin 2015-07-01 15:04:47 UTC
My patch has not been accepted. There is some work done. But no positive result so far.
Comment 105 Jaime Pérez 2015-07-01 15:08:55 UTC
Oh ok! you are still working on it =) I thought this bug was forgotten
Comment 106 Tobias Jakobi 2015-12-16 08:37:51 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.