Holger Schemel
Summary: This patch adds support for key events for the "rewind" and "fast forward" media keys on the Amazon Fire TV remote control.
How to reproduce the problem: Run Android build of SDL2 application on the Amazon Fire TV (tested with "stick" version) and log key events.
Expected behaviour: Every key pressed on the Fire TV remote control should result in a corresponding key event (pressed/released).
Observed behaviour: Of the bottom row of buttons on the Fire TV remote control, only the "play/pause" (middle) button generates a key event, while the "rewind" (left) and "fast forward" (right) buttons to not generate any event at all.
The attached patch adds support for these two missing buttons/keys.
Note 1: Some missing definitions were added for the already existing key codes SDL_SCANCODE_APP1 and SDL_SCANCODE_APP2 (to keep up the correct order of enumerations / array positions when adding the two new key codes).
Note 2: Definitions in "scancodes_linux.h" and "scancodes_xfree86.h" (to also add support for these keys on other platforms) were added without testing. However, I was unable to find corresponding definitions for these two media keys for Windows and Mac OS X.
Note 3: I have also updated the (broken) link to the USB usage page standard PDF document (comment in "include/SDL_scancode.h").
kdrakehp
The attached patch adds capture support to the sndio backend.
The patch also allows the `OpenDevice' function to accept arbitrary device names.
Bogomancer
On X11, windows created using the shaped window API appear distorted unless the width of the shape surface is divisible by 8.
Steps to reproduce:
1) Use your favorite image editor to resize one of the images in test/shapes/ to a width that's not a multiple of 8.
2) Compile and run test/testshape.c on the image you edited.
3) The shaped window will appear twisted and distorted.
It appears the bug was not caught sooner because all the test images are either 640 or 256 pixels wide.
I tracked down the bug to SDL_CalculateShapeBitmap() in SDL_shape.c. The shape surface is reduced to a 1-bit-per-pixel mask, but the original code doesn't take into account that X11 apparently wants each scanline to begin on a new byte.
Juha Niemimäki
Fix for PTHREAD_MUTEX_RECURSIVE_NP check and restoring the original flags
Two fixes proposed:
1) Looks like there is a copy-paste issue regarding PTHREAD_MUTEX_RECURSIVE_NP check.
2) Compiler flag restoration doesn't look symmetrical regarding if/endif blocks. Moved to an outer block (if PTHREADS).
Ozkan Sezer
(In reply to Ryan C. Gordon from comment #9)
> I've put this patch in as https://hg.libsdl.org/SDL/rev/117d4ce1390e ...can
> you verify this works on the latest MinGW?
>
> Thanks,
> --ryan.
This patch is wrong: the structure in question has nothing to do with any
gcc version in use. I suggest reverting this adding a conigury check for
it, instead. Something like the following should do it: (configure needs
regenerating.)
Mark Callow
SDL_ShowMessageBox calls SDL_CaptureMouse which, in the UIKit driver, raises a “That operation is not supported” error, overwriting the SDL error that an application may be trying to report.
This is because UIKit SDL_CaptureMouse returns SDL_Unsupported() which ends up calling SDL_SetError() which has the following code:
/* If we are in debug mode, print out an error message */
SDL_LogDebug(SDL_LOG_CATEGORY_ERROR, "%s", SDL_GetError());
The SDL_GetError call here overwrites the static buffer…..
Although an application can avoid this by using SDL_GetErrorMsg(char* errstr, int maxlen) to avoid the static buffer, SDL should be fixed.
The fix is simple. In SDL_SetError change
SDL_LogDebug(SDL_LOG_CATEGORY_ERROR, "%s", SDL_GetError());
to
SDL_LogDebug(SDL_LOG_CATEGORY_ERROR, "%s", error);
where error is the pointer to the buffer where it assembled the message.
Amruth Raj
- My app runs in full screen to play video(I use SDL_WINDOW_FULLSCREEN_DESKTOP)
- Cmd-tab to go out of full screen to another app
- Cmd-tab again to get back to my app
- Press left mouse button at one of the edges of the screen, don't release yet.
After this point the main thread is stuck until I release the left mouse button and hence video rendering doesn't happen anymore.
On debugging more, I see that thread 0 is stuck as shown below with sendEvent processing left mouse down. It comes out only after it receives a left mouse up. There are some frames below which show NSWindowResizing, but my window flag doesn't have SDL_WINDOW_RESIZABLE set.
Thread 0:: CrBrowserMain Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x00007fffbe13d34a mach_msg_trap + 10
1 libsystem_kernel.dylib 0x00007fffbe13c797 mach_msg + 55
2 com.apple.CoreFoundation 0x00007fffa889d434 __CFRunLoopServiceMachPort + 212
3 com.apple.CoreFoundation 0x00007fffa889c8c1 __CFRunLoopRun + 1361
4 com.apple.CoreFoundation 0x00007fffa889c114 CFRunLoopRunSpecific + 420
5 com.apple.HIToolbox 0x00007fffa7dfdebc RunCurrentEventLoopInMode + 240
6 com.apple.HIToolbox 0x00007fffa7dfdcf1 ReceiveNextEventCommon + 432
7 com.apple.HIToolbox 0x00007fffa7dfdb26 _BlockUntilNextEventMatchingListInModeWithFilter + 71
8 com.apple.AppKit 0x00007fffa6396a54 _DPSNextEvent + 1120
9 com.apple.AppKit 0x00007fffa6b127ee -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 2796
10 com.apple.AppKit 0x00007fffa66f568d +[NSWindow(NSWindowResizing) _mouseHysteresisCheck:withExpiration:andDistance:finalMouseLocation:] + 525
11 com.apple.AppKit 0x00007fffa65eedb5 -[NSWindow(NSWindowResizing) _hitTestWithHysteresisCheck:forEvent:allowWindowDragging:] + 394
12 com.apple.AppKit 0x00007fffa6c8f0db -[NSWindow(NSEventRouting) _handleMouseDownEvent:isDelayedEvent:] + 1873
13 com.apple.AppKit 0x00007fffa6c8ca6c -[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] + 1942
14 com.apple.AppKit 0x00007fffa6c8bf0a -[NSWindow(NSEventRouting) sendEvent:] + 541
15 org.libsdl.SDL2 0x000000010d46d74a -[SDLWindow sendEvent:] + 90
16 com.apple.AppKit 0x00007fffa6b10681 -[NSApplication(NSEvent) sendEvent:] + 1145
17 org.libsdl.SDL2 0x000000010d46532b -[SDLApplication sendEvent:] + 139
18 org.libsdl.SDL2 0x000000010d466b2f Cocoa_PumpEvents + 495
19 org.libsdl.SDL2 0x000000010d44c1d5 SDL_PumpEvents_REAL + 53
20 org.libsdl.SDL2 0x000000010d44c2f5 SDL_WaitEventTimeout_REAL + 53
21 org.libsdl.SDL2 0x000000010d44c2b7 SDL_PollEvent_REAL + 23
22 org.libsdl.SDL2 0x000000010d51bb24 SDL_PollEvent + 36
23 libTest.dylib 0x000000010cf3e0e8 SDLEventProcessor::processEvents(int) + 568
24 Test 0x000000010cde6bba BrowserApp::RunAppMessageLoop(BAInstData*, CefStringBase, CefStringBase) + 810
25 Test 0x000000010ce04bbc main + 17980
26 libdyld.dylib 0x00007fffbe016235 start + 1
I further noticed that while entering full screen in SDL_cocoawindow.m NSResizableWindowMask is set. If I clear it inside windowDidEnterFullScreen, then, the issue doesn't repro.
This is discussed at https://discourse.libsdl.org/t/main-thread-gets-stuck-on-left-mouse-down/22753/3 and thanks to Eric for the pointers.
The Xlib documentation demands that 32-bit values here be passed in a long,
even when long itself isn't a 32-bit value. Otherwise libx11 might read
memory incorrectly.
Fixes Bugzilla #3692.
