The BIOS on recent HP laptops behaves differently with Win8 OSI,
e.g. no backlight control and no rfkill are available. List them in
the blacklist as a workaround.
This patch tries to reduce the added items by matching "G1" suffix,
e.g. machines are named like "HP ProBook 430 G1".
Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=856294
Signed-off-by: Takashi Iwai <[email protected]>
---
Rafael, could you check this?
If the problem were only about the backlight, we could fix differenly,
but BIOS on these machines seems to switching more other functions
like rfkill.
thanks,
Takashi
drivers/acpi/blacklist.c | 50 ++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 50 insertions(+)
diff --git a/drivers/acpi/blacklist.c b/drivers/acpi/blacklist.c
index 078c4f7fe2dd..40c91f5052ef 100644
--- a/drivers/acpi/blacklist.c
+++ b/drivers/acpi/blacklist.c
@@ -323,6 +323,56 @@ static struct dmi_system_id acpi_osi_dmi_table[] __initdata = {
DMI_MATCH(DMI_PRODUCT_VERSION, "2349D15"),
},
},
+ {
+ .callback = dmi_disable_osi_win8,
+ .ident = "HP ProBook 2013 models",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "HP ProBook "),
+ DMI_MATCH(DMI_PRODUCT_NAME, " G1"),
+ },
+ },
+ {
+ .callback = dmi_disable_osi_win8,
+ .ident = "HP EliteBook 2013 models",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "HP EliteBook "),
+ DMI_MATCH(DMI_PRODUCT_NAME, " G1"),
+ },
+ },
+ {
+ .callback = dmi_disable_osi_win8,
+ .ident = "HP ZBook 14",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "HP ZBook 14"),
+ },
+ },
+ {
+ .callback = dmi_disable_osi_win8,
+ .ident = "HP ZBook 15",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "HP ZBook 15"),
+ },
+ },
+ {
+ .callback = dmi_disable_osi_win8,
+ .ident = "HP ZBook 17",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "HP ZBook 17"),
+ },
+ },
+ {
+ .callback = dmi_disable_osi_win8,
+ .ident = "HP EliteBook 8780w",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "HP EliteBook 8780w"),
+ },
+ },
/*
* BIOS invocation of _OSI(Linux) is almost always a BIOS bug.
--
1.8.5
On Monday, January 13, 2014 12:14:18 PM Takashi Iwai wrote:
> The BIOS on recent HP laptops behaves differently with Win8 OSI,
> e.g. no backlight control and no rfkill are available. List them in
> the blacklist as a workaround.
>
> This patch tries to reduce the added items by matching "G1" suffix,
> e.g. machines are named like "HP ProBook 430 G1".
>
> Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=856294
> Signed-off-by: Takashi Iwai <[email protected]>
> ---
>
> Rafael, could you check this?
> If the problem were only about the backlight, we could fix differenly,
> but BIOS on these machines seems to switching more other functions
> like rfkill.
It looks like I have this patch in my linux-next branch.
Thanks!
> drivers/acpi/blacklist.c | 50 ++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 50 insertions(+)
>
> diff --git a/drivers/acpi/blacklist.c b/drivers/acpi/blacklist.c
> index 078c4f7fe2dd..40c91f5052ef 100644
> --- a/drivers/acpi/blacklist.c
> +++ b/drivers/acpi/blacklist.c
> @@ -323,6 +323,56 @@ static struct dmi_system_id acpi_osi_dmi_table[] __initdata = {
> DMI_MATCH(DMI_PRODUCT_VERSION, "2349D15"),
> },
> },
> + {
> + .callback = dmi_disable_osi_win8,
> + .ident = "HP ProBook 2013 models",
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
> + DMI_MATCH(DMI_PRODUCT_NAME, "HP ProBook "),
> + DMI_MATCH(DMI_PRODUCT_NAME, " G1"),
> + },
> + },
> + {
> + .callback = dmi_disable_osi_win8,
> + .ident = "HP EliteBook 2013 models",
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
> + DMI_MATCH(DMI_PRODUCT_NAME, "HP EliteBook "),
> + DMI_MATCH(DMI_PRODUCT_NAME, " G1"),
> + },
> + },
> + {
> + .callback = dmi_disable_osi_win8,
> + .ident = "HP ZBook 14",
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
> + DMI_MATCH(DMI_PRODUCT_NAME, "HP ZBook 14"),
> + },
> + },
> + {
> + .callback = dmi_disable_osi_win8,
> + .ident = "HP ZBook 15",
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
> + DMI_MATCH(DMI_PRODUCT_NAME, "HP ZBook 15"),
> + },
> + },
> + {
> + .callback = dmi_disable_osi_win8,
> + .ident = "HP ZBook 17",
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
> + DMI_MATCH(DMI_PRODUCT_NAME, "HP ZBook 17"),
> + },
> + },
> + {
> + .callback = dmi_disable_osi_win8,
> + .ident = "HP EliteBook 8780w",
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
> + DMI_MATCH(DMI_PRODUCT_NAME, "HP EliteBook 8780w"),
> + },
> + },
>
> /*
> * BIOS invocation of _OSI(Linux) is almost always a BIOS bug.
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
At Mon, 13 Jan 2014 12:46:31 +0100,
Rafael J. Wysocki wrote:
>
> On Monday, January 13, 2014 12:14:18 PM Takashi Iwai wrote:
> > The BIOS on recent HP laptops behaves differently with Win8 OSI,
> > e.g. no backlight control and no rfkill are available. List them in
> > the blacklist as a workaround.
> >
> > This patch tries to reduce the added items by matching "G1" suffix,
> > e.g. machines are named like "HP ProBook 430 G1".
> >
> > Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=856294
> > Signed-off-by: Takashi Iwai <[email protected]>
> > ---
> >
> > Rafael, could you check this?
> > If the problem were only about the backlight, we could fix differenly,
> > but BIOS on these machines seems to switching more other functions
> > like rfkill.
>
> It looks like I have this patch in my linux-next branch.
OK, thanks!
Takashi
>
> Thanks!
>
>
> > drivers/acpi/blacklist.c | 50 ++++++++++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 50 insertions(+)
> >
> > diff --git a/drivers/acpi/blacklist.c b/drivers/acpi/blacklist.c
> > index 078c4f7fe2dd..40c91f5052ef 100644
> > --- a/drivers/acpi/blacklist.c
> > +++ b/drivers/acpi/blacklist.c
> > @@ -323,6 +323,56 @@ static struct dmi_system_id acpi_osi_dmi_table[] __initdata = {
> > DMI_MATCH(DMI_PRODUCT_VERSION, "2349D15"),
> > },
> > },
> > + {
> > + .callback = dmi_disable_osi_win8,
> > + .ident = "HP ProBook 2013 models",
> > + .matches = {
> > + DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
> > + DMI_MATCH(DMI_PRODUCT_NAME, "HP ProBook "),
> > + DMI_MATCH(DMI_PRODUCT_NAME, " G1"),
> > + },
> > + },
> > + {
> > + .callback = dmi_disable_osi_win8,
> > + .ident = "HP EliteBook 2013 models",
> > + .matches = {
> > + DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
> > + DMI_MATCH(DMI_PRODUCT_NAME, "HP EliteBook "),
> > + DMI_MATCH(DMI_PRODUCT_NAME, " G1"),
> > + },
> > + },
> > + {
> > + .callback = dmi_disable_osi_win8,
> > + .ident = "HP ZBook 14",
> > + .matches = {
> > + DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
> > + DMI_MATCH(DMI_PRODUCT_NAME, "HP ZBook 14"),
> > + },
> > + },
> > + {
> > + .callback = dmi_disable_osi_win8,
> > + .ident = "HP ZBook 15",
> > + .matches = {
> > + DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
> > + DMI_MATCH(DMI_PRODUCT_NAME, "HP ZBook 15"),
> > + },
> > + },
> > + {
> > + .callback = dmi_disable_osi_win8,
> > + .ident = "HP ZBook 17",
> > + .matches = {
> > + DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
> > + DMI_MATCH(DMI_PRODUCT_NAME, "HP ZBook 17"),
> > + },
> > + },
> > + {
> > + .callback = dmi_disable_osi_win8,
> > + .ident = "HP EliteBook 8780w",
> > + .matches = {
> > + DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
> > + DMI_MATCH(DMI_PRODUCT_NAME, "HP EliteBook 8780w"),
> > + },
> > + },
> >
> > /*
> > * BIOS invocation of _OSI(Linux) is almost always a BIOS bug.
> >
>
> --
> I speak only for myself.
> Rafael J. Wysocki, Intel Open Source Technology Center.
>
On Mon, Jan 13, 2014 at 12:14:18PM +0100, Takashi Iwai wrote:
> The BIOS on recent HP laptops behaves differently with Win8 OSI,
> e.g. no backlight control and no rfkill are available. List them in
> the blacklist as a workaround.
What's the plan for fixing this properly?
--
Matthew Garrett | [email protected]
On Tuesday, January 14, 2014 04:12:44 PM Matthew Garrett wrote:
> On Mon, Jan 13, 2014 at 12:14:18PM +0100, Takashi Iwai wrote:
> > The BIOS on recent HP laptops behaves differently with Win8 OSI,
> > e.g. no backlight control and no rfkill are available. List them in
> > the blacklist as a workaround.
>
> What's the plan for fixing this properly?
What exactly do you mean by "fixing this properly"?
Rafael
At Tue, 14 Jan 2014 16:12:44 +0000,
Matthew Garrett wrote:
>
> On Mon, Jan 13, 2014 at 12:14:18PM +0100, Takashi Iwai wrote:
> > The BIOS on recent HP laptops behaves differently with Win8 OSI,
> > e.g. no backlight control and no rfkill are available. List them in
> > the blacklist as a workaround.
>
> What's the plan for fixing this properly?
For the backlight, there have been attempts to fix (use the native
backlight control primarily over ACPI), but didn't land to the
mainline yet.
For the rfkill part, it depends on the user-space. Without the patch,
it sends a scan code, and OS is supposed to do rfkill via each
driver. The proper key mapping would be needed. Not sure about the
LED state on the WiFi button, though, whether it's properly controlled
by WiFi and/or BT driver. With the patch, all rfkill and LED are
handled by BIOS, so it works as is.
Also I thought there are changes in some media keys by acpi_osi, but I
need to double check.
Takashi
On Tue, Jan 14, 2014 at 05:42:57PM +0100, Rafael J. Wysocki wrote:
> On Tuesday, January 14, 2014 04:12:44 PM Matthew Garrett wrote:
> > On Mon, Jan 13, 2014 at 12:14:18PM +0100, Takashi Iwai wrote:
> > > The BIOS on recent HP laptops behaves differently with Win8 OSI,
> > > e.g. no backlight control and no rfkill are available. List them in
> > > the blacklist as a workaround.
> >
> > What's the plan for fixing this properly?
>
> What exactly do you mean by "fixing this properly"?
rfkill and backlight control presumably work fine under Windows 8, so
there's obviously some new mechanism for doing so. HP will presumably
ship more hardware that behaves this way, so if we don't add support for
the new mechanisms then we'll just have to keep adding entries to the
blacklist.
--
Matthew Garrett | [email protected]
On Tue, Jan 14, 2014 at 05:33:50PM +0100, Takashi Iwai wrote:
> For the rfkill part, it depends on the user-space. Without the patch,
> it sends a scan code, and OS is supposed to do rfkill via each
> driver. The proper key mapping would be needed. Not sure about the
> LED state on the WiFi button, though, whether it's properly controlled
> by WiFi and/or BT driver. With the patch, all rfkill and LED are
> handled by BIOS, so it works as is.
Ok, so userspace needs to work - there's plenty of hardware that only
sends a scancode already. Let's just add the keycode and then remove
this once the backlight stuff is fixed.
--
Matthew Garrett | [email protected]
On Tuesday, January 14, 2014 04:34:25 PM Matthew Garrett wrote:
> On Tue, Jan 14, 2014 at 05:42:57PM +0100, Rafael J. Wysocki wrote:
> > On Tuesday, January 14, 2014 04:12:44 PM Matthew Garrett wrote:
> > > On Mon, Jan 13, 2014 at 12:14:18PM +0100, Takashi Iwai wrote:
> > > > The BIOS on recent HP laptops behaves differently with Win8 OSI,
> > > > e.g. no backlight control and no rfkill are available. List them in
> > > > the blacklist as a workaround.
> > >
> > > What's the plan for fixing this properly?
> >
> > What exactly do you mean by "fixing this properly"?
>
> rfkill and backlight control presumably work fine under Windows 8, so
> there's obviously some new mechanism for doing so. HP will presumably
> ship more hardware that behaves this way, so if we don't add support for
> the new mechanisms then we'll just have to keep adding entries to the
> blacklist.
Well, presumably.
To add any kind of support for anything we need to know how that thing
works in the first place which we don't in this particular case, at least
at the moment. I hontestly don't want the users of those systems to wait
until we figure that out.
Thanks!
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
On Tue, Jan 14, 2014 at 05:53:20PM +0100, Rafael J. Wysocki wrote:
> On Tuesday, January 14, 2014 04:34:25 PM Matthew Garrett wrote:
> > rfkill and backlight control presumably work fine under Windows 8, so
> > there's obviously some new mechanism for doing so. HP will presumably
> > ship more hardware that behaves this way, so if we don't add support for
> > the new mechanisms then we'll just have to keep adding entries to the
> > blacklist.
>
> Well, presumably.
>
> To add any kind of support for anything we need to know how that thing
> works in the first place which we don't in this particular case, at least
> at the moment. I hontestly don't want the users of those systems to wait
> until we figure that out.
Adding blacklist entries without making some effort to figure out what
the underlying problem is doesn't provide any incentive for fixing the
underlying problem. In this case Toshio has described what the problem
is and it sounds like fixing the rfkill problem is straightforward, so
we should just classify this in the same way as all the other backlight
control issues. Perhaps we should add it to the native video blacklist
rather than the OSI one?
--
Matthew Garrett | [email protected]
At Tue, 14 Jan 2014 16:36:00 +0000,
Matthew Garrett wrote:
>
> On Tue, Jan 14, 2014 at 05:33:50PM +0100, Takashi Iwai wrote:
>
> > For the rfkill part, it depends on the user-space. Without the patch,
> > it sends a scan code, and OS is supposed to do rfkill via each
> > driver. The proper key mapping would be needed. Not sure about the
> > LED state on the WiFi button, though, whether it's properly controlled
> > by WiFi and/or BT driver. With the patch, all rfkill and LED are
> > handled by BIOS, so it works as is.
>
> Ok, so userspace needs to work - there's plenty of hardware that only
> sends a scancode already. Let's just add the keycode and then remove
> this once the backlight stuff is fixed.
Yes, sounds feasible.
Takashi
On Tue, Jan 14, 2014 at 05:43:56PM +0100, Takashi Iwai wrote:
> At Tue, 14 Jan 2014 16:36:00 +0000,
> Matthew Garrett wrote:
> >
> > On Tue, Jan 14, 2014 at 05:33:50PM +0100, Takashi Iwai wrote:
> >
> > > For the rfkill part, it depends on the user-space. Without the patch,
> > > it sends a scan code, and OS is supposed to do rfkill via each
> > > driver. The proper key mapping would be needed. Not sure about the
> > > LED state on the WiFi button, though, whether it's properly controlled
> > > by WiFi and/or BT driver. With the patch, all rfkill and LED are
> > > handled by BIOS, so it works as is.
> >
> > Ok, so userspace needs to work - there's plenty of hardware that only
> > sends a scancode already. Let's just add the keycode and then remove
> > this once the backlight stuff is fixed.
>
> Yes, sounds feasible.
Oh, and once we've got the keycode in it's possible to handle this
in-kernel - you just need rfkill-input.
--
Matthew Garrett | [email protected]