Maximilian Engelhardt wrote: > On Wednesday 13 August 2008, Alan Jenkins wrote: > >> [Dupe apology: CC'd to stable@xxxxxxxxxx, with the right address this time] >> >> Andrew Morton wrote: >> >>> On Wed, 13 Aug 2008 11:21:10 +0100 Alan Jenkins >>> > <alan-jenkins@xxxxxxxxxxxxxx> 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 > This is expected behaviour - I can explain it in detail if that helps. I see the same on my laptop, though perhaps it is more annoying on yours. The patch I've submitted here is not intended to fix #10919. You said the patch at <http://bugzilla.kernel.org/show_bug.cgi?id=10919#c21> worked for you, and I think the approach there is the way forward for this "laggy" issue. However I don't know if it will be ready for this kernel release. I pointed out a cosmetic issue with it to Alexey but haven't heard anything since. Alan -- 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
