Patchwork ACPI: Disable Windows 8 compatibility for some Lenovo ThinkPads

login
register
mail settings
Submitter Seth Forshee
Date Feb. 11, 2013, 4:21 p.m.
Message ID <1360599681-24781-1-git-send-email-seth.forshee@canonical.com>
Download mbox | patch
Permalink /patch/2124861/
State RFC, archived
Headers show

Comments

Seth Forshee - Feb. 11, 2013, 4:21 p.m.
The AML implementation for brightness control on several ThinkPads
contains a workaround to meet a Windows 8 requirement of 101 brightness
levels [1]. The implementation is flawed, as only 16 of the brighness
values reported by _BCL affect a change in brightness. _BCM silently
discards the rest of the values. Disabling Windows 8 compatibility on
these machines reverts them to the old behavior, making _BCL only report
the 16 brightness levels which actually work. Add a quirk to do this
along with a dmi callback to disable Win8 compatibility.

[1] http://msdn.microsoft.com/en-us/library/windows/hardware/jj128256.aspx

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=51231
BugLink: http://bugs.launchpad.net/bugs/1098216
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
---

This has been discussed previously at [2], however the description of
the problem there is incorrect. _BCM simply discards any value written
that isn't one of the brightness levels returned by _BCL for non-Win8
systems; it does not do any rounding.

This patch quirks six machines that have been confirmed to have this
problem, but there may be others. I looked for some way to do this other
than quirking for individual models, but unfortunately I couldn't find
any other criteria which worked.

Thanks,
Seth

[2] http://comments.gmane.org/gmane.linux.acpi.devel/58398


 drivers/acpi/blacklist.c |   62 ++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 62 insertions(+)
Matthew Garrett - Feb. 11, 2013, 5:52 p.m.
On Mon, Feb 11, 2013 at 10:21:21AM -0600, Seth Forshee wrote:
> The AML implementation for brightness control on several ThinkPads
> contains a workaround to meet a Windows 8 requirement of 101 brightness
> levels [1]. The implementation is flawed, as only 16 of the brighness
> values reported by _BCL affect a change in brightness. _BCM silently
> discards the rest of the values. Disabling Windows 8 compatibility on
> these machines reverts them to the old behavior, making _BCL only report
> the 16 brightness levels which actually work. Add a quirk to do this
> along with a dmi callback to disable Win8 compatibility.

So the problem is that userspace is writing values that don't happen to 
be aligned with the values the hardware reacts to, and so nothing gets 
changed?
Seth Forshee - Feb. 11, 2013, 7:06 p.m.
On Mon, Feb 11, 2013 at 05:52:13PM +0000, Matthew Garrett wrote:
> On Mon, Feb 11, 2013 at 10:21:21AM -0600, Seth Forshee wrote:
> > The AML implementation for brightness control on several ThinkPads
> > contains a workaround to meet a Windows 8 requirement of 101 brightness
> > levels [1]. The implementation is flawed, as only 16 of the brighness
> > values reported by _BCL affect a change in brightness. _BCM silently
> > discards the rest of the values. Disabling Windows 8 compatibility on
> > these machines reverts them to the old behavior, making _BCL only report
> > the 16 brightness levels which actually work. Add a quirk to do this
> > along with a dmi callback to disable Win8 compatibility.
> 
> So the problem is that userspace is writing values that don't happen to 
> be aligned with the values the hardware reacts to, and so nothing gets 
> changed?

Yes. The values are valid according to to _BCL, but _BCM is discarding
any values that aren't contained in an array named BRTW. BRTW is
literally the object returned by _BCL returns for !Windows 2012. Here's
a link to the AML if you'd like to take a look.

http://people.canonical.com/~sforshee/x230-acpi-tables/SSDT1.dsl

Seth

--
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
Matthew Garrett - Feb. 11, 2013, 7:09 p.m.
On Mon, Feb 11, 2013 at 01:06:17PM -0600, Seth Forshee wrote:
> On Mon, Feb 11, 2013 at 05:52:13PM +0000, Matthew Garrett wrote:
> > So the problem is that userspace is writing values that don't happen to 
> > be aligned with the values the hardware reacts to, and so nothing gets 
> > changed?
> 
> Yes. The values are valid according to to _BCL, but _BCM is discarding
> any values that aren't contained in an array named BRTW. BRTW is
> literally the object returned by _BCL returns for !Windows 2012. Here's
> a link to the AML if you'd like to take a look.

Right. My concern here is that Windows clearly doesn't trigger the 
issue, and so there's some chance that we'll see similar issues on other 
machines. Disabling Windows 8 compatibility isn't really an option. One 
choice might be to have the ACPI video driver set all intermediate 
values if the system makes the Windows 8 OSI call?
Rafael Wysocki - Feb. 11, 2013, 7:31 p.m.
On Monday, February 11, 2013 07:09:14 PM Matthew Garrett wrote:
> On Mon, Feb 11, 2013 at 01:06:17PM -0600, Seth Forshee wrote:
> > On Mon, Feb 11, 2013 at 05:52:13PM +0000, Matthew Garrett wrote:
> > > So the problem is that userspace is writing values that don't happen to 
> > > be aligned with the values the hardware reacts to, and so nothing gets 
> > > changed?
> > 
> > Yes. The values are valid according to to _BCL, but _BCM is discarding
> > any values that aren't contained in an array named BRTW. BRTW is
> > literally the object returned by _BCL returns for !Windows 2012. Here's
> > a link to the AML if you'd like to take a look.
> 
> Right. My concern here is that Windows clearly doesn't trigger the 
> issue, and so there's some chance that we'll see similar issues on other 
> machines. Disabling Windows 8 compatibility isn't really an option. One 
> choice might be to have the ACPI video driver set all intermediate 
> values if the system makes the Windows 8 OSI call?

At least I'd prefer that, so it would be great to verify if it works.

Thanks,
Rafael
Seth Forshee - Feb. 12, 2013, 3:05 a.m.
On Mon, Feb 11, 2013 at 08:31:08PM +0100, Rafael J. Wysocki wrote:
> On Monday, February 11, 2013 07:09:14 PM Matthew Garrett wrote:
> > On Mon, Feb 11, 2013 at 01:06:17PM -0600, Seth Forshee wrote:
> > > On Mon, Feb 11, 2013 at 05:52:13PM +0000, Matthew Garrett wrote:
> > > > So the problem is that userspace is writing values that don't happen to 
> > > > be aligned with the values the hardware reacts to, and so nothing gets 
> > > > changed?
> > > 
> > > Yes. The values are valid according to to _BCL, but _BCM is discarding
> > > any values that aren't contained in an array named BRTW. BRTW is
> > > literally the object returned by _BCL returns for !Windows 2012. Here's
> > > a link to the AML if you'd like to take a look.
> > 
> > Right. My concern here is that Windows clearly doesn't trigger the 
> > issue, and so there's some chance that we'll see similar issues on other 
> > machines. Disabling Windows 8 compatibility isn't really an option. One 

So my take on this is that it's a transition issue. In the case of the
x230 I know that this machine was sold with Windows 7 before Windows 8
came out and that older versions of the firmware don't have the Win8
workaround. I suspect the story is the same with the other models.

> > choice might be to have the ACPI video driver set all intermediate 
> > values if the system makes the Windows 8 OSI call?
> 
> At least I'd prefer that, so it would be great to verify if it works.

I expect it will work, depending on your definition of "works."

The problem with this suggestion is that there are still going to be
instances where a user's desktop says the brightness has changed without
it actually changing. For example, gnome-settings-daemon is going to
break this down into increments of 5, and even with hitting every point
in between some steps aren't going to change the brightness at all.

But if disabling Windows 8 compatibility is out then that may be the
best we can do without resorting to something really ugly.

Seth

--
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
Seth Forshee - Feb. 13, 2013, 8:32 p.m.
On Mon, Feb 11, 2013 at 07:09:14PM +0000, Matthew Garrett wrote:
> On Mon, Feb 11, 2013 at 01:06:17PM -0600, Seth Forshee wrote:
> > On Mon, Feb 11, 2013 at 05:52:13PM +0000, Matthew Garrett wrote:
> > > So the problem is that userspace is writing values that don't happen to 
> > > be aligned with the values the hardware reacts to, and so nothing gets 
> > > changed?
> > 
> > Yes. The values are valid according to to _BCL, but _BCM is discarding
> > any values that aren't contained in an array named BRTW. BRTW is
> > literally the object returned by _BCL returns for !Windows 2012. Here's
> > a link to the AML if you'd like to take a look.
> 
> Right. My concern here is that Windows clearly doesn't trigger the 
> issue, and so there's some chance that we'll see similar issues on other 
> machines. Disabling Windows 8 compatibility isn't really an option. One 
> choice might be to have the ACPI video driver set all intermediate 
> values if the system makes the Windows 8 OSI call?

This turns out to have some problems. The hotkeys on the x230 at least
generate increase/decrease brightness notifications. In response
acpi_video reads the current brightness level via _BQC and decides what
the next value should be. A value adjacent to a working value is never
another working value on this machine, so _BCM does nothing. The next
time a notification comes _BQC returns the same value as it did the
previous time. Obviously this gets us nowhere.

The (untested) fix I've come up with is to use the cached value for the
current brightness rather than asking the firmware. I'm assuming though
that acpi_video would be using the cached values already if there wasn't
a chance that their changing without its knowledge?

The other issue with using the cached value is that the hotkeys on these
machines are still going to end up cycling through 101 brightness levels
with 85% of them leaving the brightness unchanged. When there's that
many levels though maybe it makes sense to jump more than one level at a
time.

Seth

--
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
Matthew Garrett - Feb. 13, 2013, 8:55 p.m.
On Wed, Feb 13, 2013 at 02:32:28PM -0600, Seth Forshee wrote:
> On Mon, Feb 11, 2013 at 07:09:14PM +0000, Matthew Garrett wrote:
> > Right. My concern here is that Windows clearly doesn't trigger the 
> > issue, and so there's some chance that we'll see similar issues on other 
> > machines. Disabling Windows 8 compatibility isn't really an option. One 
> > choice might be to have the ACPI video driver set all intermediate 
> > values if the system makes the Windows 8 OSI call?
> 
> This turns out to have some problems. The hotkeys on the x230 at least
> generate increase/decrease brightness notifications. In response
> acpi_video reads the current brightness level via _BQC and decides what
> the next value should be. A value adjacent to a working value is never
> another working value on this machine, so _BCM does nothing. The next
> time a notification comes _BQC returns the same value as it did the
> previous time. Obviously this gets us nowhere.

Nrgh. Having this logic in the kernel has always been miserable. On the 
other hand, having _BQC return wrong values is arguably even worse.

> The (untested) fix I've come up with is to use the cached value for the
> current brightness rather than asking the firmware. I'm assuming though
> that acpi_video would be using the cached values already if there wasn't
> a chance that their changing without its knowledge?

Yeah. What I'd suggest here is calling _BQC after every change, and if 
it returns the old value throw a firmware bug message and fall back to 
using a cached one.

> The other issue with using the cached value is that the hotkeys on these
> machines are still going to end up cycling through 101 brightness levels
> with 85% of them leaving the brightness unchanged. When there's that
> many levels though maybe it makes sense to jump more than one level at a
> time.

