[SDL] RFC: prototype implementation of physical key codes
cwalther at gmx.ch
Tue Sep 5 13:26:31 PDT 2006
> Gerry JJ wrote:
>> Oh, and the caps lock and num lock keys only registered when enabling, not
>> disabling, but scroll lock worked like a regular key. I know SDL always
>> worked like this, but while we're on the subject of keys anyway .. First,
>> why doesn't scroll lock work like the other lock keys (no light, even) ?
>> And second, it'd be very nice if these lock keys could (perhaps optionally)
>> be treated like regular keys. We've got the modifier information handy
>> anyway, so there's no reason for them not to, is there ?
> I don't have any strong opinion on this. Making SDL's locking optional
> does sound sensible (e.g. for emulators, where the emulated OS already
> does this), but I wouldn't remove it entirely.
Wait, I just had an idea: This could be a use for the "locking caps
lock" etc. usage codes that are in the USB spec, but that I commented
out in my SDLPKey list. Like this:
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.
(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 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).
More information about the SDL