KMSDRM: using atomic mode setting breaks GPU compatibility


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: 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).

This is a major regression in the KMSDRM driver …

1 Like

Filed a bug afterall

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.

I’m afraid they don’t read that often the forum.

@vanfanel can you drop by ?


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 :slight_smile: 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.

We’ve put back the original KMSDRM driver and try to use that if the new one doesn’t work.

Can you please try this and see if it works for you? This is the last issue holding up release.


The KMSDRM issue @Substring reported needs some radeon hardware + linux to reproduce with I guess.

(Sorry, I don’t have have any radeon devices at the moment)

Will test ASAP.

Can also be tested with a GFX card using the amdgpu driver with amdgpu.dc=0 as module parameter to disable Display Core.

1 Like

@slouken We’re almost there. I had to force SDL_VIDEODRIVER=KMSDRM_LEGACY on command line to get it working.

On a side note, I hope this fix is temporary, because there were some interesting fixes and improvements in 2.0.14.

1 Like

Discussion continued at bugzilla (
with suggested patch(es).

This has been fixed, thank you slouken and sezero

1 Like