SDL
SDL copied to clipboard
libsdl-org
[KMSDRM/ATOMIC] Bring back the ATOMIC KMSDRM backend.
Description
This brings back my own ATOMIC KMSDRM backend.
Existing Issue(s)
Allows proper fullscreen scaling using modern ATOMIC KMSDRM graphics infraestructure.
Build-tested only, no issues on my old setup. Attached patch to regenerate configure: configure-regenerate.txt
@sezero Thanks! Can you regenerate the configure after this is merged, please?
Maybe I can simply run autogen.sh and do another PR, but I am not sure...
Yes, go ahead and re-run autogen.sh, check to make sure configure only has the changes you expect, and then redo the PR.
I'm almost certainly missing context, but this PR confuses me. Is it just the same KMSDRM backend as before with the changes made in the past few weeks reverted? If so, why are there two backends for the same platform now? The discussion in #4417 sounded like the issues with recent commits were close to being resolved and the branch with fixes just needs more testing. Will this new backend be immediately deprecated once those fixes go in, or will it live on with its own set of missing features? What do I tell users to use?
It basically brings back the atomic KMSDRM backend that was removed due to hardware compatibility issues (SoCs with Panfrost GPUs doesn't support it properly to my knowledge).
What's the rationale for bringing it back after it was removed? It looks like it doesn't have feature parity with the current KMSDRM backend (for example it doesn't appear to support fullscreen mode switching). Is there a list of missing features which need to be implemented and tested, somewhere?
@slouken Configure file regenerated.
@slime73 I will gladly explain what ATOMIC KMSDRM backend is. First, there's legacy KMSDRM, which is the interface that has been used for more than a decade now to access the graphics hardware on GNU/Linux at low level, but it has some limitations by design. Then, there's the ATOMIC KMSDRM interface, which allows a better control over the graphic resources (you can change all the properties you want with a single atomic commit!)
Eventually, all "modern" hw should support the ATOMIC interface, as it's the future, but legacy KMSDRM is going to be supported for now anyway. All hardware around me (Intel graphics, AMDGPU, VC4/Raspberry Pi) supports ATOMIC nicely right now, too.
I have brought back this backend because the legacy KMSDRM does not look like it's being fixed anytime soon: the person who did those commits claims to be unable to reproduce the problems caused, so I believe things in that front won't be solved, and I certainly won't fix it so it's broken again and again. If I want to use the latest SDL2 git code, or develop something with SDL2 KMSDRM in mind, or just play Scummvm or Prince of Persia, I need something that works and I can trust it won't be broken while I don't look (good luck trying to mess with the ATOMIC interface, heh).
It's not a redundant backend. It's just a different backend for X-less SDL2 fun, using a different interface to the kernel graphics. It won't do any harm to currently available backends, and if you have any problem with your usercase and tell me what your usercase is, I will look into it.
About fullscreen modesetting, it seems to be supported. At least I recall it being supported when I did the backend last summer.
And what should you recommend to use? Well, KMSDRM is broken right now, so I wouldn't recommend it. Easy.
About fullscreen modesetting, it seems to be supported.
My apologies, I misread some code earlier.
I have brought back this backend because
Have the original reasons for removal been addressed in the new PR? What will happen on systems that were affected by compatibility issues?
the legacy KMSDRM does not look like it's being fixed anytime soon: the person who did those commits claims to be unable to reproduce the problems caused, so I believe things in that front won't be solved
You've been pushing this framing for a while but so far I haven't observed anything suggesting it's true. No doubt you, like me, can relate to differences in system and hardware configurations resulting in issues that can only be reproduced on certain setups. As per the comments in #4417 there are fixes being tested in a separate branch pending a merge request to upstream. Your most recent comment there referenced the wrong branch - maybe that's where some confusion on your end is coming from? I'm sure more testing of the actual fixes would be appreciated.
I need something that works and I can trust it won't be broken while I don't look (good luck trying to mess with the ATOMIC interface, heh).
I think it was mentioned by someone else to you a while ago but SDL is an open source contribution-friendly project. Your code, my code, and everyone else's code will be changed by other people in the future. Sometimes those changes will have bugs. And sometimes your code and my code will also have bugs that we don't run into ourselves, which other people might fix. This is the environment we enter when we contribute to this project, the two can't be separated.
I'm looking at what I believe was the removal commit b24494734b89c800d8a70fab9ff2c3d512ef4c40, and from what I can tell the atomic and legacy codepaths were in the same backend before the former's removal. If that's true, what's the reasoning for making them separate backends in this PR?
The atomic codepath didn't support AMD GPU systems with analog output setups (they do not work with Display Core enabled in the kernel driver) and certainly had very restricted OS support. Support was also restricted to GPUs supported by the amdgpu driver (the old radeon driver doesn't support atomic modesetting) when it came to AMD/ATI hardware. The only other OS that works with it is FreeBSD.
Here's the reference issue @slime73, https://github.com/libsdl-org/SDL/issues/3920, that led to the atomic backend being removed in the first place. And no, the atomic and legacy codepaths was never the same; more like the backend was rewritten for atomic modesetting.
It sems that @inolen has finally fixed the KMSDRM backend scaling via https://github.com/inolen/SDL/commit/9bbf0bbf072e2203a330d1dc5d51e9970157a222
All software I test works well again with the default KMSDRM backend.
I admit I have been hard on Inolen about this because I didn't see him fixing the backend after his commits, but he has finally done so and I am truly sorry about my doubts and insistence.
I would love to see an atomic KMS/DRM backend, but from what I can see, this one has the same fatal flaw as the regular KMS/DRM backend: it requires a GPU.
The KMS/DRM video driver should only care about presentation of the rendered frames. Then how these frames are rendered is up to the renderer driver.
Just saying. Anyway the backend isn't likely to work on framebuffer-only systems without SimpleDRM.
I am not trying to run SDL2 on the framebuffer. I want to run SDL2 on KMS/DRM, on a system without a GPU.
You still need SimpleDRM for that. And right now the KMSDRM framebuffer support is handled by higher level code which still needs a GPU to function and still hasn't been implemented in the backend itself so you will have to wait for that if that's what you mean.
No, I do not need SimpleDRM. I do have a KMS/DRM kernel driver that I wrote myself and which is upstream (ingenic-drm), so I know what I can and can't do.
I have a KMS/DRM video driver for SDL1 which does not require a GPU, so there's no reason why SDL2 couldn't do that too.
Ah I misunderstood then.
Well the rest of the post I made after the first sentence still applies.
FYI, @icculus is working on merging the atomic and non-atomic KMSDRM backends. At that point, @pcercuei, it would be great if you want to update it so it doesn't require a GPU.
No, I do not need SimpleDRM. I do have a KMS/DRM kernel driver that I wrote myself and which is upstream (ingenic-drm), so I know what I can and can't do.
I have a KMS/DRM video driver for SDL1 which does not require a GPU, so there's no reason why SDL2 couldn't do that too.
I have the same situation (KMS/DRM video driver, hardware that can only do 2D operations). It seems like doing any scaling etc in the kernel is a no-no. The compositor is meant to handle it but this hardware doesn't really have enough memory to waste on that when all it really wants is a scaled/rotated framebuffer.
I would like to have this working without a GPU and maybe use the 2D hardware to help out so I'll take a look..
So I see this just closed, so I'll say real fast: I had this mostly-merged into a single codebase at one point, and then a million unrelated things pulled my attention from it, so it never got done.
The idea was to decide if the system had the capabilities to use the atomic version, and if so, use those features, but since the two backends shared most of their code, it could just simply not use the atomic features on unsupported systems, but we would have one codebase and no code duplication.
We have open issues that would benefit from the atomic work, afaik, so we still want it. I don't know how the state of kmsdrm has changed in the past years; maybe there are newer/better kernel interfaces, etc?
@vanfanel, I'm very busy right now, but sometime soon let's talk about this and figure out what SDL should be doing in modern times.
@slouken This closed because I deleted my fork. I didn't know you still had interest on this... sorry, really. Is the code lost, or do you happen to have a version of it? It was working perfectly well if I am not mistaken, but after 5 years without being merged or touched, I though it made no sense to keep it.
Ah I see the code is still in the commits. Well, then nothing was lost I guess.