This work was done by Jacob Lifshay and Mark Callow; I'm just merging it
into revision control.
--HG--
extra : rebase_source : cb3bb332146125366b5242c0d7444f44638733d9
extra : amend_source : c72ebb6d3a92efc3fdd085ce3b6d4b1d7f573cc9
Note that linking with AVFoundation is now required if you don't disable SDL_audio compilation on iOS and tvOS.
--HG--
rename : src/audio/coreaudio/SDL_coreaudio.c => src/audio/coreaudio/SDL_coreaudio.m
I think this was important for SDL 1.2 because some targets needed
special device memory for DMA buffers or locked memory buffers for use in
hardware interrupts or something, but since it just defines to SDL_malloc
and SDL_free now, I took it out for clarity's sake.
--HG--
extra : histedit_source : 57b48e44e65de9ce4e16604167db325df05bdf98%2C31d881e4d1b5eeba771f04bb43be0d23c3e605ce
Code signature can be added after build with the following command line:
codesign --force --sign 76BB5ACAC44CA5EFA5F879434D157B81DA842CFB SDL2.framework/Versions/A
Alex Szpakowski
SDL's Cocoa backend uses the CGDisplayMode API to get refresh rate information about a display mode, but CGDisplayModeGetRefreshRate will return 0 on most non-CRT monitors.
The only way I know of to get correct refresh rate information in OS X is via the CoreVideo DisplayLink API.
I have attached a patch which tries to use the CVDisplayLinkGetNominalOutputVideoRefreshPeriod function if CGDisplayModeGetRefreshRate fails, which fixes display mode refresh rate information on the monitors I tested.
The CVDisplayLink API requires linking with the CoreVideo framework, and the patch updates the various build files to do so.
Thomas Schatz
The dynamic library (extracted from SDL2-2.0.3.dmg and put in /Library/Frameworks/) references the __Block_copy symbol in /usr/lib/libSystem.B.dylib, which cannot be found:
dlopen(/Library/Frameworks/SDL2.framework/SDL2, 6): Symbol not found: __Block_copy
Referenced from: /Library/Frameworks/SDL2.framework/SDL2
Expected in: /usr/lib/libSystem.B.dylib
From what I could gather __Block_copy seems to be related to the blocks extension to the C programming language introduced by Apple since OSX-10.6 (see: http://thirdcog.eu/pwcblocks/). If this is indeed the case, I don't think the SDL2-2.0.3.dmg on the website is at all compatible with OSX-10.5 countrary to what is announced.
Alex Szpakowski
I actually made a mistake when creating the previous patch file... I forgot to include a crucial line which changed.
I've attached a new patch which just changes the line I forgot, since the other part has already been applied to the repository.
I tested this one by doing a clean rebuild of SDL, and it works with the new patch.
This uses a better mouse grab if you define SDL_MAC_NO_SANDBOX. This
mouse grab uses CGEventTapCreate, which you cannot access if you have
sandboxing enabled.
