SDL has been building on GNU/Hurd for a long time, using either drivers
based on external libraries (e.g. X11, pulseaudio, sndio, etc) or dummy
drivers. This commit introduces it explicitly as platform, so it can be
recognized, and tweaked as needed. In particular:
- introduce the SDL_PLATFORM_HURD define
- tighten/improve the platform detection in cmake, and use "Hurd" as
identifier
- return the platform name in SDL_GetPlatform()
- tweak the CFLAGS/LDFLAGS so pthreads can be used properly
- implement SDL_GetExeName(), using /proc/self/exe as provided by the
basic Linux-like procfs
- enable GLES 2 in tests (mostly for consistency with Linux)
I assume the demoninator is a typo, rather than an indication that
someone has been playing too much Doom :-)
Signed-off-by: Simon McVittie <smcv@collabora.com>
"This thing allows to do something" is not really grammatically correct.
The closest rephrasing would be "allows one to do something" or "allows
the user to do something", but I think the passive voice reads more
naturally here.
Detected by Debian's lintian QA tool.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The currently used way to determine the endianness (i.e. include
<endian.h> and use the __BYTE_ORDER macro) is provided in general by
GNU libc. Thus, extend that to any platform/OS based on GNU libc.
This reverts commit 47d8bdd1c3.
There are runtime reasons why creating a tray can fail, so the correct approach is not to assume that just because a platform supports a tray that trays are available. Instead, you should create a tray at application startup, for the lifetime of the application, and handle failures at that point.
Closes https://github.com/libsdl-org/SDL/pull/13632
This reverts commit 608f706a95.
Didn't end up using this in SDL3_mixer, and it's a super-awkward API if we
don't need it.
I _might_ bite the bullet and let people lock a physical audio device, though,
as I could see that being useful but less awkward for the same reasons I
originally wanted it.
This still logs backend choices, but we might use it for other things. For
example, what Android device is being used, or all the devices we enumerated,
etc.
Ideally this eventually logs all the stuff we often have to ask followup
questions about.
...so the backends don't have to do it.
Also added a stern warning about `org` being omitted, but leaving it as
allowed so as not to break existing apps (more than they are already broken,
at least).
Fixes#13322.
It _must_ have the format set for the opposite side from the device (so
playback needs the src format set, and recording needs the dst format set),
since the stream gets mangled by the device thread if not. So if it has never
been set (stream created with NULL audiospec), just set it to match the device.
If the stream is just meant to buffer and not convert, this is desired
behavior, even if it didn't also fix a bug.
Binding the audio stream will always set the device side's format, as usual;
this does not need to be set by the caller at all.
Fixes#13363.
This is a special-case piece of functionality, generally these are expected
to go away during shutdown, but maybe someone is switching between audio
subsystems or something...
