> > -void handle_scancode(unsigned char scancode)
> > +static void kbd_repeat(unsigned long devid)
>
> Maybe you should note somewhere that you are changing autorepeat
> behaviour. Does this correspond with Russel King's patches?
I'm not changing autorepeat behaviour (at least, not deliberately :-).
The repeat_timer stuff is only used if the low-level driver requests
it by setting the dont_repeat element of the kbd_ll_operations struct
to a non-null value. Otherwise it's up to the low level driver to do
the auto-repeat. The PC keyboard driver does the auto-repeat itself.
I put the optional auto-repeat stuff in keyboard.c because I noticed
that the mac keyboard driver and one or two others use a very similar
scheme to do auto-repeat, and it seemed like a good place for that
functionality.
> > + if (ks->repeat_timer_running) {
> > + del_timer(&ks->repeat_timer);
> > + ks->repeat_timer_running = 0;
> > + }
>
> I think it is safe to just del_timer(&ks->repeat_timer) without
> needing to check anything. Ask arca if unsure.
Good point - you're right. (It's doing add_timer on a timer which is
running that is fatal.)
> What sense does this piece of code have? I thought that keyboard leds
> should be independend for each keyboard...
I thought about this. We already have saved led states for each VC.
I shied off from extending this to saved led states for each VC for
each keyboard, but maybe that's what we have to do. This would
probably mean more extensive modifications to stuff like the console
code, though.
If we have independent led states for each keyboard, what does it mean
to do the VC ioctls which set/get the led state? Do they just operate
on the first keyboard perhaps?
Paul.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/