| Message ID | 1360599681-24781-1-git-send-email-seth.forshee@canonical.com (mailing list archive) |
|---|---|
| State | RFC, archived |
| Headers | show |
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?
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
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?
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
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
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
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...
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
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
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
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
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.
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
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
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
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
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
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
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
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
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.
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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.
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
? ??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
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
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
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
? ??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
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
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
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
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
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
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
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. */
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(+)