KMS/DRM context for the GL/GLES renderer

Hi there,

According to this thread
https://forums.libsdl.org/viewtopic.php?t=9110&sid=ce39ff11902a8e58d9eca8e126872fc1
there was someone implementing a KMS/DRM context so the GLES/GL accelerated renderer would work outside X11 (as it already does, with awesome results, on the Raspberry Pi platform).
However, I don’t know if it was ever implemented or if is someone working on this anymore.
I am willing do it it, as it’s relatively easy and I have done similar things, but first I would like to know how are things in that front.
Oh, and I know about DirectFB, but depending on other libs (specially something obscure as DirectFB) is not very optimal.

Thanks

With more lightweight alternatives to X11 available now, the advantage of
going straight for the kernel is not as big as it was back then. However,
it’d be a very interesting option to have available, so by all means please
work on this if you can/want.

2016-06-16 7:25 GMT-03:00 vanfanel :> Hi there,

According to this thread

https://forums.libsdl.org/viewtopic.php?t=9110&sid=ce39ff11902a8e58d9eca8e126872fc1
there was someone implementing a KMS/DRM context so the GLES/GL
accelerated renderer would work outside X11 (as it already does, with
awesome results, on the Raspberry Pi platform).
However, I don’t know if it was ever implemented or if is someone working
on this anymore.
I am willing do it it, as it’s relatively easy and I have done similar
things, but first I would like to know how are things in that front.
Oh, and I know about DirectFB, but depending on other libs (specially
something obscure as DirectFB) is not very optimal.

Thanks


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


Gabriel.

I’ve recently been working on a KMS/DRM videodriver for SDL2, in this branch on Github: https://github.com/sigmaris/SDL-mirror/tree/kmsdrm
I’ve been copying the Raspberry Pi videodriver quite closely.
It doesn’t use anything from DirectFB - only libdrm, GBM, and Mesa EGL.
My motivation is basically to get EmulationStation from RetroPie working, using this videodriver, without X11 on a Raspberry Pi 3 (not using dispmanx but using Mesa and Eric Anholt’s open-source vc4 drivers).
It’s at an early-ish stage, but it’s working to the extent that EmulationStation can be built against SDL2 with this driver, and starts up and shows its UI on the frame buffer.

A few things are missing or still to be done, though, and there are bugs.

  • There’s no support for mouse cursor yet. It could be done with drmModeSetCursor on platforms that support hardware cursors, but I don’t know what to do for a software fallback.
  • There’s no support for changing the screen mode with SDL.
  • There’s no support for multiple displays.
  • It’d be nice to have dynamic loading support for libdrm/libgbm/etc, like the Wayland and X11 videodrivers.
  • There’s no way to have more than one (fullscreen) SDL window (Maybe this is OK as a limitation of this platform though)
  • I’ve only added it into the CMake build system, not the autotools system.

Right now I’m investigating a problem where EmulationStation shuts down its SDL video system (calls SDL_VideoQuit) and launches another program, then when that program finishes, ES re-initialises its SDL video. After it re-inits the video subsystem, I keep getting Access Denied when calling drmModePageFlip(). So it works the first time, but not after quit and re-init, even though I close the /dev/dri/card0 file descriptor in VideoQuit and re-open it in VideoInit.

sigmaris wrote:

I’ve recently been working on a KMS/DRM videodriver for SDL2, in this branch on Github: https://github.com/sigmaris/SDL-mirror/tree/kmsdrm
I’ve been copying the Raspberry Pi videodriver quite closely.
It doesn’t use anything from DirectFB - only libdrm, GBM, and Mesa EGL.
My motivation is basically to get EmulationStation from RetroPie working, using this videodriver, without X11 on a Raspberry Pi 3 (not using dispmanx but using Mesa and Eric Anholt’s open-source vc4 drivers).
It’s at an early-ish stage, but it’s working to the extent that EmulationStation can be built against SDL2 with this driver, and starts up and shows its UI on the frame buffer.

