kmx git

Commit	Date	Message
7232e51a	2015-06-08T01:52:43	Unix: Don't send quit events during signal handler. Make note to send it, and send next time we SDL_PumpEvents(). Otherwise, we might be trying to use malloc() to push a new event on the queue while a signal is interrupting malloc() elsewhere, usually causing a crash. Fixes Bugzilla #2870.
fd8b7c1c	2015-06-05T19:41:18	Fixed comments at conditional compilation macros.
32d6dcdb	2015-05-28T12:48:20	Fixed bug 2096 - Mapping from scancode to keycode doesn't work for remapped modifier keys Jacob Lee If a user has a non-standard keyboard mapping -- say, their caps lock key has been mapped to Ctrl -- then SDL_GetModState() is no longer accurate: it only considers the unmapped keys. This is a regression from SDL 1.2. I think there are two parts to this bug: first, GetModState should use keycodes, rather than scancodes, which is easy enough. Unfortunately, on my system, SDL considers Caps Lock, even when mapped as Control, to be both SDL_SCANCODE_CAPSLOCK and SDLK_CAPSLOCK. The output from checkkeys for it is: INFO: Key pressed : scancode 57 = CapsLock, keycode 0x40000039 = CapsLock modifiers: CAPS Whereas the output for xev is: KeyPress event, serial 41, synthetic NO, window 0x4a00001, root 0x9a, subw 0x0, time 40218333, (144,177), root:(1458,222), state 0x10, keycode 66 (keysym 0xffe3, Control_L), same_screen YES, XKeysymToKeycode returns keycode: 37 XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False I think the problem is that X11_UpdateKeymap in SDL_x11keyboard.c only builds a mapping for keycodes associated with a Unicode character (anything where X11_KeyCodeToUcs returns a value). In the case of caps lock, SDL scancode 57 becomes x11 keycode 66, which becomes x11 keysym 65507(Control_L), which does not have a unicode value. To fix this, I suspect that SDL needs a mapping of the rest of the x11 keysyms to their corresponding SDL key codes.
21d0cded	2015-05-26T20:55:03	Added some unknown keys from Japanese 106/109 keyboards (thanks, "ver0hiro"!). This adds them for Windows and X11. Fixes Bugzilla #2820.
2c4a6ea0	2015-05-26T06:27:46	Updated the copyright year to 2015
b72938c8	2015-04-20T12:22:44	Windows: Always set the system timer resolution to 1ms by default. An existing hint lets apps that don't need the timer resolution changed avoid this, to save battery, etc, but this fixes several problems in timing, audio callbacks not firing fast enough, etc. Fixes Bugzilla #2944.
eff61ee3	2014-06-05T11:55:37	Add an entry for X11 "/" key for Brazilian keyboard. SDL2 reports the following message when we type the "/" on br-abnt2 keyboards: The key you just pressed is not recognized by SDL. \ To help get this fixed, please report this to the SDL mailing list \ <sdl@libsdl.org> X11 KeyCode 97 (89), X11 KeySym 0x2F (slash). That's because the corresponding entry in the scancodes table is marked with value SDL_SCANCODE_UNKNOWN. This commit fixes that adding the value SDL_SCANCODE_SLASH for this entry.

7232e51a

2015-06-08T01:52:43

Unix: Don't send quit events during signal handler. Make note to send it, and send next time we SDL_PumpEvents(). Otherwise, we might be trying to use malloc() to push a new event on the queue while a signal is interrupting malloc() elsewhere, usually causing a crash. Fixes Bugzilla #2870.

fd8b7c1c

2015-06-05T19:41:18

Fixed comments at conditional compilation macros.

32d6dcdb

2015-05-28T12:48:20

Fixed bug 2096 - Mapping from scancode to keycode doesn't work for remapped modifier keys Jacob Lee If a user has a non-standard keyboard mapping -- say, their caps lock key has been mapped to Ctrl -- then SDL_GetModState() is no longer accurate: it only considers the unmapped keys. This is a regression from SDL 1.2. I think there are two parts to this bug: first, GetModState should use keycodes, rather than scancodes, which is easy enough. Unfortunately, on my system, SDL considers Caps Lock, even when mapped as Control, to be both SDL_SCANCODE_CAPSLOCK and SDLK_CAPSLOCK. The output from checkkeys for it is: INFO: Key pressed : scancode 57 = CapsLock, keycode 0x40000039 = CapsLock modifiers: CAPS Whereas the output for xev is: KeyPress event, serial 41, synthetic NO, window 0x4a00001, root 0x9a, subw 0x0, time 40218333, (144,177), root:(1458,222), state 0x10, keycode 66 (keysym 0xffe3, Control_L), same_screen YES, XKeysymToKeycode returns keycode: 37 XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False I think the problem is that X11_UpdateKeymap in SDL_x11keyboard.c only builds a mapping for keycodes associated with a Unicode character (anything where X11_KeyCodeToUcs returns a value). In the case of caps lock, SDL scancode 57 becomes x11 keycode 66, which becomes x11 keysym 65507(Control_L), which does not have a unicode value. To fix this, I suspect that SDL needs a mapping of the rest of the x11 keysyms to their corresponding SDL key codes.

21d0cded

2015-05-26T20:55:03

Added some unknown keys from Japanese 106/109 keyboards (thanks, "ver0hiro"!). This adds them for Windows and X11. Fixes Bugzilla #2820.

2c4a6ea0

2015-05-26T06:27:46

b72938c8

2015-04-20T12:22:44

Windows: Always set the system timer resolution to 1ms by default. An existing hint lets apps that don't need the timer resolution changed avoid this, to save battery, etc, but this fixes several problems in timing, audio callbacks not firing fast enough, etc. Fixes Bugzilla #2944.

eff61ee3

2014-06-05T11:55:37

Add an entry for X11 "/" key for Brazilian keyboard. SDL2 reports the following message when we type the "/" on br-abnt2 keyboards: The key you just pressed is not recognized by SDL. \ To help get this fixed, please report this to the SDL mailing list \ <sdl@libsdl.org> X11 KeyCode 97 (89), X11 KeySym 0x2F (slash). That's because the corresponding entry in the scancodes table is marked with value SDL_SCANCODE_UNKNOWN. This commit fixes that adding the value SDL_SCANCODE_SLASH for this entry.

kc3-lang/SDL/src/events

src/events

Log