kmsdrm: Restore atomic support. #11511
Draft
+1,085
−95
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
andDRM_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.
Reference Issue #4984.