Right. I'd recommend turning off that functionality and just leaving it 
up to userspace. We still seem to be carrying a patch to do that in 
Fedora. I thought I had a patch to make this a config option somewhere, 
but can't find any sign of it now...
Ben Jencks - Feb. 13, 2013, 9:04 p.m.
On 02/13/2013 03:55 PM, Matthew Garrett wrote:
> On Wed, Feb 13, 2013 at 02:32:28PM -0600, Seth Forshee wrote:
>> On Mon, Feb 11, 2013 at 07:09:14PM +0000, Matthew Garrett wrote:
>>> Right. My concern here is that Windows clearly doesn't trigger the 
>>> issue, and so there's some chance that we'll see similar issues on other 
>>> machines. Disabling Windows 8 compatibility isn't really an option. One 
>>> choice might be to have the ACPI video driver set all intermediate 
>>> values if the system makes the Windows 8 OSI call?

I'm not too familiar with the per-machine tweaks code; would it be
possible to override the SSDT1 table if it's this particular bad one?

>> The (untested) fix I've come up with is to use the cached value for the
>> current brightness rather than asking the firmware. I'm assuming though
>> that acpi_video would be using the cached values already if there wasn't
>> a chance that their changing without its knowledge?
> 
> Yeah. What I'd suggest here is calling _BQC after every change, and if 
> it returns the old value throw a firmware bug message and fall back to 
> using a cached one.

This still has the problem that some changes will have no effect, which
isn't a great user experience.

>> The other issue with using the cached value is that the hotkeys on these
>> machines are still going to end up cycling through 101 brightness levels
>> with 85% of them leaving the brightness unchanged. When there's that
>> many levels though maybe it makes sense to jump more than one level at a
>> time.
> 
> Right. I'd recommend turning off that functionality and just leaving it 
> up to userspace. We still seem to be carrying a patch to do that in 
> Fedora. I thought I had a patch to make this a config option somewhere, 
> but can't find any sign of it now...

I think you're looking for video.brightness_switch_enabled=0, which I
have to use, otherwise a single keypress changes brightness by two levels.

-Ben
--
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
Ben Jencks - Feb. 13, 2013, 9:09 p.m.
On 02/11/2013 02:09 PM, Matthew Garrett wrote:
> On Mon, Feb 11, 2013 at 01:06:17PM -0600, Seth Forshee wrote:
>> On Mon, Feb 11, 2013 at 05:52:13PM +0000, Matthew Garrett wrote:
>>> So the problem is that userspace is writing values that don't happen to 
>>> be aligned with the values the hardware reacts to, and so nothing gets 
>>> changed?
>>
>> Yes. The values are valid according to to _BCL, but _BCM is discarding
>> any values that aren't contained in an array named BRTW. BRTW is
>> literally the object returned by _BCL returns for !Windows 2012. Here's
>> a link to the AML if you'd like to take a look.
> 
> Right. My concern here is that Windows clearly doesn't trigger the 
> issue, and so there's some chance that we'll see similar issues on other 
> machines. Disabling Windows 8 compatibility isn't really an option. One 
> choice might be to have the ACPI video driver set all intermediate 
> values if the system makes the Windows 8 OSI call?

Stupid hack idea: what about trying all the levels _BCL reports and
seeing which ones change _BQC? Then filter out any that don't really
exist. It might make bootup look odd, seeing the backlight quickly scan
through all brightness levels, but it's only once per boot.

-Ben

--
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
Seth Forshee - Feb. 13, 2013, 9:46 p.m.
On Wed, Feb 13, 2013 at 08:55:58PM +0000, Matthew Garrett wrote:
> On Wed, Feb 13, 2013 at 02:32:28PM -0600, Seth Forshee wrote:
> > On Mon, Feb 11, 2013 at 07:09:14PM +0000, Matthew Garrett wrote:
> > > Right. My concern here is that Windows clearly doesn't trigger the 
> > > issue, and so there's some chance that we'll see similar issues on other 
> > > machines. Disabling Windows 8 compatibility isn't really an option. One 
> > > choice might be to have the ACPI video driver set all intermediate 
> > > values if the system makes the Windows 8 OSI call?
> > 
> > This turns out to have some problems. The hotkeys on the x230 at least
> > generate increase/decrease brightness notifications. In response
> > acpi_video reads the current brightness level via _BQC and decides what
> > the next value should be. A value adjacent to a working value is never
> > another working value on this machine, so _BCM does nothing. The next
> > time a notification comes _BQC returns the same value as it did the
> > previous time. Obviously this gets us nowhere.
> 
> Nrgh. Having this logic in the kernel has always been miserable. On the 
> other hand, having _BQC return wrong values is arguably even worse.
> 
> > The (untested) fix I've come up with is to use the cached value for the
> > current brightness rather than asking the firmware. I'm assuming though
> > that acpi_video would be using the cached values already if there wasn't
> > a chance that their changing without its knowledge?
> 
> Yeah. What I'd suggest here is calling _BQC after every change, and if 
> it returns the old value throw a firmware bug message and fall back to 
> using a cached one.

After every brightness change? Maybe it would be better to just test for
this during initialization, then set device->cap._BQC to 0 so we won't
use it.

--
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
Seth Forshee - Feb. 13, 2013, 9:49 p.m.
On Wed, Feb 13, 2013 at 04:04:13PM -0500, Ben Jencks wrote:
> >> The other issue with using the cached value is that the hotkeys on these
> >> machines are still going to end up cycling through 101 brightness levels
> >> with 85% of them leaving the brightness unchanged. When there's that
> >> many levels though maybe it makes sense to jump more than one level at a
> >> time.
> > 
> > Right. I'd recommend turning off that functionality and just leaving it 
> > up to userspace. We still seem to be carrying a patch to do that in 
> > Fedora. I thought I had a patch to make this a config option somewhere, 
> > but can't find any sign of it now...
> 
> I think you're looking for video.brightness_switch_enabled=0, which I
> have to use, otherwise a single keypress changes brightness by two levels.

I think that option does what Matthew's suggesting. It would be a simple
change to default it to 0.

--
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
Matthew Garrett - Feb. 13, 2013, 9:54 p.m.
On Wed, Feb 13, 2013 at 03:46:54PM -0600, Seth Forshee wrote:

> After every brightness change? Maybe it would be better to just test for
> this during initialization, then set device->cap._BQC to 0 so we won't
> use it.

That would require us to change the backlight during boot, which we 
don't necessarily want to do. There's also the risk that if we only do 
the check once it'll correspond to a valid value and we'll get a false 
positive.
Seth Forshee - Feb. 13, 2013, 10:04 p.m.
On Wed, Feb 13, 2013 at 09:54:35PM +0000, Matthew Garrett wrote:
> On Wed, Feb 13, 2013 at 03:46:54PM -0600, Seth Forshee wrote:
> 
> > After every brightness change? Maybe it would be better to just test for
> > this during initialization, then set device->cap._BQC to 0 so we won't
> > use it.
> 
> That would require us to change the backlight during boot, which we 
> don't necessarily want to do. There's also the risk that if we only do 
> the check once it'll correspond to a valid value and we'll get a false 
> positive.

We're already setting the level during boot to check whether or not _BQC
returns brightness values or indexes. We'd obviously have to try several
values to be fairly certain that this bug wasn't present.

--
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
Seth Forshee - March 7, 2013, 7:38 p.m.
On Wed, Feb 13, 2013 at 08:55:58PM +0000, Matthew Garrett wrote:
> On Wed, Feb 13, 2013 at 02:32:28PM -0600, Seth Forshee wrote:
> > On Mon, Feb 11, 2013 at 07:09:14PM +0000, Matthew Garrett wrote:
> > > Right. My concern here is that Windows clearly doesn't trigger the 
> > > issue, and so there's some chance that we'll see similar issues on other 
> > > machines. Disabling Windows 8 compatibility isn't really an option. One 
> > > choice might be to have the ACPI video driver set all intermediate 
> > > values if the system makes the Windows 8 OSI call?
> > 
> > This turns out to have some problems. The hotkeys on the x230 at least
> > generate increase/decrease brightness notifications. In response
> > acpi_video reads the current brightness level via _BQC and decides what
> > the next value should be. A value adjacent to a working value is never
> > another working value on this machine, so _BCM does nothing. The next
> > time a notification comes _BQC returns the same value as it did the
> > previous time. Obviously this gets us nowhere.
> 
> Nrgh. Having this logic in the kernel has always been miserable. On the 
> other hand, having _BQC return wrong values is arguably even worse.
> 
> > The (untested) fix I've come up with is to use the cached value for the
> > current brightness rather than asking the firmware. I'm assuming though
> > that acpi_video would be using the cached values already if there wasn't
> > a chance that their changing without its knowledge?
> 
> Yeah. What I'd suggest here is calling _BQC after every change, and if 
> it returns the old value throw a firmware bug message and fall back to 
> using a cached one.
> 
> > The other issue with using the cached value is that the hotkeys on these
> > machines are still going to end up cycling through 101 brightness levels
> > with 85% of them leaving the brightness unchanged. When there's that
> > many levels though maybe it makes sense to jump more than one level at a
> > time.
> 
> Right. I'd recommend turning off that functionality and just leaving it 
> up to userspace. We still seem to be carrying a patch to do that in 
> Fedora. I thought I had a patch to make this a config option somewhere, 
> but can't find any sign of it now...

I've had the patches implementing your suggestions written for a while
now but just got test feedback this week. So here they are.

Seth

--
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
Seth Forshee - March 18, 2013, 9:25 p.m.
On Thu, Mar 07, 2013 at 01:38:12PM -0600, Seth Forshee wrote:
> On Wed, Feb 13, 2013 at 08:55:58PM +0000, Matthew Garrett wrote:
> > On Wed, Feb 13, 2013 at 02:32:28PM -0600, Seth Forshee wrote:
> > > On Mon, Feb 11, 2013 at 07:09:14PM +0000, Matthew Garrett wrote:
> > > > Right. My concern here is that Windows clearly doesn't trigger the 
> > > > issue, and so there's some chance that we'll see similar issues on other 
> > > > machines. Disabling Windows 8 compatibility isn't really an option. One 
> > > > choice might be to have the ACPI video driver set all intermediate 
> > > > values if the system makes the Windows 8 OSI call?
> > > 
> > > This turns out to have some problems. The hotkeys on the x230 at least
> > > generate increase/decrease brightness notifications. In response
> > > acpi_video reads the current brightness level via _BQC and decides what
> > > the next value should be. A value adjacent to a working value is never
> > > another working value on this machine, so _BCM does nothing. The next
> > > time a notification comes _BQC returns the same value as it did the
> > > previous time. Obviously this gets us nowhere.
> > 
> > Nrgh. Having this logic in the kernel has always been miserable. On the 
> > other hand, having _BQC return wrong values is arguably even worse.
> > 
> > > The (untested) fix I've come up with is to use the cached value for the
> > > current brightness rather than asking the firmware. I'm assuming though
> > > that acpi_video would be using the cached values already if there wasn't
> > > a chance that their changing without its knowledge?
> > 
> > Yeah. What I'd suggest here is calling _BQC after every change, and if 
> > it returns the old value throw a firmware bug message and fall back to 
> > using a cached one.
> > 
> > > The other issue with using the cached value is that the hotkeys on these
> > > machines are still going to end up cycling through 101 brightness levels
> > > with 85% of them leaving the brightness unchanged. When there's that
> > > many levels though maybe it makes sense to jump more than one level at a
> > > time.
> > 
> > Right. I'd recommend turning off that functionality and just leaving it 
> > up to userspace. We still seem to be carrying a patch to do that in 
> > Fedora. I thought I had a patch to make this a config option somewhere, 
> > but can't find any sign of it now...
> 
> I've had the patches implementing your suggestions written for a while
> now but just got test feedback this week. So here they are.

Ping.

Matthew, do these patches look like what you had in mind?

