Sun, 01 Mar 2020 17:53:30 -0800We already have a hidapi implementation for Windows, we don't need libusb
Sam Lantinga [Sun, 01 Mar 2020 17:53:30 -0800] rev 13565
We already have a hidapi implementation for Windows, we don't need libusb

Sun, 01 Mar 2020 14:58:16 -0800Updated version to 2.0.12 for release candidate build
Sam Lantinga [Sun, 01 Mar 2020 14:58:16 -0800] rev 13564
Updated version to 2.0.12 for release candidate build

Sun, 01 Mar 2020 14:52:49 -0800Fixed bug 4996 - Mac: XBoxOne Bluetooth rumble isn't working
Sam Lantinga [Sun, 01 Mar 2020 14:52:49 -0800] rev 13563
Fixed bug 4996 - Mac: XBoxOne Bluetooth rumble isn't working

rofferom

I have an annoying issue on MacOS about XBoxOne Bluetooth rumble (Vendor: 0x045e, Product: 0x02fd).

When 360controller is installed, rumble is working correctly. However, Bluetooth rumble isn't working at all, with or without 360controller installed (although it is working with Chrome + https://html5gamepad.com).

I looked at the code, and it seems that XBox controllers are managed in MacOS in this file: SDL_hidapi_xbox360.c. The XBoxOne file is disabled for MacOS in SDL_hidjoystick_c.h.

The function HIDAPI_DriverXbox360_Rumble() is called correctly, and hid_write() returns no error.

I have tried a stupid test. I took the rumble packet from 360controller: https://github.com/360Controller/360Controller/blob/ec4e88eb2d2535e9b32561c702f42fb22b0a7f99/XBOBTFF/FFDriver.cpp#L620. With the patch I have attached, I manage to have rumble working on Bluetooth (with some stupid vibration level, but it proves it can if the packet is changed).

But it breaks the USB rumble with 360controller. A comment in the function makes an explicit reference to 360controller, I think that's why I have broken this specific usecase.

I don't know what is the correct way to fix this, but it seems that the current implementation has a missing case for Bluetooth support.


Note that I also tested master this morning, and I have another issue:
if (!device->ffservice) {
return SDL_Unsupported();
}

test fails in DARWIN_JoystickRumble(). This test has been done quickly, I'm not totaly confident about its accuracy.

Sun, 01 Mar 2020 13:01:53 -0800mac: Fix gamepad detection
Romain Roffé [Sun, 01 Mar 2020 13:01:53 -0800] rev 13562
mac: Fix gamepad detection

Sun, 01 Mar 2020 13:00:50 -0800Fixed whitespace
Sam Lantinga [Sun, 01 Mar 2020 13:00:50 -0800] rev 13561
Fixed whitespace

Sun, 01 Mar 2020 12:58:50 -0800Fixed bug 4369 - Going fullscreen with green knob in MacOS freezes app for 15 seconds.
Sam Lantinga [Sun, 01 Mar 2020 12:58:50 -0800] rev 13560
Fixed bug 4369 - Going fullscreen with green knob in MacOS freezes app for 15 seconds.


Elmar

creating a fullscreen window with SDL_CreateWindow(..SDL_WINDOW_FULLSCREEN_DESKTOP..) in MacOS works fine, except if it was triggered by the user with the green knob in the top left window title bar.

Then "something" is different, and SDL_CreateWindow hangs for 15-20 seconds (tested in MacOS 10.13 and 10.14).

Responsible for the hang is this code in SDL_cocoawindow.m - Cocoa_SetWindowFullscreenSpace:

const int maxattempts = 3;
int attempt = 0;
while (++attempt <= maxattempts) {
/* Wait for the transition to complete, so application changes
take effect properly (e.g. setting the window size, etc.)
*/
const int limit = 10000;
int count = 0;
while ([data->listener isInFullscreenSpaceTransition]) {
if ( ++count == limit ) {
/* Uh oh, transition isn't completing. Should we assert? */
break;
}
SDL_Delay(1);
SDL_PumpEvents();
}
if ([data->listener isInFullscreenSpace] == (state ? YES : NO))
break;
/* Try again, the last attempt was interrupted by user gestures */
if (![data->listener setFullscreenSpace:(state ? YES : NO)])
break; /* ??? */
}

One trivial workaround is to change 'const int limit = 10000' to 500. Then the freeze is so short that it doesn't look like a freeze to the user.

Looking further into the problem, I observed that the function Cocoa_SetWindowFullscreenSpace recursively calls itself via some ObjectiveC messages. I managed to extract a callstack for this (copied below): Note how Cocoa_SetWindowFullscreenSpace in stack line 22 calls SDL_PumpEvents, which eventually arrives at SDL_SendWindowEvent, which calls SDL_UpdateFullscreenMode (stack line 0), which then calls Cocoa_SetWindowFullscreenSpace again (not shown). This recursive second call is the one that hangs.

Another "solution" that worked for me was to add a flag to SDL_Window that is set in Cocoa_SetWindowFullscreenSpace and causes this function to return immediately if called from itself.

Obviously, this is also an ugly hack, but I don't have enough time to dive into this crazy Cocoa/ObjectiveC business deep enough to find a proper solution. But hopefully it's easy for one of the experts around.

Note that there is a "failure to go fullscreen"-message involved, maybe using the green knob causes this failure at first.

I can unfortunately not provide a minimum example.

