Date:	Wed, 13 Aug 2008 15:36:51 +0200
From:	Maximilian Engelhardt <maxi@...monizer.de>
To:	Alan Jenkins <alan-jenkins@...fmail.co.uk>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Alexey Starikovskiy <astarikovskiy@...e.de>,
	linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org,
	hmh@....eng.br, stable@...nel.org
Subject: Re: [PATCH] acpi: Avoid dropping rapid hotkey events (or other GPEs) on Asus EeePC

On Wednesday 13 August 2008, Alan Jenkins wrote:
> [Dupe apology: CC'd to stable@...nel.org, with the right address this time]
>
> Andrew Morton wrote:
> > On Wed, 13 Aug 2008 11:21:10 +0100 Alan Jenkins 
<alan-jenkins@...fmail.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

Download attachment "signature.asc " of type "application/pgp-signature" (198 bytes)

Powered by blists - more mailing lists