A few things are missing or still to be done, though, and there are bugs.

  • There’s no support for mouse cursor yet. It could be done with drmModeSetCursor on platforms that support hardware cursors, but I don’t know what to do for a software fallback.
  • There’s no support for changing the screen mode with SDL.
  • There’s no support for multiple displays.
  • It’d be nice to have dynamic loading support for libdrm/libgbm/etc, like the Wayland and X11 videodrivers.
  • There’s no way to have more than one (fullscreen) SDL window (Maybe this is OK as a limitation of this platform though)
  • I’ve only added it into the CMake build system, not the autotools system.

Right now I’m investigating a problem where EmulationStation shuts down its SDL video system (calls SDL_VideoQuit) and launches another program, then when that program finishes, ES re-initialises its SDL video. After it re-inits the video subsystem, I keep getting Access Denied when calling drmModePageFlip(). So it works the first time, but not after quit and re-init, even though I close the /dev/dri/card0 file descriptor in VideoQuit and re-open it in VideoInit.

This is exactly what I was looking for!
Support for changing the videomode, multiple displays, etc… is a bit out of the scope of SDL2 in my opinion. These days changing the phisical videomode doesn’t make much sense really.
In fact, SDL2 on dispmanx/GLES doesn’t change videomode and there’s no need for it.

Are you merging this into mainline SDL2, please? :smiley:

I would like to submit the driver as a patch to SDL2, yes, once I’ve cleared up the bugs and tested it with more than just the Raspberry Pi.

@sigmaris: I see on github you’re making very solid progress on this!
I have cloned the drmkms branch, what’s the configure option to enable DRM/KMS support, if there’s such an option?

Ok, it seems the CMAKE buildsystem activates the KMS/DRM backend.
This is how I am configuring it:

cmake …/ -DVIDEO_X11=OFF -DVIDEO_WAYLAND=OFF -DOSS=OFF -DDISKAUDIO=OFF -DVIDEO_DUMMY=OFF -DCMAKE_INSTALL_PREFIX=/usr

The KMS/DRM backend is on now.

However, when trying it I get:> Couldn’t create window: Couldn’t find display mode match.

vanfanel, you could try compiling git commit 97b104930053b3ba8725b6d2fa882ea05d2e0898
I am in the middle of implementing support for different display modes, but that’s not finished yet. That commit was the last one before I started working on the display mode stuff.

@sigmarils:

I have built and installed commit 97b104930053b3ba8725b6d2fa882ea05d2e0898, and it kind of works, but games have graphics problems. SDLPop for example shows in a small area, with wrong colors.
According to SDL_GetRendererInfo(), the opengl renderer is being used. Is that also expected with that commit?

@sigmarils: SDL2 on the Pi uses dispmanx for EGL window (in this case, KMS/DRM/GBM would be used as the windowing system to provice a context for the GLES tenderer) and then uses GLES2 to render 2D bitmaps to screen. SDLPop works fine there, on the Pi. SDLPop is a 2D game, it doesn’t use OpenGL calls, just SDL2 calls, an in turn SDL2 uses GLES2 to render the 2D graphics as a texture.
The Pi driver has no limitations regarding this…it works very well :slight_smile:

Yes, if you’re talking about rendering 2D using SDL’s built-in renderers, it would need to use the OpenGL renderer as there’s no support for blitting pixels directly to a GBM surface. In theory, the driver could choose between creating KMS “dumb buffers” which can be blitted to, or GBM surfaces which can be drawn to using EGL + OpenGL, but right now it only creates a GBM surface and so can only support rendering using EGL + OpenGL.
It was originally based on the Raspberry Pi dispmanx driver which has the same approach & limitations.

Also, I would like to say that the pi(dispmanx) driver does not try to change videomode: it uses whatever is in use, and scales fullscreen using the GLES renderer, that’s all.
I believe it’e the best and simpler approach for enviroments without a window manager: simply use whatever videomode the system is using.