--
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
Aaron Lu - April 1, 2013, 1:53 a.m.
On 02/12/2013 12:21 AM, Seth Forshee wrote:
> The AML implementation for brightness control on several ThinkPads
> contains a workaround to meet a Windows 8 requirement of 101 brightness
> levels [1]. The implementation is flawed, as only 16 of the brighness
> values reported by _BCL affect a change in brightness. _BCM silently
> discards the rest of the values. Disabling Windows 8 compatibility on
> these machines reverts them to the old behavior, making _BCL only report
> the 16 brightness levels which actually work. Add a quirk to do this
> along with a dmi callback to disable Win8 compatibility.

If we disable the _BQC(i.e. set cap._BQC=0) for these systems, will the
problem go away? If so, I think perhaps we can put these systems into a
_BQC quirk table and set cap._BQC=0 for them.

Thanks,
Aaron

> 
> [1] http://msdn.microsoft.com/en-us/library/windows/hardware/jj128256.aspx
> 
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=51231
> BugLink: http://bugs.launchpad.net/bugs/1098216
> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
> ---
> 
> This has been discussed previously at [2], however the description of
> the problem there is incorrect. _BCM simply discards any value written
> that isn't one of the brightness levels returned by _BCL for non-Win8
> systems; it does not do any rounding.
> 
> This patch quirks six machines that have been confirmed to have this
> problem, but there may be others. I looked for some way to do this other
> than quirking for individual models, but unfortunately I couldn't find
> any other criteria which worked.
> 
> Thanks,
> Seth
> 
> [2] http://comments.gmane.org/gmane.linux.acpi.devel/58398
> 
> 
>  drivers/acpi/blacklist.c |   62 ++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 62 insertions(+)
> 
> diff --git a/drivers/acpi/blacklist.c b/drivers/acpi/blacklist.c
> index cb96296..6c242ed 100644
> --- a/drivers/acpi/blacklist.c
> +++ b/drivers/acpi/blacklist.c
> @@ -193,6 +193,13 @@ static int __init dmi_disable_osi_win7(const struct dmi_system_id *d)
>  	return 0;
>  }
>  
> +static int __init dmi_disable_osi_win8(const struct dmi_system_id *d)
> +{
> +	printk(KERN_NOTICE PREFIX "DMI detected: %s\n", d->ident);
> +	acpi_osi_setup("!Windows 2012");
> +	return 0;
> +}
> +
>  static struct dmi_system_id acpi_osi_dmi_table[] __initdata = {
>  	{
>  	.callback = dmi_disable_osi_vista,
> @@ -269,6 +276,61 @@ static struct dmi_system_id acpi_osi_dmi_table[] __initdata = {
>  	},
>  
>  	/*
> +	 * The following Lenovo models have a broken workaround in the
> +	 * acpi_video backlight implementation to meet the Windows 8
> +	 * requirement of 101 backlight levels. Reverting to pre-Win8
> +	 * behavior fixes the problem.
> +	 */
> +	{
> +	.callback = dmi_disable_osi_win8,
> +	.ident = "Lenovo ThinkPad L430",
> +	.matches = {
> +		     DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
> +		     DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad L430"),
> +		},
> +	},
> +	{
> +	.callback = dmi_disable_osi_win8,
> +	.ident = "Lenovo ThinkPad T430s",
> +	.matches = {
> +		     DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
> +		     DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad T430s"),
> +		},
> +	},
> +	{
> +	.callback = dmi_disable_osi_win8,
> +	.ident = "Lenovo ThinkPad T530",
> +	.matches = {
> +		     DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
> +		     DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad T530"),
> +		},
> +	},
> +	{
> +	.callback = dmi_disable_osi_win8,
> +	.ident = "Lenovo ThinkPad W530",
> +	.matches = {
> +		     DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
> +		     DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad W530"),
> +		},
> +	},
> +	{
> +	.callback = dmi_disable_osi_win8,
> +	.ident = "Lenovo ThinkPad X1 Carbon",
> +	.matches = {
> +		     DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
> +		     DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad X1 Carbon"),
> +		},
> +	},
> +	{
> +	.callback = dmi_disable_osi_win8,
> +	.ident = "Lenovo ThinkPad X230",
> +	.matches = {
> +		     DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
> +		     DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad X230"),
> +		},
> +	},
> +
> +	/*
>  	 * BIOS invocation of _OSI(Linux) is almost always a BIOS bug.
>  	 * Linux ignores it, except for the machines enumerated below.
>  	 */
> 

--
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
Seth Forshee - April 1, 2013, 1:03 p.m.
On Mon, Apr 01, 2013 at 09:53:36AM +0800, Aaron Lu wrote:
> On 02/12/2013 12:21 AM, Seth Forshee wrote:
> > The AML implementation for brightness control on several ThinkPads
> > contains a workaround to meet a Windows 8 requirement of 101 brightness
> > levels [1]. The implementation is flawed, as only 16 of the brighness
> > values reported by _BCL affect a change in brightness. _BCM silently
> > discards the rest of the values. Disabling Windows 8 compatibility on
> > these machines reverts them to the old behavior, making _BCL only report
> > the 16 brightness levels which actually work. Add a quirk to do this
> > along with a dmi callback to disable Win8 compatibility.
> 
> If we disable the _BQC(i.e. set cap._BQC=0) for these systems, will the
> problem go away? If so, I think perhaps we can put these systems into a
> _BQC quirk table and set cap._BQC=0 for them.

That helps a little, but we're still left with only 16 of the 101
brightness levels causing any change in brightness. The firmware isn't
rounding the "bad" values or anything like that; it just silently
ignores them.

I submitted a second set of patches [1] which writes all intermediate
values between the old and new brightness values and disables _BQC for
these machines (empirically rather than using a quirk table), though no
one seems to be interested in reviewing them.

Seth

[1] http://www.spinics.net/lists/linux-acpi/msg42525.html
--
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
Ben Jencks - April 2, 2013, 5:18 a.m.
On 03/18/2013 05:25 PM, Seth Forshee wrote:
> On Thu, Mar 07, 2013 at 01:38:12PM -0600, Seth Forshee wrote:
>> On Wed, Feb 13, 2013 at 08:55:58PM +0000, Matthew Garrett wrote:
>>> On Wed, Feb 13, 2013 at 02:32:28PM -0600, Seth Forshee wrote:
>>>> On Mon, Feb 11, 2013 at 07:09:14PM +0000, Matthew Garrett wrote:
>>>>> Right. My concern here is that Windows clearly doesn't trigger the 
>>>>> issue, and so there's some chance that we'll see similar issues on other 
>>>>> machines. Disabling Windows 8 compatibility isn't really an option. One 
>>>>> choice might be to have the ACPI video driver set all intermediate 
>>>>> values if the system makes the Windows 8 OSI call?
>>>>
>>>> This turns out to have some problems. The hotkeys on the x230 at least
>>>> generate increase/decrease brightness notifications. In response
>>>> acpi_video reads the current brightness level via _BQC and decides what
>>>> the next value should be. A value adjacent to a working value is never
>>>> another working value on this machine, so _BCM does nothing. The next
>>>> time a notification comes _BQC returns the same value as it did the
>>>> previous time. Obviously this gets us nowhere.
>>>
>>> Nrgh. Having this logic in the kernel has always been miserable. On the 
>>> other hand, having _BQC return wrong values is arguably even worse.
>>>
>>>> The (untested) fix I've come up with is to use the cached value for the
>>>> current brightness rather than asking the firmware. I'm assuming though
>>>> that acpi_video would be using the cached values already if there wasn't
>>>> a chance that their changing without its knowledge?
>>>
>>> Yeah. What I'd suggest here is calling _BQC after every change, and if 
>>> it returns the old value throw a firmware bug message and fall back to 
>>> using a cached one.
>>>
>>>> The other issue with using the cached value is that the hotkeys on these
>>>> machines are still going to end up cycling through 101 brightness levels
>>>> with 85% of them leaving the brightness unchanged. When there's that
>>>> many levels though maybe it makes sense to jump more than one level at a
>>>> time.
>>>
>>> Right. I'd recommend turning off that functionality and just leaving it 
>>> up to userspace. We still seem to be carrying a patch to do that in 
>>> Fedora. I thought I had a patch to make this a config option somewhere, 
>>> but can't find any sign of it now...
>>
>> I've had the patches implementing your suggestions written for a while
>> now but just got test feedback this week. So here they are.
> 
> Ping.
> 
> Matthew, do these patches look like what you had in mind?

Finally got a chance to try these patches out. It seems to perform as
expected, exposing levels 0-100 and actually allowing proper changes
between them. It's not optimal, though.

Using the up/down keys with gnome-settings-daemon, which uses 20 steps,
several steps don't actually change the brightness (including the very
first one, 100->95). Additionally, the changes are asymmetric: going
down, the brightness changes at 95->90, but going up 90->95 has no
change, and 95->100 changes it.

As a user, I'd definitely consider this a regression compared to the
"!Windows 2012" behavior. If you can't remove that OSI or override the
_BCL list as a machine-specific quirk, this is probably the best generic
behavior possible, though.

-Ben
--
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
Aaron Lu - April 2, 2013, 9:08 a.m.
On 04/01/2013 09:03 PM, Seth Forshee wrote:
> On Mon, Apr 01, 2013 at 09:53:36AM +0800, Aaron Lu wrote:
>> On 02/12/2013 12:21 AM, Seth Forshee wrote:
>>> The AML implementation for brightness control on several ThinkPads
>>> contains a workaround to meet a Windows 8 requirement of 101 brightness
>>> levels [1]. The implementation is flawed, as only 16 of the brighness
>>> values reported by _BCL affect a change in brightness. _BCM silently
>>> discards the rest of the values. Disabling Windows 8 compatibility on
>>> these machines reverts them to the old behavior, making _BCL only report
>>> the 16 brightness levels which actually work. Add a quirk to do this
>>> along with a dmi callback to disable Win8 compatibility.
>>
>> If we disable the _BQC(i.e. set cap._BQC=0) for these systems, will the
>> problem go away? If so, I think perhaps we can put these systems into a
>> _BQC quirk table and set cap._BQC=0 for them.
> 
> That helps a little, but we're still left with only 16 of the 101
> brightness levels causing any change in brightness. The firmware isn't
> rounding the "bad" values or anything like that; it just silently
> ignores them.

OK, and if GUI tool like g-s-d decides to go some more steps when
adjusting backlight level, it may always choose the non-functional
values. Hmm, doesn't seem to be an usable way then.

I really wondered, how Windows handled this, it should have the same
problem, unless they are not using the acpi video interface?

> 
> I submitted a second set of patches [1] which writes all intermediate
> values between the old and new brightness values and disables _BQC for
> these machines (empirically rather than using a quirk table), though no
> one seems to be interested in reviewing them.

Suppose we are at level 100, and the user sets the target level to be
20, then we will need to call _BCM 80 times?

Thanks,
Aaron

--
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
Aaron Lu - April 2, 2013, 9:15 a.m.
On 04/02/2013 01:18 PM, Ben Jencks wrote:
> On 03/18/2013 05:25 PM, Seth Forshee wrote:
>> On Thu, Mar 07, 2013 at 01:38:12PM -0600, Seth Forshee wrote:
>>> On Wed, Feb 13, 2013 at 08:55:58PM +0000, Matthew Garrett wrote:
>>>> On Wed, Feb 13, 2013 at 02:32:28PM -0600, Seth Forshee wrote:
>>>>> On Mon, Feb 11, 2013 at 07:09:14PM +0000, Matthew Garrett wrote:
>>>>>> Right. My concern here is that Windows clearly doesn't trigger the 
>>>>>> issue, and so there's some chance that we'll see similar issues on other 
>>>>>> machines. Disabling Windows 8 compatibility isn't really an option. One 
>>>>>> choice might be to have the ACPI video driver set all intermediate 
>>>>>> values if the system makes the Windows 8 OSI call?
>>>>>
>>>>> This turns out to have some problems. The hotkeys on the x230 at least
>>>>> generate increase/decrease brightness notifications. In response
>>>>> acpi_video reads the current brightness level via _BQC and decides what
>>>>> the next value should be. A value adjacent to a working value is never
>>>>> another working value on this machine, so _BCM does nothing. The next
>>>>> time a notification comes _BQC returns the same value as it did the
>>>>> previous time. Obviously this gets us nowhere.
>>>>
>>>> Nrgh. Having this logic in the kernel has always been miserable. On the 
>>>> other hand, having _BQC return wrong values is arguably even worse.
>>>>
>>>>> The (untested) fix I've come up with is to use the cached value for the
>>>>> current brightness rather than asking the firmware. I'm assuming though
>>>>> that acpi_video would be using the cached values already if there wasn't
>>>>> a chance that their changing without its knowledge?
>>>>
>>>> Yeah. What I'd suggest here is calling _BQC after every change, and if 
>>>> it returns the old value throw a firmware bug message and fall back to 
>>>> using a cached one.
>>>>
>>>>> The other issue with using the cached value is that the hotkeys on these
>>>>> machines are still going to end up cycling through 101 brightness levels
>>>>> with 85% of them leaving the brightness unchanged. When there's that
>>>>> many levels though maybe it makes sense to jump more than one level at a
>>>>> time.
>>>>
>>>> Right. I'd recommend turning off that functionality and just leaving it 
>>>> up to userspace. We still seem to be carrying a patch to do that in 
>>>> Fedora. I thought I had a patch to make this a config option somewhere, 
>>>> but can't find any sign of it now...
>>>
>>> I've had the patches implementing your suggestions written for a while
>>> now but just got test feedback this week. So here they are.
>>
>> Ping.
>>
>> Matthew, do these patches look like what you had in mind?
> 
> Finally got a chance to try these patches out. It seems to perform as
> expected, exposing levels 0-100 and actually allowing proper changes
> between them. It's not optimal, though.
> 
> Using the up/down keys with gnome-settings-daemon, which uses 20 steps,
> several steps don't actually change the brightness (including the very
> first one, 100->95). Additionally, the changes are asymmetric: going
> down, the brightness changes at 95->90, but going up 90->95 has no
> change, and 95->100 changes it.
> 
> As a user, I'd definitely consider this a regression compared to the
> "!Windows 2012" behavior. If you can't remove that OSI or override the
> _BCL list as a machine-specific quirk, this is probably the best generic
> behavior possible, though.

