acpi: Add "acpi_osi=" for ASUS X200MA to enable, brightness keys

PATCH In review Dmitry Tunin 5 participants 24 messages Dec 18, 2014 – Dec 19, 2014

Subsystems (2)

Stable branch ACPI

lore

Share & tools

lore

Dmitry Tunin

author

2014-12-18 12:16 UTC #0 lore raw

PATCH v3 1/2 acpi: Add "acpi_osi=" for ASUS X200MA to enable, brightness keys

Add "acpi_osi=" quirk for ASUS X200MA
More information can be found in UX302LA bugreport
https://bugzilla.kernel.org/show_bug.cgi?id=70241

X200MA is affected by th e same bug and the solution has been tested

I reported it to launchpad too
https://bugs.launchpad.net/ubuntu/bug/1400068

Cc [email protected]

Signed-off-by Dmitry Tunin <[email protected]>

---
 drivers/acpi/blacklist.c | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

drivers/acpi/blacklist.c +20 -0

index 7556e7c..f78ed08 100644
@@ -162,6 +162,17 @@ static int __init dmi_disable_osi_win8(const struct dmi_system_id *d)
 	acpi_osi_setup("!Windows 2012");
 	return 0;
 }
+/*
+ * Some ASUS models firmware declares 16 devices instead of 8
+ * 'acpi_osi=' kernel parameter fixes it
+ * Without this parameters brightness keys Fn+F5 and F6 do not work
+ */
+static int __init dmi_disable_osi_all(const struct dmi_system_id *d)
+{
+	printk(KERN_NOTICE PREFIX "DMI detected: %s\n", d->ident);
+	acpi_osi_setup("");
+	return 0;
+}
 
 static struct dmi_system_id acpi_osi_dmi_table[] __initdata = {
 	{

@@ -371,6 +382,15 @@ static struct dmi_system_id acpi_osi_dmi_table[] __initdata = {
 		     DMI_MATCH(DMI_PRODUCT_NAME, "1015PX"),
 		},
 	},
+	/* Without this brightness keys do not work */	
+	{
+	.callback = dmi_disable_osi_all,
+	.ident = "ASUSTeK COMPUTER INC. X200MA",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+		     DMI_MATCH(DMI_PRODUCT_NAME, "X200MA"),
+		},
+	},
 	{}
 };

Signature · 1 line

1.9.1

Dmitry Tunin

author

2014-12-18 12:19 UTC #1 lore raw

PATCH 2/2 acpi: Add "acpi_osi=" for ASUS UX302LA to enable, brightness keys

This patch is a workaround quirk to enable brightness keys.

BugLink https://bugzilla.kernel.org/show_bug.cgi?id=70241

Cc [email protected]

Signed-off-by Dmitry Tunin <[email protected]>

---
 drivers/acpi/blacklist.c | 8 ++++++++
 1 file changed, 8 insertions(+)

drivers/acpi/blacklist.c +8 -0

index f78ed08..a96295c 100644
@@ -391,6 +391,14 @@ static struct dmi_system_id acpi_osi_dmi_table[] __initdata = {
 		     DMI_MATCH(DMI_PRODUCT_NAME, "X200MA"),
 		},
 	},
+	{
+	.callback = dmi_disable_osi_all,
+	.ident = "ASUSTeK COMPUTER INC. UX302LA",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+		     DMI_MATCH(DMI_PRODUCT_NAME, "UX302LA"),
+		},
+	},
 	{}
 };

Signature · 1 line

1.9.1

Josh Boyer

2014-12-18 13:25 UTC #2 lore raw

In reply to Dmitry Tunin

Quoted 4 lines · Dmitry Tunin

Add "acpi_osi=" quirk for ASUS X200MA
More information can be found in UX302LA bugreport
https://bugzilla.kernel.org/show_bug.cgi?id=70241

Quoted 8 lines

X200MA is affected by th e same bug and the solution has been tested
I reported it to launchpad too
https://bugs.launchpad.net/ubuntu/bug/1400068
Cc [email protected]
Signed-off-by Dmitry Tunin <[email protected]>

The UX301LA models have the same setup, with 16 devices instead of 8. I discussed this with Matthew Garrett a bit and a more ideal approach is to actually enumerate all 16 devices between the firmware and i915 driver. The problem we have is that the intel opregion spec that hasn't been updated since 2008 doesn't cover the additional 8 devices. Anyway, that is being tracked here:

