I updated .clang-format and ran clang-format 14 over the src and test directories to standardize the code base.
In general I let clang-format have it's way, and added markup to prevent formatting of code that would break or be completely unreadable if formatted.
The script I ran for the src directory is added as build-scripts/clang-format-src.sh
This fixes:
#6592#6593#6594
* Add braces after if conditions
* More add braces after if conditions
* Add braces after while() conditions
* Fix compilation because of macro being modified
* Add braces to for loop
* Add braces after if/goto
* Move comments up
* Remove extra () in the 'return ...;' statements
* More remove extra () in the 'return ...;' statements
* More remove extra () in the 'return ...;' statements after merge
* Fix inconsistent patterns are xxx == NULL vs !xxx
* More "{}" for "if() break;" and "if() continue;"
* More "{}" after if() short statement
* More "{}" after "if () return;" statement
* More fix inconsistent patterns are xxx == NULL vs !xxx
* Revert some modificaion on SDL_RLEaccel.c
* SDL_RLEaccel: no short statement
* Cleanup 'if' where the bracket is in a new line
* Cleanup 'while' where the bracket is in a new line
* Cleanup 'for' where the bracket is in a new line
* Cleanup 'else' where the bracket is in a new line
I ran this script in the include directory:
```sh
sed -i '' -e 's,#include "\(SDL.*\)",#include <SDL3/\1>,' *.h
```
I ran this script in the src directory:
```sh
for i in ../include/SDL3/SDL*.h
do hdr=$(basename $i)
if [ x"$(echo $hdr | egrep 'SDL_main|SDL_name|SDL_test|SDL_syswm|SDL_opengl|SDL_egl|SDL_vulkan')" != x ]; then
find . -type f -exec sed -i '' -e 's,#include "\('$hdr'\)",#include <SDL3/\1>,' {} \;
else
find . -type f -exec sed -i '' -e '/#include "'$hdr'"/d' {} \;
fi
done
```
Fixes https://github.com/libsdl-org/SDL/issues/6575
* The header is no longer dependent on SDL build configuration
* The structures are versioned separately from the rest of SDL
* SDL_GetWindowWMInfo() now returns a standard result code and is passed the version expected by the application
* Updated WhatsNew.txt and docs/README-migration.md with the first API changes in SDL 3.0
* Consolidated scancode mapping tables into a single location for all backends
* Verified that the xfree86_scancode_table2 is largely identical to the Linux scancode table
* Updated the Linux scancode table with the latest kernel keycodes (still unmapped)
* Route X11 keysym -> scancode mapping through the linux scancode table (which a few hand-written exceptions), which will allow mappings to automatically get picked up as they are added in the Linux scancode table
* Disabled verbose reporting of missing keysym mappings, we have enough data for now
Before calling any D-Bus related methods we should first ensure that
they
were correctly loaded.
In the event where `LoadDBUSLibrary()` was not able to load the D-Bus
library, we should just return early, signalling with SDL_FALSE that we
were unable to inhibit the Screensaver.
Helps: https://github.com/ValveSoftware/steam-for-linux/issues/8815
Signed-off-by: Ludovico de Nittis <ludovico.denittis@collabora.com>
In order to inhibit the screen saver, SDL currently uses
`org.freedesktop.ScreenSaver.Inhibit()` and, as a fallback, a protocol
specific method for X11 or Wayland.
Accessing `org.freedesktop.ScreenSaver` is usually not allowed when
inside a sandbox like Flatpak, unless the permission has been explicitly
granted to the application.
Another issue is that the Wayland protocol "Idle inhibit" is relatively
new and not yet widely adopted. For example Mutter still doesn't support
it.
For those reasons, when running under Flatpak or Snap, we should try to
inhibit the screen saver by using xdg-desktop-portal instead. This
should give us an higher chance of success.
Fixes: https://github.com/libsdl-org/SDL/issues/6075
Signed-off-by: Ludovico de Nittis <ludovico.denittis@collabora.com>
Refactor the previous sandbox check in a standalone function that also
includes Snap support.
Signed-off-by: Ludovico de Nittis <ludovico.denittis@collabora.com>
SDL_DBus_CallWithBasicReply() allows us to send a DBus message and get
its result, if it is a basic type, e.g. integer or string.
With this function we avoid duplicating code.
Signed-off-by: Ludovico de Nittis <ludovico.denittis@collabora.com>
If the D-Bus subsystem is shutdown and restarted mid-execution, the cached connection will be invalid. Fetch it each time that it is used to ensure that the connection is always from the current context.
This is necessary for consistent position reports with absolute mice
and improves application performance with relative mice by cutting the
number of reported mouse motion events roughly in half.
Use the xdg-desktop-portal interface to RealtimeKit1, when available, to set realtime scheduling and elevated priority for threads. This portal allows for the use of rtkit within containers such as Flatpak. It will fall back to using RealtimeKit1 directly if the xdg-desktop-portal interface is too old or not available.
The documentation doesn't state that the argument is ever modified,
and no implementation does so currently.
This is a non-breaking change to guarantee as much to callers.
See SDL bug #4703. This implements two new hints:
- SDL_APP_NAME
- SDL_SCREENSAVER_INHIBIT_ACTIVITY_NAME
The former is the successor to SDL_HINT_AUDIO_DEVICE_APP_NAME, and acts
as a generic "application name" used both by audio drivers and DBUS
screensaver inhibition. If SDL_AUDIO_DEVICE_APP_NAME is set, it will
still take priority over SDL_APP_NAME.
The second allows the "activity name" used by
org.freedesktop.ScreenSavver's Inhibit method, which are often shown in
the UI as the reason the screensaver (and/or suspend/other
power-managment features) are disabled.
This prevents a race if two threads that need d-bus try to init it at the
same time. Note that SDL_Init will likely handle this from a single thread
at startup, but there are places outside of init where one might trigger
D-Bus init, like setting thread priority (a common first thing for a new
thread to do) resulting in SDL trying to use RTKit.
Fixes#4587.
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.
wahil1976
This patch adds the KBIO text input driver for FreeBSD, which allows text input to fully work without text spilling out into the console. It also supports accented input, AltGr keys and Alt Lock combinations.
Tested with US accent keys layout and various AltGr layouts.
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>
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
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);
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)
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.
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.
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.
There are multiple SDL APIs that internally sink into dbus calls, e.g. battery
status, thread priority. If those calls happen in different threads simultaneously
it can result in dbus crashes.
To abide by dbus's multithreading guidelines we must call dbus_threads_init_default()
to enable dbus's internal locking mechanisms:
https://dbus.freedesktop.org/doc/api/html/group__DBusThreads.html#gac7b8a7001befc3eaa8c6b043151008dc
Additionally, access to a DBusMessage must be synchronized between threads.
SDL was already abiding that guideline as the DBusMessage structs aren't shared.
The following email from the dbus mailing list hints that arbitrating access to
the DBusConnection on the SDL may also be required:
https://lists.freedesktop.org/archives/dbus/2017-September/017306.html
Currently the message is double terminated, which results in SDL_DBus_CallMethodInternal()
incorrectly assuming that the other party is always returning true.
I'm not super familiar with dbus, so I'm not sure if this could also be the cause of this bug:
https://github.com/ValveSoftware/steam-for-linux/issues/6901
Add an include on SDL_error.h to avoid the following build failure
without threads:
/home/buildroot/autobuild/instance-0/output-1/host/opt/ext-toolchain/bin/../lib/gcc/arm-buildroot-linux-uclibcgnueabihf/8.3.0/../../../../arm-buildroot-linux-uclibcgnueabihf/bin/ld: build/.libs/SDL_threadprio.o: in function `SDL_LinuxSetThreadPriority_REAL':
SDL_threadprio.c:(.text+0x0): undefined reference to `SDL_Unsupported'
Fixes:
- http://autobuild.buildroot.org/results/7f7712c5bd47de4a3fcec1e0d0526fd5a3ecd532
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
The SDL_USE_LIBDBUS define is set inside SDL_debug.h, therefore the
circular dependency made it impossible for this feature to be enabled.
Instead, guard SDL_dbus.h based on the autoconf variable HAVE_DBUS_DBUS_H
Additionally, fix one of the rtkit comments. CAP_SYS_NICE isn't required
to achieve high priority. But there is some scheduler config that rtkit
needs the app to setup.
Daniel Drake
A long time ago, it was possible to play neverball on Linux using the accelerometer found in HP laptops.
The kernel exposes the accelerometer as a joystick (/dev/input/jsX) as well as an evdev device (/dev/input/eventX). I guess it worked fine when SDL was using the js interface, but then stopped working here: http://hg.libsdl.org/SDL/rev/fdaeea9e7567
Looking at current code which uses udev to discover joysticks, it looks for the udev tag ID_INPUT_JOYSTICK.
However udev's internal input_id logic specifically tags accelerometers as ID_INPUT_ACCELEROMETER and nothing else.
This looks like a good fit for SDL_HINT_ACCELEROMETER_AS_JOYSTICK.
Cameron Gutman
The bugfix in https://hg.libsdl.org/SDL/rev/ca9417a52f18 caused SDL_SetRelativeMouseMode() to begin failing on Vivante (Steam Link). Even though Vivante doesn't have a SetRelativeMouseMode() or WarpMouse() function, it's in relative mode already (because it uses evdev) so the function was actually working as intended.
I think providing a no-op SetRelativeMouseMode() function for Vivante is a reasonable fix. Since it's already getting relative events through evdev, it really is a no-op to "enter relative mode".
In fact, this is probably the right thing to do for all backends that use evdev (vivante, raspberry, and kmsdrm). Raspberry and kmsdrm both have WarpMouse() implementations so SDL_SetRelativeMouseMode() isn't failing there, but it still seems to make sense not to have to do the fake warping if they're evdev-based anyway.
Manuel Sabogal
There is an issue on the latest commit of the mercurial repo when SDL_THREADS_DISABLED is set:
src/core/linux/SDL_threadprio.c:79:28: error: unknown type name 'Sint64'; did you mean 'int'
Jan Martin Mikkelsen
The attached patch adds support for single-touch evdev devices.
These devices report ABS_X, ABS_Y and BTN_TOUCH events. This patch sets them up as MT devices with a single slot and handles the appropriate messages.
Sam Lantinga
Sylvain Becker
Frank Praznik
Pierre Wendling
Ozkan Sezer
Ryan C. Gordon
Hubert Maier
Ludovico de Nittis
Cameron Gutman
Adam Butcher
rohlem
Mathieu Eyraud
Guldoman
Weng Xuetian
David Gow
Steven Noonan
Ethan Lee
Luca Weiss
Simon McVittie
Fabrice Fontaine
Alex Szpakowski