[SDL] RFC: prototype implementation of physical key codes

Gerry JJ trick at icculus.org
Tue Sep 5 17:00:54 PDT 2006


On Tue, 05 Sep 2006 22:26:31 +0200, Christian Walther <cwalther at gmx.ch>  
wrote:
> 1. Press caps lock key (caps lock light goes on) - SDL sends a key down
> event with SDL_PK_LOCKINGCAPSLOCK and a key down event with  
> SDL_PK_CAPSLOCK.
> 2. Release caps lock key - SDL sends a key up event with SDL_PK_CAPSLOCK.
> 3. Press caps lock key - SDL sends a key down event with SDL_PK_CAPSLOCK.
> 4. Release caps lock key (light goes off) - SDL sends a key up event
> with SDL_PK_CAPSLOCK and a key up event with SDL_PK_LOCKINGCAPSLOCK.

The problem is, such locking events are unreliable at best.  Think of what
happens when you press Caps Lock (-> enabled) in your SDL app, then switch
focus to a different app and press it again (-> disabled).  If you then
switch back to the SDL app and press Caps Lock again, you'll get another
enable event, but you never got the disable!  In this way, press and
release events can occur on their own -- switching back and forth, you can
generate as many events as you wish in a row without any complementing
events in between.  With the current behavior of the lock keys, this sort
of thing can easily happen accidentally.

I just tried this, and it is actually possible to do this with regular
keys as well.  Holding a regular key and switching away from the SDL app
before releaseing it does generate a release event, but holding a key,
then switching to the SDL app and releasing it generates the release
event without any press event first.  This is obviously less likely to
happen accidentally, but it could still lead to problems.  Should it be
considered a bug in SDL, though ?  The key *did* get released, it just
didn't get pressed while the SDL app had focus.  However, since SDL
generated a release event on switch-away, I think this isn't intended
behavior.  (In fact, pressing a key, switching away from the SDL app
and back, and then releasing it, generates two release events ..)

Anyway, what I'd like to have is a way for the lock keys to generate
press/release events as if they were regular keys (thus making them more
reliable and available for non-locking (ab)uses; handy for emulators),
and also, optional led control!  That is, making it possible to press
eg the Caps Lock key in the SDL app without affecting the state of the
Caps Lock led.  This would obviously be optional.

While I'm at it, a way to directly control the leds on the keyboard would
be great (think disk drive lights in an emulator, etc)  =)

Maybe something like this ?

   SDL_SetLed(led, state);

led = SDL_KLED_CAPS_LOCK|SDL_KLED_NUM_LOCK|SDL_KLED_SCROLL_LOCK|..
state = SDL_ENABLE|SDL_DISABLE|SDL_AUTOMATIC|SDL_QUERY
(AUTOMATIC = state controlled by keyboard, default)

> (Or should the SDL_PK_LOCKINGCAPSLOCK up event come already at 3? That's
> how the actual caps lock state behaves here on Mac OS X, though the
> light behaves as above. Weird.)

On my keyboard, the leds go on at 1 and off at 3.  Exactly what happens
probably depends on the keyboard.

> On the other hand, it might not even be possible to detect 2 and 3 (or 2
> and 4) on some platforms. In fact, I think it isn't in Cocoa (though it
> may be in some lower level API).

That would be a problem, yeah =(.  Still, at least supporting this where
possible would be nice, I think.

- Gerry




More information about the SDL mailing list