https://bugs.freedesktop.org/show_bug.cgi?id=81762

Quoted 14 lines

---
 drivers/acpi/blacklist.c | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

drivers/acpi/blacklist.c +1 -0

index 7556e7c..f78ed08 100644
@@ -162,6 +162,17 @@ static int __init dmi_disable_osi_win8(const struct
 dmi_system_id *d)
        acpi_osi_setup("!Windows 2012");
        return 0;
 }
+/*

drivers/acpi/blacklist.c static int __init dmi_disable_osi_win8(const struct · line 176

Quoted 10 lines

drivers/acpi/blacklist.c +10 -0

+ * Some ASUS models firmware declares 16 devices instead of 8
+ * 'acpi_osi=' kernel parameter fixes it
+ * Without this parameters brightness keys Fn+F5 and F6 do not work
+ */
+static int __init dmi_disable_osi_all(const struct dmi_system_id *d)
+{
+       printk(KERN_NOTICE PREFIX "DMI detected: %s\n", d->ident);
+       acpi_osi_setup("");
+       return 0;
+}

What does this do to the rest of the function keys? Does everything else still work as expected, including suspend and resume?

Quoted 25 lines

drivers/acpi/blacklist.c +9 -1

  static struct dmi_system_id acpi_osi_dmi_table[] __initdata = {
        {

@@ -371,6 +382,15 @@ static struct dmi_system_id acpi_osi_dmi_table[]
 __initdata = {
                     DMI_MATCH(DMI_PRODUCT_NAME, "1015PX"),
                },
        },
+       /* Without this brightness keys do not work */
+       {
+       .callback = dmi_disable_osi_all,
+       .ident = "ASUSTeK COMPUTER INC. X200MA",
+       .matches = {
+                    DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+                    DMI_MATCH(DMI_PRODUCT_NAME, "X200MA"),
+               },
+       },
        {}
 };
 
--

1.9.1
--
To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Matthew Garrett

2014-12-18 13:27 UTC #3 lore raw

Quoted 2 lines · Josh Boyer

What does this do to the rest of the function keys? Does everything else still work as expected, including suspend and resume?

Disabling OSI completely certainly runs the risk of turning off things like HPET. It certainly shouldn't be done without checking the ACPI tables, and it really shouldn't be done at all because this is Intel's bug and they should just fix it.

Signature · 1 line

Matthew Garrett | [email protected]

Dmitry Tunin

author

2014-12-18 13:28 UTC #4 lore raw

In reply to Josh Boyer

Josh,

I agree, that a better approach is to implement opregion in a right way. But it will take some time. In the meantime this kind of quirks solve the problem. And it is quite safe.

18.12.2014 16:25, Josh Boyer пишет:

Quoted 76 lines · Dmitry Tunin

Quoted 4 lines
Add "acpi_osi=" quirk for ASUS X200MA
More information can be found in UX302LA bugreport
https://bugzilla.kernel.org/show_bug.cgi?id=70241
Quoted 8 lines
X200MA is affected by th e same bug and the solution has been tested
I reported it to launchpad too
https://bugs.launchpad.net/ubuntu/bug/1400068
Cc [email protected]
Signed-off-by Dmitry Tunin <[email protected]>
The UX301LA models have the same setup, with 16 devices instead of 8. I discussed this with Matthew Garrett a bit and a more ideal approach is to actually enumerate all 16 devices between the firmware and i915 driver. The problem we have is that the intel opregion spec that hasn't been updated since 2008 doesn't cover the additional 8 devices. Anyway, that is being tracked here:
https://bugs.freedesktop.org/show_bug.cgi?id=81762
Quoted 14 lines
---
  drivers/acpi/blacklist.c | 20 ++++++++++++++++++++
  1 file changed, 20 insertions(+)
drivers/acpi/blacklist.c +1 -0
index 7556e7c..f78ed08 100644
@@ -162,6 +162,17 @@ static int __init dmi_disable_osi_win8(const struct
 dmi_system_id *d)
         acpi_osi_setup("!Windows 2012");
         return 0;
  }
