| Message ID | 1389611658-19424-1-git-send-email-tiwai@suse.de (mailing list archive) |
|---|---|
| State | Superseded, archived |
| Headers | show |
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 <tiwai@suse.de> > > --- > > > > 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. > -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 <tiwai@suse.de> > --- > > 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. >
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?
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 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
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.
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?
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 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
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!
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.
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 <tiwai@suse.de> --- 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(+)