This is an attempt to restore the ATOMIC support to the kmsdrm backend.
This was done by merging @vanfanel's final atomic work from SDL2 into the latest from SDL3. This wasn't a trivial effort, as a lot had changed in both kmsdrm specifically and SDL3 generally, so I expect there are issues to resolve in this PR still. It's at the "it compiles" stage; I'll be trying it on a Raspberry Pi 5 soon and fixing obvious issues that pop up.
There isn't a separate atomic and non-atomic version of the kmsdrm backend in this PR; it's now one codebase that will decide to use the atomic features if it can set the DRM_CLIENT_CAP_ATOMIC and DRM_CLIENT_CAP_UNIVERSAL_PLANES client capabilities. If not, it'll use the "legacy" codepaths. Before merging, we should probably add an SDL hint to let people turn off atomic support even if the system would otherwise support it, as a failsafe.
Note a few FIXMEs in this PR; these were pieces I couldn't decide how to correctly adapt, but I made a reasonable attempt anyhow.
This is an attempt to restore the ATOMIC support to the kmsdrm backend.
This was done by merging @vanfanel's final atomic work from SDL2 into the latest from SDL3. This wasn't a trivial effort, as a lot had changed in both kmsdrm specifically and SDL3 generally, so I expect there are issues to resolve in this PR still. It's at the "it compiles" stage; I'll be trying it on a Raspberry Pi 5 soon and fixing obvious issues that pop up.
There isn't a separate atomic and non-atomic version of the kmsdrm backend in this PR; it's now one codebase that will decide to use the atomic features if it can set the
DRM_CLIENT_CAP_ATOMICandDRM_CLIENT_CAP_UNIVERSAL_PLANESclient capabilities. If not, it'll use the "legacy" codepaths. Before merging, we should probably add an SDL hint to let people turn off atomic support even if the system would otherwise support it, as a failsafe.Note a few FIXMEs in this PR; these were pieces I couldn't decide how to correctly adapt, but I made a reasonable attempt anyhow.
Reference Issue #4984.