Public bug reported: Any received SDL_KeyboardEvent relating to NumLock and CapsLock does not correspond to the state of the keys. The current behavior was introduced by a patch in Debian bug #317010.
Traditional behavior: (before debian 317010; currently, if SDL_DISABLE_LOCK_KEYS is nonempty in the environment) * Pressing to enable the NumLock state generates a SDL_KEYDOWN event, releasing generates nothing. * Pressing to disable the NumLock state generates a SDL_KEYUP event, releasing generates nothing. * Any other key event will have the correct SDLMod * This means that, for all bits in SDLMod, between the SDL_KEYDOWN and SDL_KEYUP the bit is set. To nitpick, unlike the others, the bit is already set for NumLock (or CapsLock) in its own SDL_KEYDOWN event, but is not set for either of another modifier's events. * However, the whole point of a lock is that it is not equivalent to press, hold, release, as a simple modifier is. Current behavior: * if NumLock is off when program is started, a received SDL_KeyboardEvent will initially show it off in its SDLMod. Without discernable pattern, sometimes pressing NumLock will enable the bit in an SDLMod. * if NumLock is on when program is started, the bit is set in any SDLMod. * however the bit was set, I have not found any input that will disable the bit again. * if NumLock was enabled when program is started, the first time it is pressed it only generates SDL_KEYUP * after that, or if NumLock was initially disabled, every press generates SDL_KEYDOWN and SDL_KEYUP as expected With either behavior, the fields of a SDL_KEYDOWN event (Uint8 scancode and SDLKey sym) are identical, except that if NumLock is on and SDL_EnableUNICODE, the unicode field is set to the character [0123456789/*+-] Expected: NumLock generates SDL_KEYDOWN when pressed and SDL_KEYUP when released AND any SDLMod shows the correct bit. For compatibility, leave the SDL_DISABLE_LOCK_KEYS environment override (but perhaps by another name) to enable the (predictable) "traditional" behavior. Note: in the description, I refer to NumLock but not CapsLock. I normally have CapsLock mapped to compose, but I disabled that to confirm at least one inconsistency and that the traditional mode was consistent. References: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=317010#5 noted the inconsistency in "Traditional" behavior, and patched it to cause this bug (but this was supposed to be disabled by default). Also, reply #15 noted that, among other things, CapsLock got broken. The buggy behavior of patch (and SDL_DISABLE_LOCK_KEYS override) is in the final 1.2.14 upstream library (extracted from .rpm and overridden with LD_LIBRARY_PATH). (All future releases will break ABI and partial API) http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=399945 reported that the patch was enabled by default instead of disabled, but never got a reply. ** Affects: libsdl1.2 (Ubuntu) Importance: Undecided Status: New -- SDL_Event gives bogus NumLock and CapsLock values https://bugs.launchpad.net/bugs/564412 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
