With multitouch, register to receive XI_Motion (which desctivates MotionNotify),
so that we can distinguish real mouse motions from synthetic one.
(bug 4690)
(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.)
Windows generates fake raw mouse events for touchscreens for compatibility
with legacy apps that predate touch support in Windows. We already handle
touch events explicitly, so drop the synthetic events to avoid duplicates.
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.
Anthony Pesch
The previous code first configured the period size using snd_pcm_hw_par-
ams_set_period_size_near. Then, it further narrowed the configuration
space by calling snd_pcm_hw_params_set_buffer_size_near using a buffer
size of 2 times the _requested_ period size in order to try and get a
configuration with only 2 periods. If the configured period size was
larger than the requested size, the second call could inadvertently
narrow the configuration space to contain only a single period.
Rather than fixing the call to snd_pcm_hw_params_set_buffer_size_near
to use a size of 2 times the configured period size, the code has been
changed to use snd_pcm_hw_params_set_periods_min in order to more
clearly explain the intent.
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.
"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.
The real problem is that SDL_atomic.c was built in thumb mode instead of ARM mode, which is required to use the mcr instruction on ARM platforms. Added a compiler error to catch this case so we don't generate code that does infinite recursion.
I also added a potentially better way to handle things on Linux ARM platforms, based on comments in the Chromium headers, which we can try out after 2.0.10 ships.
daniel.c.sinclair
Hi, this patch breaks dpad/hat input on my PS4 controller. The attached patch restores functionality. Calling SDL_PrivateJoystickHat() at the end of BSD_JoystickUpdate was setting the hat state to zero on every kind of input, instead of just the HUG_DPAD events.
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.
Braden Obrzut
https://hg.libsdl.org/SDL/file/7dc39b047055/CMakeLists.txt#l911
I believe the following should also be specified there:
set(SDL_VIDEO_OPENGL_ES 1)
set(SDL_VIDEO_RENDER_OGL_ES 1)
As it is now GLES1 support is missing when building for Android despite it linking to the library.
It causes the HIDAPI devices to always be opened on enumeration, which causes crashes in the Windows drivers when multiple applications are reading and writing at the same time. We can revisit this after 2.0.10 release.
The Nintendo USB GameCube Adapter has two USB connectors. Black for data
and grey for additional power for rumble. The Wii U and other software
require both cables to use rumble. The rumble is weaker without the
second USB cable. Other than that I don't know if there is any negative
side affects from using rumble with only one cable.
