This is my port of SDL3 to HarmonyOS/OpenHarmony. It has been tested on real
hardware from Huawei, and commercial games are being prepped to ship with it
already.
There is _heavy_ documentation in docs/README-harmonyos.md, including how to
set up a development environment and project, build, and debug, for the
completely uninitiated.
This work was sponsored by Outfit7: https://outfit7.com/Fixes#9837.
Open files and directories as read-only, as the fd is only used as proof of access by the portal, and a mismatch between fd write permissions and the portal write parameter will cause the fd to be rejected.
This makes the Vulkan code match the D3D/Metal/GPU renderers, and avoids bugs and unsupported format/sampler combinations on various vendor's drivers (including NVIDIA!)
The buffer parameters aren't necessarily correct, due to bugs or missing metadata, so we'll use the texture colorspace as a guide for YUV conversion unless it's specifically set to SDL_COLORSPACE_UNKNOWN.
XI_DeviceChanged should trigger an update of both relative and scroll info on the device, as anything may have changed. Combine the scroll and relative valuators into one device info struct, and update them together.
This is a better fix for https://github.com/libsdl-org/SDL/issues/16227. It also allows you to create a whole set of indexed textures from surfaces that share a single palette and then modify that palette to change all textures.
Validation Error: [ VUID-VkImageMemoryBarrier-oldLayout-01212 ] | MessageID = 0xff795e16
vkCmdPipelineBarrier(): pImageMemoryBarriers[0].newLayout (VK_IMAGE_LAYOUT_TRANSFER_SRC_OPTIMAL) is not compatible with VkImage 0x2160000000216 usage flags VK_IMAGE_USAGE_2_TRANSFER_DST_BIT_KHR|VK_IMAGE_USAGE_2_COLOR_ATTACHMENT_BIT_KHR.
The Vulkan spec states: If layouts are not ignored, oldLayout or newLayout is VK_IMAGE_LAYOUT_TRANSFER_SRC_OPTIMAL then image must have been created with the VK_IMAGE_USAGE_TRANSFER_SRC_BIT usage flag set (https://docs.vulkan.org/spec/latest/chapters/synchronization.html#VUID-VkImageMemoryBarrier-oldLayout-01212)
The use case for this is 2D render target overlays on HDR10 output. In this case we've already done the conversion to the output colorspace and we just want to get the pixels on the screen as fast as possible. Video frames still need YUV conversion, so they shouldn't go through this output path.
This doesn't actually save much code size and complicates the drivers a fair bit.
Upside is that you'll now be able to build SDL without software YUV support and still be able to play videos with hardware acceleration enabled.
The window may not have keyboard focus when using remote control tools, so drop the keyboard focus requirement. Tested not to regress clickthrough suppression.