Perhaps we can introduce a _BCM quirk function, with a DMI table for
these systems. On boot/load, the callback of the dmi entry would to
evaluate for which values _BCM has effect by checking with _BQC, and
re-construct the _BCL table according to this.

This has the benefit of not affecting other systems, while also derive
the correct table for _BCL for these broken systems.

I saw you guys have talked about this idea in this thread, so I wonder
if this is a viable solution?

Thanks,
Aaron

> 
> -Ben
> --
> 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
> 

--
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
Matthew Garrett - April 2, 2013, 11:23 a.m.
On Tue, Apr 02, 2013 at 05:15:03PM +0800, Aaron Lu wrote:

> Perhaps we can introduce a _BCM quirk function, with a DMI table for
> these systems.

No. Really, plesae no.
Seth Forshee - April 2, 2013, 1 p.m.
On Tue, Apr 02, 2013 at 05:08:23PM +0800, Aaron Lu wrote:
> On 04/01/2013 09:03 PM, Seth Forshee wrote:
> > On Mon, Apr 01, 2013 at 09:53:36AM +0800, Aaron Lu wrote:
> >> On 02/12/2013 12:21 AM, Seth Forshee wrote:
> >>> The AML implementation for brightness control on several ThinkPads
> >>> contains a workaround to meet a Windows 8 requirement of 101 brightness
> >>> levels [1]. The implementation is flawed, as only 16 of the brighness
> >>> values reported by _BCL affect a change in brightness. _BCM silently
> >>> discards the rest of the values. Disabling Windows 8 compatibility on
> >>> these machines reverts them to the old behavior, making _BCL only report
> >>> the 16 brightness levels which actually work. Add a quirk to do this
> >>> along with a dmi callback to disable Win8 compatibility.
> >>
> >> If we disable the _BQC(i.e. set cap._BQC=0) for these systems, will the
> >> problem go away? If so, I think perhaps we can put these systems into a
> >> _BQC quirk table and set cap._BQC=0 for them.
> > 
> > That helps a little, but we're still left with only 16 of the 101
> > brightness levels causing any change in brightness. The firmware isn't
> > rounding the "bad" values or anything like that; it just silently
> > ignores them.
> 
> OK, and if GUI tool like g-s-d decides to go some more steps when
> adjusting backlight level, it may always choose the non-functional
> values. Hmm, doesn't seem to be an usable way then.

Exactly.

> I really wondered, how Windows handled this, it should have the same
> problem, unless they are not using the acpi video interface?

I can only guess.

I think I remember reading that Windows 8 does smooth backlight
transitions, so it may well hit every intermediate brightness value.
Lenovo could also be supplying a driver which rounds values to the
nearest working value or uses some other interface or something else.

> > I submitted a second set of patches [1] which writes all intermediate
> > values between the old and new brightness values and disables _BQC for
> > these machines (empirically rather than using a quirk table), though no
> > one seems to be interested in reviewing them.
> 
> Suppose we are at level 100, and the user sets the target level to be
> 20, then we will need to call _BCM 80 times?

Yes. And on machines where _BQC actually returns legitimate values it
will get called 80 times as well. On these Lenovo's we'd quickly
determine that _BQC doesn't work and stop trying to use it however.

Seth
--
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
Aaron Lu - April 2, 2013, 1:43 p.m.
On 04/02/2013 09:00 PM, Seth Forshee wrote:
> On Tue, Apr 02, 2013 at 05:08:23PM +0800, Aaron Lu wrote:
>> On 04/01/2013 09:03 PM, Seth Forshee wrote:
>>> On Mon, Apr 01, 2013 at 09:53:36AM +0800, Aaron Lu wrote:
>>>> On 02/12/2013 12:21 AM, Seth Forshee wrote:
>>>>> The AML implementation for brightness control on several ThinkPads
>>>>> contains a workaround to meet a Windows 8 requirement of 101 brightness
>>>>> levels [1]. The implementation is flawed, as only 16 of the brighness
>>>>> values reported by _BCL affect a change in brightness. _BCM silently
>>>>> discards the rest of the values. Disabling Windows 8 compatibility on
>>>>> these machines reverts them to the old behavior, making _BCL only report
>>>>> the 16 brightness levels which actually work. Add a quirk to do this
>>>>> along with a dmi callback to disable Win8 compatibility.
>>>>
>>>> If we disable the _BQC(i.e. set cap._BQC=0) for these systems, will the
>>>> problem go away? If so, I think perhaps we can put these systems into a
>>>> _BQC quirk table and set cap._BQC=0 for them.
>>>
>>> That helps a little, but we're still left with only 16 of the 101
>>> brightness levels causing any change in brightness. The firmware isn't
>>> rounding the "bad" values or anything like that; it just silently
>>> ignores them.
>>
>> OK, and if GUI tool like g-s-d decides to go some more steps when
>> adjusting backlight level, it may always choose the non-functional
>> values. Hmm, doesn't seem to be an usable way then.
> 
> Exactly.
> 
>> I really wondered, how Windows handled this, it should have the same
>> problem, unless they are not using the acpi video interface?
> 
> I can only guess.
> 
> I think I remember reading that Windows 8 does smooth backlight
> transitions, so it may well hit every intermediate brightness value.
> Lenovo could also be supplying a driver which rounds values to the
> nearest working value or uses some other interface or something else.

Right, thanks for the hint.

> 
>>> I submitted a second set of patches [1] which writes all intermediate
>>> values between the old and new brightness values and disables _BQC for
>>> these machines (empirically rather than using a quirk table), though no
>>> one seems to be interested in reviewing them.
>>
>> Suppose we are at level 100, and the user sets the target level to be
>> 20, then we will need to call _BCM 80 times?
> 
> Yes. And on machines where _BQC actually returns legitimate values it
> will get called 80 times as well. On these Lenovo's we'd quickly
> determine that _BQC doesn't work and stop trying to use it however.

OK, but we still have to call it 80 times, right? From smooth point of
view, this might be a good thing, but I'm not sure if such change of
behaviour just for this problem is desired.

And I just took a look at patch 3, it seems to affect the normal code
path too, so we are changing the behaviour of a brightness level change
for some specific systems.

I really do not want these quirk code to pollute normal code path, it
made code difficult to understand and complicated. And all systems
suffer from this change, not just the affected ones.

I hope we can use quirk to differentiate them.

Thanks,
Aaron

--
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
Aaron Lu - April 2, 2013, 1:44 p.m.
On 04/02/2013 07:23 PM, Matthew Garrett wrote:
> On Tue, Apr 02, 2013 at 05:15:03PM +0800, Aaron Lu wrote:
> 
>> Perhaps we can introduce a _BCM quirk function, with a DMI table for
>> these systems.
> 
> No. Really, plesae no.
> 

I would like to know why, care to explain?

Thanks,
Aaron
--
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
Matthew Garrett - April 2, 2013, 7:08 p.m.
On Tue, Apr 02, 2013 at 09:44:07PM +0800, Aaron Lu wrote:
> On 04/02/2013 07:23 PM, Matthew Garrett wrote:
> > On Tue, Apr 02, 2013 at 05:15:03PM +0800, Aaron Lu wrote:
> > 
> >> Perhaps we can introduce a _BCM quirk function, with a DMI table for
> >> these systems.
> > 
> > No. Really, plesae no.
> > 
> 
> I would like to know why, care to explain?

Because Lenovo release another machine with the same behavour and it's 
broken until someone notices and files a bug and gets it added to a 
list. DMI blacklisting is almost always the wrong answer.
Ben Jencks - April 3, 2013, 7:04 a.m.
On 04/02/2013 09:00 AM, Seth Forshee wrote:
> On Tue, Apr 02, 2013 at 05:08:23PM +0800, Aaron Lu wrote:
>> On 04/01/2013 09:03 PM, Seth Forshee wrote:
>>> On Mon, Apr 01, 2013 at 09:53:36AM +0800, Aaron Lu wrote:
>>>> On 02/12/2013 12:21 AM, Seth Forshee wrote:
>>>>> The AML implementation for brightness control on several ThinkPads
>>>>> contains a workaround to meet a Windows 8 requirement of 101 brightness
>>>>> levels [1]. The implementation is flawed, as only 16 of the brighness
>>>>> values reported by _BCL affect a change in brightness. _BCM silently
>>>>> discards the rest of the values. Disabling Windows 8 compatibility on
>>>>> these machines reverts them to the old behavior, making _BCL only report
>>>>> the 16 brightness levels which actually work. Add a quirk to do this
>>>>> along with a dmi callback to disable Win8 compatibility.
>>>>
>>>> If we disable the _BQC(i.e. set cap._BQC=0) for these systems, will the
>>>> problem go away? If so, I think perhaps we can put these systems into a
>>>> _BQC quirk table and set cap._BQC=0 for them.
>>>
>>> That helps a little, but we're still left with only 16 of the 101
>>> brightness levels causing any change in brightness. The firmware isn't
>>> rounding the "bad" values or anything like that; it just silently
>>> ignores them.
>>
>> I really wondered, how Windows handled this, it should have the same
>> problem, unless they are not using the acpi video interface?
> 
> I can only guess.
> 
> I think I remember reading that Windows 8 does smooth backlight
> transitions, so it may well hit every intermediate brightness value.
> Lenovo could also be supplying a driver which rounds values to the
> nearest working value or uses some other interface or something else.

