Browsers don't have the functionality to fully support the generic
SDL_ShowMessageBox(), but this handles the likely most-common case.
Without this, you'd return immediately with a proper error result and no UI,
but probably no one checks that for SDL_ShowSimpleMessageBox. And if they
did: what would they do to handle this anyhow?
We'd need to lobby for an HTML spec of some sort that allows customizable
message boxes--that block!--to properly support SDL message boxes on
Emscripten, but this is probably Good Enough for now.
AudioQueues are available in Mac OS X 10.5 and later (and iOS 2.0 and later).
Their API is much more clear (and if you don't mind the threading tapdance
to get its own CFRunLoop) much easier to use in general for our purposes.
As an added benefit: they seemlessly deal with format conversion in ways
AudioUnits don't: for example, my MacBook Pro's built-in microphone won't
capture at 8000Hz and the AudioUnit version wouldn't resample to hide this
fact; the AudioQueue version, however, can handle this.
Generate the C protocol files from the protocol XML files installed by
wayland-protocols, and use them to implement support for relative pointer
motions and pointer locking.
Note that at the time, the protocol is unstable and may change in the future.
Any future breaking changes will, however, fail gracefully and result in no
regressions compared to before this patch.
Since we are loading shared objects dynamically, build our own version of the
core protocol symbols, so that we in the future can include protocol
extensions.
This will be used by Wayland compositors to match the application ID and
.desktop file to the SDL window(s).
Applications can set the SDL_VIDEO_WAYLAND_WMCLASS environemnt variable
early in the process to override using the binary name as a fallback.
Note that we also support the SDL_VIDEO_X11_WMCLASS in the Wayland
backend so that if a program correctly associated the desktop file with
the window under X11, only a newer SDL would be needed for it to work
under Wayland.
https://bugzilla.libsdl.org/show_bug.cgi?id=3376
Author: James Zipperer <james.zipperer@synapse.com>
Date: Sun Aug 21 01:19:19 2016 -0700
bugfix for controller / joystick add / remove being in the event queue at the same time
The repro steps were this:
1. run an sdl2 winrt/uwp app, on Win10, v10.0.10586.0 or higher
2. hide the cursor, via a call to SDL_ShowCursor(0)
3. make the Win10 game bar appear, by pressing the Windows + G hotkey
4. observe that the mouse cursor appears, in order to interact with the
game bar (this is expected behavior)
5. make the Win10 game bar disappear, either by pressing the Windows + G hotkey
again, or clicking somewhere in the app
EXPECTED RESULT: cursor disappears, as game bar disappears
ACTUAL RESULT: cursor didn't always disappear
Moved this code from winmm into core so both can use it.
DirectSound (at least on Win10) also returns truncated device names, even
though it's handed in as a string pointer and not a static-sized buffer. :/
The Windows 10 Anniversary Update (1607) breaks the method uses that SDL uses to
detect XInput devices. That is, on Windows 10 Anniversary Update, it is no longer
possible to query RAWINPUT for HID devices, and check for "IG_" in the device name.
Presumably, this will be fixed in the future.
This patch works around the issue by adding the Xbox One controller series to the
well-known device list.
This skips the more expensive RAWINPUT check for those devices, and causes them to
be detected as XInput devices once again.
Otherwise, if you had a massive, one-time queue buildup, the memory from that
remains allocated until you close the device. Also, if you are just using a
reasonable amount of space, this would previously cause you to reallocate it
over and over instead of keeping a little bit of memory around.
I think this was important for SDL 1.2 because some targets needed
special device memory for DMA buffers or locked memory buffers for use in
hardware interrupts or something, but since it just defines to SDL_malloc
and SDL_free now, I took it out for clarity's sake.
- It's now always called if device->hidden isn't NULL, even if OpenDevice()
failed halfway through. This lets implementation code not have to clean up
itself on every possible failure point; just return an error and SDL will
handle it for you.
- Implementations can assume this->hidden != NULL and not check for it.
- implementations don't have to set this->hidden = NULL when done, because
the caller is always about to free(this).
- Don't reset other fields that are in a block of memory about to be free()'d.
- Implementations all now free things like internal mix buffers last, after
closing devices and such, to guarantee they definitely aren't in use anymore
at the point of deallocation.
Turns out that libartsc isn't thread-safe, so if we run a capture and playback
device at the same time, it often crashes in arts's internal event loop.
We could throw mutexes around the read/write calls, but these are meant to
block, so one device could cause serious latency and stutter in the other.
Since this audio target isn't in high-demand (Ubuntu hasn't offered a libartsc
package for years), I'm just backing out the capture support. If someone needs
it, they can pull it out of the revision history.
(We probably never noticed because this is meant to block until it fully
writes a buffer, and would only trigger an issue if we had a short write
that wasn't otherwise an error condition.)
This workaround, unfortunately, requires that apps directly link to a set of
Win32-style cursor resource files (that contain a transparent cursor image).
Copies of suitable resource files are in src/core/winrt/, and should be
included directly in an app's MSVC project.
A rough explanation of this workaround/hack, and why it's needed (and
seemingly can't be done through programmatic means), is in this change's code.
This allows us to set an explicit stack size (overriding the system default
and the global hint an app might have set), and remove all the macro salsa
for dealing with _beginthreadex and such, as internal threads always set those
to NULL anyhow.
I've taken some guesses on reasonable (and tiny!) stack sizes for our
internal threads, but some of these might turn out to be too small in
practice and need an increase. Most of them are simple functions, though.
Win10's 'GamepadAdded' event seems to need to have something registered with it
in order for Xinput-based gamepad detection to work. This 'fix' simply causes
a dummy event-handler to be added for this event, in case an app wants to use
gamepads on Xbox One (most likely).
This is kind of nasty, because ALSA reports dozens of "devices" that aren't
really things you'd ever want, or things that should be listed this way, but
the default path still works as before, and it at least allows these devices
to be available to apps.
This does not handle hotplugging yet. You get a device list at init time
and that's it.
- Cache the _NET_FRAME_EXTENTS data locally, so we don't have to query
the X server for them (instead, we update our cached data when PropertyNotify
events alert us to a change).
- Use our cached extents for X11_GetWindowBordersSize(), so it's a fast call.
- Window position was meant to refer to the client area, not the window
decorations, so adjust appropriately when getting/setting the position.
We now only raise the magic exception that names the thread when
IsDebuggerPresent() returns true. In such a case, Visual Studio will
catch the exception, set the thread name, and let the debugged process
continue normally. If the debugger isn't running, we don't raise an exception
at all.
Setting the name is a debugger trick; if the debugger isn't running, the name
won't be set if attached later in any case, so this doesn't lose functionality.
This lets this code work without assembly code, on win32 and win64, and
across various compilers.
The only "gotcha" is that if you have something attached that looks like a
debugger but doesn't respect this magic exception trick, the process will
likely crash, but that's probably a deficiency of the attached program.
Fixes Bugzilla #2089.
The returned value is currently not used by the caller. The instance id would
also not be needed on Java side and providing it just complicated the function.
Partially fixes Bugzilla #3234.
This assert triggers when run under XMonad. It's safe to pass a zero here
anyhow, as this will still work "well enough" and the original
problem--GNOME printing a warning message--is still fixed because GNOME's
window manager gives us a chance to grab a non-zero user-time value before
this code is run.
(and thanks to Cengiz for many of the previous Unreal-related
patches! They were generically credited to Epic Games, but a large
amount of that work was his contribution.)
Fixes Bugzilla #3067.
This is for corner cases where a multi-window app is activated and wants to
make a decision about where focus should go.
This patch came from Unreal Engine 4's fork of SDL, compliments of Epic Games.
This lets windows know when they are dropping a mouse event because their
hit test reported something other than SDL_HITTEST_NORMAL. It lets them know
exactly where in the event queue this happened.
This patch is based on work in Unreal Engine 4's fork of SDL,
compliments of Epic Games.
This is currently implemented for X11, Cocoa, Windows, and DirectFB.
This patch is based on work in Unreal Engine 4's fork of SDL,
compliments of Epic Games.
This allows an app to know when a set of drops are coming in a grouping of
some sort (for example, a user selected multiple files and dropped them all
on the window with a single drag), and when that set is complete.
This also adds a window ID to the drop events, so the app can determine to
which window a given drop was delivered. For application-level drops (for
example, you launched an app by dropping a file on its icon), the window ID
will be zero.
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().