+/*
drivers/acpi/blacklist.c static int __init dmi_disable_osi_win8(const struct · line 176
Quoted 10 lines
drivers/acpi/blacklist.c +10 -0
+ * Some ASUS models firmware declares 16 devices instead of 8
+ * 'acpi_osi=' kernel parameter fixes it
+ * Without this parameters brightness keys Fn+F5 and F6 do not work
+ */
+static int __init dmi_disable_osi_all(const struct dmi_system_id *d)
+{
+       printk(KERN_NOTICE PREFIX "DMI detected: %s\n", d->ident);
+       acpi_osi_setup("");
+       return 0;
+}
What does this do to the rest of the function keys? Does everything else still work as expected, including suspend and resume?
Quoted 25 lines
drivers/acpi/blacklist.c +9 -1
   static struct dmi_system_id acpi_osi_dmi_table[] __initdata = {
         {
@@ -371,6 +382,15 @@ static struct dmi_system_id acpi_osi_dmi_table[]
 __initdata = {
                      DMI_MATCH(DMI_PRODUCT_NAME, "1015PX"),
                 },
         },
+       /* Without this brightness keys do not work */
+       {
+       .callback = dmi_disable_osi_all,
+       .ident = "ASUSTeK COMPUTER INC. X200MA",
+       .matches = {
+                    DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+                    DMI_MATCH(DMI_PRODUCT_NAME, "X200MA"),
+               },
+       },
         {}
  };
 
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Dmitry Tunin

author

2014-12-18 13:40 UTC #5 lore raw

In reply to Josh Boyer

I did not notice the inline question.
The rest of the keys work as they did before.
Now other regressions have been noticed.
Many people use acpi_osi= as a boot paremeter, since there is no other way to get Fn+F5 and F6 working.

18.12.2014 16:25, Josh Boyer пишет:

Quoted 76 lines · Dmitry Tunin

Quoted 4 lines
Add "acpi_osi=" quirk for ASUS X200MA
More information can be found in UX302LA bugreport
https://bugzilla.kernel.org/show_bug.cgi?id=70241
Quoted 8 lines
X200MA is affected by th e same bug and the solution has been tested
I reported it to launchpad too
https://bugs.launchpad.net/ubuntu/bug/1400068
Cc [email protected]
Signed-off-by Dmitry Tunin <[email protected]>
The UX301LA models have the same setup, with 16 devices instead of 8. I discussed this with Matthew Garrett a bit and a more ideal approach is to actually enumerate all 16 devices between the firmware and i915 driver. The problem we have is that the intel opregion spec that hasn't been updated since 2008 doesn't cover the additional 8 devices. Anyway, that is being tracked here:
https://bugs.freedesktop.org/show_bug.cgi?id=81762
Quoted 14 lines
---
  drivers/acpi/blacklist.c | 20 ++++++++++++++++++++
  1 file changed, 20 insertions(+)
drivers/acpi/blacklist.c +1 -0
index 7556e7c..f78ed08 100644
@@ -162,6 +162,17 @@ static int __init dmi_disable_osi_win8(const struct
 dmi_system_id *d)
         acpi_osi_setup("!Windows 2012");
         return 0;
  }
+/*
drivers/acpi/blacklist.c static int __init dmi_disable_osi_win8(const struct · line 176
Quoted 10 lines
drivers/acpi/blacklist.c +10 -0
+ * Some ASUS models firmware declares 16 devices instead of 8
+ * 'acpi_osi=' kernel parameter fixes it
+ * Without this parameters brightness keys Fn+F5 and F6 do not work
+ */
+static int __init dmi_disable_osi_all(const struct dmi_system_id *d)
+{
+       printk(KERN_NOTICE PREFIX "DMI detected: %s\n", d->ident);
+       acpi_osi_setup("");
+       return 0;
+}
What does this do to the rest of the function keys? Does everything else still work as expected, including suspend and resume?
Quoted 25 lines
drivers/acpi/blacklist.c +9 -1
   static struct dmi_system_id acpi_osi_dmi_table[] __initdata = {
         {
@@ -371,6 +382,15 @@ static struct dmi_system_id acpi_osi_dmi_table[]
 __initdata = {
                      DMI_MATCH(DMI_PRODUCT_NAME, "1015PX"),
                 },
         },
+       /* Without this brightness keys do not work */
+       {
+       .callback = dmi_disable_osi_all,
+       .ident = "ASUSTeK COMPUTER INC. X200MA",
+       .matches = {
+                    DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+                    DMI_MATCH(DMI_PRODUCT_NAME, "X200MA"),
+               },
+       },
         {}
  };
 
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Matthew Garrett