Just checked; Windows 8 doesn't use the ACPI interface. It seems to have
access to at least 100 distinct brightness levels.

I'd guess it's using the same interface as
/sys/class/backlight/intel_backlight, which on my system has a
max_brightness of 4438 and all the values seem to be actually distinct,
if not necessarily discernible to the naked eye.

-Ben
--
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
Aaron Lu - April 3, 2013, 7:27 a.m.
On 04/03/2013 03:04 PM, Ben Jencks wrote:
> On 04/02/2013 09:00 AM, Seth Forshee wrote:
>> On Tue, Apr 02, 2013 at 05:08:23PM +0800, Aaron Lu wrote:
>>> On 04/01/2013 09:03 PM, Seth Forshee wrote:
>>>> On Mon, Apr 01, 2013 at 09:53:36AM +0800, Aaron Lu wrote:
>>>>> On 02/12/2013 12:21 AM, Seth Forshee wrote:
>>>>>> The AML implementation for brightness control on several ThinkPads
>>>>>> contains a workaround to meet a Windows 8 requirement of 101 brightness
>>>>>> levels [1]. The implementation is flawed, as only 16 of the brighness
>>>>>> values reported by _BCL affect a change in brightness. _BCM silently
>>>>>> discards the rest of the values. Disabling Windows 8 compatibility on
>>>>>> these machines reverts them to the old behavior, making _BCL only report
>>>>>> the 16 brightness levels which actually work. Add a quirk to do this
>>>>>> along with a dmi callback to disable Win8 compatibility.
>>>>>
>>>>> If we disable the _BQC(i.e. set cap._BQC=0) for these systems, will the
>>>>> problem go away? If so, I think perhaps we can put these systems into a
>>>>> _BQC quirk table and set cap._BQC=0 for them.
>>>>
>>>> That helps a little, but we're still left with only 16 of the 101
>>>> brightness levels causing any change in brightness. The firmware isn't
>>>> rounding the "bad" values or anything like that; it just silently
>>>> ignores them.
>>>
>>> I really wondered, how Windows handled this, it should have the same
>>> problem, unless they are not using the acpi video interface?
>>
>> I can only guess.
>>
>> I think I remember reading that Windows 8 does smooth backlight
>> transitions, so it may well hit every intermediate brightness value.
>> Lenovo could also be supplying a driver which rounds values to the
>> nearest working value or uses some other interface or something else.
> 
> Just checked; Windows 8 doesn't use the ACPI interface. It seems to have
> access to at least 100 distinct brightness levels.
> 
> I'd guess it's using the same interface as
> /sys/class/backlight/intel_backlight, which on my system has a
> max_brightness of 4438 and all the values seem to be actually distinct,
> if not necessarily discernible to the naked eye.

Thanks for the information.

If all these affected systems have gpu driver's interface, I think we
can simply add them to the video_detect_dmi_table so that no acpi
backlight interface will be created for them, and gpu's interface will
be used by user space and hotkey processing can still be handled by acpi
video driver.

Best regards,
Aaron

--
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
Seth Forshee - April 3, 2013, 1:45 p.m.
On Wed, Apr 03, 2013 at 03:27:46PM +0800, Aaron Lu wrote:
> On 04/03/2013 03:04 PM, Ben Jencks wrote:
> > On 04/02/2013 09:00 AM, Seth Forshee wrote:
> >> On Tue, Apr 02, 2013 at 05:08:23PM +0800, Aaron Lu wrote:
> >>> On 04/01/2013 09:03 PM, Seth Forshee wrote:
> >>>> On Mon, Apr 01, 2013 at 09:53:36AM +0800, Aaron Lu wrote:
> >>>>> On 02/12/2013 12:21 AM, Seth Forshee wrote:
> >>>>>> The AML implementation for brightness control on several ThinkPads
> >>>>>> contains a workaround to meet a Windows 8 requirement of 101 brightness
> >>>>>> levels [1]. The implementation is flawed, as only 16 of the brighness
> >>>>>> values reported by _BCL affect a change in brightness. _BCM silently
> >>>>>> discards the rest of the values. Disabling Windows 8 compatibility on
> >>>>>> these machines reverts them to the old behavior, making _BCL only report
> >>>>>> the 16 brightness levels which actually work. Add a quirk to do this
> >>>>>> along with a dmi callback to disable Win8 compatibility.
> >>>>>
> >>>>> If we disable the _BQC(i.e. set cap._BQC=0) for these systems, will the
> >>>>> problem go away? If so, I think perhaps we can put these systems into a
> >>>>> _BQC quirk table and set cap._BQC=0 for them.
> >>>>
> >>>> That helps a little, but we're still left with only 16 of the 101
> >>>> brightness levels causing any change in brightness. The firmware isn't
> >>>> rounding the "bad" values or anything like that; it just silently
> >>>> ignores them.
> >>>
> >>> I really wondered, how Windows handled this, it should have the same
> >>> problem, unless they are not using the acpi video interface?
> >>
> >> I can only guess.
> >>
> >> I think I remember reading that Windows 8 does smooth backlight
> >> transitions, so it may well hit every intermediate brightness value.
> >> Lenovo could also be supplying a driver which rounds values to the
> >> nearest working value or uses some other interface or something else.
> > 
> > Just checked; Windows 8 doesn't use the ACPI interface. It seems to have
> > access to at least 100 distinct brightness levels.
> > 
> > I'd guess it's using the same interface as
> > /sys/class/backlight/intel_backlight, which on my system has a
> > max_brightness of 4438 and all the values seem to be actually distinct,
> > if not necessarily discernible to the naked eye.
> 
> Thanks for the information.
> 
> If all these affected systems have gpu driver's interface, I think we
> can simply add them to the video_detect_dmi_table so that no acpi
> backlight interface will be created for them, and gpu's interface will
> be used by user space and hotkey processing can still be handled by acpi
> video driver.

I've got two machines here with discrete graphics, one with nvidia and
one with AMD (neither one is a Lenovo). With the nvidia machine neither
nouveau nor the proprietary driver registers a backlight device. On the
AMD machine radeon does register a backlight but the proprietary driver
does not. So I think quirking away the acpi_video backlight interface
has potential to leave some users without any backlight control at all.

Seth
--
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
Aaron Lu - April 4, 2013, 11:39 a.m.
On 04/03/2013 09:45 PM, Seth Forshee wrote:
> On Wed, Apr 03, 2013 at 03:27:46PM +0800, Aaron Lu wrote:
>> On 04/03/2013 03:04 PM, Ben Jencks wrote:
>>> On 04/02/2013 09:00 AM, Seth Forshee wrote:
>>>> On Tue, Apr 02, 2013 at 05:08:23PM +0800, Aaron Lu wrote:
>>>>> On 04/01/2013 09:03 PM, Seth Forshee wrote:
>>>>>> On Mon, Apr 01, 2013 at 09:53:36AM +0800, Aaron Lu wrote:
>>>>>>> On 02/12/2013 12:21 AM, Seth Forshee wrote:
>>>>>>>> The AML implementation for brightness control on several ThinkPads
>>>>>>>> contains a workaround to meet a Windows 8 requirement of 101 brightness
>>>>>>>> levels [1]. The implementation is flawed, as only 16 of the brighness
>>>>>>>> values reported by _BCL affect a change in brightness. _BCM silently
>>>>>>>> discards the rest of the values. Disabling Windows 8 compatibility on
>>>>>>>> these machines reverts them to the old behavior, making _BCL only report
>>>>>>>> the 16 brightness levels which actually work. Add a quirk to do this
>>>>>>>> along with a dmi callback to disable Win8 compatibility.
>>>>>>>
>>>>>>> If we disable the _BQC(i.e. set cap._BQC=0) for these systems, will the
>>>>>>> problem go away? If so, I think perhaps we can put these systems into a
>>>>>>> _BQC quirk table and set cap._BQC=0 for them.
>>>>>>
>>>>>> That helps a little, but we're still left with only 16 of the 101
>>>>>> brightness levels causing any change in brightness. The firmware isn't
>>>>>> rounding the "bad" values or anything like that; it just silently
>>>>>> ignores them.
>>>>>
>>>>> I really wondered, how Windows handled this, it should have the same
>>>>> problem, unless they are not using the acpi video interface?
>>>>
>>>> I can only guess.
>>>>
>>>> I think I remember reading that Windows 8 does smooth backlight
>>>> transitions, so it may well hit every intermediate brightness value.
>>>> Lenovo could also be supplying a driver which rounds values to the
>>>> nearest working value or uses some other interface or something else.
>>>
>>> Just checked; Windows 8 doesn't use the ACPI interface. It seems to have
>>> access to at least 100 distinct brightness levels.
>>>
>>> I'd guess it's using the same interface as
>>> /sys/class/backlight/intel_backlight, which on my system has a
>>> max_brightness of 4438 and all the values seem to be actually distinct,
>>> if not necessarily discernible to the naked eye.
>>
>> Thanks for the information.
>>
>> If all these affected systems have gpu driver's interface, I think we
>> can simply add them to the video_detect_dmi_table so that no acpi
>> backlight interface will be created for them, and gpu's interface will
>> be used by user space and hotkey processing can still be handled by acpi
>> video driver.
> 
> I've got two machines here with discrete graphics, one with nvidia and
> one with AMD (neither one is a Lenovo). With the nvidia machine neither
> nouveau nor the proprietary driver registers a backlight device. On the
> AMD machine radeon does register a backlight but the proprietary driver
> does not. So I think quirking away the acpi_video backlight interface
> has potential to leave some users without any backlight control at all.

Then let's try to work around this problem in acpi video driver.

Thanks,
Aaron

> 
> Seth
> --
> 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
> 

--
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
Aaron Lu - April 19, 2013, 3:15 a.m.
On 04/03/2013 03:04 PM, Ben Jencks wrote:
> On 04/02/2013 09:00 AM, Seth Forshee wrote:
>> On Tue, Apr 02, 2013 at 05:08:23PM +0800, Aaron Lu wrote:
>>>
>>> I really wondered, how Windows handled this, it should have the same
>>> problem, unless they are not using the acpi video interface?
>>
>> I can only guess.
>>
>> I think I remember reading that Windows 8 does smooth backlight
>> transitions, so it may well hit every intermediate brightness value.
>> Lenovo could also be supplying a driver which rounds values to the
>> nearest working value or uses some other interface or something else.
> 
> Just checked; Windows 8 doesn't use the ACPI interface. It seems to have
> access to at least 100 distinct brightness levels.

I just came across a document on win8 backlight control, it has words
like this:
"
In Windows 8, the primary mechanism by which a platform should expose
its display brightness control functionality is the Windows Display
Driver Model (WDDM) miniport Device Driver Interfaces (DDI).
"
So looks like, on win8, ACPI interface is not used for these systems.

The link for the document is here:
http://msdn.microsoft.com/en-US/library/windows/hardware/jj159305

-Aaron

--
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
Seth Forshee - April 19, 2013, 12:24 p.m.
On Mon, Mar 18, 2013 at 04:25:46PM -0500, Seth Forshee wrote:
> > I've had the patches implementing your suggestions written for a while
> > now but just got test feedback this week. So here they are.
> 
> Ping.
> 
> Matthew, do these patches look like what you had in mind?

What needs to be done to move forward on this issue? Because so far no
one besides Aaron has made any comment at all on the actual content of
the patches.

Thanks,
Seth

