> On Wednesday 13 August 2008, Alan Jenkins wrote:
>
>> [Dupe apology: CC'd to
stable@kernel.org, with the right address this time]
>>
>> Andrew Morton wrote:
>>
>>> On Wed, 13 Aug 2008 11:21:10 +0100 Alan Jenkins
>>>
> <alan-jenkins@tuffmail.co.uk> wrote:
>
>>>> Andrew Morton wrote:
>>>>
>>>>> Did this get fixed yet?
>>>>>
>>>>> I have an patch in -mm which I just restored (I had to tempdrop it
>>>>> because the acpi tree was busted for some time). But it seems to be
>>>>> old.
>>>>>
>>>>>
http://bugzilla.kernel.org/show_bug.cgi?id=10919 is marked "resolved"
>>>>> but the reporter (Maximilian) seems to think otherwise. 2.6.26.x is,
>>>>> afaik, still unfixed, as is 2.6.27-rc.
>>>>>
>>>> That's correct. I think this specific patch should go in 2.6.27 and
>>>> 2.6.26-stable. No objections have been raised so far.
>>>>
>>>> I still need this patch to make my brightness and volume control keys
>>>> usable in 2.6.27-rc3. (They auto-repeat fast enough to trigger the
>>>> bug). This is true even after applying the latest patches from bug
>>>> 10919 (#25 + #27).
>>>>
>>> Confusing. Please send the patch which you think we should apply.
>>>
>>>
>>>> I think the 10919 fix makes it harder to reproduce, but it definitely
>>>> still happens. I guess this is because the polling-driven EC
>>>> transactions add 1ms delays between each byte. The slower timings leave
>>>> a window where the buggy behaviour of my EC can make a difference. (It
>>>> has been seen to clear the "pending event" bit after a single event is
>>>> read, despite having more events pending).
>>>>
>>>> There are more serious consequences of this bug. After a while it can
>>>> confuse the EC enough to cause lockups or reboots during boot, or after
>>>> pressing a single hotkey. This bad state is preserved over reboots,
>>>> even into known good kernels. Fortunately the badness clears when power
>>>> is removed for a long enough period. For a while I was worried that
>>>> something had physically burnt out.
>>>>
>>> Oh gad. And there's no workaround?
>>>
>> Sorry, that was confusing.
>>
>> The patch in currently in -mm _is_ the workaround for this damage. It
>> was not initially obvious just how important it was :-). I've
>> re-attached it as requested.
>>
>> 10919, "laggy hotkeys" is just what it says; ACPI EC events are slower
>> because of polling. It appears to be a more cosmetic issue which is
>> orthogonal to the _dropping_ of events.
>>
>> Thanks
>> Alan
>>
>
> This patch doesn't fix my problem (bug 10919), it only changes it a bit.
> When I press the dimming key and hold it pressed the display should dim
> up/down step by step as long as I hold the key pressed (that's how it has
> always been).
> I'm now running a 2.6.27-rc3 kernel with your patch applied and the display
> does dim as described below.
> When I press the dimming key first the display brightness doesn't change at
> all, then it jumps multiple steps, stays there for a short while and again
> jumps some steps till it reaches the end of the dimming interval.
> It looks like the key presses (assuming holding down the key does generate
> multiple key presses) get queued up, then all processed all at once, then
> again queued up...
>
> Maxi
>
