KMS/DRM context for the GL/GLES renderer |
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 |
|||||||||||
|
sigmaris
|
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. |
|||||||||||
|
KMS/DRM context for the GL/GLES renderer |
gabomdq
|
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:
-- Gabriel. |
|||||||||||||
|
vanfanel
|
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? |
|||||||||||||
|
vanfanel
|
@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? |
|||||||||||
|
vanfanel
|
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:
|
|||||||||||||
|
sigmaris
|
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. |
|||||||||||
|
vanfanel
|
@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? |
|||||||||||
|
sigmaris
|
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. |
|||||||||||
|
vanfanel
|
@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 |
|||||||||||
|
vanfanel
|
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. |
|||||||||||
|