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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