2014-12-18 13:57 UTC #6 lore raw

Can you run acpidump and upload the ACPI tables somewhere?

Signature · 1 line

Matthew Garrett | [email protected]

Dmitry Tunin

author

2014-12-18 14:03 UTC #7 lore raw

It is already done.

https://bugzilla.kernel.org/attachment.cgi?id=160161

18.12.2014 16:57, Matthew Garrett пишет:

Quoted 2 lines

Can you run acpidump and upload the ACPI tables somewhere?

Dmitry Tunin

author

2014-12-18 14:04 UTC #8 lore raw

In reply to Matthew Garrett

Sry, wrong url b4

https://bugzilla.kernel.org/attachment.cgi?id=125091

18.12.2014 16:57, Matthew Garrett пишет:

Quoted 2 lines

Can you run acpidump and upload the ACPI tables somewhere?

Matthew Garrett

2014-12-18 14:09 UTC #9 lore raw

Quoted 3 lines · Dmitry Tunin

Sry, wrong url b4
https://bugzilla.kernel.org/attachment.cgi?id=125091

Can you check whether acpi_osi="Windows 2012" also results in things working?

Signature · 1 line

Matthew Garrett | [email protected]

Dmitry Tunin

author

2014-12-18 14:22 UTC #10 lore raw

No, It does not. That's first I tried.

18.12.2014 17:09, Matthew Garrett пишет:

Quoted 8 lines · Dmitry Tunin

Quoted 3 lines
Sry, wrong url b4
https://bugzilla.kernel.org/attachment.cgi?id=125091
Can you check whether acpi_osi="Windows 2012" also results in things working?

Matthew Garrett

2014-12-18 14:26 UTC #11 lore raw

Ah, I see - can you try acpi_osi="!Windows 2013" ?

Signature · 1 line

Matthew Garrett | [email protected]

Dmitry Tunin

author

2014-12-18 14:34 UTC #12 lore raw

I tried that too. No effect.

18.12.2014 17:26, Matthew Garrett пишет:

Quoted 2 lines

Ah, I see - can you try acpi_osi="!Windows 2013" ?

Matthew Garrett

2014-12-18 14:36 UTC #13 lore raw

That's odd - it looks like the default behaviour in the absence of any OSI strings is to just default to an OSYS value that matches Windows 2012, so disabling the 2013 value should be equivalent. If it's not, it's definitely not safe to turn off all values - there are several devices that change behaviour as a result.

Signature · 1 line

Matthew Garrett | [email protected]

Dmitry Tunin

author

2014-12-18 14:40 UTC #14 lore raw

But at least two devices work well with this quirk.
That must be some ASUS UEFI firmware fault, but still it is a workaround. You can find some more information in those bugzilla reports.

https://bugzilla.kernel.org/show_bug.cgi?id=89401
https://bugzilla.kernel.org/show_bug.cgi?id=70241

18.12.2014 17:36, Matthew Garrett пишет:

Quoted 6 lines

That's odd - it looks like the default behaviour in the absence of any OSI strings is to just default to an OSYS value that matches Windows 2012, so disabling the 2013 value should be equivalent. If it's not, it's definitely not safe to turn off all values - there are several devices that change behaviour as a result.

Matthew Garrett

2014-12-18 14:43 UTC #15 lore raw

The actual fix is known - Intel need to fix their code to match their specification. Applying this patch may break functionality that other users are depending on.

Signature · 1 line

Matthew Garrett | [email protected]

Matthew Garrett

2014-12-18 14:50 UTC #16 lore raw

Oh, I see - acpi_osi= disables _OSI entirely, so we end up going down a different path that results in us claiming to be XP. That results in a bunch of changes in exposed hardware, so this patch certainly isn't acceptable.

Signature · 1 line

Matthew Garrett | [email protected]

Len Brown

reviewer

2014-12-18 18:09 UTC #17 lore raw

NAK on addoing this acpi_osi= quirk to upstream Linux.

The reason is that problem is being actively debugged. Quirks in upstream Linux are for when we give up.

Sure, it is perfectly okay for individual users to invoke it. It is even fine for a distro to check in this workaround if they care about that box working *now*
and they are not concerned about side effects.

But the real fix is in development, and checking workarounds with possible other side-effects
into up-stream Linux is just a distraction from getting it right for not just this machine,
but other machines w/ the same issue.

