Messages in this thread | | | Date | Mon, 12 Oct 2009 01:57:08 -0700 | From | Dmitry Torokhov <> | Subject | Re: Regression?: keyboard state/LED inconsistency in 2.6.32-rc1/2,3,4 |
| |
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)...
-- Dmitry
| |