A few days ago there were some discussion on the list about how keyboards
detect keypresses, and the combinations that cause the keyboard to “lock”.
I wrote a little test program for this (attached) It’s pretty simple; it
displays each keyboard scancode (0 to 255, although most of the upper ones
aren’t used) in red, and when the key is down it turns yellow. This makes it
easy to see which keys block which others.
Also while playing with it (and checkkeys from the SDL examples) I noticed
my keyboard appears to send scancode 135 when the keys are locked. The
program can also detect this (the code is easily modified through a #define) and display “locked”.
Maybe someone else will find this interesting.
I’ve also actually bothered to comment the code, so it might be helpful as a
keyboard handling/SDL-TTF example program or something, too.–
Mike.
-------------- next part --------------
A non-text attachment was scrubbed…
Name: keytest.c
Type: text/x-csrc
Size: 7849 bytes
Desc: keytest.c
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020116/ffbdf49a/attachment.c
Also while playing with it (and checkkeys from the SDL examples) I noticed
my keyboard appears to send scancode 135 when the keys are locked. The
program can also detect this (the code is easily modified through a #define) and display “locked”.
Maybe someone else will find this interesting.
I find that extremely interesting. Maybe the keyboard’s processor sends that because it knows that it can’t cope with that many keys at a time (some kind of a hardware limit). I had once an old 386 whose keyboard allowed pressing 15 keys simultaneously. They must’ve cut down on the cost of the processor later…
I’m pretty sure a limit can be/is imposed by the keyboard itself. Back
in the Doom II days I spilled coffee on my keyboard and had to
temporarily swap in a cheaper no-name one. With the cheaper keyboard I
couldn’t run, fire and strafe at the same time. Closer examination
(sans SDL at the time) showed that the keyboard couldn’t handle more
than 3 keys pressed at a time.
Caused many deathmatch deaths, I assure you. :)On Wed, 2002-01-16 at 05:00, Ville Koskinen wrote:
Also while playing with it (and checkkeys from the SDL examples) I noticed
my keyboard appears to send scancode 135 when the keys are locked. The
program can also detect this (the code is easily modified through a #define) and display “locked”.
Maybe someone else will find this interesting.
I find that extremely interesting. Maybe the keyboard’s processor sends that because it knows that it can’t cope with that many keys at a time (some kind of a hardware limit). I had once an old 386 whose keyboard allowed pressing 15 keys simultaneously. They must’ve cut down on the cost of the processor later…
From what I’ve read and experienced, most keyboards cannot correctly
generate certain key combinations. My conversations with other developers
have always resulted in the same key combinations not working properly,
but I’ve read that which combinations the keyboard cannot generate depends
from keyboard to keyboard. My experience and discussion with other
developers has shown that you can always press any two keys in combination
reliably, but certain three key combinations won’t work properly. This is
the keyboard’s limitation, not software or other parts of the hardware.
Good idea: Use the shift keys – ctrl, alt, shift, … They’re meant to
be used in combinations.