Caleb Cornett
Unlike iOS and macOS, tvOS does not have any persistent local storage. In fact, the ApplicationSupport directory pointed to by the existing Cocoa GetPrefPath() throws an error whenever any attempt is made to access it. To get any local storage on an Apple TV, our only option is to use a temporary cache directory.
This patch changes the tvOS PrefPath to this cache directory and also logs a critical warning that this if developers want their save data to persist across game sessions, they must use some form of iCloud storage.
superfury
I notice that, somehow, when locking the mouse into place(using SDL_SetRelativeMouseMode), somehow at least the movement information gets through to both mouse movement and touch movement events?
My app handles both, so when moving a touched finger accross the app(using RDP from an Android device) I see the mouse moving inside the app when it shouldn't(meaning that the touch movement is ignored properly by the app(press-location dependant) but the mouse movement is still performed due to the mouse movement events)?
alexrice999
I have a knock off wired xbox 360 controller called afterglow for xbox 360 controller. Despite there being a few afterglow controllers in the controller mapping the guid of my controller seems to map to Generic Xbox pad. This binding is as follows:
```
"030000006f0e00001304000000010000,Generic X-Box pad,a:b0,b:b1,back:b6,dpdown:h0.4,dpleft:h0.8,dpright:h0.2,dpup:h0.1,guide:b8,leftshoulder:b4,leftstick:a0,lefttrigger:a2,leftx:a0,lefty:a1,rightshoulder:b5,rightstick:a3,righttrigger:a5,rightx:a3,righty:a4,start:b7,x:b2,y:b3,",
```
When running openmw I have a strange issue that the joysticks work for up and down movements but not for side to side. I managed to track this down to the side to side events being classified as joystick events instead of gamepad events.
I believe this is due to both "leftstick" and "leftx" being bound to "a0" which seems odd to me. If I change openmw's mappings to remove these the controller works as expected. I was hoping someone who knows a lot more than me (as I have only been exploring this today trying to fix my controller) would know what is happening
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.
