To use, set the following CMake variables when running CMake's configuration stage:
- CMAKE_SYSTEM_NAME=tvOS
- CMAKE_OSX_SYSROOT=<SDK> (examples: appletvos, appletvsimulator, appletvos12.4, /full/path/to/AppleTVOS.sdk, etc.)
- CMAKE_OSX_ARCHITECTURES=<semicolon-separated list of CPU architectures> (example: "arm64;x86_64")
When using a recent version of CMake (3.14+), this should make it possible to:
- build SDL for iOS, both static and dynamic
- build SDL test apps (as iOS .app bundles)
- generate a working SDL_config.h for iOS (using SDL_config.h.cmake as a basis)
To use, set the following CMake variables when running CMake's configuration stage:
- CMAKE_SYSTEM_NAME=iOS
- CMAKE_OSX_SYSROOT=<SDK> (examples: iphoneos, iphonesimulator, iphoneos12.4, /full/path/to/iPhoneOS.sdk, etc.)
- CMAKE_OSX_ARCHITECTURES=<semicolon-separated list of CPU architectures> (example: "arm64;armv7s")
Examples:
- for Simulator, using the latest, installed SDK:
cmake path/to/SDL -DCMAKE_SYSTEM_NAME=iOS -DCMAKE_OSX_SYSROOT=iphonesimulator -DCMAKE_OSX_ARCHITECTURES=x86_64
- for Device, using the latest, installed SDK, 64-bit only
cmake path/to/SDL -DCMAKE_SYSTEM_NAME=iOS -DCMAKE_OSX_SYSROOT=iphoneos -DCMAKE_OSX_ARCHITECTURES=arm64
- for Device, using the latest, installed SDK, mixed 32/64 bit
cmake path/to/SDL -DCMAKE_SYSTEM_NAME=iOS -DCMAKE_OSX_SYSROOT=iphoneos -DCMAKE_OSX_ARCHITECTURES="arm64;armv7s"
- for Device, using a specific SDK revision (iOS 12.4, in this example):
cmake path/to/SDL -DCMAKE_SYSTEM_NAME=iOS -DCMAKE_OSX_SYSROOT=iphoneos12.4 -DCMAKE_OSX_ARCHITECTURES=arm64
- for Simulator, using the latest, installed SDK, and building SDL test apps (as .app bundles):
cmake path/to/SDL -DSDL_TEST=1 -DCMAKE_SYSTEM_NAME=iOS -DCMAKE_OSX_SYSROOT=iphonesimulator -DCMAKE_OSX_ARCHITECTURES=x86_64
Background:
Chengdu Haiguang IC Design Co., Ltd (Hygon) is a Joint Venture
between AMD and Haiguang Information Technology Co.,Ltd., aims at
providing high performance x86 processor for China server market.
Its first generation processor codename is Dhyana, which
originates from AMD technology and shares most of the
architecture with AMD's family 17h, but with different CPU Vendor
ID("HygonGenuine")/Family series number(Family 18h).
Related Hygon kernel patch can be found on:
http://lkml.kernel.org/r/5ce86123a7b9dad925ac583d88d2f921040e859b.1538583282.git.puwen@hygon.cn
Best regards.
The LE transformation for vec_perm has an implicit assumption that the
permutation is being used to reorder vector elements (in this case 4-byte
integer word elements), not to reorder bytes within those elements. Although
this is legal behavior, it is not anticipated by the transformation performed
by the compilers.
This causes pygame-1.9.1 test failure on PPC64LE because blitted pixmaps are
corrupted there due to how SDL uses vec_perm().
From RedHat / Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1392465
Original patch was provided by: Menanteau Guy <menantea@linux.vnet.ibm.com>
If KMSDRM_drmModeSetCrtc is called when the swap interval is
set to 0, the driver behaves as though vertical sync is engaged by
limiting framerate to the refresh rate, but performance is much worse
than with vertical sync enabled.
Resolve this issue by ensuring that the Crtc is only set up once,
and KMSDRM_drmModePageFlip is called, albeit without any followup
queueing or waiting for flips.
Daniel Drake
A long time ago, it was possible to play neverball on Linux using the accelerometer found in HP laptops.
The kernel exposes the accelerometer as a joystick (/dev/input/jsX) as well as an evdev device (/dev/input/eventX). I guess it worked fine when SDL was using the js interface, but then stopped working here: http://hg.libsdl.org/SDL/rev/fdaeea9e7567
Looking at current code which uses udev to discover joysticks, it looks for the udev tag ID_INPUT_JOYSTICK.
However udev's internal input_id logic specifically tags accelerometers as ID_INPUT_ACCELEROMETER and nothing else.
This looks like a good fit for SDL_HINT_ACCELEROMETER_AS_JOYSTICK.
Ozkan Sezer
As for the issue: This bmp reports bpp=0, therefore SDL_CalculatePitch()
returns pitch==0, which is then fed to SDL_malloc() (which is malloc())
and malloc(0) returns _something_ which is not NULL but not someting
that we expect.. Then testsprite.c:LoadSprite() accesses the pixels
as *(Uint8*)pixels which valrind reports as:
==15533== Invalid read of size 1
==15533== at 0x8048C08: LoadSprite (testsprite.c:45)
==15533== by 0x80492FC: main (testsprite.c:224)
==15533== Address 0x449e588 is 0 bytes after a block of size 0 alloc'd
==15533== at 0x40072B2: malloc (vg_replace_malloc.c:270)
==15533== by 0x4045719: SDL_CreateRGBSurface (SDL_surface.c:126)
==15533== by 0x40403C1: SDL_LoadBMP_RW (SDL_bmp.c:237)
==15533== by 0x8048BB2: LoadSprite (testsprite.c:36)
==15533== by 0x80492FC: main (testsprite.c:224)
Besides, valrind also reports this:
==15533== Conditional jump or move depends on uninitialised value(s)
==15533== at 0x40403F3: SDL_LoadBMP_RW (SDL_bmp.c:247)
==15533== by 0x8048BB2: LoadSprite (testsprite.c:36)
==15533== by 0x80492FC: main (testsprite.c:224)
Easy/quick solution would be early-rejecting a bmp with 0 bpp from SDL_bmp.c:SDL_LoadBMP_RW()
David Ludwig
Jinke Fan
Ozkan Sezer
Sam Lantinga
Sylvain Becker
Conn O'Griofa
Ryan C. Gordon
Alex Szpakowski