Best regards,
Elmar

0 com.yasara.View 0x00000001007495af SDL_UpdateFullscreenMode + 207
1 com.yasara.View 0x00000001006e2591 SDL_SendWindowEvent + 401
2 com.yasara.View 0x0000000100775a72 -[Cocoa_WindowListener windowDidResize:] + 370
3 com.yasara.View 0x0000000100776550 -[Cocoa_WindowListener windowDidExitFullScreen:] + 512
4 com.apple.AppKit 0x00007fff3180a2a4 -[_NSWindowEnterFullScreenTransitionController failedToEnterFullScreen] + 692
5 com.apple.AppKit 0x00007fff31c59737 -[_NSEnterFullScreenTransitionController _doFailedToEnterFullScreen] + 349
6 com.apple.AppKit 0x00007fff3172aa53 __NSFullScreenDockConnectionSendEnterForSpace_block_invoke + 135
7 libxpc.dylib 0x00007fff6114b9b1 _xpc_connection_reply_callout + 36
8 libxpc.dylib 0x00007fff6114b938 _xpc_connection_call_reply_async + 82
9 libdispatch.dylib 0x00007fff60ec7e39 _dispatch_client_callout3 + 8
10 libdispatch.dylib 0x00007fff60ede3b0 _dispatch_mach_msg_async_reply_invoke + 322
11 libdispatch.dylib 0x00007fff60ed2e25 _dispatch_main_queue_callback_4CF + 807
12 com.apple.CoreFoundation 0x00007fff33d39e8b __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 9
13 com.apple.CoreFoundation 0x00007fff33d3959a __CFRunLoopRun + 2335
14 com.apple.CoreFoundation 0x00007fff33d38a28 CFRunLoopRunSpecific + 463
15 com.apple.HIToolbox 0x00007fff32fd1b35 RunCurrentEventLoopInMode + 293
16 com.apple.HIToolbox 0x00007fff32fd1774 ReceiveNextEventCommon + 371
17 com.apple.HIToolbox 0x00007fff32fd15e8 _BlockUntilNextEventMatchingListInModeWithFilter + 64
18 com.apple.AppKit 0x00007fff3128deb7 _DPSNextEvent + 997
19 com.apple.AppKit 0x00007fff3128cc56 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1362
20 com.yasara.View 0x000000010076fab2 Cocoa_PumpEvents + 290
21 com.yasara.View 0x00000001006dd1c7 SDL_PumpEvents_REAL + 23
22 com.yasara.View 0x00000001007795cf Cocoa_SetWindowFullscreenSpace + 223
23 com.yasara.View 0x000000010074970b SDL_UpdateFullscreenMode + 555
24 com.yasara.View 0x00000001006e2476 SDL_SendWindowEvent + 118
25 com.yasara.View 0x0000000100774ff7 -[Cocoa_WindowListener resumeVisibleObservation] + 135
26 com.yasara.View 0x000000010077664c Cocoa_ShowWindow + 188
27 com.yasara.View 0x0000000100749492 SDL_FinishWindowCreation + 546
28 com.yasara.View 0x0000000100748da5 SDL_CreateWindow_REAL + 1573
29 com.yasara.View 0x000000010010d9b1 vga_setvideomode + 1347
30 com.yasara.View 0x00000001003f0d46 mod_initscreen + 2614
31 com.yasara.View 0x00000001003f344b mod_reinitscreen + 460
32 com.yasara.View 0x00000001003f370d mod_resizescreen + 383
33 com.yasara.View 0x0000000100418e39 mod_main + 815
34 com.yasara.View 0x000000010029ca5d main2 + 5766
35 com.yasara.View 0x000000010011d1b7 main.main_cpuok + 19

Sun, 01 Mar 2020 12:50:42 -0800Fixed bug 4992 - UWP/WinRT does not set thread priority when using SDL_SetThreadPriority
Sam Lantinga [Sun, 01 Mar 2020 12:50:42 -0800] rev 13559
Fixed bug 4992 - UWP/WinRT does not set thread priority when using SDL_SetThreadPriority

Ethan Lee

Attached is a diff that I used to get SetThreadPriority working locally. I still have no idea what the minimum SDK version is since Microsoft never documented it, but it's worth pointing out that they're much more aggressive about using the latest VS and UWP SDK anyway (for example, an updated Xbox is no longer compatible with VS2017, and updates are required to have a network connection of any kind).

Thu, 27 Feb 2020 13:53:32 -0800Fixed trying to handle the HORI Wireless Switch Pad when connected via USB
Sam Lantinga [Thu, 27 Feb 2020 13:53:32 -0800] rev 13558
Fixed trying to handle the HORI Wireless Switch Pad when connected via USB

Thu, 27 Feb 2020 09:33:32 -0800Xbox One controller rumble doesn't need synchronization if you use a packet counter of 0
Sam Lantinga [Thu, 27 Feb 2020 09:33:32 -0800] rev 13557
Xbox One controller rumble doesn't need synchronization if you use a packet counter of 0

Thu, 27 Feb 2020 09:32:03 -0800Temporarily disabled NEON optimizations added for bug 4365
Sam Lantinga [Thu, 27 Feb 2020 09:32:03 -0800] rev 13556
Temporarily disabled NEON optimizations added for bug 4365
The ABGR to ARGB blit results in an empty surface, this needs to be looked at.