(and it defaults to "yes" on those platforms. Other places, which use libusb,
still default to no because they probably need root permissions to work.)
This time, we make anything we think is a MacBook trackpad report its touches
as SDL_MOUSE_TOUCHID, even though they're not _actually_ synthesized events,
and let all mouse input--even if the OS synthesized it from a multitouch
trackpad on our behalf--look like physical input. This is backwards from
reality, but produces the results most apps will expect.
Note that if you have a real touch device that doesn't appear to be the
trackpad, it'll produce real touch events with unique device ids, so it's
not a total loss here, but also note that the way we decide if it was the
trackpad is an imperfect heuristic; it happens to work out right now, but
it's not impossible that a real touchscreen could come to the Mac at some
point and (incorrectly?) call it a "mouse" input, etc.
But for now, good enough.
Fixes Bugzilla #4690.
"Starting with changeset 12433, the mouse cursor is not displayed on the
Raspberry Pi platform, due to a bug in the handling of the new
"global_cursor" in RPI_ShowCursor(). Currently, if cursor == global_cursor,
the function immediately returns 0. The function should not return here.
Instead, if cursor == global_cursor, it shouldn't try to hide the current
cursor and update global_cursor = cursor. However, it *should* still continue
through the rest of the function."
Fixes Bugzilla #4699.
Using IOKit for this pops up a warning at startup on macOS 10.15 ("Catalina"),
asking the user to authorize the app to listen to all keyboard input in the
system, which is unacceptable.
I _think_ we were using IOKit under incorrect presumptions here; the Stack
Overflow link mentioned in it was complaining about not being able to use
flagsChanged to differentiate between left and right mod keys, but that's not
an issue for capslock.
It's also possible this code was trying to deal with capslock changing when
the window didn't have focus, but we handle this elsewhere now, if we didn't
at the time.
GetWindowText() wants you to tell it the size of the buffer--including the
terminating NULL char--but we weren't counting that last char, losing the
last char of the string in the process. This was only seen with the special
case of SDL_CreateWindowFrom() to use an existing native window, not
the usual SDL_CreateWindow() codepath.
Fixes Bugzilla #4696.
(technically, this function never returns an error at this point, but since
it _does_ have an "uhoh, is this corrupt data?" comment that it ignores, we
should probably make sure we handle error cases in the future. :) )
This was to deal with broken vsync support in macOS 10.14, which we assumed
would remain broken indefinitely, but a later 10.14 released fixed it.
This is a loss of late-swap support, but there are several subtle problems
in our CVDiplayLink code that are also evaporating, to be fair.
Fixes Bugzilla #4575.
(Backed out changeset 8760fed23001)
This was meant to migrate CoreAudio onto the same SDL_RunAudio() path that
most other audio drivers are on, but it introduced a bug because it doesn't
deal with dropped audio buffers...and fixing that properly just introduces
latency.
I might revisit this later, perhaps by reworking SDL_RunAudio to allow for
this sort of API better, or redesigning the whole subsystem or something, I
don't know. I'm not super-thrilled that this has to exist outside of the usual
codepaths, though.
Fixes Bugzilla #4481.
This lets you build a custom embedded device that roughly offers the "this
process is going to the background NOW" semantics of SDL on a mobile device.
This lets apps see and choose between both an HDMI and DSI-connected display,
such as a television and the Pi Foundation's official touchscreen. It only
exposes the second display if the hardware reports that it is connected.
This also solves reports of this log message:
"INFO: The key you just pressed is not recognized by SDL. To help get this
fixed, please report this to the SDL forums/mailing list
<https://discourse.libsdl.org/> EVDEV KeyCode 330"
(EVDEV KeyCode 330 is BTN_TOUCH.)
Fixes Bugzilla #4147.
This is the best option for macOS and iOS, the only platforms with Metal.
Pre-Metal versions of these platforms will fall back to OpenGL (ES), as
appropriate.
Huge thanks to Alexander Szpakowski, who worked incredibly hard to get the
Metal renderer to such a high-quality state!
Not only does this fix macOS 10.14 ("Mojave")'s broken NSOpenGLCPSwapInterval
support, it also lets us implement "adaptive vsync" on macOS!
CVDisplayLink is supported back to macOS 10.4 ("Tiger"), so we just use it
universally without version checks and dump NSOpenGLCPSwapInterval, Mojave or
not.
Ryan C. Gordon