On 3/30/07, Pete Zaitcev <zaitcev@redhat.com> wrote:
quoted text
> On Fri, 30 Mar 2007 14:14:20 -0400, "Dmitry Torokhov" <dmitry.torokhov@gmail.com> wrote:
>
> > > I didn't like a) layering violation, and b) that they defeat filtering
> > > unconditionally. Why have any filtering then?
> > >
> > > Instead, I propose for USB HID driver to reset NumLock on probe. Like this:
> > >
> > > --- a/drivers/usb/input/hid-core.c
>
> > This is fine and that's what we do in atkbd probe but maybe we should
> > move that in input core and reset leds as part of
> > input_register_device()?
>
> Sure, as long as it works. I think (as much as I understand), that we
> already attempt to do this indirectly. input_register_device invokes
> ->start handlers, and the kbd_start attempts to reset LEDs, but fails
> because of the state filtering.
>

Not exactly... Keyboard handler's start method tries to bring state of
new keyboard in sync with the state of the rest of keyboards. The
purpose of start() is not to complete hardware initialization but to
adjust logical state of the device according to handler's
requirements...

But I am backpedaling on my statement about moving it into input core.
The driver (HID in this case) should properly reset the device before
registering it with input layer.

-- 
Dmitry
-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/