Use zwp_keyboard_shortcuts_inhibit_manager_v1 to allow SDL applications
to capture system keyboard shortcuts like Alt+Tab when keyboard grab is
enabled via SDL_HINT_GRAB_KEYBOARD.
Existing SDL applications may not know about the need to set a specific
hint to enable rumble on PS5 controllers, even though they may already
set the equivalent SDL_HINT_JOYSTICK_HIDAPI_PS4_RUMBLE hint for PS4
controller rumble support.
Rather than requiring those developers update their apps, let's use the
SDL_HINT_JOYSTICK_HIDAPI_PS4_RUMBLE value as an indication of the behavior
they are expected for all PlayStation controllers.
From hidapi mainstream git: https://github.com/libusb/hidapi/issues/142d2c3a9862e
Read callback may fire itself on its own even after its been requested
to stop and exactly before the calling code waits for its completion in
indefinite loop. Explicitly preventing re-fireing the submission loop
fixes the issue.
jibb
I'm testing with DualShock 4, DualSense, Switch Pro Controller, and PowerA Switch Controller.
I'm using the standard mapping file from here:
https://raw.github.com/gabomdq/SDL_GameControllerDB/master/gamecontrollerdb.txt
With SDL_HINT_GAMECONTROLLER_USE_BUTTON_LABELS turned off (set to "0") I expect the button positions to be the same on all devices, based on Xbox controller button naming (eg SDL_GameControllerGetButton(g, SDL_CONTROLLER_BUTTON_Y) gives me whether the North face button is pressed).
However, the Switch Pro Controller layout is wrong (matching labels rather than positions, so X and Y are swapped and A and B are swapped). And with the PowerA controller the East and West buttons are correct, but the North and South buttons are swapped instead.
Mathias Kaerlev
Also seeing this on 2.0.14. This is most likely a regression, since we weren't seeing this on an earlier SDL version.
I suspect it might be caused by this commit:
a569b21188 (diff-da9344d94c66b8c702a45e7649f412039f08bba83bd82de33f5c80ea9c8c39d5)
It seems like both the HIDAPI driver and SDL_gamecontroller.c will try to swap the buttons if the hint is set to 0, causing the button remap to cancel out.
RustyM
This is related to Bug 5034, but crashes under a somewhat different condition.
In the latest tip (changeset 13914) or with the SDL 2.0.12 source + David?s 5034 patch, unplugging and then replugging in certain controller types on macOS will crash. A mix of new controllers like Switch Pro, PS4 and Xbox One all work without issue. But if a controller without a rumble function, like many SNES retro USB gamepads, is mixed with a PS4 or Switch Pro controller it will crash.
File: joystick/darwin/SDL_sysjoystick.c
Function: static recDevice *FreeDevice(recDevice *removeDevice)
On line 159: while (device->pNext != removeDevice) {
Causes: Thread 1: EXC_BAD_ACCESS (code=1, address=0x188)
This can be reproduced in testgamecontroller" by starting the test program with both a ?retro? controller plugged in and a ?modern rumble? controller (Switch Pro/PS4). This may crash on launch, but it depends on which controller ends up as device 0. If it doesn?t crash, unplug the ?modern rumble? controller and plug it back in.
Some of the "retro" controllers I?ve seen this crash with:
- iBuffalo SNES Controller
- 8Bitdo SN30 Gamepad (in MacOS mode)
- Retrolink NES Controller
- HuiJia SNES Controller Adaptor
The issue appears macOS specific. Seen on 10.12.6 and 10.14.6. Not seen on Windows 10.
The while loop in FreeDevice() assumes that every device is not NULL.
recDevice *device = gpDeviceList;
while (device->pNext != removeDevice) {
device = device->pNext;
}
device->pNext = pDeviceNext;
So maybe we should check for NULL here? Or instead prevent adding NULL devices to the list in the first place? Checking device for NULL before entering the loop appears to work.
recDevice *device = gpDeviceList;
if (!device) {
while (device->pNext != removeDevice) {
device = device->pNext;
}
}
device->pNext = pDeviceNext;
sashikknox
In some cases, need create EGLWindow with SDLWindow. In X11 i can get pointer to NativeWindow from **struct SDL_SysWMinfo wmInfo**
```C++
struct SDL_SysWMinfo wmInfo;
SDL_GetWindowWMInfo(ptSDLWindow, &wmInfo)
#if defined(__unix__) && defined(SDL_VIDEO_DRIVER_X11)
nativeWindow=(EGLNativeWindowType)wmInfo.info.x11.window;
nativeDisplay=(EGLNativeDisplayType)wmInfo.info.x11.display;
#endif
```
than i can create EGLSurface
```
eglCreateWindowSurface(nativeDisplay, EGL_CONFIG, nativeWindow, SURFACE_ATTRIBUTES);
```
in Wayland i can do it with same way, just need pointer to **EGLWindow**, we already have pointer to **wl_display** from **SDL_sysWMInfo**, need add to **wl** struct in SDL_SysWMInfo another pointer to **struct wl_egl_window *egl_window;**. And in wayland backend, in function **Wayland_GetWindowWMInfo** return pointer to **egl_window** from **SDL_WindowData**
Now i use patched statically built SDL2 in port of Quake 2 GLES2 for SailfishOS (it use QtWayland):
link to SDL2 commit and changed string for patch:
- 6858a618cd
- b1e29e87b9/SDL2/src/video/wayland/SDL_waylandwindow.c (L463)
link to use in Quake2 port:
1. here i get pointer to EGLNativeWindowType: 6d94fedb1b/Engine/Sources/Compatibility/OpenGLES/EGLWrapper.c (L319)
2. then use it for create EGLSurface: 6d94fedb1b/Engine/Sources/Compatibility/OpenGLES/EGLWrapper.c (L391)
wahil1976
This patch adds a written-from-scratch WSCONS driver for OpenBSD. It does not have hardcoded keymaps, and it features mouse support when wsmux is available.
For this to work, it needs access to the /dev/wskbd* devices which are not available to non-root users by default. Access to those can be granted by changing /etc/fbtab to give the logging user the ownership of those devices.
Note that axes are changed to match the axes we're using with PlayStation controllers, since users will appreciate consistent behaviour across devices.
Nia Alarie
The NetBSD kernel's audio resampling code is much simpler and lower quality than libsamplerate.
Presumably, if SDL always performs I/O on the audio device in its native frequency, we can avoid resampling audio in the kernel and let SDL do it with libsamplerate instead.
Dominik Reichardt
Exult (http://exult.info) has an editor app that uses GTK+2. Up to now we were using X's drag'n'drop to allow dropping of assets from the editor onto Exult.
There is now an experimental branch that makes use of SDL_DROPFILE. That works under X, dropping in Exult's SDL2 window puts the asset right at the spot you dropped at.
On macOS with native Exult and Quartz GTK+2 this doesn't work, the location of the drop is where the mouse was last tracked before you left the window (usually one of the edges, unless you tabbed out).
All we tried out pointed to the fact that the location update needs to be done by the dropfile event in SDL2, not by our own (which always only worked after the Exult window getting focus).
This patch adds this to SDL_cocoawindow.m and it works perfectly, passing the correct coordinates to our code (SDL_GetMouseState()).
- explicitly use UNICODE versions of DrawText, EnumDisplaySettings,
EnumDisplayDevices, and CreateDC: the underlying structures have
WCHAR strings.
- change WIN_UpdateDisplayMode and WIN_GetDisplayMode() to accept
LPCWSTR instead of LPCTSTR for the same reason.
- change WIN_StringToUTF8 and WIN_UTF8ToString to the explicit 'W'
versions where appropriate.
i.e. where the string is known guaranteed to be WCHAR*, in:
- SDL_dinputjoystick.c (WIN_IsXInputDevice): VARIANT->var is BSTR (WCHAR*)
- SDL_rawinputjoystick.c (RAWINPUT_AddDevice): string is WCHAR*
- SDL_windows_gaming_input.c (IEventHandler_CRawGameControllerVtbl_InvokeAdded):
string is WCHAR*
There should be more of these..
_InterlockedExchange_rel() is required for correctness on ARM because
the _ReadWriteBarrier() macro is only a compiler memory barrier, not a
hardware memory barrier. Due to ARM's relaxed memory model, this means
the '*lock = 0' write may be observed before the operations inside the
lock, causing possible corruption of data protected by the lock.
_InterlockedExchange_acq() is more efficient on ARM because it avoids an
expensive full memory barrier that _InterlockedExchange() does.
C.W. Betts
I tested building commit http://hg.libsdl.org/SDL/rev/7adf3fdc19f3 on Mac Catalyst and found some issues:
* MTLFeatureSet_iOS_* enums aren't available under Mac Catalyst.
* OpenGL ES is unavailable under Mac Catalyst.
* Some Metal features are available under Catalyst but not iOS, such as displaySyncEnabled.
* Set Metal as the default renderer on Mac Catalyst
Attaching a patch that will make SDL2 build for Mac Catalyst.
This is unsafe because the event is auto-reset, therefore the call to
WaitForSingleObject() resets the event which GetOverlappedResult() will
try to wait on.
Even though the overlapped operation is guaranteed to be completed at
the point we call GetOverlappedResult(), it will still wait on the event
handle for a short time to trigger the reset for auto-reset events. This
amounts to roughly a 100 ms sleep each time GetOverlappedResult() is called
for a completed I/O with a non-signalled event.
In the context of HIDAPI, this extra sleep means that callers that loop
on hid_read_timeout() with timeout=0 will loop forever, since the 100 ms
sleep each iteration ensures ReadFile() will always have new data.
Caleb Cornett
For a window created with SDL_WINDOW_ALLOW_HIGHDPI, SDL_GL_GetDrawableSize will return the high-dpi drawable size even before any GL context creation happens. But SDL_Metal_GetDrawableSize will return the size of the window if the Metal view has not been created. This is confusing and inconsistent behavior.
An easy way to test this is to build testgl2 and testvulkan on macOS with the SDL_WINDOW_ALLOW_HIGHDPI flag enabled during window creation. The GL2 program will report a drawable size of 2x window width and 2x window height, while the Vulkan program will report the window size.
This patch addresses the issue by falling back to using the content view dimensions if no Metal view exists in the window. (The code for this was taken directly from Cocoa_GL_GetDrawableSize.) With this change, the testvulkan behavior matches that of testgl2.
Note that I haven't tested for this issue on UIKit. It's possible a similar change will need to be made there too.
David Carlier
This form of 'or' provides a hint that performance
will probably be improved if shared resources dedicated
to the executing processor are released for use by other
processors
- hidapi already called CancelIo on hid_close but that only cancels pending IO for the current thread. Controller read/writes originate from multiple
threads (serialized, but on a different thread nonetheless) but device destruction was always done on the main device thread which left any
pending overlapped reads still running after hidapi's internal read buffer is deallocated leading to intermittent free list corruption.
Ivan Kuzmenko
MCST Elbrus 2000 (E2K, https://en.wikipedia.org/wiki/Elbrus_2000) is a russian processor architecture based on VLIW/EPIC instruction set (like Intel Itanium (IA-64) architecture). Architecture has half native / half software support of most Intel/AMD SIMD (e.g. MMX/SSE/SSE2/SSE3/SSSE3/SSE4.1/SSE4.2/AES/AVX/AVX2 & 3DNow!/SSE4a/XOP/FMA4).
It also has built-in x86/x86_64 <-> e2k binary translators (RTC, http://www.mcst.ru/rtc and Lintel, http://www.mcst.ru/lintel) that can run code for x86/x86_64 architecture (Transmeta did something similiar with their Crusoe series) with SIMD extensions support.
Attached patch allows SDL2 to detect extensions supported by E2K like MMX, 3dNOW!, AVX etc. (test/testplatform log: https://termbin.com/7qs3).
wahil1976
This patch adds support for OpenBSD to KMSDRM_LEGACY. Note that the patch won't be ported to the atomic KMSDRM backend because OpenBSD does not support atomic KMS properly yet.
Is automatically used when the SRW SDL_mutex implementation is active.
Otherwise falls back to the generic implementation.
v2: - Rebase onto master fa3ea1051a4b
https://bugzilla.libsdl.org/show_bug.cgi?id=5308
The udev code labels devices that are found by this code with
ID_INPUT_KEY which in turn gets used by SDL to label the devices as
SDL_UDEV_DEVICE_KEYBOARD.
This was missing for the code path when udev is not running and as such
devices such as the power button of a phone was not detected as keyboard
input and no devices were emitted.
Cameron Cawley
stdlib: Added SDL_round, SDL_roundf, SDL_lround and SDL_lroundf
The default implementation is based on the one used in the Windows RT video driver.
Keep Semaphore Kernel Object impl for Windows 7 and older - choose at runtime
v2: - Fix mixed int/LONG types
- Reorder definitions
- Add missing include
v3: - Use `GetModuleHandle()` to load the API Set
v2: - Add SRW definitions as suggested by Ozkan Sezer
Allows building against older platform headers.
- Rename "hidden" function parameter `mutex_` to `_mutex`
v3: - Use GetModuleHandle instead of LoadLibrary
- Fix typo in comment
SDL_systhread.c and SDL_syslocale.c used to call LoadLibrary() without
calling FreeLibrary() later. GetModuleHandleW() should always succeed
because GetModuleHandleW() itself is imported from kernel32.dll and we
don't need to bother releasing it.
.. so that KMSDRM_CreateDevice() can fail and SDL_VideoInit() would
move on to next bootstrap member which is kmsdrm_legacy. hopefully
fixes bug #5393.
Substring
I was trying the KMSDRM video backend with some very simple programs that were working ok on 2.0.12. The same code won?t work on the current dev branch and I get:
DEBUG: check_modesetting: probing ?/dev/dri/card0?
DEBUG: /dev/dri/card0 connector, encoder and CRTC counts are: 4 5 6
DEBUG: check_modesetting: probing ?/dev/dri/card0?
DEBUG: /dev/dri/card0 connector, encoder and CRTC counts are: 4 5 6
DEBUG: KMSDRM_VideoInit()
DEBUG: Opening device /dev/dri/card0
DEBUG: Opened DRM FD (3)
DEBUG: no atomic modesetting support.
DEBUG: Video subsystem has not been initialized
INFO: Using SDL video driver: (null)
DEBUG: Video subsystem has not been initialized
After carefully checking, the radeon driver doesn?t support atomic modesetting. That?s not the only problem : the same happens with the amdgpu driver if we disable Display Core (kernel parameter amdgpu.dc=0, which is required to get analogue outputs working).
This is a major regression in the KMSDRM driver.
Using atomic mode setting is great, but having no fallback to the "standard KMS" is bad.
pj5085
I added some printf to verify the math being done. Of the three joysticks I have, it works correctly for at least two, and seems to work correctly for the third. I say "seems to" because, for the third joystick, the values never go through the AxisCorrect function, and thus never hit my printf statements, even though they did in the version I wrote my patch against. I'm not sure what's going on there, but it at least seems to be working correctly in as much as I can tell.
I note this result in particular, for an SNES Gamepad (min=0, max=255):
Joystick value 0 becomes -32768
Joystick value 127 becomes 0
Joystick value 255 becomes 32767
Without the code that forces a zero point, the 127 input value would become -129, so I think you see why I added that code to turn it into zero. However, I think Kai Krakow has a point about how SDL shouldn't assume that there should be a center.
Obviously in the majority of cases there actually should be a center, and the code that turns that 127 into an actual 0 is creating only a 0.2% error over 0.4% of this joystick's range. However, what if there is an axis that is some kind of special control, like a 4-position switch, and, for whatever reason, the joystick reports it as an axis with 4 possible values, 0 to 3? In that case, mutilating the two center values to the same value is much more of an error and and turns that 4-position switch into a 3-position switch. If any joystick does this with a 2-position switch, then this code would render that control entirely useless as it would report the same value with the switch in either position. Obviously the code could require that there be at least N possible values, to guess whether something is a proper axis or just some kind of switch, but the choice of N would be arbitrary and that's ugly.
I guess the real problem here is that my gamepad is just kind of broken. It should be reporting a range of -1 to +1 since that's what it actually does. Also, as Kai Krakow points out, it's probably not SDL's place to fix broken hardware. I'll add that, if SDL does fix broken hardware, it should probably actually know that it's broken rather than be merely guessing that it is.
So, to the extent that SDL is able to do stuff like this, perhaps it's something better left for the user to configure in some kind of config file.