--
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
Rafael Wysocki - April 20, 2013, 10:06 p.m.
On Friday, April 19, 2013 07:24:03 AM Seth Forshee wrote:
> On Mon, Mar 18, 2013 at 04:25:46PM -0500, Seth Forshee wrote:
> > > I've had the patches implementing your suggestions written for a while
> > > now but just got test feedback this week. So here they are.
> > 
> > Ping.
> > 
> > Matthew, do these patches look like what you had in mind?
> 
> What needs to be done to move forward on this issue? Because so far no
> one besides Aaron has made any comment at all on the actual content of
> the patches.

I'm not commenting mostly because I haven't had the time to think more about
this issue yet.  Sorry about that.

If I were to comment without much consideration, though, I'd say I wasn't
particularly impressed by any approach mentioned so far.

Thanks,
Rafael
Rafael Wysocki - April 20, 2013, 10:06 p.m.
On Friday, April 19, 2013 11:15:57 AM Aaron Lu wrote:
> On 04/03/2013 03:04 PM, Ben Jencks wrote:
> > On 04/02/2013 09:00 AM, Seth Forshee wrote:
> >> On Tue, Apr 02, 2013 at 05:08:23PM +0800, Aaron Lu wrote:
> >>>
> >>> I really wondered, how Windows handled this, it should have the same
> >>> problem, unless they are not using the acpi video interface?
> >>
> >> I can only guess.
> >>
> >> I think I remember reading that Windows 8 does smooth backlight
> >> transitions, so it may well hit every intermediate brightness value.
> >> Lenovo could also be supplying a driver which rounds values to the
> >> nearest working value or uses some other interface or something else.
> > 
> > Just checked; Windows 8 doesn't use the ACPI interface. It seems to have
> > access to at least 100 distinct brightness levels.
> 
> I just came across a document on win8 backlight control, it has words
> like this:
> "
> In Windows 8, the primary mechanism by which a platform should expose
> its display brightness control functionality is the Windows Display
> Driver Model (WDDM) miniport Device Driver Interfaces (DDI).
> "
> So looks like, on win8, ACPI interface is not used for these systems.
> 
> The link for the document is here:
> http://msdn.microsoft.com/en-US/library/windows/hardware/jj159305

OK, so what does that mean for the issue at hand?

Rafael
Seth Forshee - April 21, 2013, 2:29 a.m.
On Sun, Apr 21, 2013 at 12:06:00AM +0200, Rafael J. Wysocki wrote:
> On Friday, April 19, 2013 07:24:03 AM Seth Forshee wrote:
> > On Mon, Mar 18, 2013 at 04:25:46PM -0500, Seth Forshee wrote:
> > > > I've had the patches implementing your suggestions written for a while
> > > > now but just got test feedback this week. So here they are.
> > > 
> > > Ping.
> > > 
> > > Matthew, do these patches look like what you had in mind?
> > 
> > What needs to be done to move forward on this issue? Because so far no
> > one besides Aaron has made any comment at all on the actual content of
> > the patches.
> 
> I'm not commenting mostly because I haven't had the time to think more about
> this issue yet.  Sorry about that.
> 
> If I were to comment without much consideration, though, I'd say I wasn't
> particularly impressed by any approach mentioned so far.

I doubt there's going to be any "good" solution to this problem. What
gives the best results is to force the affected models back to the
pre-Win8 behavior, but of course that requires quirking. If we could
assume that all graphics drivers will export backlight control then just
disabling the ACPI interface for these machines would work nearly as
well, but I don't think we can count on that, and it probably requires
quirking as well.

If we rule out quirking there are only a couple of options that anyone
has suggested. We can hit every intermediate brightness level as in the
patches I sent, but this is imperfect and requires a number of
comprimises. Or we can test every level the machine claims to support
and see which ones cause the value returned by _BQC to change, which
seems like it ought to work but means changing the brightness during
boot (which Matthew already objected to, though in another context). I
haven't been able to think of any others, but I'm happy to listen to
suggestions.

Thanks,
Seth

--
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
Aaron Lu - April 21, 2013, 11:07 a.m.
On 04/21/2013 06:06 AM, Rafael J. Wysocki wrote:
> On Friday, April 19, 2013 11:15:57 AM Aaron Lu wrote:
>> On 04/03/2013 03:04 PM, Ben Jencks wrote:
>>> On 04/02/2013 09:00 AM, Seth Forshee wrote:
>>>> On Tue, Apr 02, 2013 at 05:08:23PM +0800, Aaron Lu wrote:
>>>>>
>>>>> I really wondered, how Windows handled this, it should have the same
>>>>> problem, unless they are not using the acpi video interface?
>>>>
>>>> I can only guess.
>>>>
>>>> I think I remember reading that Windows 8 does smooth backlight
>>>> transitions, so it may well hit every intermediate brightness value.
>>>> Lenovo could also be supplying a driver which rounds values to the
>>>> nearest working value or uses some other interface or something else.
>>>
>>> Just checked; Windows 8 doesn't use the ACPI interface. It seems to have
>>> access to at least 100 distinct brightness levels.
>>
>> I just came across a document on win8 backlight control, it has words
>> like this:
>> "
>> In Windows 8, the primary mechanism by which a platform should expose
>> its display brightness control functionality is the Windows Display
>> Driver Model (WDDM) miniport Device Driver Interfaces (DDI).
>> "
>> So looks like, on win8, ACPI interface is not used for these systems.
>>
>> The link for the document is here:
>> http://msdn.microsoft.com/en-US/library/windows/hardware/jj159305
>
> OK, so what does that mean for the issue at hand?

That means, we should not try to use acpi video interface to control
backlight on these systems if they are in win8 mode.

-Aaron
--
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
Aaron Lu - April 21, 2013, 12:11 p.m.
On 04/21/2013 07:07 PM, Aaron Lu wrote:
> On 04/21/2013 06:06 AM, Rafael J. Wysocki wrote:
>> On Friday, April 19, 2013 11:15:57 AM Aaron Lu wrote:
>>> On 04/03/2013 03:04 PM, Ben Jencks wrote:
>>>> On 04/02/2013 09:00 AM, Seth Forshee wrote:
>>>>> On Tue, Apr 02, 2013 at 05:08:23PM +0800, Aaron Lu wrote:
>>>>>>
>>>>>> I really wondered, how Windows handled this, it should have the same
>>>>>> problem, unless they are not using the acpi video interface?
>>>>>
>>>>> I can only guess.
>>>>>
>>>>> I think I remember reading that Windows 8 does smooth backlight
>>>>> transitions, so it may well hit every intermediate brightness value.
>>>>> Lenovo could also be supplying a driver which rounds values to the
>>>>> nearest working value or uses some other interface or something else.
>>>>
>>>> Just checked; Windows 8 doesn't use the ACPI interface. It seems to
>>>> have
>>>> access to at least 100 distinct brightness levels.
>>>
>>> I just came across a document on win8 backlight control, it has words
>>> like this:
>>> "
>>> In Windows 8, the primary mechanism by which a platform should expose
>>> its display brightness control functionality is the Windows Display
>>> Driver Model (WDDM) miniport Device Driver Interfaces (DDI).
>>> "
>>> So looks like, on win8, ACPI interface is not used for these systems.
>>>
>>> The link for the document is here:
>>> http://msdn.microsoft.com/en-US/library/windows/hardware/jj159305
>>
>> OK, so what does that mean for the issue at hand?
>
> That means, we should not try to use acpi video interface to control
> backlight on these systems if they are in win8 mode.

The reason I mentioned this document is: we have been wondering how
windows handle such systems, and according to Ben's own use of win8, he
thinks win8 is not using acpi interface to control backlight. And the
words from the document that I pasted here kind of confirms this I think,
so I mentioned this document here, it is used to confirm how windows
handle such systems: using a native driver instead of acpi video
interface.

Thanks,
Aaron
--
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
Henrique de Moraes Holschuh - April 21, 2013, 3:46 p.m.
On Sat, 20 Apr 2013, Seth Forshee wrote:
> pre-Win8 behavior, but of course that requires quirking. If we could
> assume that all graphics drivers will export backlight control then just
> disabling the ACPI interface for these machines would work nearly as
> well, but I don't think we can count on that, and it probably requires
> quirking as well.

You can certainly do that for all thinkpads with win8 compatibility.
Rafael Wysocki - April 21, 2013, 9:42 p.m.
On Sunday, April 21, 2013 07:07:04 PM Aaron Lu wrote:
> On 04/21/2013 06:06 AM, Rafael J. Wysocki wrote:
> > On Friday, April 19, 2013 11:15:57 AM Aaron Lu wrote:
> >> On 04/03/2013 03:04 PM, Ben Jencks wrote:
> >>> On 04/02/2013 09:00 AM, Seth Forshee wrote:
> >>>> On Tue, Apr 02, 2013 at 05:08:23PM +0800, Aaron Lu wrote:
> >>>>>
> >>>>> I really wondered, how Windows handled this, it should have the same
> >>>>> problem, unless they are not using the acpi video interface?
> >>>>
> >>>> I can only guess.
> >>>>
> >>>> I think I remember reading that Windows 8 does smooth backlight
> >>>> transitions, so it may well hit every intermediate brightness value.
> >>>> Lenovo could also be supplying a driver which rounds values to the
> >>>> nearest working value or uses some other interface or something else.
> >>>
> >>> Just checked; Windows 8 doesn't use the ACPI interface. It seems to have
> >>> access to at least 100 distinct brightness levels.
> >>
> >> I just came across a document on win8 backlight control, it has words
> >> like this:
> >> "
> >> In Windows 8, the primary mechanism by which a platform should expose
> >> its display brightness control functionality is the Windows Display
> >> Driver Model (WDDM) miniport Device Driver Interfaces (DDI).
> >> "
> >> So looks like, on win8, ACPI interface is not used for these systems.
> >>
> >> The link for the document is here:
> >> http://msdn.microsoft.com/en-US/library/windows/hardware/jj159305
> >
> > OK, so what does that mean for the issue at hand?
> 
> That means, we should not try to use acpi video interface to control
> backlight on these systems if they are in win8 mode.

In that case, how are we going to indentify "these systems"?

Rafael
Joey Lee - April 22, 2013, 2:18 a.m.
? ??2013-04-19 ? 11:15 +0800?Aaron Lu ???
> On 04/03/2013 03:04 PM, Ben Jencks wrote:
> > On 04/02/2013 09:00 AM, Seth Forshee wrote:
> >> On Tue, Apr 02, 2013 at 05:08:23PM +0800, Aaron Lu wrote:
> >>>
> >>> I really wondered, how Windows handled this, it should have the same
> >>> problem, unless they are not using the acpi video interface?
> >>
> >> I can only guess.
> >>
> >> I think I remember reading that Windows 8 does smooth backlight
> >> transitions, so it may well hit every intermediate brightness value.
> >> Lenovo could also be supplying a driver which rounds values to the
> >> nearest working value or uses some other interface or something else.
> > 
> > Just checked; Windows 8 doesn't use the ACPI interface. It seems to have
> > access to at least 100 distinct brightness levels.
> 
> I just came across a document on win8 backlight control, it has words
> like this:
> "
> In Windows 8, the primary mechanism by which a platform should expose
> its display brightness control functionality is the Windows Display
> Driver Model (WDDM) miniport Device Driver Interfaces (DDI).
> "
> So looks like, on win8, ACPI interface is not used for these systems.
> 
> The link for the document is here:
> http://msdn.microsoft.com/en-US/library/windows/hardware/jj159305
> 
> -Aaron
> 

Per WDDM document, OEM/ODM should keep the ACPI methods (_BQL, _BCM,
_BQC) available for compliant to the OS that doesn't support WDDM, e.g.
XP, Vista.

But, I discussed with Acer for this situation at last year, they didn't
force their ODM do test ACPI compatibility. They only test through
Windows 8 UI with Fn keys.


