Specifically: always on top, skip taskbar, tooltip, utility, and popup menu.
This is currently only implemented for X11.
This patch is based on work in Unreal Engine 4's fork of SDL,
compliments of Epic Games.
Notably: it sets the error string to inform you that your custom SDL is built
without xrandr support, which apparently has been a support issue for
Unreal Engine 4 developers.
This is often useful for SDL apps that aren't meant to be games: the
integrated GPU starts up faster, uses less power, and is often more than
fast enough.
Note that even with this change, the app will still default to the more
powerful, discrete GPU if one is available; an app that prefers the integrated
GPU will still need the NSSupportsAutomaticGraphicsSwitching key properly
set in its Info.plist and Mac OS X 10.7 or later.
https://developer.apple.com/library/mac/qa/qa1734/_index.html
Martin Gerhardy
According to https://msdn.microsoft.com/de-de/library/2kzt1wy3%28v=vs.120%29.aspx when one is using /MT for msvc compilations the libcmt.lib is already linked to the binary. This lib includes the symbol that is now guarded (see attached patch) by the #ifndef _MT.
I don't know if any joysticks report those usages for any buttons in practice, but other prominent Mac gaming software exposes them, so we might as well too.
xaudio2 is not linked against sdl but the sdk already handles dynamically loading (XAudio2Create is inlined and just loads a com object). Updated SDL_xaudio2.c
DXGI fails to report any displays in at least one of the
"Windows App Certification Kit 10.0"'s tests for Store Apps. This was
causing SDL's video initialization code to fail, when the suspect test
("Direct3D Feature Test") was run, as DXGI was unable to report a
display-output at adapter-index 0, output-index 0.
The workaround that is applied here attempts to detect this case, then
use a hopefully-reasonable alternative means to calculate at least one
display output.
"UWP" appears to be Microsoft's new name for WinRT/Windows-Store APIs.
This set of changes updates SDL's WinRT backends to support the Win10 flavor
of WinRT. It has been tested on Win10 on a desktop. In theory, it should
also support Win10 on other devices (phone, Xbox One, etc.), however further
patches may be necessary.
This adds:
- a set of MSVC 2015 project files, for use in creating UWP apps
- modifications to various pieces of SDL, in order to compile via MSVC 2015 +
the Win10 API set
- enables SDL_Window resizing and programmatic-fullscreen toggling, when using
the WinRT backend
- WinRT README updates
WinRT 8.0 (Phone and non-Phone) didn't offer an API to set an already-created
thread's priority. WinRT 8.1 offered this API, along with several other
Win32 thread functions that were previously unavailable (in WinRT).
This change makes WinRT 8.1+ platforms use SDL's Win32 backend.
This change-set fixes a lot of windowing related bugs, especially with
regards to Windows 8.x apps running on Windows 10 (which was the driver for
this work). The primary fixes include:
* listed display modes were wrong, especially when launching apps into a
non-fullscreen space
* reported window flags were often wrong, especially on Windows 10
* fullscreen/windowed mode switches weren't failing (they are not
programmatically possible in Win 8.x apps).
This change has also been tested as buildable + runnable on Win32 + MSVC 2015,
2013, 2012, and 2010. It may fix similar build errors (in XInput code) that
are appearing in MingW builds (on buildbot).
They were not needed internally since the switch to the common EGL backend.
Thanks to the SDL mailing list for pointing out that the functions seem unused.
The Y coordinate is flipped in Cocoa, so if you change the height, the window
will move and maybe clip against the screen edge if you don't adjust its Y
coordinate to match.
Possibly fixes Bugzilla #3066.
Unity's window manager is (legitimately, since it moves the client window's
position) sending one, and SDL was incorrectly trying to mask it out. Other
window managers (KWin, apparently) don't move the window and would hang here
indefinitely.
Fixes Bugzilla #3052.
Martin Gerhardy
Just a minor thing, but a huge outcome. All the other jni related functions already have those flags, but the nativeInit function lacks them - so it might be stripped away.
In extremely rare cases, probably due to misconfigured drivers, one might
see this happen, and rather than terminate the process, we try to recover
by reporting an error to the app.
Fixes Bugzilla #3068.
Note that extra steps must be taken when using glReadPixels to read the contents of the main OpenGL ES framebuffer on iOS, if multisampling is used. See the OpenGL ES section of README-ios.md for details.
There are platforms it isn't implemented on (and currently can't be
implemented on!), and there's currently no way for an app to know this.
This shouldn't break ABI on apps that moved to a revision between 2.0.3 and
2.0.4.
This relies on a successful SDL_Init(SDL_INIT_VIDEO) to work, since it's
silly to reproduce all the Xinerama/XRandR code in the message box parts. If
X11 is available but SDL hasn't been initialized, the message box will center
in the primary screen, which will be positioned weirdly on multi-head setups,
but this should fix the most significant common case.
Author: Benoit Pierre <benoit.pierre@gmail.com>
Date: Fri Jul 3 02:17:10 2015 +0200
fix 14dd48ae5bc43b61b2a0dd0b3177d22edec707ef regression
The window manager detection code in X11_HasWindowManager does not work
with Awesome (http://awesome.naquadah.org/). Remove it, and reuse the
result of the more correct checks in X11_CheckWindowManager.
Elise Maurer
When inputting text, dead-keys are currently not handled correctly on Windows with the latest SDL2 tip as well as the 2.0.3 release.
Using a French AZERTY keyboard, when I type the `^` key followed by `e` key to compose the `` character, I erroneously get two SDL_TEXTINPUT events, one with the `^` character and one with the `e` character.
I've looked at the history for SDL_windowsevents.c and there's been some back-and-forth with several methods for handling text input:
* r8142 removed any handling of WM_CHAR because keyboard input was being handled through WM_KEYDOWN along with ToUnicode since r7645.
* But using ToUnicode actually breaks dead-keys (googling for "ToUnicode dead keys" reports many horror stories of people trying to work around that and failing).
* It seems like r7645 introduced a double-fix: it fixed WM_CHAR to properly handle Unicode, and also (unnecessarily?) added text input handling to WM_KEYDOWN. Later, r8142 removed the WM_CHAR stuff instead of the WM_KEYDOWN stuff.
The attached patch restores handling of text input through WM_CHAR and removes it from WM_KEYDOWN. I've tested it with French, English and Russian layouts and it seems to do its job. Obviously, with such matters, it's still a risky change.
Sometimes, on removal SDL_EVDEV_udev_callback() gets called with zero udev_class. This in turn seems to be caused the SDL_udev.c:guess_device_class() failing to find the attributes of the parent device.
Apparently this is normal, attributes are not guaranteed to be in place during removal, depending on timing. This lack of attributes causes guess_device_class() to return zero.
This fix mimics the code in linux/SDL_sysjoystick.c:joystick_udev_callback() which effectively has the same fix already in place.
- disable compiling in XAudio2 support. We both need the DX SDK to make this code plus we need to work out the runtime dependency problem this code bring in on windows (needing the DX runtime installed).
CR: SamL
- do the scancode to keyboard code lookup for the grave key, so that we can show users the correct keyface for the key, rather than forcing it to "`". Note that if a game is using SDLK_* for its KB mapping then after this change on some keyboards the top left key will no longer be mapped correctly with the old data.
CR: SamL
Adam M.
It loses the title and icon when window recreation fails. For instance, this may happen when trying to create an OpenGL ES window on a system that doesn't support it. But at that point, the title and icon have already been lost.
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().
