Re: [PATCH] ACPI: Disable Windows 8 compatibility for some Lenovo ThinkPads

[Aaron Lu <aaron.lu@intel.com>]

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
>