From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aaron Lu Subject: Re: [PATCH] ACPI: Disable Windows 8 compatibility for some Lenovo ThinkPads Date: Tue, 02 Apr 2013 17:15:03 +0800 Message-ID: <515AA197.7020601@intel.com> References: <1360599681-24781-1-git-send-email-seth.forshee@canonical.com> <20130211175213.GA25139@srcf.ucam.org> <20130211190617.GH13768@thinkpad-t410> <20130211190914.GA27364@srcf.ucam.org> <20130213203228.GE22867@thinkpad-t410> <20130213205558.GA16559@srcf.ucam.org> <20130307193812.GD24233@thinkpad-t410> <20130318212546.GC3964@thinkpad-t410> <515A6A10.70404@bjencks.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: Received: from mga11.intel.com ([192.55.52.93]:65321 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760434Ab3DBJNt (ORCPT ); Tue, 2 Apr 2013 05:13:49 -0400 In-Reply-To: <515A6A10.70404@bjencks.net> Sender: linux-acpi-owner@vger.kernel.org List-Id: linux-acpi@vger.kernel.org To: Ben Jencks , Seth Forshee Cc: Matthew Garrett , Len Brown , "Rafael J. Wysocki" , linux-acpi@vger.kernel.org, joeyli 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 >