thanks,
Len Brown, Intel Open Source Technology Center

ps. lots of people are mis-using acpi_osi= in debugging, please consult Documentation/kernel-parameters.txt for a detailed description of how this cmdline option works. Note, in particular, that acpi_osi=XYZ by itself will _add_ XYZ to the list of recognized strings. If that string is already built
into Linux (eg. "Windows 2012"), then adding it again has no effect.

Dmitry Tunin

author

2014-12-18 18:20 UTC #18 lore raw

Len,

I completely agree that debugging and testing of a real solution would be a problem. And adding "acpi_osi=" is not too hard as a boot option.

In some cases it can be built-in, if it is a box solution.

So the patch is no good.

18.12.2014 21:09, Len Brown пишет:

Quoted 26 lines

NAK on addoing this acpi_osi= quirk to upstream Linux.
The reason is that problem is being actively debugged. Quirks in upstream Linux are for when we give up.
Sure, it is perfectly okay for individual users to invoke it. It is even fine for a distro to check in this workaround if they care about that box working *now*
and they are not concerned about side effects.
But the real fix is in development, and checking workarounds with possible other side-effects
into up-stream Linux is just a distraction from getting it right for not just this machine,
but other machines w/ the same issue.
thanks,
Len Brown, Intel Open Source Technology Center
ps. lots of people are mis-using acpi_osi= in debugging, please consult Documentation/kernel-parameters.txt for a detailed description of how this cmdline option works. Note, in particular, that acpi_osi=XYZ by itself will _add_ XYZ to the list of recognized strings. If that string is already built
into Linux (eg. "Windows 2012"), then adding it again has no effect.

Matthew Garrett

2014-12-18 20:04 UTC #19 lore raw

In reply to Matthew Garrett

Ah, http://cgit.freedesktop.org/~jani/drm/log/?h=didl nominally has support for doing the right thing here - any chance you can try that tree?

Signature · 1 line

Matthew Garrett | [email protected]

Dmitry Tunin

author

2014-12-18 21:20 UTC #20 lore raw

I did already. It is not that simple.
https://bugzilla.kernel.org/show_bug.cgi?id=70241#c86

18.12.2014 23:04, Matthew Garrett пишет:

Quoted 4 lines

Ah, http://cgit.freedesktop.org/~jani/drm/log/?h=didl nominally has support for doing the right thing here - any chance you can try that tree?

Dmitry Tunin

author

2014-12-18 14:06 UTC #21 lore raw

In reply to Matthew Garrett

Here is another one from X200MA

https://bugzilla.kernel.org/attachment.cgi?id=160161

18.12.2014 16:57, Matthew Garrett пишет:

Quoted 2 lines

Can you run acpidump and upload the ACPI tables somewhere?

Aaron Lu

2014-12-19 01:46 UTC #22 lore raw

In reply to Josh Boyer

CC Jani, who is working on the patchset to enable 8+ output devices and may have some comments on this.

Regards,
Aaron

Quoted 76 lines · Josh Boyer

Quoted 4 lines · Dmitry Tunin
Add "acpi_osi=" quirk for ASUS X200MA
More information can be found in UX302LA bugreport
https://bugzilla.kernel.org/show_bug.cgi?id=70241
Quoted 8 lines
X200MA is affected by th e same bug and the solution has been tested
I reported it to launchpad too
https://bugs.launchpad.net/ubuntu/bug/1400068
Cc [email protected]
Signed-off-by Dmitry Tunin <[email protected]>
The UX301LA models have the same setup, with 16 devices instead of 8. I discussed this with Matthew Garrett a bit and a more ideal approach is to actually enumerate all 16 devices between the firmware and i915 driver. The problem we have is that the intel opregion spec that hasn't been updated since 2008 doesn't cover the additional 8 devices. Anyway, that is being tracked here:
https://bugs.freedesktop.org/show_bug.cgi?id=81762
Quoted 14 lines
---
 drivers/acpi/blacklist.c | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)
drivers/acpi/blacklist.c +1 -0
index 7556e7c..f78ed08 100644
@@ -162,6 +162,17 @@ static int __init dmi_disable_osi_win8(const struct
 dmi_system_id *d)
        acpi_osi_setup("!Windows 2012");
        return 0;
 }
