kmsdrm: Restore atomic support.

[icculus]

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.

Reference Issue #4984.

[Kontrabant]

Based on the preceding comment:

Also, DON'T remove the asserts: if a fence-related call fails, it's better that program exits immediately, or we could leave KMS waiting for a failed/missing fence forever.

this should be SDL_assert_always(), or the asserts will be compiled out in release builds.

Suggested change

	SDL_assert(dispdata->gpu_fence);
	SDL_assert_always(dispdata->gpu_fence);

[Kontrabant]

Same here:

Suggested change

	SDL_assert(dispdata->kms_in_fence_fd != -1);
	SDL_assert_always(dispdata->kms_in_fence_fd != -1);

[Kontrabant]

One more time:

Suggested change

	SDL_assert(dispdata->kms_fence);
	SDL_assert_always(dispdata->kms_fence);

[icculus]

I'm not sure we should get into the business of promising to crash the entire process if something goes wrong, by adding assert_always to this.

[slouken]

I'm not sure we should get into the business of promising to crash the entire process if something goes wrong, by adding assert_always to this.

Agreed. Gamers get very unhappy if they lose several hours progress without getting a chance to save. :)

[icculus]

Tried this out on a raspberry pi, and it mostly works. Here's the current TODO list:

• It crashes because it does this in several places...

  SDL_DisplayData *dispdata = (SDL_DisplayData *)SDL_GetDisplayDriverData(0);

  ...and this results in a NULL dispdata. I assume this function changed from an index to an instance ID, and hardcoding a 1 instead of a zero makes this work, since that's the instance ID that I've got. But I assume this also comes from a time where you'd only have one display in the kmsdrm backend, so this probably needs a bit of a refactor in any case to not have a hardcoded value.

• Running things like testsprite and testaudio are only rendering a tiny window to maybe a quarter of the screen, in the top right. Something failed to scale? Something failed to change resolutions? I'm not sure. This definitely takes the whole television screen in main, so it's a regression.

• The mouse cursor on my 1080p TV is microscopic. Might be that it was intended to scale and didn't?

These are obviously important issues to resolve, but I was surprised that it was otherwise rendering stuff on the (almost) first attempt. More work to be done still, though.

[slouken]

Tried this out on a raspberry pi, and it mostly works. Here's the current TODO list:

• It crashes because it does this in several places...

  SDL_DisplayData *dispdata = (SDL_DisplayData *)SDL_GetDisplayDriverData(0);

As you noted, we probably want to get the correct display data. If we have a window, you can use SDL_GetDisplayDriverDataForWindow(). Otherwise if you really want the first display, you can use SDL_GetDisplayDriverData(SDL_GetPrimaryDisplay()).

[ccawley2011]

• Running things like testsprite and testaudio are only rendering a tiny window to maybe a quarter of the screen, in the top right. Something failed to scale? Something failed to change resolutions? I'm not sure. This definitely takes the whole television screen in main, so it's a regression.

Setting VIDEO_DEVICE_CAPS_FULLSCREEN_ONLY for the kmsdrm backend might help here, but that does assume that it doesn't need to support multiple windows on a single display.