I was trying te KMSDRM with some very simple programs that were working ok on 2.0.12. The same code won’t work on the current dev branch and I get:
DEBUG: check_modesetting: probing “/dev/dri/card0”
DEBUG: /dev/dri/card0 connector, encoder and CRTC counts are: 4 5 6
DEBUG: check_modesetting: probing “/dev/dri/card0”
DEBUG: /dev/dri/card0 connector, encoder and CRTC counts are: 4 5 6
DEBUG: KMSDRM_VideoInit()
DEBUG: Opening device /dev/dri/card0
DEBUG: Opened DRM FD (3)
DEBUG: no atomic modesetting support.
DEBUG: Video subsystem has not been initialized
INFO: Using SDL video driver: (null)
DEBUG: Video subsystem has not been initialized
After carefully checking, the radeon driver doesn’t support atomic modesetting. That’s not the only problem : the same happens with the amdgpu driver if we disable display core (kernel parameter amdgpu.dc=0, which is required to get analog outputs working).
I am concerned by this comment at Bugzilla: “it worries me that the next release has such a compatibility regression, but there’s not much time…” which implies that meeting some artificial deadline is more important than fixing a serious regression.
Can I make a plea either to delay the release of 2.0.14 or to revert this breaking change.
If release is in two days, I am not going to make it in time.
I am currently very busy with real life and fixing Vulkan compatibility with the KMS/DRM backend, which is currently in a very bad state on my local copy.
I would need at least two weeks to:
1- Finish my personal things
2- Finish the Vulkan fix and tidy up the code
3- Fix the regression (which I didn’t see coming, sorry… It was reported very late on the bugzilla but I really want to fix this, because it’s my fault for believing the basic ATOMIC stuff was already compatible with EVERYTHING.
I ask for some comprension: I am not a professional programmer, I am not paid for all this and, most importantly, the lowlevel stufff involved here is very convoluted. VERY.
So, more time is all I need.
@rtrussell Please don’t push on trying to revert the change to ATOMIC: not only makes SDL2 future-proof but fixes some issues on the legacy backend. It’s not that easy as “going back to legacy”. Be patient, it will be fixed, you can be sure.
Delaying the release is my preference too. Wasn’t the idea that even-numbered SDL2 releases should not have radical changes, to minimise the chance of regressions?
I regret that the version numbering doesn’t adhere to the major.minor.patch system, in which changes to the patch number should imply only “backwards compatible bug fixes”.
I had hoped devs would look more often here, and I got surprised by the 2.0.14 annoucement, hence the late bug, sorry.
I’m very comprehensive to the"open source is done on my spare time", that’s the very same for me I would have loved to help, but the time frame is too short for me to be of any use. But I’d be happy to test if you ever have a branch I should compile to report progress.
I would have loved to help, but the time frame is too short for me to be of any use. But I’d be happy to test if you ever have a branch I should compile to report progress.