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