On 3/30/07, Pete Zaitcev <[EMAIL PROTECTED]> wrote:
On Fri, 30 Mar 2007 14:14:20 -0400, "Dmitry Torokhov" <[EMAIL PROTECTED]> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