Thanks a lot!
Joey Lee

--
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
Aaron Lu - April 22, 2013, 9:39 a.m.
On 04/22/2013 05:42 AM, Rafael J. Wysocki wrote:
> On Sunday, April 21, 2013 07:07:04 PM Aaron Lu wrote:
>> On 04/21/2013 06:06 AM, Rafael J. Wysocki wrote:
>>> On Friday, April 19, 2013 11:15:57 AM Aaron Lu wrote:
>>>> On 04/03/2013 03:04 PM, Ben Jencks wrote:
>>>>> On 04/02/2013 09:00 AM, Seth Forshee wrote:
>>>>>> On Tue, Apr 02, 2013 at 05:08:23PM +0800, Aaron Lu wrote:
>>>>>>>
>>>>>>> I really wondered, how Windows handled this, it should have the same
>>>>>>> problem, unless they are not using the acpi video interface?
>>>>>>
>>>>>> I can only guess.
>>>>>>
>>>>>> I think I remember reading that Windows 8 does smooth backlight
>>>>>> transitions, so it may well hit every intermediate brightness value.
>>>>>> Lenovo could also be supplying a driver which rounds values to the
>>>>>> nearest working value or uses some other interface or something else.
>>>>>
>>>>> Just checked; Windows 8 doesn't use the ACPI interface. It seems to have
>>>>> access to at least 100 distinct brightness levels.
>>>>
>>>> I just came across a document on win8 backlight control, it has words
>>>> like this:
>>>> "
>>>> In Windows 8, the primary mechanism by which a platform should expose
>>>> its display brightness control functionality is the Windows Display
>>>> Driver Model (WDDM) miniport Device Driver Interfaces (DDI).
>>>> "
>>>> So looks like, on win8, ACPI interface is not used for these systems.
>>>>
>>>> The link for the document is here:
>>>> http://msdn.microsoft.com/en-US/library/windows/hardware/jj159305
>>>
>>> OK, so what does that mean for the issue at hand?
>>
>> That means, we should not try to use acpi video interface to control
>> backlight on these systems if they are in win8 mode.
> 
> In that case, how are we going to indentify "these systems"?

Sorry, I don't know.

According to the following bug page:
https://bugzilla.kernel.org/show_bug.cgi?id=51231
"these systems" now include: thinkpad x230, t430s, t530, L430.

-Aaron

--
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
Aaron Lu - April 22, 2013, 10:08 a.m.
On 04/22/2013 10:18 AM, joeyli wrote:
> ? ??2013-04-19 ? 11:15 +0800?Aaron Lu ???
>> On 04/03/2013 03:04 PM, Ben Jencks wrote:
>>> On 04/02/2013 09:00 AM, Seth Forshee wrote:
>>>> On Tue, Apr 02, 2013 at 05:08:23PM +0800, Aaron Lu wrote:
>>>>>
>>>>> I really wondered, how Windows handled this, it should have the same
>>>>> problem, unless they are not using the acpi video interface?
>>>>
>>>> I can only guess.
>>>>
>>>> I think I remember reading that Windows 8 does smooth backlight
>>>> transitions, so it may well hit every intermediate brightness value.
>>>> Lenovo could also be supplying a driver which rounds values to the
>>>> nearest working value or uses some other interface or something else.
>>>
>>> Just checked; Windows 8 doesn't use the ACPI interface. It seems to have
>>> access to at least 100 distinct brightness levels.
>>
>> I just came across a document on win8 backlight control, it has words
>> like this:
>> "
>> In Windows 8, the primary mechanism by which a platform should expose
>> its display brightness control functionality is the Windows Display
>> Driver Model (WDDM) miniport Device Driver Interfaces (DDI).
>> "
>> So looks like, on win8, ACPI interface is not used for these systems.
>>
>> The link for the document is here:
>> http://msdn.microsoft.com/en-US/library/windows/hardware/jj159305
>>
>> -Aaron
>>
> 
> Per WDDM document, OEM/ODM should keep the ACPI methods (_BQL, _BCM,
> _BQC) available for compliant to the OS that doesn't support WDDM, e.g.
> XP, Vista.

Thanks for the information, so this suggests that acpi interface is
mostly used for pre-win8 OSes?(does win7 support WDDM?)

One interesting thing is, if they do not support acpi interface, why
they even bother to expose this interface in acpi table?

-Aaron
--
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
Rafael Wysocki - April 22, 2013, 11:51 a.m.
On Monday, April 22, 2013 05:39:43 PM Aaron Lu wrote:
> On 04/22/2013 05:42 AM, Rafael J. Wysocki wrote:
> > On Sunday, April 21, 2013 07:07:04 PM Aaron Lu wrote:
> >> On 04/21/2013 06:06 AM, Rafael J. Wysocki wrote:
> >>> On Friday, April 19, 2013 11:15:57 AM Aaron Lu wrote:
> >>>> On 04/03/2013 03:04 PM, Ben Jencks wrote:
> >>>>> On 04/02/2013 09:00 AM, Seth Forshee wrote:
> >>>>>> On Tue, Apr 02, 2013 at 05:08:23PM +0800, Aaron Lu wrote:
> >>>>>>>
> >>>>>>> I really wondered, how Windows handled this, it should have the same
> >>>>>>> problem, unless they are not using the acpi video interface?
> >>>>>>
> >>>>>> I can only guess.
> >>>>>>
> >>>>>> I think I remember reading that Windows 8 does smooth backlight
> >>>>>> transitions, so it may well hit every intermediate brightness value.
> >>>>>> Lenovo could also be supplying a driver which rounds values to the
> >>>>>> nearest working value or uses some other interface or something else.
> >>>>>
> >>>>> Just checked; Windows 8 doesn't use the ACPI interface. It seems to have
> >>>>> access to at least 100 distinct brightness levels.
> >>>>
> >>>> I just came across a document on win8 backlight control, it has words
> >>>> like this:
> >>>> "
> >>>> In Windows 8, the primary mechanism by which a platform should expose
> >>>> its display brightness control functionality is the Windows Display
> >>>> Driver Model (WDDM) miniport Device Driver Interfaces (DDI).
> >>>> "
> >>>> So looks like, on win8, ACPI interface is not used for these systems.
> >>>>
> >>>> The link for the document is here:
> >>>> http://msdn.microsoft.com/en-US/library/windows/hardware/jj159305
> >>>
> >>> OK, so what does that mean for the issue at hand?
> >>
> >> That means, we should not try to use acpi video interface to control
> >> backlight on these systems if they are in win8 mode.
> > 
> > In that case, how are we going to indentify "these systems"?
> 
> Sorry, I don't know.
> 
> According to the following bug page:
> https://bugzilla.kernel.org/show_bug.cgi?id=51231
> "these systems" now include: thinkpad x230, t430s, t530, L430.

I suppose we need to blacklist them to start with.  I wouldn't like to apply
any general changes before we know how many different systems are affected by
this particular issue.

Thanks,
Rafael
Joey Lee - April 22, 2013, noon
? ??2013-04-22 ? 18:08 +0800?Aaron Lu ???
> On 04/22/2013 10:18 AM, joeyli wrote:
> > ? ??2013-04-19 ? 11:15 +0800?Aaron Lu ???
> >> On 04/03/2013 03:04 PM, Ben Jencks wrote:
> >>> On 04/02/2013 09:00 AM, Seth Forshee wrote:
> >>>> On Tue, Apr 02, 2013 at 05:08:23PM +0800, Aaron Lu wrote:
> >>>>>
> >>>>> I really wondered, how Windows handled this, it should have the same
> >>>>> problem, unless they are not using the acpi video interface?
> >>>>
> >>>> I can only guess.
> >>>>
> >>>> I think I remember reading that Windows 8 does smooth backlight
> >>>> transitions, so it may well hit every intermediate brightness value.
> >>>> Lenovo could also be supplying a driver which rounds values to the
> >>>> nearest working value or uses some other interface or something else.
> >>>
> >>> Just checked; Windows 8 doesn't use the ACPI interface. It seems to have
> >>> access to at least 100 distinct brightness levels.
> >>
> >> I just came across a document on win8 backlight control, it has words
> >> like this:
> >> "
> >> In Windows 8, the primary mechanism by which a platform should expose
> >> its display brightness control functionality is the Windows Display
> >> Driver Model (WDDM) miniport Device Driver Interfaces (DDI).
> >> "
> >> So looks like, on win8, ACPI interface is not used for these systems.
> >>
> >> The link for the document is here:
> >> http://msdn.microsoft.com/en-US/library/windows/hardware/jj159305
> >>
> >> -Aaron
> >>
> > 
> > Per WDDM document, OEM/ODM should keep the ACPI methods (_BQL, _BCM,
> > _BQC) available for compliant to the OS that doesn't support WDDM, e.g.
> > XP, Vista.
> 
> Thanks for the information, so this suggests that acpi interface is
> mostly used for pre-win8 OSes?(does win7 support WDDM?)

Yes, they applied WDDM driver support on Windows 7 platform, but I don't
know how many models only work on WDDM and have broken ACPI
implementation.

> 
> One interesting thing is, if they do not support acpi interface, why
> they even bother to expose this interface in acpi table?
> 
> -Aaron
> 

I don't know, maybe they just thought that doesn't hurt anything because
they only test Windows 7 or Windows 8, dependent on which OS preloaded
and shipped with the machine.

Use OSI string fallback to Windows XP or Vista mode sometimes can
workaround problem when we are lucky. But, bad thing is OEM/ODM also
didn't test XP/Vista code path with other ACPI features, e.g. S3/S4.

Fallback to vendor mode, leave video driver to control backlight is what
we done in platform driver, that's why we have quirk table. That best
situation is we find a general logic to detect does issue machine
shipped with WDDM driver. It's out of my knowledge.


Thanks a lot!
Joey Lee

--
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
Aaron Lu - April 22, 2013, 12:11 p.m.
On 04/22/2013 07:51 PM, Rafael J. Wysocki wrote:
> On Monday, April 22, 2013 05:39:43 PM Aaron Lu wrote:
>> On 04/22/2013 05:42 AM, Rafael J. Wysocki wrote:
>>> On Sunday, April 21, 2013 07:07:04 PM Aaron Lu wrote:
>>>> On 04/21/2013 06:06 AM, Rafael J. Wysocki wrote:
>>>>> On Friday, April 19, 2013 11:15:57 AM Aaron Lu wrote:
>>>>>> On 04/03/2013 03:04 PM, Ben Jencks wrote:
>>>>>>> On 04/02/2013 09:00 AM, Seth Forshee wrote:
>>>>>>>> On Tue, Apr 02, 2013 at 05:08:23PM +0800, Aaron Lu wrote:
>>>>>>>>>
>>>>>>>>> I really wondered, how Windows handled this, it should have the same
>>>>>>>>> problem, unless they are not using the acpi video interface?
>>>>>>>>
>>>>>>>> I can only guess.
>>>>>>>>
>>>>>>>> I think I remember reading that Windows 8 does smooth backlight
>>>>>>>> transitions, so it may well hit every intermediate brightness value.
>>>>>>>> Lenovo could also be supplying a driver which rounds values to the
>>>>>>>> nearest working value or uses some other interface or something else.
>>>>>>>
>>>>>>> Just checked; Windows 8 doesn't use the ACPI interface. It seems to have
>>>>>>> access to at least 100 distinct brightness levels.
>>>>>>
>>>>>> I just came across a document on win8 backlight control, it has words
>>>>>> like this:
>>>>>> "
>>>>>> In Windows 8, the primary mechanism by which a platform should expose
>>>>>> its display brightness control functionality is the Windows Display
>>>>>> Driver Model (WDDM) miniport Device Driver Interfaces (DDI).
>>>>>> "
>>>>>> So looks like, on win8, ACPI interface is not used for these systems.
>>>>>>
>>>>>> The link for the document is here:
>>>>>> http://msdn.microsoft.com/en-US/library/windows/hardware/jj159305
>>>>>
>>>>> OK, so what does that mean for the issue at hand?
>>>>
>>>> That means, we should not try to use acpi video interface to control
>>>> backlight on these systems if they are in win8 mode.
>>>
>>> In that case, how are we going to indentify "these systems"?
>>
>> Sorry, I don't know.
>>
>> According to the following bug page:
>> https://bugzilla.kernel.org/show_bug.cgi?id=51231
>> "these systems" now include: thinkpad x230, t430s, t530, L430.
> 
> I suppose we need to blacklist them to start with.  I wouldn't like to apply
> any general changes before we know how many different systems are affected by
> this particular issue.

