-----==
----== _
---== (_)__ __ ____ __ James Simmons
--== / / _ \/ // /\ \/ / jsimmons@edgeglobal.com
-=====/_/_//_/\_,_/ /_/\_\ fbcon/gfx developer
The choice of a GNU generation
On Thu, 2 Dec 1999, Andrei Pitis wrote:
>
> Again, sorry to bother you about this, but the problem with Toshiba's
> keyboard is real, and not only on my notebook, I confirmed this with
> other people on the net. Please, is anybody in charge with the
> keyboard code? Of course that code is supposedly working ok and
> probably it was forgotten - but see - this keyboard really has this
> annoying problem. Well - you might choose not to implement it in the
> kernel, but at least let me know about this so I can patch each and
> every kernel I install on the damn notebook by hand from this day
> forward.
>
>
> Thanks,
> Andrei
>
> ------------
> From: Andrei Pitis <pink@roedu.net>
> To: linux-kernel@vger.rutgers.edu
> Subject: Toshiba Satellite 2595XDVD
> Date: Wed, 1 Dec 1999 06:22:41 +0200 (EET)
>
>
> Hi everybody,
>
> I am not sure to whom should I address this, it's about a buggy
> keyboard controller (I guess) found on <subj> laptops that has a
> peculiar behavior with some key sequences. Specifically, when you
> press a shift (ctrl, alt, shift) and a key - (mostly when you play a
> lot with shifts, like in emacs :-)) - sometimes the controller ignores
> the repeat delay and repeats the key, sending very close (tens of
> miliseconds) key_down interrups (kbd MAKEs).
>
> Since this become very frustrating in time (imagine an emacs where
> meta or control sequences get out of hand) I have modified the
> handle_scancode function in drivers/char/keyboard.c to ack like a
> forced kbd delay. In other words, for each new (different from the
> previous one) scancode it sets up a delay (of 200 ms) in which it
> ignores the same scancode, if received within this window.
>
> I think this may as well be left there, I cannot think of things that
> might be broken by it, the second aparition of a scancode being
> always protected by the kdb delay (min 250 ms on PC kbds) - on sane PC
> kbds, at least... therefore the 200 ms does not do any harm to the
> normal kbds :-)
>
> Anyway, I would be grateful if the person in charge (Linus?) would be
> so kind to accept this patch, so I will not be doomed to patch by hand
> each and every kernel from now on :-))
>
> The code is as follows, and should be placed immediately after the
> variable declarations in the abovementioned function:
>
> /*
> * Begin patch for Toshiba Satellite 2595XDVD. Under some
> * circumstances, its keyboards behaves like ignoring the
> * kbd repeat delay. This happens in conjunction with shift
> * keys (ctrl, alt, shift) and leads to undesirable repeat
> * of a key even if pressed briefly. Fix it by ignoring any
> * subsequent occurence of the second identical scancode for
> * 200 ms. IMO, this doesn't break anything on a good keyboard.
> */
> static int prev_scancode = 0;
> static int stop_jiffies = 0;
>
> /* new scancode, trigger delay */
> if (scancode != prev_scancode)
> stop_jiffies = jiffies;
>
> /* same scancode, accept only after the delay */
> else if (jiffies - stop_jiffies >= 20)
> stop_jiffies = 0;
>
> /* glitch! bail out... */
> else
> return;
>
> prev_scancode = scancode;
> /* End Toshiba patch. */
>
>
>
>
> -
> 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/
>
-
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/