Double caps lock to switch?

Yo, why is it that in most ports if I have caps lock set to "autorun on\off", I need to press it twice for something to happen? Also unrelated but I have to do funny magic sometimes, like I have autorun on but caps lock glowing and it bothers me (yeah OCD), so I have to alt+tab to Windows, press caps lock there, and then go back to the game. Lol.

Does 'most ports' mean 'SDL-based ports'?

If so, I'd guess it's an SDL bug, not that this would surprise me.

They're not actually unrelated, and occur because most ports use SDL for input handling, and SDL had a bug where the caps/num/scroll lock keys would alternate between being handled by the game, and actually toggling caps/num/scroll lock. That is, the first time you press caps lock, it just toggles caps locks without being detected by the game (so if caps lock was off when you started the game, it's now on), and the second time you press it, it is detected by game but doesn't toggle caps lock (which means caps lock is still on from the first time you pressed caps lock, even though you pressed it twice). As I understand, this is fixed in the latest version of SDL, but many ports are still using older versions.

Very annoying indeed. I may be mistaken, but I think this capslock behaviour appeared with Win7 and onward. How about disabling the capslock function? I believe I've never used it for its intended purpose once in my life.

Foxpup said:

As I understand, this is fixed in the latest version of SDL, but many ports are still using older versions.

... and that's the real problem. Of course some strange things will happen when using outdated versions of certain libraries.

As a non-SDL user I have to ask what's the reason for sticking with this old and increasingly problematic SDL version. It can only get worse.

Graf Zahl said:

As a non-SDL user I have to ask what's the reason for sticking with this old and increasingly problematic SDL version. It can only get worse.

What's the alternative and what are its caveats? I mean, compared to the unbearable terror of the malfunctioning capslock key.

dew, the double caps lock happens on my xp computer too in prboom-plus, but zdoom only needs single-press.

Caps lock for autorun.
Windows is notable on breaking keyboard actions into keypress and keyrelease events.
If the keyboard code is like what I saw in DoomLegacy around 2009 it only responds to some keys on the key release event.
If the caps locking behavior was not disabled, it could still be affecting the keyboard behavior, with it only allowing a keyrelease event upon every other key-press (because the low level driver does the locking part). How this would be disabled on particular versions of Windows, is for experts in Windows behavior to tell us.
How to disable it for different versions of SDL, and DirectX, is another question.
I have seen it behave both ways. I think it is the windows machines that retain the key locking, but I would have to check.

When using DirectInput for checking key input this shouldn't be a problem at all. For the low level driver Caps Lock is just a key like everything else.

This special treatment normally happens in the keyboard driver - because different languages require different handling for their default keyboard layout (e.g. German typewriter layout uses Caps Lock to lock the shift key and pressing the normal shift key to unlock it - I really wonder if some people really still use that, it's an utterly insane relic from a time long ago)

None of this is of any concern if DirectInput is used, that's why ZDoom doesn't have any problems with it.

My guess is that the SDL people were just incompetent hacks and ineptly tried to replicate the high level way of how Caps Lock works on the English keyboard by messing around with the DirectInput data and as a result the app doesn't get proper data.

This is actually one of the reasons why ZDoom implements its own low level stuff on Windows - to get rid of such an unstable dependency. ZDoom also uses high level key events for submodules that use actual character input, like the menus and the console, because for text input SDL is even less useful than for game input.
And from what I read on the forum, SDL is also on its way out for Macs, because there it also significantly degrades the user experience - even more than on Windows, as it looks.

Graf Zahl said:

As a non-SDL user I have to ask what's the reason for sticking with this old and increasingly problematic SDL version. It can only get worse.

If you're talking about a SDL 1.2 version older than the latest one (1.2.14 instead of 1.2.15?) then I think it's enough for the user to replace the DLLs with the latest x86 (32-bit) SDL 1.2 version.

If you're comparing SDL 1.2 with SDL 2, then, I'd strongly recommend SDL 2 at least for OS X, iOS and Android. Transitioning to it involves upgrading the video code (well documented as a tutorial in the wiki) and the mouse input code (some things are now window-based). But it's totally worth it for a real smooth OS X experience, and ready support for Android and iOS (no complicated entry code needed to make it work on iOS!)

I have this bug in PrBoom (and PrBoom+) without SDL (software) in Linux.

Foxpup said:

[...]SDL had a bug where the caps/num/scroll lock keys would alternate between being handled by the game, and actually toggling caps/num/scroll lock. That is, the first time you press caps lock, it just toggles caps locks without being detected by the game (so if caps lock was off when you started the game, it's now on), and the second time you press it, it is detected by game but doesn't toggle caps lock[...]

Hm, not exactly. There is no distinction between the button toggling states and the button being registered by "the game".

Actually, SDL registers the *locking* of Caps Lock as a key-down event and the unlocking as a key-up event. That is, if you press and release the Caps Lock button and thus lock it, then SDL registers this as a single key-down event. If you press and release the button a second time to unlock its state, then SDL registers this as a single key-up event.

However, this is not considered a bug, but a feature that has been added on purpose, c.f.

http://hg.libsdl.org/SDL/file/SDL-1.2/src/events/SDL_keyboard.c#l429

You will also find in the code that it is possible to entirely disable this behaviour by setting the "SDL_DISABLE_LOCK_KEYS=1" environment variable. This is what I've done in Crispy Doom:

https://github.com/fabiangreffrath/crispy-doom/commit/40b41e86872bb708bdab24dd767529ac4c8ac1a1

fabian said:

However, this is not considered a bug, but a feature that has been added on purpose, c.f.

Actually, having such a feature on by default is just moronic.
As is the option to handle this through a system-wide global setting instead of an API call.

But well, we're talking about SDL here, right? So no big surprise.