I totally agree.

Thanks,
Aaron
--
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
Seth Forshee - April 22, 2013, 1:06 p.m.
On Mon, Apr 22, 2013 at 08:11:17PM +0800, Aaron Lu wrote:
> On 04/22/2013 07:51 PM, Rafael J. Wysocki wrote:
> > On Monday, April 22, 2013 05:39:43 PM Aaron Lu wrote:
> >> On 04/22/2013 05:42 AM, Rafael J. Wysocki wrote:
> >>> On Sunday, April 21, 2013 07:07:04 PM Aaron Lu wrote:
> >>>> On 04/21/2013 06:06 AM, Rafael J. Wysocki wrote:
> >>>>> On Friday, April 19, 2013 11:15:57 AM Aaron Lu wrote:
> >>>>>> On 04/03/2013 03:04 PM, Ben Jencks wrote:
> >>>>>>> On 04/02/2013 09:00 AM, Seth Forshee wrote:
> >>>>>>>> On Tue, Apr 02, 2013 at 05:08:23PM +0800, Aaron Lu wrote:
> >>>>>>>>>
> >>>>>>>>> I really wondered, how Windows handled this, it should have the same
> >>>>>>>>> problem, unless they are not using the acpi video interface?
> >>>>>>>>
> >>>>>>>> I can only guess.
> >>>>>>>>
> >>>>>>>> I think I remember reading that Windows 8 does smooth backlight
> >>>>>>>> transitions, so it may well hit every intermediate brightness value.
> >>>>>>>> Lenovo could also be supplying a driver which rounds values to the
> >>>>>>>> nearest working value or uses some other interface or something else.
> >>>>>>>
> >>>>>>> Just checked; Windows 8 doesn't use the ACPI interface. It seems to have
> >>>>>>> access to at least 100 distinct brightness levels.
> >>>>>>
> >>>>>> I just came across a document on win8 backlight control, it has words
> >>>>>> like this:
> >>>>>> "
> >>>>>> In Windows 8, the primary mechanism by which a platform should expose
> >>>>>> its display brightness control functionality is the Windows Display
> >>>>>> Driver Model (WDDM) miniport Device Driver Interfaces (DDI).
> >>>>>> "
> >>>>>> So looks like, on win8, ACPI interface is not used for these systems.
> >>>>>>
> >>>>>> The link for the document is here:
> >>>>>> http://msdn.microsoft.com/en-US/library/windows/hardware/jj159305
> >>>>>
> >>>>> OK, so what does that mean for the issue at hand?
> >>>>
> >>>> That means, we should not try to use acpi video interface to control
> >>>> backlight on these systems if they are in win8 mode.
> >>>
> >>> In that case, how are we going to indentify "these systems"?
> >>
> >> Sorry, I don't know.
> >>
> >> According to the following bug page:
> >> https://bugzilla.kernel.org/show_bug.cgi?id=51231
> >> "these systems" now include: thinkpad x230, t430s, t530, L430.

Also W530, X1 Carbon, and Edge E330.

> > I suppose we need to blacklist them to start with.  I wouldn't like to apply
> > any general changes before we know how many different systems are affected by
> > this particular issue.
> 
> I totally agree.

Are you sure that all of these machines have an alternate interface for
userspace to change the brightness? I know that I've got a non-Lenovo
machine with nVidia graphics for which nouveau exposes no backlight
control, and I have no idea what controls are exposed by the proprietary
graphics drivers.

Seth

--
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
Aaron Lu - April 22, 2013, 1:40 p.m.
On 04/22/2013 09:06 PM, Seth Forshee wrote:
> On Mon, Apr 22, 2013 at 08:11:17PM +0800, Aaron Lu wrote:
>> On 04/22/2013 07:51 PM, Rafael J. Wysocki wrote:
>>> I suppose we need to blacklist them to start with.  I wouldn't like to apply
>>> any general changes before we know how many different systems are affected by
>>> this particular issue.
>>
>> I totally agree.
>
> Are you sure that all of these machines have an alternate interface for
> userspace to change the brightness? I know that I've got a non-Lenovo
> machine with nVidia graphics for which nouveau exposes no backlight

What's the problem with this system then? The same as the thinkpads in
bug 51231?

-Aaron

> control, and I have no idea what controls are exposed by the proprietary
> graphics drivers.
>
> Seth
--
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
Seth Forshee - April 22, 2013, 1:56 p.m.
On Mon, Apr 22, 2013 at 09:40:00PM +0800, Aaron Lu wrote:
> On 04/22/2013 09:06 PM, Seth Forshee wrote:
> >On Mon, Apr 22, 2013 at 08:11:17PM +0800, Aaron Lu wrote:
> >>On 04/22/2013 07:51 PM, Rafael J. Wysocki wrote:
> >>>I suppose we need to blacklist them to start with.  I wouldn't like to apply
> >>>any general changes before we know how many different systems are affected by
> >>>this particular issue.
> >>
> >>I totally agree.
> >
> >Are you sure that all of these machines have an alternate interface for
> >userspace to change the brightness? I know that I've got a non-Lenovo
> >machine with nVidia graphics for which nouveau exposes no backlight
> 
> What's the problem with this system then? The same as the thinkpads in
> bug 51231?

There's no problem with that system; it has another working backlight
interface. I'm only mentioning it to demonstrate that taking away the
ACPI interface could leave some machines without any backlight control
mechanism that Linux currently supports.

Seth
--
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
Aaron Lu - April 22, 2013, 2:07 p.m.
On 04/22/2013 09:56 PM, Seth Forshee wrote:
> On Mon, Apr 22, 2013 at 09:40:00PM +0800, Aaron Lu wrote:
>> On 04/22/2013 09:06 PM, Seth Forshee wrote:
>>> On Mon, Apr 22, 2013 at 08:11:17PM +0800, Aaron Lu wrote:
>>>> On 04/22/2013 07:51 PM, Rafael J. Wysocki wrote:
>>>>> I suppose we need to blacklist them to start with.  I wouldn't like to apply
>>>>> any general changes before we know how many different systems are affected by
>>>>> this particular issue.
>>>>
>>>> I totally agree.
>>>
>>> Are you sure that all of these machines have an alternate interface for
>>> userspace to change the brightness? I know that I've got a non-Lenovo
>>> machine with nVidia graphics for which nouveau exposes no backlight
>>
>> What's the problem with this system then? The same as the thinkpads in
>> bug 51231?
>
> There's no problem with that system; it has another working backlight
> interface. I'm only mentioning it to demonstrate that taking away the
> ACPI interface could leave some machines without any backlight control
> mechanism that Linux currently supports.

I think we just need take away the ACPI interface for these known broken
systems for now, that would require: check if we are in win8 mode, if
so, disable acpi video interface for these known broken systems.

I think video_detect_dmi_table is the proper place to do this.

-Aaron
--
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
Seth Forshee - April 22, 2013, 3:11 p.m.
On Mon, Apr 22, 2013 at 10:07:32PM +0800, Aaron Lu wrote:
> On 04/22/2013 09:56 PM, Seth Forshee wrote:
> >On Mon, Apr 22, 2013 at 09:40:00PM +0800, Aaron Lu wrote:
> >>On 04/22/2013 09:06 PM, Seth Forshee wrote:
> >>>On Mon, Apr 22, 2013 at 08:11:17PM +0800, Aaron Lu wrote:
> >>>>On 04/22/2013 07:51 PM, Rafael J. Wysocki wrote:
> >>>>>I suppose we need to blacklist them to start with.  I wouldn't like to apply
> >>>>>any general changes before we know how many different systems are affected by
> >>>>>this particular issue.
> >>>>
> >>>>I totally agree.
> >>>
> >>>Are you sure that all of these machines have an alternate interface for
> >>>userspace to change the brightness? I know that I've got a non-Lenovo
> >>>machine with nVidia graphics for which nouveau exposes no backlight
> >>
> >>What's the problem with this system then? The same as the thinkpads in
> >>bug 51231?
> >
> >There's no problem with that system; it has another working backlight
> >interface. I'm only mentioning it to demonstrate that taking away the
> >ACPI interface could leave some machines without any backlight control
> >mechanism that Linux currently supports.
> 
> I think we just need take away the ACPI interface for these known broken
> systems for now, that would require: check if we are in win8 mode, if
> so, disable acpi video interface for these known broken systems.
> 
> I think video_detect_dmi_table is the proper place to do this.

Well, I suppose that's better than what we've got now. I'll post some
patches to the bug for testing.

Seth
--
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

Patch

diff --git a/drivers/acpi/blacklist.c b/drivers/acpi/blacklist.c
index cb96296..6c242ed 100644
--- a/drivers/acpi/blacklist.c
+++ b/drivers/acpi/blacklist.c
@@ -193,6 +193,13 @@  static int __init dmi_disable_osi_win7(const struct dmi_system_id *d)
 	return 0;
 }
 
+static int __init dmi_disable_osi_win8(const struct dmi_system_id *d)
+{
+	printk(KERN_NOTICE PREFIX "DMI detected: %s\n", d->ident);
+	acpi_osi_setup("!Windows 2012");
+	return 0;
+}
+
 static struct dmi_system_id acpi_osi_dmi_table[] __initdata = {
 	{
 	.callback = dmi_disable_osi_vista,
@@ -269,6 +276,61 @@  static struct dmi_system_id acpi_osi_dmi_table[] __initdata = {
 	},
 
 	/*
+	 * The following Lenovo models have a broken workaround in the
+	 * acpi_video backlight implementation to meet the Windows 8
+	 * requirement of 101 backlight levels. Reverting to pre-Win8
+	 * behavior fixes the problem.
+	 */
+	{
+	.callback = dmi_disable_osi_win8,
+	.ident = "Lenovo ThinkPad L430",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+		     DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad L430"),
+		},
+	},
+	{
+	.callback = dmi_disable_osi_win8,
+	.ident = "Lenovo ThinkPad T430s",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+		     DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad T430s"),
+		},
+	},
+	{
+	.callback = dmi_disable_osi_win8,
+	.ident = "Lenovo ThinkPad T530",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+		     DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad T530"),
+		},
+	},
+	{
+	.callback = dmi_disable_osi_win8,
+	.ident = "Lenovo ThinkPad W530",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+		     DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad W530"),
+		},
+	},
+	{
+	.callback = dmi_disable_osi_win8,
+	.ident = "Lenovo ThinkPad X1 Carbon",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+		     DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad X1 Carbon"),
+		},
+	},
+	{
+	.callback = dmi_disable_osi_win8,
+	.ident = "Lenovo ThinkPad X230",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+		     DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad X230"),
+		},
+	},
+
+	/*
 	 * BIOS invocation of _OSI(Linux) is almost always a BIOS bug.
 	 * Linux ignores it, except for the machines enumerated below.
 	 */