Anything with X, Y and Z axes but no buttons is probably an
accelerometer (this is the assumption made in udev).
Signed-off-by: Simon McVittie <smcv@collabora.com>
Previously we only checked for at least one button or key and at least
the X and Y absolute axes, but this has both false positives and false
negatives.
Graphics tablets, trackpads and touchscreens all have buttons and
absolute X and Y axes, but we don't want to detect those as joysticks.
On normal Linux systems ordinary users do not have access to these
device nodes, but members of the 'input' group do.
Conversely, some game controllers only have digital buttons and no
analogue axes (the Nintendo Wiimote is an example), and some have axes
and no buttons (steering wheels or flight simulator rudders might not
have buttons).
Use the more elaborate heuristic factored out from SDL's udev code path
to handle these cases.
In an ideal world we could use exactly the same heuristic as udev's
input_id builtin, but that isn't under a suitable license for inclusion
in SDL, so we have to use a parallel implementation of something
vaguely similar.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This works on capability bitfields that can either come from udev or
from ioctls, so it is equally applicable to both udev and non-udev
input device detection.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Device enumeration via libudev can fail in a container for two reasons:
* the netlink protocol between udevd and libudev is considered private,
so there is no API guarantee that the version of libudev in a container
will understand netlink messages from a dissimilar version of udevd
on the host system;
* the netlink protocol between udevd and libudev relies for security on
being able to check the uid of each message, but in a container with
a user namespace where host uid 0 is not mapped, the libudev client
cannot distinguish between messages from host uid 0 and messages from
a different, malicious user on the host
To make this easier to experiment with, always compile the fallback
code path even if libudev is disabled. libudev remains the default if
enabled at compile time, but the fallback code path can be forced.
Signed-off-by: Simon McVittie <smcv@collabora.com>
GetAsyncKeyState() and GetRawInputData() report the state of the physical
buttons without applying the user's primary/secondary mouse button swap
preference. Swap the buttons returned from these functions, so we expose a
consistent view of the buttons to SDL callers. This new behavior also matches
the behavior of macOS and X11 backends.
See the Remarks section of the GetAsyncKeyState() function on MSDN.
We should only perform the VK_LEFT, VK_UP, etc. mapping if none of the other
special mappings apply. This allows the scancode normalization for the number
pad to take place as intended.
When we request realtime priority from rtkit, we have a rttime limit. If we exceed
that limit, the kernel will send SIGKILL to the process to terminate it.
This isn't something that most high priority processes will want, only processes
that selectively opt into SCHED_RR/FIFO through SDL_HINT_THREAD_PRIORITY_POLICY
should be subject to this level of scrutiny.
This change:
* Switches non-apple posix OSs to use SCHED_OTHER instead of SCHED_RR
for SDL_THREAD_PRIORITY_HIGH/SDL_THREAD_PRIORITY_TIME_CRITICAL.
* Fixes using a hardcoded RLIMIT_RTTIME, instead queries it from rtkit
* Only sets RLIMIT_RTTIME for MakeRealtime rtkit requests
* Adds a note regarding the possible SIGKILL with SDL_HINT_THREAD_PRIORITY_POLICY
* Introduces SDL_HINT_THREAD_FORCE_REALTIME_TIME_CRITICAL to allow apps to acquire realtime scheduling policies on Linux
CPU Vendor ID "Shanghai" and "CentaurHauls" belongs to Zhaoxin.
Background:
Shanghai Zhaoxin Semiconductor Co., Ltd ("Zhaoxin") , established in 2013,
headquartered in Zhangjiang, Shanghai, China. Zhaoxin aims at providing
general-purpose x86 processors.
Related Zhaoxin Linux Kernel patch can be found at
https://lore.kernel.org/lkml/01042674b2f741b2aed1f797359bdffb@zhaoxin.com
Best regards.
Debugging inside rtkit showed we were failing the RLIMIT_RTTIME check, now that we're asking for realtime and not just high-priority due to a change in SDL.
Between that and the DBus code in SDL being wrong in previous changelist I'm not sure how this could have ever worked.
Nov 02 20:34:15 redcore rtkit-daemon[2825]: Failed to parse MakeThreadRealtime() method call: Argument 1 is specified to be of type "uint32", but is actually of type "int32"
Nov 02 20:34:15 redcore rtkit-daemon[2825]: Failed to parse MakeThreadRealtime() method call: Argument 1 is specified to be of type "uint32", but is actually of type "int32"
Docs:
http://git.0pointer.net/rtkit.git/tree/README
CLIENTS:
To be able to make use of realtime scheduling clients may
request so with a small D-Bus interface that is accessible on
the interface org.freedesktop.RealtimeKit1 as object
/org/freedesktop/RealtimeKit1 on the service
org.freedesktop.RealtimeKit1:
void MakeThreadRealtime(u64 thread_id, u32 priority);
void MakeThreadHighPriority(u64 thread_id, s32 priority);
wcodelyokoyt
The atom name that X11_GetAtomName() returns never gets freed, which result in a minor memory leak (14 bytes?) every time the user drops a file on a window.
You can see the line in question here:
6b6170caf6/src/video/x11/SDL_x11events.c (L1350)
Fix: call XFree on name after the while loop.
Joel Linn
This patch fixes a MSVC warning, which is dependent on the regional settings of the build system. Although the character is inside a comment and harmless, it is undesirable to disable the warning for this.
OpenGL leaves the final line segment open, SDL's software renderer does not,
so we need a tiny bit of trigonometry here to move one more pixel in the right
direction.
Xbox Elite controllers use AUX1-AUX4 to represent the paddle buttons when using the HIDAPI driver
PS4 and PS5 controllers use AUX1 to represent the touchpad button
Nintendo Switch Pro controllers use AUX1 to represent the capture button
This allows one to build Raspberry Pi versions on an ancient version of
Raspbian and get both the KMSDRM and RPI video targets built into SDL, giving
maximum binary compatibility from linking against an older glibc, etc, but
also making one library that can access video on all RPi models and OS
releases.
batyastudios
Basicly there is problem and somewhat a solution: https://discourse.libsdl.org/t/setwindowmaximumsize-bug/28267
If you SDL_SetWindowMaximumSize() after SDL_SetWindowMinimumSize() with one of axes have the same value, function will have no effect.
This: (line 2144@SDL_video.c)
if (max_w <= window->min_w || max_h <= window->min_h) {
SDL_SetError("SDL_SetWindowMaximumSize(): Tried to set maximum size smaller than minimum size");
return;
}
May be changed to this:
if (max_w < window->min_w || max_h < window->min_h) {
SDL_SetError("SDL_SetWindowMaximumSize(): Tried to set maximum size smaller than minimum size");
return;
}
When converting audio from signed to unsigned values of vice-versa
the silence value chosen by SDL was the value of the device, not
of the stream that the data was being put into. After conversion
this would lead to a very high or low value, making the speaker
jump to a extreme positon, leading to an audible noise whenever
creating, destroying or playing scilence on a device that reqired
such conversion.
UnmapNotify event does not mean that window has been iconified. It
just reports that window changed state from mapped to unmapped.
XReparentWindow can unmap and remap window if it was mapped. This
causes unnecessary events - HIDDEN, MINIMIZED, RESTORED and SHOW.
These events are problematic with Metacity 3.36+ which started to
remove window decorations from fullscreen windows.
- SDL makes decorated window fullscreen
- Metacity removes decorations
- SDL gets UnmapNotify and exits from fullscreen
- Metacity re-adds decorations
As SDL will also get MapNotify event it will try to restore
window state causing above steps to repeat.
https://bugzilla.libsdl.org/show_bug.cgi?id=5314
Add a minimal my_gradd.h containing structures and constants only used
by SDL_os2vman.c -- based on public knowledge from around the internet
including pages from http://www.osfree.org and http://www.edm2.com .
Original code assigned MCIMixSetup.ulSamplesPerSec value to it, but it
is just the freq... We now change spec->samples only either if it is 0
or we changed the frequency, by picking a default of ~46 ms at desired
frequency (code taken from SDL_audio.c:prepare_audiospec()).
With this, the crashes I have been experiencing are gone.
- video: VideoBootStrap->available() is gone.
- thread: all important SDL_CreateThread internal data now put into
struct SDL_Thread: changes to SDL_SYS_CreateThread().
- events / video: SDL_SetDoubleClickTime() removed -- functionality
moved to SDL_mouse.c:SDL_MouseDoubleClickTimeChanged().
- video: struct SDL_VideoDevice-> CreateWindow and CreateWindowFrom
members renamed to CreateSDLWindow and CreateSDLWindowFrom
Has been happening with testfilesystem from 2.0.6 and newer because
of commit 572a721879ef.
Also set error strings in certain error conditions.
Also applied coding style / whitespace fixes, while I was there.
- Displays may have been added, removed or changed and all cached monitor
handles are invalidated as a result.
- Display events are handled in three steps:
1. Mark all currently know displays as invalid
2. Enumerate all displays, adding new ones and marking known displays as valid
3. Remove all displays still invalid after enumeration
- Display connect/disconnect events are sent when displays are added or removed
after initial setup
(Also see: https://bugzilla.libsdl.org/show_bug.cgi?id=4822)
Building the current tree against 10.8 SDK, clang emits the following warning:
src/video/cocoa/SDL_cocoawindow.m:1846:27: warning: instance method '-isOperatingSystemAtLeastVersion:' not found (return type defaults to 'id') [-Wobjc-method-access]
![processInfo isOperatingSystemAtLeastVersion:version]) {
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/opt/MacOSX10.8.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSProcessInfo.h:20:12: note: receiver is instance of class declared here
@interface NSProcessInfo : NSObject {
^
1 warning generated.
isOperatingSystemAtLeastVersion is an 10.10 thing.
loadNibNamed:owner:topLevelObjects is available on 10.8 and newer.
There is an issue report here about an app failing to function on
10.7 and earlier: https://discourse.libsdl.org/t/28179
I _think_ this is a right thing to do; it fixes a .wav file I have here that
has blockalign==2 when channels==2 and bitspersample==16, which otherwise
would fail.
Add hint SDL_HINT_ANDROID_BLOCK_ON_PAUSE_PAUSEAUDIO not to pause audio when
the app goes to background.
(It requires SDL_ANDROID_BLOCK_ON_PAUSE as "Non blocking")
SDL_cocoametalview was consuming the first click rather than passing it
through to the SDLView underneath which overrides [NSView acceptsFirstMouse]
based on the user's SDL_HINT_MOUSE_FOCUS_CLICKTHROUGH preference.
that are mapped to it and automatically invalidate them when it is freed
- refcount is kept so that an external application can still create a reference
to SDL_Surface.
- lock_data was un-used and is now renamed and used as a list keep track of the blitmap
"In the second half of 2021, new apps will be required to publish with the Android App Bundle on Google Play"
(see https://developer.android.com/guide/app-bundle)
And "Android App Bundles don't support APK expansion (*.obb) files".
It is a protocol error to attempt to create a pointer confine (i.e.
`SDL_SetWindowGrab`) while a locked pointer is active, and vice-versa.
Instead of aborting due to a protocol error, this commit makes SDL
gracefully downgrade locked pointers to confines when appropriate.
We now handle HiDPI correctly, and touches are clamped to the viewport. So
if you are rendering to a logical 640x480 in a 720p window, and touch the
letterboxing at point (640,700), it will report the touch at (0.5,1.0) instead
of outside the documented range.
Previously the first card with non-empty connectors, encoders
and crtcs would be selected, however KMSDRM_VideoInit could still reject
it if the connector was not connected. This allow finding the first card
(in a multi GPU setup) that is actually connected to a display.
Manuel Alfayate Corchete
I noticed pt2-clone had problems with it's optional hardware mouse on the KMSDRM backend: cursor had a transparent block around it.
So I was investigating and it seems that a GBM cursor needs it's pixels to be alpha-premultiplied instead of straight-alpha.
A
lso, I was previously relying on "manual testing" for the cursor size, but it's far better to use whatever the DRM driver recommends via drmGetCap(): any working driver should make a size recommendation via drmGetCap(), so that's what we use now. I took this decision because I found out that the AMDGPU driver reported working cursor sizes that would appear garbled on screen, and only the recommended cursor size works.
This fixes a case where you render to the backbuffer, then render to a render
target, set the current target back to the backbuffer, and then present
without drawing anything else; in this circumstance, the Present command
would never happen.
Fixes Bugzilla #5011.
This is handled in in the higher-level SDL_GL_LoadLibrary().
All uses of SDL_EGL_LoadLibrary (which calls the Only version) are just
target-specific wrappers for their own GL_LoadLibrary hook, with two
exceptions which now handle driver_loaded correctly (although it's
questionable if these init-if-no-one-did-it-correctly-already code blocks
should exist at all, fwiw).
Fixes Bugzilla #5190.
Instead of creating an X11 connection to test that X11 is available,
closing the connection, and then reconnecting for real, use the same
connection to handle both cases.
The X11 connection retry delay mechanism in the case where X11 is
dynamically loaded has been removed. It was only necessary to avoid
authetnication token reuse from the XOpenDisplay call that used to
exist in X11_Available. Now that this call is only made once, it
is no longer needed.
Also drop unused and inapplicable code from a comment.
***
The two are only ever called together, and combining them makes it possible
to eliminate redundant symbol loading and redundant attempts to connect
to a display server.
Manuel Alfayate Corchete
This small patch fixes the KMSDRM_CreateSurfaces() call in KMSDRM_CreateWindow(), that was segfaulting deeper into SDL internals because the windata->viddata pointer wasn't set before the KMSDRM_CreateSurfaces() call.
So that's what this small patch does.
Now, L?VE2D works perfectly well on the Raspberry Pi 3, instead of just segfaulting.
JackBoosY
In src/video/winrt/SDL_winrtgamebar.cpp line 55:
virtual HRESULT STDMETHODCALLTYPE add_VisibilityChanged(
__FIEventHandler_1_IInspectable *handler,
Windows::Foundation::EventRegistrationToken *token) = 0;
The macro __FIEventHandler_1_IInspectable defined in windows.fondation.h(Windows10 SDK 10.0.17763.0) line 3576:
#define __FIVector_1_Windows__CFoundation__CPoint ABI::Windows::Foundation::Collections::__FIVector_1_Windows__CFoundation__CPoint_t
but no longer exists in Windows 10 SDK 10.0.19041.0.
After searching this macro in the sdk include path, I found that it was defined in many header files. But it should be replaced in windows.system.h .
On some systems, GetClipCursor() impacts performance when called frequently, so only call it every once in a while to make sure we haven't lost our capture.
Manuel Alfayate Corchete
I'm trying to build SDL2 with threads support here in GNU/Linux, both X86 and ARM, and it does not seem to be possible ATM:
/home/manuel/src/SDLLLL/src/core/linux/SDL_threadprio.c:233:26: error: 'rtkit_max_realtime_priority' undeclared (first use in this function)
Manuel Alfayate Corchete
This patch is needed so programs that do this work as expected:
1) Start in a different video mode than the mode used by the system and then...
2) Try to go fullscreen with the mode originally used by the system via SetWindowFullScreen() with the SDL_WINDOW_FULLSCREEN_DESKTOP flag.
An example would be pt2-clone in https://github.com/8bitbubsy/pt2-clone.
This program does this:
Starts with:
video.window = SDL_CreateWindow("", SDL_WINDOWPOS_CENTERED,
SDL_WINDOWPOS_CENTERED, screenW, screenH, windowFlags);
and then, *IF* the user has configured it in fullscreen mode in its .ini, it tries to go fullscreen with the desktop mode:
SDL_SetWindowFullscreen(video.window, SDL_WINDOW_FULLSCREEN_DESKTOP);
This sequence of operations is currently failing because SDL_SetDisplayModeForDisplay() in SDL_video.c fails because display->desktop_mode is not being initialized with its correct value: SetDisplayMode() in SDL_kmsdrmvideo.c will not be able to set the mode because it detects the mode to have a driverdata of 0x0 ("if (!modedata)") and rightfully returns an error.
So, the included patch fixes this small problem, and programs that first change the video mode and then try to go fullscreen with the system video mode will now work.
The patch simply fixes an small omission, but its really needed now that dynamic video mode changing was implemented on the KMSDRM backend.
Ryan C. Gordon
As discussed here:
https://discourse.libsdl.org/t/question-about-implementation-of-sdl-updatewindowsurfacerects/27561
"As you can see this function [WIN_UpdateWindowFramebuffer, in src/video/windows/SDL_windowsframebuffer.c] calls BitBlt on entire screen, even though it accepts the rects. Rects variable is not even used in this function at all. Now my question is why is that the case?"
Anthony Pesch
I was looking into my own input bug and noticed an issue in the HIDAPI code while looking over it. I don't have a controller that goes down this path to test and try to provoke the issue, but it looks pretty straight forward.
The memmove to shift the joystick id array on disconnect isn't scaling the size by sizeof(SDL_JoystickID), likely corrupting the ids on disconnect.
It currently behaves like a locking key which is pressed
when Caps Lock is enabled and released when disabled. This
means that apps that trigger events on Caps Lock key down will
only fire these events every other time Caps Lock is pressed.
Lacky
It looks like refactoring of SDL2 internal API has broken SDL_RenderFillRect for DirectFB. In new version function SDL_RenderFillRect returns 0, but rectangle is not visible.
Replacing "count" with "len" in the argument list for SDL_memcpy in DirectFB_QueueFillRects fixes problem.
Jan Bujak
I wrote a new driver for my gamepad on Linux. I'd like SDL to support it out-of-box, as currently it just treats it as a generic joystick instead of a gamepad. From what I can see the only way to do that is to either 1) pick one of the already supported controllers' PID, VID and button layouts and have my driver send that (effectively lying that it's something else), or 2) submit a preconfigured, hardcoded mapping to SDL.
Both of those, in my opinion, are silly when we already have the Linux Gamepad Specification which standarizes this:
https://www.kernel.org/doc/html/v4.15/input/gamepad.html
Unfortunately SDL doesn't make use of it currently. So I've took it upon myself to add it; patch is in the attachments.
Basically what the patch does is that if SDL finds no built-it controller mappings for a given joystick it then asks the joystick backend to autodetect it, and that uses the relevant evdev bits to figure out which button/axis is which. (See the specs for more details.)
With this patch applied my own driver for my controller works out-of-box with SDL with no extra configuration and is correctly recognized as a gamepad; this is also going to be the case for any other driver which follows the Linux Gamepad Specification.
Arithmatic operations promote Uint8 to signed int. If the top bit of a
Uint8 is set, and it is left shifted 24 places, then the result is not
representable in a signed 32 bit int. This would be undefined behaviour
on systems where int is 32 bits.
It makes it clearer who owns the memory, and more reasonable to free it on
failure in the creating function.
(and, of course, pacifies static analysis.)
Manuel Alfayate Corchete
On the KMSDRM backend, there is no such thing as a desktop, yet some programs could (and DO) use SDL_GetGlobalMouseState().
So I think its good idea that, in KMSDRM, it returns the same mouse coordinates anyway as SDL_GetMouseState() would return. There is nothing else it could return, as far as I can understand, since there is no desktop anyway.
This small patch does precisely that.
Manuel Alfayate Corchete
The KMSDRM backend was doing things wrong because of some small (but important) misconceptions on how KMS/DRM works: to implement a largely broken non-vsync refresh mechanism, the SwapWindow() function was issuing new pageflips before previous ones had completed, thus causing EBUSY returns, buffer mismanagement, etc... resulting in general breakage on vsync disabling from apps, that would not allow vsync to work again without KMSDRM video re-initialization.
To further clarify, on most DRM drivers async pageflips are NOT working nowadays, so all issued pageflips will complete on next VBLANK, NOT ASAP (calling drmModePageFlip() with the DRM_MODE_PAGE_FLIP_ASYNC flag will return error).
The old code was assuming that can just issue a synchronous (=on VBLANK) pageflip and then pass a 0 timeout to the pull() function so we do not wait for the pageflip event, thinking that this will lead to correct non-vsynced screen updates from the program: That is plain wrong.
Each pageflip has to be waite before issuing a new one, ALWAYS. And if we do not support ASYNC pageflips on the DRM driver level, then we are forced to wait for the next VBLANK. There is no way around it.
I have also added many comments on the KMSDRM code. This is needed for future reference for me or others who may need to look at this code: KMS/DRM terminology regarding what SYNC and ASYNC mean in pageflip terms, and where to do certain things and why, is not trivial. It is not desirable or possible to invest time on researching the same concepts every time there is need to dive into this code. So please leave all these comments in the patch.
1. Comment that SDL_SetThreadPriority will make any necessary system changes when applying priority.
2. Add a hint to override SDL's default behavior for scheduler policy.
3. Modify the pthreads SDL_SetThreadPriority so that instead of just using the current thread scheduler policy it will change it to a policy that should work best for the requested priority.
4. Add hint checks in SDL_SetThreadPriority so that #3 can be overridden if desired.
5. Modify the Linux SDL_SetThreadPriority so that in the case that policy, either by SDL defaults or from the hint, is a realtime policy it uses the realtime rtkit API.
6. Prior to calling rtkit on Linux make the necessary thread state changes that rtkit requires. Currently this is done every time as it isn't expected that SDL_SetThreadPriority will be called repeatedly for a thread.
michaeljosephmaltese
Display ends up taking only 1/4 of the screen area. It needs to call "setWantsBestResolutionOpenGLSurface:highdpi", like when creating a window the normal way.
wengxt
Due to the new major fcitx version is coming close, the existing code need to be ported to use new Fcitx dbus interface.
The new dbus interface is supported by both fcitx 4 and 5, and has a good side effect, which is that it will work with flatpak for free. Also the patch remove the dependency on fcitx header. Instead, it just hardcodes a few enum value in the code so need to handle the different header for fcitx4 or 5.
meyraud705
'SDL_Windows::driverdata' of a Wayland window is allocated by calloc in 'Wayland_CreateWindow' but freed by SDL_free in 'Wayland_DestroyWindow'.
meyraud705
I see how the documentation is confusing. I think that the choice of the axis is an implementation detail. The documentation should state the goal of this value, so I propose this wording:
"Use this value to play an effect on the steering wheel axis. This provides
better compatibility across platforms and devices as SDL will guess the
correct axis."
Value could even be renamed 'SDL_HAPTIC_STEERING_AXIS'.
For Linux, sending an effect on the X axis with a Logitech wheel works. Others brands don't have driver for Linux as far as I know.
This is only supported on PulseAudio. You can set a description when opening
your audio device that will show up in pauvcontrol, which lets you set
per-stream volume levels.
Fixes Bugzilla #4801.
dark_sylinc
Trying to build SDL with VS2019 using CMake will encounter a linking error
More specifically:
1>SDL_string.obj : error LNK2019: unresolved external symbol memset referenced in function SDL_vsnprintf_REAL
* 8BitDo N30 Pro 2
* 8BitDo SN30 Gamepad
* 8BitDo SN30 Pro+
* 8BitDo Zero 2
* SZMY-POWER PC Gamepad
* ThrustMaster eSwap PRO Controller
* ZEROPLUS P4 Wired Gamepad
In additional, all 8BitDo controllers use SDL_HINT_GAMECONTROLLER_USE_BUTTON_LABELS to have the correct mapping based on user preferences.
This patch removes deferred error string formatting: now we do it during
SDL_SetError(), so there's no limit on printf-style arguments used.
Also removes stub for managing error string translations; we don't have the
facilities to maintain that and the way we set arbitrary error strings
doesn't really make this practical anyhow.
Since the final error string is set right away and unique to the thread,
we no longer need a static buffer for legacy SDL_GetError(), and we don't
have to allocate 5x 128-byte argument fields per-thread. Also, since we now
use SDL_vsnprintf instead of parsing the format string ourselves, there's a
lot of code deleted and we have access to more robust formatting powers now.
This does mean the final error strings can't be more than 128 bytes, down
from the theoretical maximum of around 768, but I think this is probably okay.
They might truncate but they will always be null-terminated!
Fixes Bugzilla #5092.
The joystick layer can't necessarily give us perfect centering, but we know
that the game controller level has logical absolute idle positions that have
nothing to do with the physical device.
So send game controller events to make it look like the device is completely
untouched before sending the final removal event.
This driver supports the Razer Atrox Arcade Stick
Some of the quirks of this driver, inherent in Windows Gaming Input:
* There will never appear to be controllers connected at startup. You must support hot-plugging in order to see these controllers.
* You can't read the state of the guide button
* You can't get controller events in the background
meyraud705
On line 220 of SDL_hidapi_xbox360.c https://hg.libsdl.org/SDL/file/4608f0e6e8e3/src/joystick/hidapi/SDL_hidapi_xbox360.c#l220
if (!XINPUTGETSTATE(user_index, &xinput_state[user_index].state) == ERROR_SUCCESS) {
logical not is only applied to the left hand side of this comparison.
I think you mean:
if (XINPUTGETSTATE(user_index, &xinput_state[user_index].state) != ERROR_SUCCESS) {
On Raspberry Pi 3 via the VC4 driver in firmware KMS mode, none of the
found configs match the desired format, causing the function to fall through
without any config being selected.
Fix by first iterating over the found configs, and if no match exists,
don't exclude the non-matching configs. This should fix RPI3 and possibly other
targets without breaking targets that have a matching native format (such as RPI4).
This allows you to bind surfaceless contexts on a background thread to, for
example, load assets in a separate context, for platforms that have different
requirements about sharing surfaces, etc.
Martin's notes on the matter:
"Here's a patch that enables passing NULL windows to SDL_GL_MakeCurrent, if
the involved APIs allow it. Currently, this is only the case for EGL, and
even then only if some specific extensions are present (which they usually
are).
If "surfaceless" contexts are not supported, SDL_GL_MakeCurrent continues to
generate an error (albeit with a more specific error message than it used to),
so this should not break anything that wasn't broken before."
(Please see https://bugzilla.libsdl.org/show_bug.cgi?id=3695 for more
discussion.)
Fixes Bugzilla #3695.
This behavior matches SDL_RecreateWindow and makes it less likely that
another piece of code (e.g. a DestroyWindowFramebuffer implementation)
will attempt to use or free the stale surface pointer.
From hmk:
"When scaling is enabled (e.g. via SDL_RenderSetLogicalSize, size not equal
to window size), mouse motion events are also scaled. Small motions are
rounded up (SDL_max() when the value after scaling is less than 1), while
larger motions are truncated by the floating point -> integer conversion.
https://hg.libsdl.org/SDL/file/b18197f9bf9d/src/render/SDL_render.c#l658
The end result feels something like mouse reverse mouse acceleration + angle
snapping at low speeds, but less consistent (amount of truncation & rounding
depends on how fast the mouse is moved) and potentially much worse if the
scaling factor is large. This pretty much makes it useless for anything
where you need precise mouse aiming (think of games). I suspect this is why
aiming gets so terrible in some games that let you use scaling to reduce the
render resolution (e.g. Ion Fury).
With 4x4 scaling, I can reproduce a situation where it takes three fast flicks
of the mouse across the pad to undo one slow sweep across the pad. In other
words, extreme reverse acceleration. This does not happen when scaling is
disabled.
Furthermore, any game that uses relative mouse motion events for 3D camera
rotation probably wants the raw mouse deltas and not a value that depends on
scaling and resolution and rounding and truncation. Ideal camera rotation
just takes mouse input, multiplies it by sensitivity, and adds it to the
angle-in-radians or whatever measure is used for yaw & pitch. Pixels and
screen resolution or window dimensions should not be a part of the equation
at all, even if it could be implemented without rounding errors.
[...]
This [patch] completely eliminates angle snapping for me, and makes
sensitivity consistent. In other words, it's completely usable for, say,
aiming in a first person shooter."
Partially fixes Bugzilla #4811.
Caleb Cornett's comments:
"A few weeks ago, Alex added a partial Metal API to SDL2:
https://hg.libsdl.org/SDL/rev/22c8e7cd8d38
I noticed it was missing a few features that would help Metal become a
first-class citizen in SDL, so I went ahead and wrote them! Here are the new
APIs:
1. SDL_WINDOW_METAL flag for SDL_CreateWindow(). This allows the programmer
to specify that they intend to create a window for use with SDL_MetalView.
The flag is used to ensure correct usage of the API and to prevent
accidentally defaulting to OpenGL on iOS.
2. SDL_Metal_GetLayer(). This function takes a SDL_MetalView and returns a
pointer to the view's backing CAMetalLayer. This simplifies things
considerably, since in the current version of the SDL_Metal API the
programmer is required to bridge-cast a SDL_MetalView handle to an NSView or
UIView (depending on the platform) and then extract the layer from there.
SDL_Metal_GetLayer automatically handles all of that, making the operation
simple and cross-platform.
3. SDL_Metal_GetDrawableSize(). This function already exists in the current
SDL_Metal API (and is used behind-the-scenes for SDL_Vulkan_GetDrawableSize
on Apple platforms) but was not publicly exposed. My patch exposes this
function for public use. It works just like you'd expect.
Tested on macOS 10.14 and iOS 12.4."
Fixes Bugzilla #4796.
This does not account for scrollbars nor margins. But is much better then returning the full display size when not running fullscreen, but for example in an iframe.
The first terminator is for input parameters. The second terminator was for the
output parameters.
If an error occurs when calling MakeThreadHighPriority(), e.g. a bad thread id,
then the reply from connection_send_with_reply_and_block() will be null.
Anthony Pesch's notes on his patch:
"Currently, the WASAPI backend creates a stream in shared mode and sets the
device's callback size to be half of the shared stream's total buffer size.
This works, but doesn't coordinate will with the actual hardware. The hardware
will raise an interrupt after every period which in turn will signal the
object being waited on inside of WaitDevice. From my empirical testing, the
callback size was often larger than the period size and not a multiple of it,
which resulted in poor latency when trying to time an application based on the
audio callback. The reason for this looked something like:
* The device's callback would be called and and the audio buffer was filled.
* WaitDevice would be called.
* The hardware would raise an interrupt after one period.
* WaitDevice would resume, see that a a full callback had not been played and
then wait again.
* The hardware would raise an interrupt after another period.
* WaitDevice would resume, see that a full callback + some extra amount had
been played and then it would again call our callback and this process would
repeat.
The effect of this is that the pacing between subsequent callbacks is poor -
sometimes it's called very quickly, sometimes it's called very late.
By matching the callback's size to the stream's period size, the pacing of
calls to the user callback is improved substantially. I didn't write an actual
test for this, but my use case for this was my Dreamcast emulator
(https://redream.io) which uses the audio callback to help drive the emulation
speed. Without this change and with the default shared stream buffer (which
has a period of ~10ms) I would get frame times that were between ~3-30
milliseconds; after this change I get frame times of ~11-22 milliseconds.
Note, this patch also has a change that removes passing a duration to the
Initialize call. It seems that the default duration used (when 0 is passed)
does typically match up with the duration returned by GetDevicePeriod, however
the Initialize docs say:
> To set the buffer to the minimum size required by the engine thread, the
> client should call Initialize with the hnsBufferDuration parameter set to 0.
> Following the Initialize call, the client can get the size of the resulting
> buffer by calling IAudioClient::GetBufferSize.
This change isn't strictly required, but I made it to hopefully rule out
another source of unexpected latency."
Fixes Bugzilla #4592.
If called from background threads, use Grand Central Dispatch to use the
main thread instead. On the main thread, just call them directly.
Fixes Bugzilla #4932.
