This reverts commit e18ac62fa4b3f16234bab0d5a6627c57dbae9e7e.
The referenced commit added HP EliteBook Revolve 810 to the ACPI video
detected blacklist so that only the native Intel backlight interface was
exported.
However, this turned to be wrong solution after all. The ACPI video
interface works and as long as we only use that there are no problems. So
we can revert this commit and stick to use the backlight interface provided
by the ACPI video driver.
(Using Intel native interface will not work after resume since the ACPI
video driver will restore it's state which takes control over the native
one. That's a separate thing and should be addressed in the ACPI video
driver, I suppose.)
References: https://bugzilla.kernel.org/show_bug.cgi?id=70231
Cc: Aaron Lu <[email protected]>
Signed-off-by: Mika Westerberg <[email protected]>
---
Rafael,
This turned out to be misunderstanding from my side. I should have
investigated this further before submitting the original patch. Sorry about
that.
Aaron,
Thanks for the investigation and pointing me to the right direction (e.g to
use acpi_video0 over the native one).
drivers/acpi/video_detect.c | 8 --------
1 file changed, 8 deletions(-)
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index a697b77b8865..f0447d3daf2c 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -170,14 +170,6 @@ static struct dmi_system_id video_detect_dmi_table[] = {
},
{
.callback = video_detect_force_vendor,
- .ident = "HP EliteBook Revolve 810",
- .matches = {
- DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
- DMI_MATCH(DMI_PRODUCT_NAME, "HP EliteBook Revolve 810 G1"),
- },
- },
- {
- .callback = video_detect_force_vendor,
.ident = "Lenovo Yoga 13",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
--
1.8.5.2
At Fri, 14 Feb 2014 14:34:07 +0200,
Mika Westerberg wrote:
>
> This reverts commit e18ac62fa4b3f16234bab0d5a6627c57dbae9e7e.
>
> The referenced commit added HP EliteBook Revolve 810 to the ACPI video
> detected blacklist so that only the native Intel backlight interface was
> exported.
>
> However, this turned to be wrong solution after all. The ACPI video
> interface works and as long as we only use that there are no problems. So
> we can revert this commit and stick to use the backlight interface provided
> by the ACPI video driver.
>
> (Using Intel native interface will not work after resume since the ACPI
> video driver will restore it's state which takes control over the native
> one. That's a separate thing and should be addressed in the ACPI video
> driver, I suppose.)
>
> References: https://bugzilla.kernel.org/show_bug.cgi?id=70231
> Cc: Aaron Lu <[email protected]>
> Signed-off-by: Mika Westerberg <[email protected]>
> ---
> Rafael,
>
> This turned out to be misunderstanding from my side. I should have
> investigated this further before submitting the original patch. Sorry about
> that.
>
> Aaron,
>
> Thanks for the investigation and pointing me to the right direction (e.g to
> use acpi_video0 over the native one).
Could you check whether the ACPI video still really works even if you
remove the recent acpi_osi blacklist entry below? It might be that
BIOS changed its mind to behave more kindly as if handling for Win7.
Takashi
---
diff --git a/drivers/acpi/blacklist.c b/drivers/acpi/blacklist.c
index 10e4964d051a..64d14406465d 100644
--- a/drivers/acpi/blacklist.c
+++ b/drivers/acpi/blacklist.c
@@ -322,6 +322,7 @@ static struct dmi_system_id acpi_osi_dmi_table[] __initdata = {
DMI_MATCH(DMI_PRODUCT_VERSION, "2349D15"),
},
},
+#if 0
{
.callback = dmi_disable_osi_win8,
.ident = "HP ProBook 2013 models",
@@ -372,6 +373,7 @@ static struct dmi_system_id acpi_osi_dmi_table[] __initdata = {
DMI_MATCH(DMI_PRODUCT_NAME, "HP EliteBook 8780w"),
},
},
+#endif
/*
* BIOS invocation of _OSI(Linux) is almost always a BIOS bug.
On Fri, Feb 14, 2014 at 02:37:00PM +0100, Takashi Iwai wrote:
> At Fri, 14 Feb 2014 14:34:07 +0200,
> Mika Westerberg wrote:
> >
> > This reverts commit e18ac62fa4b3f16234bab0d5a6627c57dbae9e7e.
> >
> > The referenced commit added HP EliteBook Revolve 810 to the ACPI video
> > detected blacklist so that only the native Intel backlight interface was
> > exported.
> >
> > However, this turned to be wrong solution after all. The ACPI video
> > interface works and as long as we only use that there are no problems. So
> > we can revert this commit and stick to use the backlight interface provided
> > by the ACPI video driver.
> >
> > (Using Intel native interface will not work after resume since the ACPI
> > video driver will restore it's state which takes control over the native
> > one. That's a separate thing and should be addressed in the ACPI video
> > driver, I suppose.)
> >
> > References: https://bugzilla.kernel.org/show_bug.cgi?id=70231
> > Cc: Aaron Lu <[email protected]>
> > Signed-off-by: Mika Westerberg <[email protected]>
> > ---
> > Rafael,
> >
> > This turned out to be misunderstanding from my side. I should have
> > investigated this further before submitting the original patch. Sorry about
> > that.
> >
> > Aaron,
> >
> > Thanks for the investigation and pointing me to the right direction (e.g to
> > use acpi_video0 over the native one).
>
> Could you check whether the ACPI video still really works even if you
> remove the recent acpi_osi blacklist entry below? It might be that
> BIOS changed its mind to behave more kindly as if handling for Win7.
>
>
> Takashi
>
> ---
> diff --git a/drivers/acpi/blacklist.c b/drivers/acpi/blacklist.c
> index 10e4964d051a..64d14406465d 100644
> --- a/drivers/acpi/blacklist.c
> +++ b/drivers/acpi/blacklist.c
> @@ -322,6 +322,7 @@ static struct dmi_system_id acpi_osi_dmi_table[] __initdata = {
> DMI_MATCH(DMI_PRODUCT_VERSION, "2349D15"),
> },
> },
> +#if 0
> {
> .callback = dmi_disable_osi_win8,
> .ident = "HP ProBook 2013 models",
> @@ -372,6 +373,7 @@ static struct dmi_system_id acpi_osi_dmi_table[] __initdata = {
> DMI_MATCH(DMI_PRODUCT_NAME, "HP EliteBook 8780w"),
> },
> },
> +#endif
>
> /*
> * BIOS invocation of _OSI(Linux) is almost always a BIOS bug.
After this patch is applied, the ACPI backlight doesn't work anymore. The
brightness stays the same, no matter what I do.
At Fri, 14 Feb 2014 16:03:16 +0200,
Mika Westerberg wrote:
>
> On Fri, Feb 14, 2014 at 02:37:00PM +0100, Takashi Iwai wrote:
> > At Fri, 14 Feb 2014 14:34:07 +0200,
> > Mika Westerberg wrote:
> > >
> > > This reverts commit e18ac62fa4b3f16234bab0d5a6627c57dbae9e7e.
> > >
> > > The referenced commit added HP EliteBook Revolve 810 to the ACPI video
> > > detected blacklist so that only the native Intel backlight interface was
> > > exported.
> > >
> > > However, this turned to be wrong solution after all. The ACPI video
> > > interface works and as long as we only use that there are no problems. So
> > > we can revert this commit and stick to use the backlight interface provided
> > > by the ACPI video driver.
> > >
> > > (Using Intel native interface will not work after resume since the ACPI
> > > video driver will restore it's state which takes control over the native
> > > one. That's a separate thing and should be addressed in the ACPI video
> > > driver, I suppose.)
> > >
> > > References: https://bugzilla.kernel.org/show_bug.cgi?id=70231
> > > Cc: Aaron Lu <[email protected]>
> > > Signed-off-by: Mika Westerberg <[email protected]>
> > > ---
> > > Rafael,
> > >
> > > This turned out to be misunderstanding from my side. I should have
> > > investigated this further before submitting the original patch. Sorry about
> > > that.
> > >
> > > Aaron,
> > >
> > > Thanks for the investigation and pointing me to the right direction (e.g to
> > > use acpi_video0 over the native one).
> >
> > Could you check whether the ACPI video still really works even if you
> > remove the recent acpi_osi blacklist entry below? It might be that
> > BIOS changed its mind to behave more kindly as if handling for Win7.
> >
> >
> > Takashi
> >
> > ---
> > diff --git a/drivers/acpi/blacklist.c b/drivers/acpi/blacklist.c
> > index 10e4964d051a..64d14406465d 100644
> > --- a/drivers/acpi/blacklist.c
> > +++ b/drivers/acpi/blacklist.c
> > @@ -322,6 +322,7 @@ static struct dmi_system_id acpi_osi_dmi_table[] __initdata = {
> > DMI_MATCH(DMI_PRODUCT_VERSION, "2349D15"),
> > },
> > },
> > +#if 0
> > {
> > .callback = dmi_disable_osi_win8,
> > .ident = "HP ProBook 2013 models",
> > @@ -372,6 +373,7 @@ static struct dmi_system_id acpi_osi_dmi_table[] __initdata = {
> > DMI_MATCH(DMI_PRODUCT_NAME, "HP EliteBook 8780w"),
> > },
> > },
> > +#endif
> >
> > /*
> > * BIOS invocation of _OSI(Linux) is almost always a BIOS bug.
>
> After this patch is applied, the ACPI backlight doesn't work anymore. The
> brightness stays the same, no matter what I do.
So, you need the video blacklist when acpi_osi blacklist doesn't
exist, right?
If the video blacklist works, it should be widened to match the
all recent HP machines as acpi_osi blacklist does (ProBook, EliteBook
and co). These are known to behave same. Then, after checking
hp-wireless is working, we can get rid of acpi_osi hack.
Takashi
On Fri, Feb 14, 2014 at 03:01:21PM +0100, Takashi Iwai wrote:
> At Fri, 14 Feb 2014 16:03:16 +0200,
> Mika Westerberg wrote:
> >
> > On Fri, Feb 14, 2014 at 02:37:00PM +0100, Takashi Iwai wrote:
> > > At Fri, 14 Feb 2014 14:34:07 +0200,
> > > Mika Westerberg wrote:
> > > >
> > > > This reverts commit e18ac62fa4b3f16234bab0d5a6627c57dbae9e7e.
> > > >
> > > > The referenced commit added HP EliteBook Revolve 810 to the ACPI video
> > > > detected blacklist so that only the native Intel backlight interface was
> > > > exported.
> > > >
> > > > However, this turned to be wrong solution after all. The ACPI video
> > > > interface works and as long as we only use that there are no problems. So
> > > > we can revert this commit and stick to use the backlight interface provided
> > > > by the ACPI video driver.
> > > >
> > > > (Using Intel native interface will not work after resume since the ACPI
> > > > video driver will restore it's state which takes control over the native
> > > > one. That's a separate thing and should be addressed in the ACPI video
> > > > driver, I suppose.)
> > > >
> > > > References: https://bugzilla.kernel.org/show_bug.cgi?id=70231
> > > > Cc: Aaron Lu <[email protected]>
> > > > Signed-off-by: Mika Westerberg <[email protected]>
> > > > ---
> > > > Rafael,
> > > >
> > > > This turned out to be misunderstanding from my side. I should have
> > > > investigated this further before submitting the original patch. Sorry about
> > > > that.
> > > >
> > > > Aaron,
> > > >
> > > > Thanks for the investigation and pointing me to the right direction (e.g to
> > > > use acpi_video0 over the native one).
> > >
> > > Could you check whether the ACPI video still really works even if you
> > > remove the recent acpi_osi blacklist entry below? It might be that
> > > BIOS changed its mind to behave more kindly as if handling for Win7.
> > >
> > >
> > > Takashi
> > >
> > > ---
> > > diff --git a/drivers/acpi/blacklist.c b/drivers/acpi/blacklist.c
> > > index 10e4964d051a..64d14406465d 100644
> > > --- a/drivers/acpi/blacklist.c
> > > +++ b/drivers/acpi/blacklist.c
> > > @@ -322,6 +322,7 @@ static struct dmi_system_id acpi_osi_dmi_table[] __initdata = {
> > > DMI_MATCH(DMI_PRODUCT_VERSION, "2349D15"),
> > > },
> > > },
> > > +#if 0
> > > {
> > > .callback = dmi_disable_osi_win8,
> > > .ident = "HP ProBook 2013 models",
> > > @@ -372,6 +373,7 @@ static struct dmi_system_id acpi_osi_dmi_table[] __initdata = {
> > > DMI_MATCH(DMI_PRODUCT_NAME, "HP EliteBook 8780w"),
> > > },
> > > },
> > > +#endif
> > >
> > > /*
> > > * BIOS invocation of _OSI(Linux) is almost always a BIOS bug.
> >
> > After this patch is applied, the ACPI backlight doesn't work anymore. The
> > brightness stays the same, no matter what I do.
>
> So, you need the video blacklist when acpi_osi blacklist doesn't
> exist, right?
In my case I don't actually need video blacklist if I use only ACPI video
for backlight control. Then it works fine.
However, using intel_backlight will cause ACPI video to restore its
settings over the Intel one on resume.
At Fri, 14 Feb 2014 16:16:52 +0200,
Mika Westerberg wrote:
>
> On Fri, Feb 14, 2014 at 03:01:21PM +0100, Takashi Iwai wrote:
> > At Fri, 14 Feb 2014 16:03:16 +0200,
> > Mika Westerberg wrote:
> > >
> > > On Fri, Feb 14, 2014 at 02:37:00PM +0100, Takashi Iwai wrote:
> > > > At Fri, 14 Feb 2014 14:34:07 +0200,
> > > > Mika Westerberg wrote:
> > > > >
> > > > > This reverts commit e18ac62fa4b3f16234bab0d5a6627c57dbae9e7e.
> > > > >
> > > > > The referenced commit added HP EliteBook Revolve 810 to the ACPI video
> > > > > detected blacklist so that only the native Intel backlight interface was
> > > > > exported.
> > > > >
> > > > > However, this turned to be wrong solution after all. The ACPI video
> > > > > interface works and as long as we only use that there are no problems. So
> > > > > we can revert this commit and stick to use the backlight interface provided
> > > > > by the ACPI video driver.
> > > > >
> > > > > (Using Intel native interface will not work after resume since the ACPI
> > > > > video driver will restore it's state which takes control over the native
> > > > > one. That's a separate thing and should be addressed in the ACPI video
> > > > > driver, I suppose.)
> > > > >
> > > > > References: https://bugzilla.kernel.org/show_bug.cgi?id=70231
> > > > > Cc: Aaron Lu <[email protected]>
> > > > > Signed-off-by: Mika Westerberg <[email protected]>
> > > > > ---
> > > > > Rafael,
> > > > >
> > > > > This turned out to be misunderstanding from my side. I should have
> > > > > investigated this further before submitting the original patch. Sorry about
> > > > > that.
> > > > >
> > > > > Aaron,
> > > > >
> > > > > Thanks for the investigation and pointing me to the right direction (e.g to
> > > > > use acpi_video0 over the native one).
> > > >
> > > > Could you check whether the ACPI video still really works even if you
> > > > remove the recent acpi_osi blacklist entry below? It might be that
> > > > BIOS changed its mind to behave more kindly as if handling for Win7.
> > > >
> > > >
> > > > Takashi
> > > >
> > > > ---
> > > > diff --git a/drivers/acpi/blacklist.c b/drivers/acpi/blacklist.c
> > > > index 10e4964d051a..64d14406465d 100644
> > > > --- a/drivers/acpi/blacklist.c
> > > > +++ b/drivers/acpi/blacklist.c
> > > > @@ -322,6 +322,7 @@ static struct dmi_system_id acpi_osi_dmi_table[] __initdata = {
> > > > DMI_MATCH(DMI_PRODUCT_VERSION, "2349D15"),
> > > > },
> > > > },
> > > > +#if 0
> > > > {
> > > > .callback = dmi_disable_osi_win8,
> > > > .ident = "HP ProBook 2013 models",
> > > > @@ -372,6 +373,7 @@ static struct dmi_system_id acpi_osi_dmi_table[] __initdata = {
> > > > DMI_MATCH(DMI_PRODUCT_NAME, "HP EliteBook 8780w"),
> > > > },
> > > > },
> > > > +#endif
> > > >
> > > > /*
> > > > * BIOS invocation of _OSI(Linux) is almost always a BIOS bug.
> > >
> > > After this patch is applied, the ACPI backlight doesn't work anymore. The
> > > brightness stays the same, no matter what I do.
> >
> > So, you need the video blacklist when acpi_osi blacklist doesn't
> > exist, right?
>
> In my case I don't actually need video blacklist if I use only ACPI video
> for backlight control. Then it works fine.
Hmm, after removing acpi_osi blacklist above, you loose the ACPI video
backlight doesn't work, no? If so, you need the video blacklist.
Am I missing anything obvious...?
> However, using intel_backlight will cause ACPI video to restore its
> settings over the Intel one on resume.
I guess the very reason why ACPI video backlight doesn't work in Win8
BIOS mode -- ACPI video won't conflict the native backlight.
Takashi
On Fri, Feb 14, 2014 at 03:16:58PM +0100, Takashi Iwai wrote:
> At Fri, 14 Feb 2014 16:16:52 +0200,
> Mika Westerberg wrote:
> >
> > On Fri, Feb 14, 2014 at 03:01:21PM +0100, Takashi Iwai wrote:
> > > At Fri, 14 Feb 2014 16:03:16 +0200,
> > > Mika Westerberg wrote:
> > > >
> > > > On Fri, Feb 14, 2014 at 02:37:00PM +0100, Takashi Iwai wrote:
> > > > > At Fri, 14 Feb 2014 14:34:07 +0200,
> > > > > Mika Westerberg wrote:
> > > > > >
> > > > > > This reverts commit e18ac62fa4b3f16234bab0d5a6627c57dbae9e7e.
> > > > > >
> > > > > > The referenced commit added HP EliteBook Revolve 810 to the ACPI video
> > > > > > detected blacklist so that only the native Intel backlight interface was
> > > > > > exported.
> > > > > >
> > > > > > However, this turned to be wrong solution after all. The ACPI video
> > > > > > interface works and as long as we only use that there are no problems. So
> > > > > > we can revert this commit and stick to use the backlight interface provided
> > > > > > by the ACPI video driver.
> > > > > >
> > > > > > (Using Intel native interface will not work after resume since the ACPI
> > > > > > video driver will restore it's state which takes control over the native
> > > > > > one. That's a separate thing and should be addressed in the ACPI video
> > > > > > driver, I suppose.)
> > > > > >
> > > > > > References: https://bugzilla.kernel.org/show_bug.cgi?id=70231
> > > > > > Cc: Aaron Lu <[email protected]>
> > > > > > Signed-off-by: Mika Westerberg <[email protected]>
> > > > > > ---
> > > > > > Rafael,
> > > > > >
> > > > > > This turned out to be misunderstanding from my side. I should have
> > > > > > investigated this further before submitting the original patch. Sorry about
> > > > > > that.
> > > > > >
> > > > > > Aaron,
> > > > > >
> > > > > > Thanks for the investigation and pointing me to the right direction (e.g to
> > > > > > use acpi_video0 over the native one).
> > > > >
> > > > > Could you check whether the ACPI video still really works even if you
> > > > > remove the recent acpi_osi blacklist entry below? It might be that
> > > > > BIOS changed its mind to behave more kindly as if handling for Win7.
> > > > >
> > > > >
> > > > > Takashi
> > > > >
> > > > > ---
> > > > > diff --git a/drivers/acpi/blacklist.c b/drivers/acpi/blacklist.c
> > > > > index 10e4964d051a..64d14406465d 100644
> > > > > --- a/drivers/acpi/blacklist.c
> > > > > +++ b/drivers/acpi/blacklist.c
> > > > > @@ -322,6 +322,7 @@ static struct dmi_system_id acpi_osi_dmi_table[] __initdata = {
> > > > > DMI_MATCH(DMI_PRODUCT_VERSION, "2349D15"),
> > > > > },
> > > > > },
> > > > > +#if 0
> > > > > {
> > > > > .callback = dmi_disable_osi_win8,
> > > > > .ident = "HP ProBook 2013 models",
> > > > > @@ -372,6 +373,7 @@ static struct dmi_system_id acpi_osi_dmi_table[] __initdata = {
> > > > > DMI_MATCH(DMI_PRODUCT_NAME, "HP EliteBook 8780w"),
> > > > > },
> > > > > },
> > > > > +#endif
> > > > >
> > > > > /*
> > > > > * BIOS invocation of _OSI(Linux) is almost always a BIOS bug.
> > > >
> > > > After this patch is applied, the ACPI backlight doesn't work anymore. The
> > > > brightness stays the same, no matter what I do.
> > >
> > > So, you need the video blacklist when acpi_osi blacklist doesn't
> > > exist, right?
> >
> > In my case I don't actually need video blacklist if I use only ACPI video
> > for backlight control. Then it works fine.
>
> Hmm, after removing acpi_osi blacklist above, you loose the ACPI video
> backlight doesn't work, no? If so, you need the video blacklist.
> Am I missing anything obvious...?
Yes, the machine needs to be in acpi_osi blacklist then the ACPI video
works fine.
> > However, using intel_backlight will cause ACPI video to restore its
> > settings over the Intel one on resume.
>
> I guess the very reason why ACPI video backlight doesn't work in Win8
> BIOS mode -- ACPI video won't conflict the native backlight.
That might be. I'm not really familiar with the whole backlight mess. Just
trying to get my machine working :)
At Fri, 14 Feb 2014 16:45:24 +0200,
Mika Westerberg wrote:
>
> On Fri, Feb 14, 2014 at 03:16:58PM +0100, Takashi Iwai wrote:
> > At Fri, 14 Feb 2014 16:16:52 +0200,
> > Mika Westerberg wrote:
> > >
> > > On Fri, Feb 14, 2014 at 03:01:21PM +0100, Takashi Iwai wrote:
> > > > At Fri, 14 Feb 2014 16:03:16 +0200,
> > > > Mika Westerberg wrote:
> > > > >
> > > > > On Fri, Feb 14, 2014 at 02:37:00PM +0100, Takashi Iwai wrote:
> > > > > > At Fri, 14 Feb 2014 14:34:07 +0200,
> > > > > > Mika Westerberg wrote:
> > > > > > >
> > > > > > > This reverts commit e18ac62fa4b3f16234bab0d5a6627c57dbae9e7e.
> > > > > > >
> > > > > > > The referenced commit added HP EliteBook Revolve 810 to the ACPI video
> > > > > > > detected blacklist so that only the native Intel backlight interface was
> > > > > > > exported.
> > > > > > >
> > > > > > > However, this turned to be wrong solution after all. The ACPI video
> > > > > > > interface works and as long as we only use that there are no problems. So
> > > > > > > we can revert this commit and stick to use the backlight interface provided
> > > > > > > by the ACPI video driver.
> > > > > > >
> > > > > > > (Using Intel native interface will not work after resume since the ACPI
> > > > > > > video driver will restore it's state which takes control over the native
> > > > > > > one. That's a separate thing and should be addressed in the ACPI video
> > > > > > > driver, I suppose.)
> > > > > > >
> > > > > > > References: https://bugzilla.kernel.org/show_bug.cgi?id=70231
> > > > > > > Cc: Aaron Lu <[email protected]>
> > > > > > > Signed-off-by: Mika Westerberg <[email protected]>
> > > > > > > ---
> > > > > > > Rafael,
> > > > > > >
> > > > > > > This turned out to be misunderstanding from my side. I should have
> > > > > > > investigated this further before submitting the original patch. Sorry about
> > > > > > > that.
> > > > > > >
> > > > > > > Aaron,
> > > > > > >
> > > > > > > Thanks for the investigation and pointing me to the right direction (e.g to
> > > > > > > use acpi_video0 over the native one).
> > > > > >
> > > > > > Could you check whether the ACPI video still really works even if you
> > > > > > remove the recent acpi_osi blacklist entry below? It might be that
> > > > > > BIOS changed its mind to behave more kindly as if handling for Win7.
> > > > > >
> > > > > >
> > > > > > Takashi
> > > > > >
> > > > > > ---
> > > > > > diff --git a/drivers/acpi/blacklist.c b/drivers/acpi/blacklist.c
> > > > > > index 10e4964d051a..64d14406465d 100644
> > > > > > --- a/drivers/acpi/blacklist.c
> > > > > > +++ b/drivers/acpi/blacklist.c
> > > > > > @@ -322,6 +322,7 @@ static struct dmi_system_id acpi_osi_dmi_table[] __initdata = {
> > > > > > DMI_MATCH(DMI_PRODUCT_VERSION, "2349D15"),
> > > > > > },
> > > > > > },
> > > > > > +#if 0
> > > > > > {
> > > > > > .callback = dmi_disable_osi_win8,
> > > > > > .ident = "HP ProBook 2013 models",
> > > > > > @@ -372,6 +373,7 @@ static struct dmi_system_id acpi_osi_dmi_table[] __initdata = {
> > > > > > DMI_MATCH(DMI_PRODUCT_NAME, "HP EliteBook 8780w"),
> > > > > > },
> > > > > > },
> > > > > > +#endif
> > > > > >
> > > > > > /*
> > > > > > * BIOS invocation of _OSI(Linux) is almost always a BIOS bug.
> > > > >
> > > > > After this patch is applied, the ACPI backlight doesn't work anymore. The
> > > > > brightness stays the same, no matter what I do.
> > > >
> > > > So, you need the video blacklist when acpi_osi blacklist doesn't
> > > > exist, right?
> > >
> > > In my case I don't actually need video blacklist if I use only ACPI video
> > > for backlight control. Then it works fine.
> >
> > Hmm, after removing acpi_osi blacklist above, you loose the ACPI video
> > backlight doesn't work, no? If so, you need the video blacklist.
> > Am I missing anything obvious...?
>
> Yes, the machine needs to be in acpi_osi blacklist then the ACPI video
> works fine.
The acpi_osi blacklist is just a workaround, and if we have better
solutions, it should be removed. That's why I'm asking it.
So, after removing acpi_osi blacklist, and keeping your video
blacklist patch, the backlight works? If yes, as mentioned, we should
think of rather extending this video blacklist to more EliteBook G1
and ProBook G1 machines, and remove acpi_osi blacklist instead.
Now hp-wireless is there, so the rfkill part should work without
acpi_osi blacklist, too.
Takashi
On 02/14/2014 10:01 PM, Takashi Iwai wrote:
> At Fri, 14 Feb 2014 16:03:16 +0200,
> Mika Westerberg wrote:
>>
>> On Fri, Feb 14, 2014 at 02:37:00PM +0100, Takashi Iwai wrote:
>>> At Fri, 14 Feb 2014 14:34:07 +0200,
>>> Mika Westerberg wrote:
>>>>
>>>> This reverts commit e18ac62fa4b3f16234bab0d5a6627c57dbae9e7e.
>>>>
>>>> The referenced commit added HP EliteBook Revolve 810 to the ACPI video
>>>> detected blacklist so that only the native Intel backlight interface was
>>>> exported.
>>>>
>>>> However, this turned to be wrong solution after all. The ACPI video
>>>> interface works and as long as we only use that there are no problems. So
>>>> we can revert this commit and stick to use the backlight interface provided
>>>> by the ACPI video driver.
>>>>
>>>> (Using Intel native interface will not work after resume since the ACPI
>>>> video driver will restore it's state which takes control over the native
>>>> one. That's a separate thing and should be addressed in the ACPI video
>>>> driver, I suppose.)
>>>>
>>>> References: https://bugzilla.kernel.org/show_bug.cgi?id=70231
>>>> Cc: Aaron Lu <[email protected]>
>>>> Signed-off-by: Mika Westerberg <[email protected]>
>>>> ---
>>>> Rafael,
>>>>
>>>> This turned out to be misunderstanding from my side. I should have
>>>> investigated this further before submitting the original patch. Sorry about
>>>> that.
>>>>
>>>> Aaron,
>>>>
>>>> Thanks for the investigation and pointing me to the right direction (e.g to
>>>> use acpi_video0 over the native one).
>>>
>>> Could you check whether the ACPI video still really works even if you
>>> remove the recent acpi_osi blacklist entry below? It might be that
>>> BIOS changed its mind to behave more kindly as if handling for Win7.
>>>
>>>
>>> Takashi
>>>
>>> ---
>>> diff --git a/drivers/acpi/blacklist.c b/drivers/acpi/blacklist.c
>>> index 10e4964d051a..64d14406465d 100644
>>> --- a/drivers/acpi/blacklist.c
>>> +++ b/drivers/acpi/blacklist.c
>>> @@ -322,6 +322,7 @@ static struct dmi_system_id acpi_osi_dmi_table[] __initdata = {
>>> DMI_MATCH(DMI_PRODUCT_VERSION, "2349D15"),
>>> },
>>> },
>>> +#if 0
>>> {
>>> .callback = dmi_disable_osi_win8,
>>> .ident = "HP ProBook 2013 models",
>>> @@ -372,6 +373,7 @@ static struct dmi_system_id acpi_osi_dmi_table[] __initdata = {
>>> DMI_MATCH(DMI_PRODUCT_NAME, "HP EliteBook 8780w"),
>>> },
>>> },
>>> +#endif
>>>
>>> /*
>>> * BIOS invocation of _OSI(Linux) is almost always a BIOS bug.
>>
>> After this patch is applied, the ACPI backlight doesn't work anymore. The
>> brightness stays the same, no matter what I do.
>
> So, you need the video blacklist when acpi_osi blacklist doesn't
> exist, right?
Yes, but not in the video_detect DMI table. A table for systems
that should favour native backlight control interface should be
used in this case. Or we can simply make all Win8 systems favour
native backlight control interface in video module. That is the
decision we need to make then.
On 02/14/2014 10:46 PM, Takashi Iwai wrote:
> At Fri, 14 Feb 2014 16:45:24 +0200,
> Mika Westerberg wrote:
>>
>> On Fri, Feb 14, 2014 at 03:16:58PM +0100, Takashi Iwai wrote:
>>> At Fri, 14 Feb 2014 16:16:52 +0200,
>>> Mika Westerberg wrote:
>>>>
>>>> On Fri, Feb 14, 2014 at 03:01:21PM +0100, Takashi Iwai wrote:
>>>>> At Fri, 14 Feb 2014 16:03:16 +0200,
>>>>> Mika Westerberg wrote:
>>>>>>
>>>>>> On Fri, Feb 14, 2014 at 02:37:00PM +0100, Takashi Iwai wrote:
>>>>>>> At Fri, 14 Feb 2014 14:34:07 +0200,
>>>>>>> Mika Westerberg wrote:
>>>>>>>>
>>>>>>>> This reverts commit e18ac62fa4b3f16234bab0d5a6627c57dbae9e7e.
>>>>>>>>
>>>>>>>> The referenced commit added HP EliteBook Revolve 810 to the ACPI video
>>>>>>>> detected blacklist so that only the native Intel backlight interface was
>>>>>>>> exported.
>>>>>>>>
>>>>>>>> However, this turned to be wrong solution after all. The ACPI video
>>>>>>>> interface works and as long as we only use that there are no problems. So
>>>>>>>> we can revert this commit and stick to use the backlight interface provided
>>>>>>>> by the ACPI video driver.
>>>>>>>>
>>>>>>>> (Using Intel native interface will not work after resume since the ACPI
>>>>>>>> video driver will restore it's state which takes control over the native
>>>>>>>> one. That's a separate thing and should be addressed in the ACPI video
>>>>>>>> driver, I suppose.)
>>>>>>>>
>>>>>>>> References: https://bugzilla.kernel.org/show_bug.cgi?id=70231
>>>>>>>> Cc: Aaron Lu <[email protected]>
>>>>>>>> Signed-off-by: Mika Westerberg <[email protected]>
>>>>>>>> ---
>>>>>>>> Rafael,
>>>>>>>>
>>>>>>>> This turned out to be misunderstanding from my side. I should have
>>>>>>>> investigated this further before submitting the original patch. Sorry about
>>>>>>>> that.
>>>>>>>>
>>>>>>>> Aaron,
>>>>>>>>
>>>>>>>> Thanks for the investigation and pointing me to the right direction (e.g to
>>>>>>>> use acpi_video0 over the native one).
>>>>>>>
>>>>>>> Could you check whether the ACPI video still really works even if you
>>>>>>> remove the recent acpi_osi blacklist entry below? It might be that
>>>>>>> BIOS changed its mind to behave more kindly as if handling for Win7.
>>>>>>>
>>>>>>>
>>>>>>> Takashi
>>>>>>>
>>>>>>> ---
>>>>>>> diff --git a/drivers/acpi/blacklist.c b/drivers/acpi/blacklist.c
>>>>>>> index 10e4964d051a..64d14406465d 100644
>>>>>>> --- a/drivers/acpi/blacklist.c
>>>>>>> +++ b/drivers/acpi/blacklist.c
>>>>>>> @@ -322,6 +322,7 @@ static struct dmi_system_id acpi_osi_dmi_table[] __initdata = {
>>>>>>> DMI_MATCH(DMI_PRODUCT_VERSION, "2349D15"),
>>>>>>> },
>>>>>>> },
>>>>>>> +#if 0
>>>>>>> {
>>>>>>> .callback = dmi_disable_osi_win8,
>>>>>>> .ident = "HP ProBook 2013 models",
>>>>>>> @@ -372,6 +373,7 @@ static struct dmi_system_id acpi_osi_dmi_table[] __initdata = {
>>>>>>> DMI_MATCH(DMI_PRODUCT_NAME, "HP EliteBook 8780w"),
>>>>>>> },
>>>>>>> },
>>>>>>> +#endif
>>>>>>>
>>>>>>> /*
>>>>>>> * BIOS invocation of _OSI(Linux) is almost always a BIOS bug.
>>>>>>
>>>>>> After this patch is applied, the ACPI backlight doesn't work anymore. The
>>>>>> brightness stays the same, no matter what I do.
>>>>>
>>>>> So, you need the video blacklist when acpi_osi blacklist doesn't
>>>>> exist, right?
>>>>
>>>> In my case I don't actually need video blacklist if I use only ACPI video
>>>> for backlight control. Then it works fine.
>>>
>>> Hmm, after removing acpi_osi blacklist above, you loose the ACPI video
>>> backlight doesn't work, no? If so, you need the video blacklist.
>>> Am I missing anything obvious...?
>>
>> Yes, the machine needs to be in acpi_osi blacklist then the ACPI video
>> works fine.
>
> The acpi_osi blacklist is just a workaround, and if we have better
> solutions, it should be removed. That's why I'm asking it.
>
> So, after removing acpi_osi blacklist, and keeping your video
> blacklist patch, the backlight works? If yes, as mentioned, we should
> think of rather extending this video blacklist to more EliteBook G1
> and ProBook G1 machines, and remove acpi_osi blacklist instead.
Agree.
>
> Now hp-wireless is there, so the rfkill part should work without
> acpi_osi blacklist, too.
Suppose we have some work around of making backlight work for
them in Win8 mode, it seems the acpi_osi blacklist is ready to
be removed now?
At Fri, 14 Feb 2014 22:50:44 +0800,
Aaron Lu wrote:
>
> On 02/14/2014 10:46 PM, Takashi Iwai wrote:
> > At Fri, 14 Feb 2014 16:45:24 +0200,
> > Mika Westerberg wrote:
> >>
> >> On Fri, Feb 14, 2014 at 03:16:58PM +0100, Takashi Iwai wrote:
> >>> At Fri, 14 Feb 2014 16:16:52 +0200,
> >>> Mika Westerberg wrote:
> >>>>
> >>>> On Fri, Feb 14, 2014 at 03:01:21PM +0100, Takashi Iwai wrote:
> >>>>> At Fri, 14 Feb 2014 16:03:16 +0200,
> >>>>> Mika Westerberg wrote:
> >>>>>>
> >>>>>> On Fri, Feb 14, 2014 at 02:37:00PM +0100, Takashi Iwai wrote:
> >>>>>>> At Fri, 14 Feb 2014 14:34:07 +0200,
> >>>>>>> Mika Westerberg wrote:
> >>>>>>>>
> >>>>>>>> This reverts commit e18ac62fa4b3f16234bab0d5a6627c57dbae9e7e.
> >>>>>>>>
> >>>>>>>> The referenced commit added HP EliteBook Revolve 810 to the ACPI video
> >>>>>>>> detected blacklist so that only the native Intel backlight interface was
> >>>>>>>> exported.
> >>>>>>>>
> >>>>>>>> However, this turned to be wrong solution after all. The ACPI video
> >>>>>>>> interface works and as long as we only use that there are no problems. So
> >>>>>>>> we can revert this commit and stick to use the backlight interface provided
> >>>>>>>> by the ACPI video driver.
> >>>>>>>>
> >>>>>>>> (Using Intel native interface will not work after resume since the ACPI
> >>>>>>>> video driver will restore it's state which takes control over the native
> >>>>>>>> one. That's a separate thing and should be addressed in the ACPI video
> >>>>>>>> driver, I suppose.)
> >>>>>>>>
> >>>>>>>> References: https://bugzilla.kernel.org/show_bug.cgi?id=70231
> >>>>>>>> Cc: Aaron Lu <[email protected]>
> >>>>>>>> Signed-off-by: Mika Westerberg <[email protected]>
> >>>>>>>> ---
> >>>>>>>> Rafael,
> >>>>>>>>
> >>>>>>>> This turned out to be misunderstanding from my side. I should have
> >>>>>>>> investigated this further before submitting the original patch. Sorry about
> >>>>>>>> that.
> >>>>>>>>
> >>>>>>>> Aaron,
> >>>>>>>>
> >>>>>>>> Thanks for the investigation and pointing me to the right direction (e.g to
> >>>>>>>> use acpi_video0 over the native one).
> >>>>>>>
> >>>>>>> Could you check whether the ACPI video still really works even if you
> >>>>>>> remove the recent acpi_osi blacklist entry below? It might be that
> >>>>>>> BIOS changed its mind to behave more kindly as if handling for Win7.
> >>>>>>>
> >>>>>>>
> >>>>>>> Takashi
> >>>>>>>
> >>>>>>> ---
> >>>>>>> diff --git a/drivers/acpi/blacklist.c b/drivers/acpi/blacklist.c
> >>>>>>> index 10e4964d051a..64d14406465d 100644
> >>>>>>> --- a/drivers/acpi/blacklist.c
> >>>>>>> +++ b/drivers/acpi/blacklist.c
> >>>>>>> @@ -322,6 +322,7 @@ static struct dmi_system_id acpi_osi_dmi_table[] __initdata = {
> >>>>>>> DMI_MATCH(DMI_PRODUCT_VERSION, "2349D15"),
> >>>>>>> },
> >>>>>>> },
> >>>>>>> +#if 0
> >>>>>>> {
> >>>>>>> .callback = dmi_disable_osi_win8,
> >>>>>>> .ident = "HP ProBook 2013 models",
> >>>>>>> @@ -372,6 +373,7 @@ static struct dmi_system_id acpi_osi_dmi_table[] __initdata = {
> >>>>>>> DMI_MATCH(DMI_PRODUCT_NAME, "HP EliteBook 8780w"),
> >>>>>>> },
> >>>>>>> },
> >>>>>>> +#endif
> >>>>>>>
> >>>>>>> /*
> >>>>>>> * BIOS invocation of _OSI(Linux) is almost always a BIOS bug.
> >>>>>>
> >>>>>> After this patch is applied, the ACPI backlight doesn't work anymore. The
> >>>>>> brightness stays the same, no matter what I do.
> >>>>>
> >>>>> So, you need the video blacklist when acpi_osi blacklist doesn't
> >>>>> exist, right?
> >>>>
> >>>> In my case I don't actually need video blacklist if I use only ACPI video
> >>>> for backlight control. Then it works fine.
> >>>
> >>> Hmm, after removing acpi_osi blacklist above, you loose the ACPI video
> >>> backlight doesn't work, no? If so, you need the video blacklist.
> >>> Am I missing anything obvious...?
> >>
> >> Yes, the machine needs to be in acpi_osi blacklist then the ACPI video
> >> works fine.
> >
> > The acpi_osi blacklist is just a workaround, and if we have better
> > solutions, it should be removed. That's why I'm asking it.
> >
> > So, after removing acpi_osi blacklist, and keeping your video
> > blacklist patch, the backlight works? If yes, as mentioned, we should
> > think of rather extending this video blacklist to more EliteBook G1
> > and ProBook G1 machines, and remove acpi_osi blacklist instead.
>
> Agree.
>
> >
> > Now hp-wireless is there, so the rfkill part should work without
> > acpi_osi blacklist, too.
>
> Suppose we have some work around of making backlight work for
> them in Win8 mode, it seems the acpi_osi blacklist is ready to
> be removed now?
Once after confirming it really works ;)
I'll check other machines and report back in the next week.
Takashi
On Fri, Feb 14, 2014 at 03:46:20PM +0100, Takashi Iwai wrote:
> The acpi_osi blacklist is just a workaround, and if we have better
> solutions, it should be removed. That's why I'm asking it.
>
> So, after removing acpi_osi blacklist, and keeping your video
> blacklist patch, the backlight works?
Yes, the backlight works (there is only intel_backlight listed under
/sys/class/backlight).
> If yes, as mentioned, we should think of rather extending this video
> blacklist to more EliteBook G1 and ProBook G1 machines, and remove
> acpi_osi blacklist instead.
Makes sense to me. (Well, I'm fine as long as backlight on my machine works
;-))
Aaron, Rafael, any comments on this?
On Friday, February 14, 2014 05:26:01 PM Mika Westerberg wrote:
> On Fri, Feb 14, 2014 at 03:46:20PM +0100, Takashi Iwai wrote:
> > The acpi_osi blacklist is just a workaround, and if we have better
> > solutions, it should be removed. That's why I'm asking it.
> >
> > So, after removing acpi_osi blacklist, and keeping your video
> > blacklist patch, the backlight works?
>
> Yes, the backlight works (there is only intel_backlight listed under
> /sys/class/backlight).
>
> > If yes, as mentioned, we should think of rather extending this video
> > blacklist to more EliteBook G1 and ProBook G1 machines, and remove
> > acpi_osi blacklist instead.
>
> Makes sense to me. (Well, I'm fine as long as backlight on my machine works
> ;-))
>
> Aaron, Rafael, any comments on this?
I generally agree with Takashi, but I'm not sure what to do for 3.14.
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
On 02/15/2014 06:21 AM, Rafael J. Wysocki wrote:
> On Friday, February 14, 2014 05:26:01 PM Mika Westerberg wrote:
>> On Fri, Feb 14, 2014 at 03:46:20PM +0100, Takashi Iwai wrote:
>>> The acpi_osi blacklist is just a workaround, and if we have better
>>> solutions, it should be removed. That's why I'm asking it.
>>>
>>> So, after removing acpi_osi blacklist, and keeping your video
>>> blacklist patch, the backlight works?
>>
>> Yes, the backlight works (there is only intel_backlight listed under
>> /sys/class/backlight).
>>
>>> If yes, as mentioned, we should think of rather extending this video
>>> blacklist to more EliteBook G1 and ProBook G1 machines, and remove
>>> acpi_osi blacklist instead.
>>
>> Makes sense to me. (Well, I'm fine as long as backlight on my machine works
>> ;-))
>>
>> Aaron, Rafael, any comments on this?
>
> I generally agree with Takashi, but I'm not sure what to do for 3.14.
I can re-base the previously sent patch titled:
[PATCH] ACPI / video: Add systems that should favor native backlight interface
And put Mika's system into the DMI table that will use native backlight
interface in video module and remove it from video_detect's DMI table at
the same time. Does this sound OK?
On Mon, Feb 17, 2014 at 01:52:46PM +0800, Aaron Lu wrote:
> On 02/15/2014 06:21 AM, Rafael J. Wysocki wrote:
> > On Friday, February 14, 2014 05:26:01 PM Mika Westerberg wrote:
> >> On Fri, Feb 14, 2014 at 03:46:20PM +0100, Takashi Iwai wrote:
> >>> The acpi_osi blacklist is just a workaround, and if we have better
> >>> solutions, it should be removed. That's why I'm asking it.
> >>>
> >>> So, after removing acpi_osi blacklist, and keeping your video
> >>> blacklist patch, the backlight works?
> >>
> >> Yes, the backlight works (there is only intel_backlight listed under
> >> /sys/class/backlight).
> >>
> >>> If yes, as mentioned, we should think of rather extending this video
> >>> blacklist to more EliteBook G1 and ProBook G1 machines, and remove
> >>> acpi_osi blacklist instead.
> >>
> >> Makes sense to me. (Well, I'm fine as long as backlight on my machine works
> >> ;-))
> >>
> >> Aaron, Rafael, any comments on this?
> >
> > I generally agree with Takashi, but I'm not sure what to do for 3.14.
>
> I can re-base the previously sent patch titled:
> [PATCH] ACPI / video: Add systems that should favor native backlight interface
> And put Mika's system into the DMI table that will use native backlight
> interface in video module and remove it from video_detect's DMI table at
> the same time. Does this sound OK?
You also need to remove it from the acpi_osi blacklist.
Anyway, that sounds good to me. Not sure if that's suitable for 3.14,
though.
At Mon, 17 Feb 2014 13:52:46 +0800,
Aaron Lu wrote:
>
> On 02/15/2014 06:21 AM, Rafael J. Wysocki wrote:
> > On Friday, February 14, 2014 05:26:01 PM Mika Westerberg wrote:
> >> On Fri, Feb 14, 2014 at 03:46:20PM +0100, Takashi Iwai wrote:
> >>> The acpi_osi blacklist is just a workaround, and if we have better
> >>> solutions, it should be removed. That's why I'm asking it.
> >>>
> >>> So, after removing acpi_osi blacklist, and keeping your video
> >>> blacklist patch, the backlight works?
> >>
> >> Yes, the backlight works (there is only intel_backlight listed under
> >> /sys/class/backlight).
> >>
> >>> If yes, as mentioned, we should think of rather extending this video
> >>> blacklist to more EliteBook G1 and ProBook G1 machines, and remove
> >>> acpi_osi blacklist instead.
> >>
> >> Makes sense to me. (Well, I'm fine as long as backlight on my machine works
> >> ;-))
> >>
> >> Aaron, Rafael, any comments on this?
> >
> > I generally agree with Takashi, but I'm not sure what to do for 3.14.
>
> I can re-base the previously sent patch titled:
> [PATCH] ACPI / video: Add systems that should favor native backlight interface
> And put Mika's system into the DMI table that will use native backlight
> interface in video module and remove it from video_detect's DMI table at
> the same time. Does this sound OK?
Rather put more generic DMI entries for the recent HP ProBook and
EliteBook machines as in acpi_osi blacklist:
{
.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"),
},
},
All these are known to have different behavior with Win8, including
the broken ACPI backlight. Once after merging that patch, we can
revert the commit 2d4054d84224.
I suppose it'd be OK for to do these for 3.14, since the acpi_osi
commit was merged first in 3.14. Then we can continue fixing in a
saner way.
thanks,
Takashi
On 02/17/2014 05:56 PM, Takashi Iwai wrote:
> At Mon, 17 Feb 2014 13:52:46 +0800,
> Aaron Lu wrote:
>>
>> On 02/15/2014 06:21 AM, Rafael J. Wysocki wrote:
>>> On Friday, February 14, 2014 05:26:01 PM Mika Westerberg wrote:
>>>> On Fri, Feb 14, 2014 at 03:46:20PM +0100, Takashi Iwai wrote:
>>>>> The acpi_osi blacklist is just a workaround, and if we have better
>>>>> solutions, it should be removed. That's why I'm asking it.
>>>>>
>>>>> So, after removing acpi_osi blacklist, and keeping your video
>>>>> blacklist patch, the backlight works?
>>>>
>>>> Yes, the backlight works (there is only intel_backlight listed under
>>>> /sys/class/backlight).
>>>>
>>>>> If yes, as mentioned, we should think of rather extending this video
>>>>> blacklist to more EliteBook G1 and ProBook G1 machines, and remove
>>>>> acpi_osi blacklist instead.
>>>>
>>>> Makes sense to me. (Well, I'm fine as long as backlight on my machine works
>>>> ;-))
>>>>
>>>> Aaron, Rafael, any comments on this?
>>>
>>> I generally agree with Takashi, but I'm not sure what to do for 3.14.
>>
>> I can re-base the previously sent patch titled:
>> [PATCH] ACPI / video: Add systems that should favor native backlight interface
>> And put Mika's system into the DMI table that will use native backlight
>> interface in video module and remove it from video_detect's DMI table at
>> the same time. Does this sound OK?
>
> Rather put more generic DMI entries for the recent HP ProBook and
> EliteBook machines as in acpi_osi blacklist:
>
> {
> .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"),
> },
> },
>
> All these are known to have different behavior with Win8, including
> the broken ACPI backlight. Once after merging that patch, we can
> revert the commit 2d4054d84224.
OK, thanks for the info.
I'll add the above laptops to the video module's use_native_backlight
DMI table.
Thanks,
Aaron
>
> I suppose it'd be OK for to do these for 3.14, since the acpi_osi
> commit was merged first in 3.14. Then we can continue fixing in a
> saner way.
>
>
> thanks,
>
> Takashi
>