lkml.org 
[lkml]   [2009]   [Oct]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Regression?: keyboard state/LED inconsistency in 2.6.32-rc1/2,3,4
Date
On Tuesday 13 October 2009 06:03:14 am Dmitry Torokhov wrote:
> On Mon, Oct 12, 2009 at 01:57:08AM -0700, Dmitry Torokhov wrote:
> > On Mon, Oct 12, 2009 at 10:30:15AM +0200, Vojtech Pavlik wrote:
> > > On Mon, Oct 12, 2009 at 11:18:28AM +0300, Marin Mitov wrote:
> > > > Hello,
> > > >
> > > > I'm testing 2.6.32-rc1/2,3,4 and I'm using 2.6.31.3.
> > > > There is a difference in keyboard/LED behavior.
> > > > If in BIOS NumLock is set on, when the kernel starts
> > > > it puts NumLock off and the LED state is off in 2.6.31.3
> > > > (which is consistent), but in 2.6.32-rc1/2,3,4 the LED
> > > > stays on (and this is not consistent with keyboard's state).
> > > >
> > > > Comparing drivers/input/keyboard/atkbd.c (I'm using it)
> > > > in 2.6.31.3 and 2.6.32-rc1/2,3,4 among others changes I
> > > > found the following lines (see the patch bellow) deleted,
> > > > so I propose either to add them again (this will restore
> > > > keyboard/LED consistency) or revert the patch that has
> > > > deleted them.
> > >
> > > Oh, wow, those lines are quite clearly needed, I wonder why they got
> > > deleted, and I'm too lazy to find the commit comment ...
> > >
> >
> > Hmm, it appears I deleted a bit too much.. At some point I was thinking
> > the input core would reset LEDs and repeat rate on newly created device
> > but it was wrong idea. Unfortunately I was careless in applying atkbd
> > patch removing resume support (which should be handled by the input
> > core)...
> >
>
> Could you please try the patch below and let me know if it fixes
> things?
>
> Thanks!
>

Yes, Dmitry, it fixes the problem, thank you.

Marin Mitov


\
 
 \ /
  Last update: 2009-10-13 07:07    [from the cache]
©2003-2011 Jasper Spaans