Re: Keyboard delay and repeat rate

From: Vojtech Pavlik (vojtech@suse.cz)
Date: Thu Apr 06 2000 - 08:50:45 EST


On Thu, Apr 06, 2000 at 03:44:40PM +0200, Maciej W. Rozycki wrote:

> > True. Many normal keyboards too. And other keyboards have broken Set 3,
> > sending wrong scancodes for some keys, because the manufacturers didn't
> > test their operation in this mode.
>
> It's not the lack of mode #3 support that is the brokenness. The problem
> is the fact at least some keyboards do positively ack the command to
> switch into mode #3 but still remain in mode #2. If they rejected the
> command it would be just OK.

This is not a big problem. By issuing a Get Mode command you can filter
out such keyboards - they'll return Mode 2 even after acking to be set
to Mode 3.

On the other hand, one BTC keyboard I have sends the same scancode for
keys '1' and '2' in Set 3, making it somewhat unusable.

> Once I wrote a program that contained a keyboard driver to support all
> three modes depending on a keyboard preset. Keyboards were autodetected
> and if an XT or an AT keyboard was present it was used in its native mode
> with all scancodes translated to their mode #3 equivalents through two
> simple lookup tables. It worked very well unless a keyboard claimed to be
> of a PS/2 type, acked the switch to mode #3 but then did not implement it.
> This is how I learned this part of PC can be broken, too...

Every little bit of the PC architecture has been broken many times by
different manufacturers. It's incredible a system still can be written
to run on this crap. ;)

-- 
Vojtech Pavlik
SuSE Labs

- 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/



This archive was generated by hypermail 2b29 : Fri Apr 07 2000 - 21:00:16 EST