SDL
SDL copied to clipboard
libsdl-org
Platform review
Review the set of supported platforms. Are there any that we should remove due to lack of active maintainer?
Platforms:
- [x] NaCl
- [x] OS/2
- [x] Pandora
- [x] QNX
Audio subsystems:
- [x] arts
- [x] esd
- [x] fusionsound
- [x] nacl
- [x] nas
- [x] paudio
- [x] qsa
- [x] sunaudio
- [x] winmm (dsp is still used by RISC OS, per https://github.com/libsdl-org/SDL/issues/6570#issuecomment-1323674096)
Video subsystems:
- [x] directfb
Misc:
- [x] visualtest
@libsdl-org/a-team
os/2 can go. that pandora config and makefile can go. several audio backends such as esd, nas, arts can go.
For Windows audio we can technically remove every backend that isn't WASAPI, but at the same time I feel like we're going to be fighting OS bugs in WASAPI until the end of time... would be good to figure out if there's something we can do at the API level to finally fix it for good.
I'm adding things to the checklist above, feel free to say something if you disagree.
@sezero, once everyone has a chance to chime in, feel free to nuke each one as a separate commit.
os/2 can go
Literally did not expect Ozkan to say this. :)
For Windows audio we can technically remove every backend that isn't WASAPI
Winmm can be retired for sure, but having DirectSound as a foil has been useful, even if it's just to demonstrate something is wrong with our WASAPI code.
But, legit question: we're dropping WinXP support, right? And Vista...? ...And 7 and 8...? :)
Where should we cut on this?
arts, esd and nas can all go.
Also fusionsound, nacl, paudio, qsa, possibly sndio if OpenBSD isn't still using it, possibly sunaudio if Solaris isn't still using it (or if no one is using Solaris).
QNX support can go; we don't have any way to maintain it and it has a proprietary SDK we no longer have a license for. If it becomes a going concern or someone steps forward to maintain it, we can resurrect it from revision control.
(Sorry for all the spam here)
If dsp can go along with all the other legacy Unix backends, we can remove the higher level code for manage Unix /dev/dsp devices that is in src/audio itself.
If all the network sound servers and all the random device name backends are going, we can remove the idea that there might be arbitrarily-named audio devices in SDL3.
(and even if not, we should just make forcing an arbitrary device name/server address a hint that affects the outcome of opening the default SDL device).
Also, this might be too aggressive, but I'd consider deleting PSP, Vita, PS2, and Nintendo 3DS support up front, and let them live in SDL2, and add them back to SDL3 if they want to maintain them once we've ripped everything up.
Obviously the Stadia fork is not migrating to SDL3. The other private forks will, I assume.
Do we need "android", "aaudio" and "opensles" audio targets? What is Android using at this point?
Can "jack" audio go away now that pipewire is the new hotness?
Did NetBSD ever pick up ALSA or PulseAudio, or do they really still need a bespoke /dev interface?
We're probably stuck with jack but only for the same reasons as pulse, both could probably be deprecated by the time 3.0 is done and be removed toward the end of 3.x's lifecycle.
The "raspberry" video driver can go (modern Raspberry Pi OS supports kmsdrm on at least the Pi 3 and Pi 4, if not others).
I think we delete the DirectFB code, which I am not convinced ever worked in SDL2.
What is "vivante"? Is this still used? How about riscos?
In joysticks, if "iphoneos" is still used, let's rename that to ios.
In render, can we dump Direct3D 9? OpenGLES 1? (Direct3D 12 and Metal should be obsoleted by the GPU work eventually, GLES2 might need to hand around for what qualifies as a lower-end device in current times).
But, legit question: we're dropping WinXP support, right? And Vista...? ...And 7 and 8...? :)
Where should we cut on this?
In my opinion we can drop WinXP and Vista, but we should keep 7 and 8. Together they are a little more than 4% of the October 2022 Steam hardware survey, and 4% of millions of players is quite a few. :)
If all the network sound servers and all the random device name backends are going, we can remove the idea that there might be arbitrarily-named audio devices in SDL3.
There will always be arbitrarily named audio devices. :)
The "raspberry" video driver can go (modern Raspberry Pi OS supports kmsdrm on at least the Pi 3 and Pi 4, if not others).
kmsdrm still doesn't perform as well as the vc code in older Raspberry Pi OSes, and the Steam Link app still needs to support it, as they are still the best direct replacement for Steam Link hardware.
I think we delete the DirectFB code, which I am not convinced ever worked in SDL2.
We still have random folks working on embedded systems that use DirectFB - it was their only alternative once we removed fbcon support. I think most embedded systems now have capable GLES2 stacks, so our dummy driver with offscreen GLES may be a viable replacement these days.
What is "vivante"? Is this still used?
Yes, Steam Link hardware, still supported by Valve. ;)
How about riscos?
We've gotten some recent commits for this, we should reach out to the author and get their opinion.
In joysticks, if "iphoneos" is still used, let's rename that to ios.
Not only is it still used, it's the recommended path going forward for macOS. It definitely needs to be renamed though.
In render, can we dump Direct3D 9? OpenGLES 1? (Direct3D 12 and Metal should be obsoleted by the GPU work eventually, GLES2 might need to hand around for what qualifies as a lower-end device in current times).
OpenGLES 1 can go.
Direct3D 9 is still the best video decode path on a lot of video cards, so Steam Remote Play defaults to using that.
WinRT can be cut, all our use cases should now fall under GDK. The Xbox Creator Program is UWP's last exclusive customer and ID@Xbox is far preferable for shipping software on Xbox.
We still have random folks working on embedded systems that use DirectFB - it was their only alternative once we removed fbcon support.
Honestly I'd sort of like to replace it with an fbcon target that can only handle a window framebuffer, or if it's feasible, add a window framebuffer that doesn't require OpenGL to the kmsdrm target.
Just really want to find a way to eject the creaky old dependency here that'll work for these embedded people.
Honestly I'd sort of like to replace it with an fbcon target that can only handle a window framebuffer, or if it's feasible, add a window framebuffer that doesn't require OpenGL to the kmsdrm target.
This seems like a good option, and there's already a request for it in https://github.com/libsdl-org/SDL/issues/6561
os/2 can go
Literally did not expect Ozkan to say this. :)
Well, why not. Obviously I'm not experienced enough to keep supporting and maintaining it. And since sdl3 is supposed to be more gpu-centric, there will be no point in keeping it.
If dsp can go along with all the other legacy Unix backends,
It might be wise to still keeping it, at least for some time? Isn't that still the default for freebsd guys?
For Windows audio we can technically remove every backend that isn't WASAPI
Winmm can be retired for sure, but having DirectSound as a foil has been useful, even if it's just to demonstrate something is wrong with our WASAPI code.
I'd definitely want something other than WASAPI to be around for a bit longer — WASAPI has been broken too often recently in "interesting" setups (weird sample rates / running under wine / etc). So having either winmm or DirectSound would be worth keeping.
Also, I'm still shipping a few things which need Windows XP support, though they easily can stay on SDL2. (Not to say it wouldn't be nice to avoid going out of our way to break support for older OSes where it doesn't gain us anything.)
More generally, do we need to work out what a "minimum hardware spec" for different parts of the API are? e.g., SDL_Surface-style software rendering only needs a framebuffer. The new GPU API will need a ~Vulkan era GPU. SDL_Renderer will need something in-between (if we're dropping GLES 1 support, do we require shader support? or do we continue supporting everything via the software renderer).
Also, this might be too aggressive, but I'd consider deleting PSP, Vita, PS2, and Nintendo 3DS support up front, and let them live in SDL2, and add them back to SDL3 if they want to maintain them once we've ripped everything up.
Obviously the Stadia fork is not migrating to SDL3. The other private forks will, I assume.
Do we need "android", "aaudio" and "opensles" audio targets? What is Android using at this point?
Can "jack" audio go away now that pipewire is the new hotness?
Did NetBSD ever pick up ALSA or PulseAudio, or do they really still need a bespoke /dev interface?
Agreed, about time to focus mainly on shader capable renderers. PSP, Vita, PS2 and Nintendo 3DS can live inside SDL2 branch.
How about riscos?
We've gotten some recent commits for this, we should reach out to the author and get their opinion.
I'm still interested in maintaining this, and would be keen to see it continue to be supported in SDL3.
If dsp can go along with all the other legacy Unix backends,
It might be wise to still keeping it, at least for some time? Isn't that still the default for freebsd guys?
If we're keeping RISC OS support, then we'll need to keep this as well.
Well, why not. Obviously I'm not experienced enough to keep supporting and maintaining it. And since sdl3 is supposed to be more gpu-centric, there will be no point in keeping it.
I was under the impression that the plan was to continue to support at least the Render API alongside the new GPU API, so SDL3 would in theory still be at capable of supporting the same platforms that SDL2 does. Is there anything planned that would require a major rework of the audio or video drivers?
I was under the impression that the plan was to continue to support at least the Render API alongside the new GPU API, so > SDL3 would in theory still be at capable of supporting the same platforms that SDL2 does. Is there anything planned that would require a major rework of the audio or video drivers?
We're not talking about dropping things because the tech is moving on, we're talking about dropping things no one is using.
We don't have specific plans yet, but both the audio and video internal interfaces had dramatic changes between 1.2 and 2.0...basically all the existing targets got rewritten to support this. It might not be as dramatic for SDL3, but we don't know yet.
Also, major releases are a good time to trim out abandoned platforms. We did this for SDL2, as well, as things like MacOS Classic and Windows CE got ripped out. And, over time, some drifted in, like OS/2...it mostly matters if someone shows up to do the work. For example, if you like RISC OS and are willing to make sure it works occasionally, I don't mind if it stays.
Yes, we plan to continue 2D platform support - for example we're talking about adding a software KMSDRM path. It obviously won't support the new GPU API, but that's not a requirement for SDL support, it's an optional feature for modern hardware.
The goal is to make sure that SDL 3 has a cleaned up API, and is supporting what people are actually using.
SysWM can drop support for Mir, as it's long since been abandoned/defunct and the backend video driver for it was deleted years ago.
SysWM can drop support for Mir, as it's long since been abandoned/defunct and the backend video driver for it was deleted years ago.
Done.
Probably worth doing a cleanup pass of the Wayland stuff for the same reason - off the top of my head we can probably clean up a ton of stuff in SysWM (i.e. old wl_shell junk) and there's probably more we can trim or clean up from the implementation as well.
SysWM can drop support for Mir, as it's long since been abandoned/defunct and the backend video driver for it was deleted years ago.
Done.
You got the enum, but the bit in the struct is still there: https://github.com/libsdl-org/SDL/blob/47c37a8e9d3128af922a4f37ae0e98c6f9067850/include/SDL_syswm.h#L289