|
9130f7c3
|
2021-01-02T10:25:38
|
|
Updated copyright for 2021
|
|
|
cb361896
|
2020-12-09T07:16:22
|
|
Fixed bug 5235 - All internal sources should include SDL_assert.h
Ryan C. Gordon
We should really stick this in SDL_internal.h or something so it's always available.
|
|
|
d4f1b520
|
2020-04-08T19:16:31
|
|
Added support for press/release hardware keyboard events in iOS 13.4
|
|
|
a8780c6a
|
2020-01-16T20:49:25
|
|
Updated copyright date for 2020
|
|
b458d7a2
|
2019-10-30T15:13:55
|
|
Readability: remove redundant cast to the same type
|
|
|
5e13087b
|
2019-01-04T22:01:14
|
|
Updated copyright for 2019
|
|
|
e3cc5b2c
|
2018-01-03T10:03:25
|
|
Updated copyright for 2018
|
|
|
3b837a26
|
2017-08-12T15:41:03
|
|
Fixed bug 3188 - AZERTY keyboard support broken and inconsistent
Daniel Gibson
AZERTY keyboard layouts (which are the default layouts in France and Belgium) don't have the number keys (1, 2, ..., 9, 0) in the first row of keys, but ?, &, ?", ', (, -, ?_, ??), = (with small differences between the France and Belgian variants). Numbers are reached via shift.
On Linux and OSX, SDL seems to use the corresponding ISO 8859-1 codes (231 for ?232 for ?tc) as SDL_Keycode (but no SDK_* constants exists for those values!), while on Windows SDL seems to map those keys to SDLK_1, SDLK_2 etc, like you'd get on QWERTY.
I don't know how other platforms behave.
So we have two problems:
1. At least on Linux and OSX invalid/undefined SDL_Keycodes are returned
2. Different platforms behave differently (Windows vs Linux/OSX)
It's unclear what behavior is desired: Should SDL_* constants for those keys be introduced (and Windows behavior changed accordingly)?
Or should all platforms behave like Windows here and use the existing SDLK_1, ..., SDLK_0 keycodes?
This bug on the mailing list:
https://forums.libsdl.org/viewtopic.php?t=11555 (my post about Linux/Windows)
https://forums.libsdl.org/viewtopic.php?t=11573 (Tim Walters discovered the same problem on OSX about 1.5 weeks later).
|
|
|
195b8bd8
|
2017-08-12T12:34:09
|
|
Fixed bug 3249 - keysym.mod is incorrect when mod keys are pressed for SDL_KEYDOWN events
Adam M.
The keysym.mod field does not reflect the state of the modified keys when processing key down events for the modifier keys themselves. The documentation says that it returns the current key modifiers, but they are not current for key down events involving modifier keys. I interpret "current" to mean "equal to SDL_GetModState() at the instant the event is processed/enqueued".
For example, if you depress the Shift key you get a key down event with .mod == 0. However, .mod should not be 0 because a shift key is down. If you then release the Shift key, you get a key up event with .mod == 0. Neither event reports the modifier key.
If you press Shift and then A, .mod is incorrect (== 0) when Shift is pressed, but is correct later when A is pressed (== KMOD_LSHIFT).
You might say this behavior is deliberate, i.e. keysym.mod is the value /before/ the event, not the current value as documented, but that explanation is incorrect because only key down events behave that way. Key up events correctly give the current value, not the value before the event.
Not only is it inconsistent with itself, I think it makes keyboard processing harder.
The problem is near line 740 in SDL_keyboard.c:
if (SDL_KEYDOWN == type) {
modstate = keyboard->modstate; // SHOULD THIS BE MOVED DOWN?
switch (keycode) {
case SDLK_NUMLOCKCLEAR:
keyboard->modstate ^= KMOD_NUM;
break;
case SDLK_CAPSLOCK:
keyboard->modstate ^= KMOD_CAPS;
break;
default:
keyboard->modstate |= modifier;
break;
}
} else {
keyboard->modstate &= ~modifier;
modstate = keyboard->modstate;
}
In the key down path, modstate (and thus keysym.mod) ends up being the modifier state /before/ the event, but in the key up path modstate ends up being the modifier state /after/ the event. Personally I think the "modstate = keyboard->modstate" line should just be moved after the entire if/else statement, so that keysym.mod always reflects the current state.
|
|
|
2008d866
|
2017-07-20T10:46:38
|
|
Fixed bug 3703 - Missing media keys support on Amazon Fire TV remote control
Holger Schemel
Summary: This patch adds support for key events for the "rewind" and "fast forward" media keys on the Amazon Fire TV remote control.
How to reproduce the problem: Run Android build of SDL2 application on the Amazon Fire TV (tested with "stick" version) and log key events.
Expected behaviour: Every key pressed on the Fire TV remote control should result in a corresponding key event (pressed/released).
Observed behaviour: Of the bottom row of buttons on the Fire TV remote control, only the "play/pause" (middle) button generates a key event, while the "rewind" (left) and "fast forward" (right) buttons to not generate any event at all.
The attached patch adds support for these two missing buttons/keys.
Note 1: Some missing definitions were added for the already existing key codes SDL_SCANCODE_APP1 and SDL_SCANCODE_APP2 (to keep up the correct order of enumerations / array positions when adding the two new key codes).
Note 2: Definitions in "scancodes_linux.h" and "scancodes_xfree86.h" (to also add support for these keys on other platforms) were added without testing. However, I was unable to find corresponding definitions for these two media keys for Windows and Mac OS X.
Note 3: I have also updated the (broken) link to the USB usage page standard PDF document (comment in "include/SDL_scancode.h").
|
|
ca0bf151
|
2017-03-03T16:38:17
|
|
Fix some more compiler warnings on armcc.
|
|
|
6d6edcb8
|
2017-01-09T11:30:29
|
|
Fixed spacing
|
|
|
45b774e3
|
2017-01-01T18:33:28
|
|
Updated copyright for 2017
|
|
|
42065e78
|
2016-01-02T10:10:34
|
|
Updated copyright to 2016
|
|
|
257b7af2
|
2015-12-28T13:07:44
|
|
Sync up the caps/numlock state properly without sending key events.
Partially fixes Bugzilla #2736 and #3125.
|
|
0e45984f
|
2015-06-21T17:33:46
|
|
Fixed crash if initialization of EGL failed but was tried again later.
The internal function SDL_EGL_LoadLibrary() did not delete and remove a mostly
uninitialized data structure if loading the library first failed. A later try to
use EGL then skipped initialization and assumed it was previously successful
because the data structure now already existed. This led to at least one crash
in the internal function SDL_EGL_ChooseConfig() because a NULL pointer was
dereferenced to make a call to eglBindAPI().
|
|
|
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.
|
|
|
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.
|
|
fe6c797c
|
2015-04-10T23:30:31
|
|
Fixed an iOS view orientation issue when SDL_GL_CreateContext or SDL_CreateRenderer is called.
|
|
b88ca1b4
|
2015-02-10T16:28:56
|
|
the last parameter of XChangeProperty is the number of elements.. and when the element format is 32.. the element is "long" so we have 5 long elements here.
Yes this seems confusing as on mac+linux Long is either 32 or 64bits depending on the architecture, but this is how the X11 protocol is defined. Thus 5 is the correct value for the nelts here. Not 5 or 10 depending on the architecture.
More info on the confusion https://bugs.freedesktop.org/show_bug.cgi?id=16802
|
|
|
b48e54aa
|
2015-01-26T22:00:29
|
|
Fixed bug 2802 - [patch] Fix android build compiling in wrong filesystem implementation
Jonas Kulla
The configure script didn't differentiate between Linux and Android, unconditionally compiling in the unix implementation of SDL_sysfilesystem.c.
I'm probably one of the very few people building SDL for android using classic configure + standalone toolchain, so this has gone undetected all along.
|
|
70438be2
|
2014-12-03T10:55:23
|
|
WinRT: fixed bug whereby SDL would override an app's default orientation
WinRT apps can set a default, preferred orientation via a .appxmanifest file.
SDL was overriding this on app startup, and making the app use all possible
orientations (landscape and portrait).
Thanks to Eric Wing for the heads up on this!
|
|
|
9c398852
|
2014-11-22T22:20:40
|
|
Corrected header file documentation comment.
|
|
24c86b55
|
2014-09-11T19:24:42
|
|
[X11] Reconcile logical keyboard state with physical state on FocusIn
since the window system doesn't do it for us like other platforms.
This prevents sticky keys and missed keys when going in and out
of focus, for example Alt would appear to stick if switching away
from an SDL app with Alt-Tab and had to be pressed again.
CR: Sam
|
|
|
b7d2c0e9
|
2014-05-24T01:30:37
|
|
Implemented SDL_CaptureMouse().
|
|
|
3dcb451f
|
2014-04-09T21:29:19
|
|
Added a README file regarding WinRT support
To note, this file is currently formatted with CRLF line endings, rather than
LF, to allow the file to be viewed with Notepad.
|
|
|
58edac3e
|
2014-02-02T00:53:27
|
|
Fixed bug 2374 - Update copyright for 2014...
Is it that time already??
|
|
f848adff
|
2013-11-29T10:06:08
|
|
Improve Android pause/resume behavior.
|
|
|
7e1289af
|
2013-11-24T23:56:17
|
|
Make internal SDL sources include SDL_internal.h instead of SDL_config.h
The new header will include SDL_config.h, but allows for other global stuff.
|
|
|
b39a4daf
|
2013-10-03T10:28:10
|
|
SDL_TEXTINPUT support for EVDEV
|
|
|
1e49b1ed
|
2013-08-21T09:47:10
|
|
OCD fixes: Adds a space after /* (glory to regular expressions!)
|
|
|
695344d1
|
2013-08-21T09:43:09
|
|
OCD fixes: Adds a space before */
|
|
|
dad42067
|
2013-08-12T11:13:50
|
|
Fixes #2022, do not resume on Android when surfaceChanged
If the app is in landscape mode and the user presses the power button, a pause
is followed immediately by a surfaceChanged event because the lock screen
is shown in portrait mode. This triggers a "false" resume.
So, we just pause and resume following the onWindowFocusChanged events.
Also, wait for SDL_APP_WILLENTERBACKGROUND and SDL_APP_DIDENTERBACKGROUND before
blocking the event pump.
|
|
|
1ad936eb
|
2013-08-11T19:56:43
|
|
Fixed bug 2027 - Full-screen appears to be broken - hang in SDL_DestroyWindow()
Rainer Deyke
I'm running Linux Mint 15 with the Cinnamon window manager. SDL_DestroyWindow consistently locks up for me when the window if fullscreen.
|