+/*
drivers/acpi/blacklist.c static int __init dmi_disable_osi_win8(const struct · line 176
Quoted 10 lines
drivers/acpi/blacklist.c +10 -0
+ * Some ASUS models firmware declares 16 devices instead of 8
+ * 'acpi_osi=' kernel parameter fixes it
+ * Without this parameters brightness keys Fn+F5 and F6 do not work
+ */
+static int __init dmi_disable_osi_all(const struct dmi_system_id *d)
+{
+       printk(KERN_NOTICE PREFIX "DMI detected: %s\n", d->ident);
+       acpi_osi_setup("");
+       return 0;
+}
What does this do to the rest of the function keys? Does everything else still work as expected, including suspend and resume?
Quoted 25 lines
drivers/acpi/blacklist.c +9 -1
  static struct dmi_system_id acpi_osi_dmi_table[] __initdata = {
        {
@@ -371,6 +382,15 @@ static struct dmi_system_id acpi_osi_dmi_table[]
 __initdata = {
                     DMI_MATCH(DMI_PRODUCT_NAME, "1015PX"),
                },
        },
+       /* Without this brightness keys do not work */
+       {
+       .callback = dmi_disable_osi_all,
+       .ident = "ASUSTeK COMPUTER INC. X200MA",
+       .matches = {
+                    DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+                    DMI_MATCH(DMI_PRODUCT_NAME, "X200MA"),
+               },
+       },
        {}
 };
 
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Aaron Lu

2014-12-19 03:23 UTC #23 lore raw

Quoted 2 lines · Aaron Lu

CC Jani, who is working on the patchset to enable 8+ output devices and may have some comments on this.

Change Jani's email address, I got a warning from the mailer about his other email address.

Quoted 82 lines

Regards,
Aaron
Quoted 76 lines · Josh Boyer
Quoted 4 lines · Dmitry Tunin
Add "acpi_osi=" quirk for ASUS X200MA
More information can be found in UX302LA bugreport
https://bugzilla.kernel.org/show_bug.cgi?id=70241
Quoted 8 lines
X200MA is affected by th e same bug and the solution has been tested
I reported it to launchpad too
https://bugs.launchpad.net/ubuntu/bug/1400068
Cc [email protected]
Signed-off-by Dmitry Tunin <[email protected]>
The UX301LA models have the same setup, with 16 devices instead of 8. I discussed this with Matthew Garrett a bit and a more ideal approach is to actually enumerate all 16 devices between the firmware and i915 driver. The problem we have is that the intel opregion spec that hasn't been updated since 2008 doesn't cover the additional 8 devices. Anyway, that is being tracked here:
https://bugs.freedesktop.org/show_bug.cgi?id=81762
Quoted 14 lines
---
 drivers/acpi/blacklist.c | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)
drivers/acpi/blacklist.c +1 -0
index 7556e7c..f78ed08 100644
@@ -162,6 +162,17 @@ static int __init dmi_disable_osi_win8(const struct
 dmi_system_id *d)
        acpi_osi_setup("!Windows 2012");
        return 0;
 }
+/*
drivers/acpi/blacklist.c static int __init dmi_disable_osi_win8(const struct · line 176
Quoted 10 lines
drivers/acpi/blacklist.c +10 -0
+ * Some ASUS models firmware declares 16 devices instead of 8
+ * 'acpi_osi=' kernel parameter fixes it
+ * Without this parameters brightness keys Fn+F5 and F6 do not work
+ */
+static int __init dmi_disable_osi_all(const struct dmi_system_id *d)
+{
+       printk(KERN_NOTICE PREFIX "DMI detected: %s\n", d->ident);
+       acpi_osi_setup("");
+       return 0;
+}
What does this do to the rest of the function keys? Does everything else still work as expected, including suspend and resume?
Quoted 25 lines
drivers/acpi/blacklist.c +9 -1
  static struct dmi_system_id acpi_osi_dmi_table[] __initdata = {
        {
@@ -371,6 +382,15 @@ static struct dmi_system_id acpi_osi_dmi_table[]
 __initdata = {
                     DMI_MATCH(DMI_PRODUCT_NAME, "1015PX"),
                },
        },
+       /* Without this brightness keys do not work */
+       {
+       .callback = dmi_disable_osi_all,
+       .ident = "ASUSTeK COMPUTER INC. X200MA",
+       .matches = {
+                    DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+                    DMI_MATCH(DMI_PRODUCT_NAME, "X200MA"),
+               },
+       },
        {}
 };
 
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html