We were returning the report size from HIDAPI_DriverPS5_RumbleJoystick() rather
than 0 upon success, causing SDL_JoystickRumble() (and callers) to think that
rumbling failed.
This didn't cause major problems until 1868c5b, when it started preventing
rumble state from being persisted in the joystick core, even though it was
successfully sent to the hardware.
This led to all sorts of strangeness, including broken rumble duration and
attempts to stop rumble being discarded.
The functions can go south if other operations are in progress, like
X11_SetWindowBordered, which might be doing something traumatic behind the
scenes of the window manager.
We can't make these tasks totally synchronous, which would fix the problem,
because not only can the window manager block however long it wants, it might
also decide to deny our requests without any notification, so we'd be waiting
forever for a window change that isn't coming. :(
Fixes#5274.
Use viewports for non-fullscreen windows when the desktop uses fractional scaling and the window is flagged as DPI-aware to provide a backbuffer mapped as close to 1:1 output as possible. In the cases of odd window sizes the backbuffer may be a pixel off of scaling perfectly into the window size due to its scaled size being rounded off, but a minute amount of scaling during output is likely preferable to the large amounts of overdraw needed with integer scaled buffers.
Expose as many emulated display modes as possible. They will currently display stretched to the display's native desktop aspect, but if an application requires a hardcoded resolution, it will work at minimum.
Aside from the change in the emulated display mode list, the Wayland event handling code had to be updated to support separate scaling for the x and y axes, as square pixels are no longer guaranteed.
Wayland doesn't support mode switching, however Wayland compositors can support the wp_viewporter protocol, which allows for the mapping of arbitrarily sized buffer regions to output surfaces. Use this functionality, when available, for fullscreen output when using non-native display modes and/or when dealing with scaled desktops, which can incur significant overdraw without this extension.
This also allows for the exposure of arbitrarily sized, emulated display modes, which can be useful for legacy compatability.
1. Mod index values are (mostly) constant, so can be done with xkb_state_new
2. Mods can change without the group changing, avoid remap events if possible
Lastly, as a bonus, I added braces to the locale check, because I was nearby.
When using shared linking (linking in the normal way with
-lwayland-client) rather than loading Wayland libraries dynamically at
runtime, listing symbols that don't exist in the current version results
in a build failure. We don't actually call wl_proxy_marshal_flags() or
wl_proxy_marshal_array_flags() directly; the reason we need them is
that they're called by the code generated by wayland-scanner >= 1.20.
If we're building against an older Wayland library, then we'll have its
corresponding version of wayland-scanner (mismatched versions are not
supported), so we won't need those two symbols, and can avoid generating
a dependency on them.
Conversely, if we're building against a newer Wayland library, the
generated code will call them unconditionally, so we cannot treat them as
optional and gracefully fall back: that would result in a crash. Instead,
treat them as a mandatory part of the Wayland library, so that if they
are not found at runtime, we can fall back to X11 without crashing.
libwayland 1.18 is in several LTS distributions (Ubuntu 20.04,
Debian 11, RHEL 8) so avoiding a hard dependency on 1.20 is quite
useful.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Resolves: https://github.com/libsdl-org/SDL/issues/5376
Using wl-output to get the desktop display dimensions and dividing by the integer scale factor will not return the correct result when using a desktop with fractional scaling (e.g. a 3840x2160 display at 150% will incorrectly report the scaled desktop area as 1920x1080 instead of 2560x1440). Use the xdg-output protocol, if available, to retrieve the correct desktop dimensions and offset.
Versions 1 through 3 of the protocol are supported.
- which also enable/disable the orientation lock status.
This is only provided when the window is not SDL_WINDOW_FULLSCREEN (see SDL_video.c).
Final orientation also depends on SDL_HINT_ORIENTATIONS.
The Java code needs the native functions to be implemented, even if
they're not surfaced via the C API, therefore, a stub version of
functions were made only to the purpose of "fill the gaps" when
SDL_HIDAPI_DISABLED set to 1.
if SDL_EnumUnixAudioDevices() fails to find any devices,
set an error message on the exit path. Without this,
SDL_Init() could fail without any message available
in SDL_GetError().
This isn't obvious, but makes sense when thinking about how games actually use it. This is also in line with how Windows mouse relative mode is implemented.
Fixes https://github.com/libsdl-org/SDL/issues/5340
Here's an IRC dump that hopefully explains the issue this fixes:
> I'm debugging something odd where, for a libre game,
unvanquished.net (a FPS), relative mouse input in fullscreen is
buggy
> it's like, working mostly ok, but it has a weird
performance/cleanup bug
> after some time in relative mouse input mode, some time as low
as 15s, usually more, the SDL sends A LOT of relative mouse
input per frame
> almost all of which have xrel==0 && yrel==0
> by A LOT, I mean that after ~1min, it's usually in the
thousands per frame
> each frame, a while ( SDL_PollEvent( &e)) loop reads the
inputs, but it seems SDL is not clearing the list.
> one way to clear the list is to open the in-game console or
menu, which switches the input mode to absolute, then close it
which gets a working relative input mode (for some time at least)
> I've shown the issue to be present with SDL2.0.20 but not with
2.0.14 on my system
> some other players on Arch Linux (SDL2.0.20) report a possibly
related issue, where some keys seem to be pressed at random
> I've did some bisection on SDL master, and I've found that
there are actually two commits involved, one breaking it
totally (no input at all), and one fixing it partially (with
the problem described above)
First related commit that breaks it totally:
commit 82793ac279
Author: Sam Lantinga <slouken@libsdl.org>
Date: Thu Oct 14 14:26:21 2021 -0700
Fixed mouse warping while in relative mode
We should get a mouse event with an absolute position and no relative motion and shouldn't change the OS cursor position at all
Second related commit, that halfway fixes it:
commit 31f8c3ef44
Author: Sam Lantinga <slouken@libsdl.org>
Date: Thu Jan 6 11:27:44 2022 -0800
Fixed event pump starvation if the application frequently pushes its own events
Reverting the first commit did fix the issue for me, but would
probably reintroduce the bug it was fixing(?). This patch should
fix it for everyone hopefully.
https://github.com/DaemonEngine/Daemon/issues/600 is the upstream
bug, and contains some early investigation.
According to MSDN, we can also get SIZE_MAXHIDE and SIZE_MAXSHOW,
based on state changes to other windows. It's not clear under
what circumstances this will happen (I saw some docs indicating
it may require multiple application windows), but it doesn't seem
right to treat them as RESTORED.
- no need to keep the error in a static variable
- always print the error code
- reduce the required stack-size
- reduce the number of snprintf calls (and code size)
* Fixes for IME Composition Truncation + Addition of SDL_ClearComposition, SDL_IsTextInputShown
* Fixed: Documentation and code style issues raised during code review.
The name that the Raw Input joystick driver pulls from the HID stack comes
from USB string descriptors contained on the device. For official wireless
receivers, this always contains "Xbox 360 Wireless Receiver for Windows"
which matches the friendly name that WGI provides.
3rd party Xbox 360 wireless receivers may have different strings in their
USB string descriptors (one uses "XBOX 360 For Windows" instead). This
fails to match WGI's name and causes Raw Input and WGI to both report the
same gamepad.
Since wireless Xbox 360 controllers seem to have a consistent VID/PID
regardless of the adapter enumerating them, we can also match on that to
catch these.
The duplicate case reported to me was:
Controller (XBOX 360 For Windows) - 030000005e040000a102000000007200
Xbox 360 Wireless Receiver for Windows - 030000005e0400000000000000007701
This adds support for all 3 of the gamecube controller's rumble modes
Rumble: 1
Stop: 0
StopHard: 2
This is useful for applications that need the full range of support
This also adds a hint to control rumble behavior, defaults 0 to maintain compatibility
If the app requested a specific renderer, even if it's not the optimal path,
let them have it, because they might want to render with a specific GPU API
on top of the framebuffer pixels.
This fixes DosBox-X crashing on startup, which forces the hint to "opengl".
Now we see if we can create an SDL_Renderer, and if that renderer reports
itself as "accelerated," and added some initial heuristics to the OpenGL
renderer to make better decisions about what qualifies as "accelerated."
This adds some FIXMEs that might be merely hypothetical, and removes the
old OpenGL checks from the video subsystem that probably weren't meaningful
in modern times. This will definitely need to improve the existing list
in the GL renderer, to catch things like llvmpipe, etc.
Reference issue #4624.
The io_list_check_add() and io_list_remove() functions are only ever called from within the Pipewire thread loop, so the locks are redundant. io_list_sort() is called from within a lock in the device detection function, so those additional locks are redundant as well.
Remove the hard upper limit of 8192 samples and instead use the buffer sizes provided by Pipewire to determine the size of the intermediate input buffer and whether double buffering is required for output streams. This allows for higher latency streams to potentially avoid double-buffering in the output case, and we can guarantee that the intermediate input buffer will always be large enough to handle whatever Pipewire may deliver.
As the buffer size calculations occur in a callback in the Pipewire processing thread itself, the stream readiness check has been modified to wait on two distinct flags set when the buffers have been configured and when the stream is ready and running.
- use the result of SDL_ConvertPixels to propagate error
- get rid of the verbose error message of D3D11_RenderReadPixels in case SDL_ConvertPixels failed
- always set error message in SDL_EGL_ChooseConfig / SDL_EGL_CreateContext
- assume SDL_EGL_DeleteContext does not alter the error message
- sync generic error message of SDL_EGL_MakeCurrent with SDL_EGL_Get/SetSwapInterval
- do not overwrite error message of SDL_EGL_ChooseConfig in WINRT_CreateWindow
- add missing error-message in SDL_LoadBMP_RW
- check return value of SDL_RWtell in SDL_LoadBMP_RW
- use standard SDL_EFREAD error instead of custom strings
+ adjust return type of readRlePixels
- allocate ime_candidates on demand
- allow write to the whole allocated memory of ime_candidates
- ensure ime_candcount is set to zero in case the candidates can not be queried for any reason
- move IME_ShowCandidateList, ImmGetContext and ImmReleaseContext to this function
- set ime_candpgsize to MAX_CANDLIST if dwPageSize is zero
- comment out deselection of ime_candsel in case of korean language for the moment (LANG_CHT does not work anyway)
The context and stream creation functions will destroy the passed properties object on failure, so no need to do it manually.
The pw_properties_free() function pointer is no longer needed, so it can be removed.
This reverts commit ca36cdb185f2f26241598068927821896f36b904.
The older Windows SDK's headers are wrong, and this change would crash if
you hotplug a device.
- drop unnecessary hascapture check
- call SDL_InvalidParamError and return -1 in case the index is out of range
- do not zfill SDL_AudioSpec
- adjust documentation to reflect the behavior
