Older Android phones have a kernel bug where time is not properly calculated
when calling `clock_gettime(CLOCK_MONOTONIC_RAW, ...)`. The returned time
either has nanoseconds out of range (outside of [0, 999999999]) or the returned
time is not monotonic in regards to previous call or both.
The issue is reproducible in Android Studio on arm64 emulators from at least
Android 7.0 (didn't try older versions) up to including Android 8.1 (kernel
3.18.94). The issue is in the kernel, these are just the versions of Android
emulator with buggy kernels.
The kernel commit that fixed this is [1]. Because this fix was backported to
various LTS releases of kernels it's hard to find out exactly which kernels are
buggy and which not. Therefore always use `CLOCK_MONOTONIC` on Android.
The `CLOCK_MONOTONIC` is slowly adjusted in case of NTP changes but not for
more than 0.5ms per second [2]. So it should be good enough for measuring
elapsed time.
---
An option would be to dynamically select
`CLOCK_MONOTONIC_RAW`/`CLOCK_MONOTONIC` at runtime by checking at init time
that `clock_gettime(CLOCK_MONOTONIC_RAW, ...)` returns nanoseconds in range.
Testing showed that nanosecons are out of range for 999/1000 cases. I guess
this could be good enough for support on older phones.
But because this would introduce a small perf hit by always reading a global
variable for first argument to `clock_gettime` and because `CLOCK_MONOTONIC`
does not have that high time deviation, this commit uses `CLOCK_MONOTONIC` on
Android always. It is also less burden to maintain.
---
[1] https://github.com/torvalds/linux/commit/dbb236c1ceb697a559e0694ac4c9e7b9131d0b16
[2] https://github.com/torvalds/linux/blob/master/include/linux/timex.h#L136
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 allows us to avoid browser mouse emulation for touches, since we provide
our own anyhow.
The other option is to "prevent default" in the legacy touch event handlers we
historically used, to tell the browser not to supply emulation, but we can't
currently tell Emscripten to mark those handlers as not "passive," so as it
stands they are unable to prevent default. Using Pointer Events bypasses this
problem entirely.
Fixes#13161.
macOS sends a focus loss event when the dialog is created, which causes SDL
to try to minimize the window, which confuses the entire system. So in this
special case, don't do the minimization.
Fixes#13168.
This specifically affects SDL_EnumerateDirectory and SDL_GetPathInfo. Android
assets are read-only, so no need to do this for things like
SDL_CreateDirectory, etc, and the POSIX SDL_CopyFile() uses SDL_IOStream
behind the scenes, which already supports Android assets.
Fixes#13050.
It apparently works better (or can work better?) on multimonitor setups
than SwapBuffers.
This should be available back to Windows 95, but just in case, it falls
back to standard SwapBuffers if not available.
Fixes#13269.
Sam Lantinga