Add display driver to support Linux DRM/KMS environment

[yf13]

Describe the project you are working on

An embedded Linux device might not use x11 or Wayland alike window manager systems at all. Instead one can run KMS/DRM based graphics apps directly on the device. Is it possible for godot engine to support this bare-metal platform?

Describe the problem or limitation you are having in your project

x11 or wayland window managers add a lot overhead as the embedded device only runs one graphics app.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

add a platform for linux bare metal

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

When building godot engine, one can choose platform=linuxdrm

If this enhancement will not be used often, can it be worked around with a few lines of script?

Not sure as I am too new to godot engine at this time. When building godot engine, I need choose the right platform.

Is there a reason why this should be core and not an add-on in the asset library?

This feels like choosing the correct target platform for godotengine as I am not sure the server platform is a good fit.

[Calinou]

There was some interest in #988 for adding EGL/DirectFB support, as it can help with performance on ARM SBCs.

See also https://github.com/efornara/frt for Godot 3.x.

In Godot 4, this should not be implemented as a platform but as a display driver that can be used with the linuxbsd platform (this is how X11 is implemented now).

[darksylinc]

What a Linux server 99.9999% of the time wants is headless support for which X11/Wayland/KMS is not necessary, I believe Godot already supports this (it's likely that it already does given the CI tests).

That's what the server cmd line is for, as you hinted. The server mode can render Vulkan, but it won't display to any screen. It can render images that can be discarded or saved to disk, or streamed through the network.

DRM/KMS is a different beast. The need for it is very specific such as an embedded device with direct output to screen and simple functionality; DVD players come to mind.

Godot guidelines for contributors is that PRs are accepted when there is a problem in the need of a solution.

Without describing your problem in more detail and why you think you need DRM/KMS support, it sounds like a solution looking for a problem.

[Calinou]

DRM/KMS is a different beast. The need for it is very specific such as an embedded device with direct output to screen and simple functionality; DVD players come to mind.

From what I can tell, supporting direct KMS output has become less relevant on modern ARM SBCs like Raspberry Pi 4 and equivalent, as the performance overhead isn't as high.

Direct KMS output also comes at the cost of convenience as it's "exclusive" – you can't alt-tab back to a desktop session without exiting the project. Instead, you have to switch VTs using Ctrl + Alt + (number).

[nergdron]

@darksylinc: I was just looking into this because I have a use case that requires running during boot inside the initramfs, where all you have is a statically compiled binary, resource files, and the kernel KMS drivers. this potentially still means opengl or vulkan acceleration, but it definitely means no X11/Wayland. I'm currently looking into writing a ton of scripting, rendering, and control logic that godot can already do, and so having a KMS rendering backend would really help me out.

I have no idea how complicated it'd be to write or add this backend, of course, but given SDL2 does provide OpenGL / Vulkan binding from a KMS console, I imagine there's some stuff that could be re-used there to avoid having to write it all from scratch, and hook into the existing gl/vk rendering code. that's what I'd hope, at least. 😅

[darksylinc]

Good luck!

Be careful that during boot the driver is not yet loaded. On most distros not even the firmware is loaded.
See my guide "Add amdgpu firmware to initramfs so it’s available early" so you get an idea of what I mean.

You may get similar issues with everything else that Godot implicitly needs (audio, ethernet / wifi, disk drivers, etc)

[rafalagoon]

@darksylinc: I was just looking into this because I have a use case that requires running during boot inside the initramfs, where all you have is a statically compiled binary, resource files, and the kernel KMS drivers. this potentially still means opengl or vulkan acceleration, but it definitely means no X11/Wayland. I'm currently looking into writing a ton of scripting, rendering, and control logic that godot can already do, and so having a KMS rendering backend would really help me out.

I have no idea how complicated it'd be to write or add this backend, of course, but given SDL2 does provide OpenGL / Vulkan binding from a KMS console, I imagine there's some stuff that could be re-used there to avoid having to write it all from scratch, and hook into the existing gl/vk rendering code. that's what I'd hope, at least. 😅

Any luck? My community and I will be happy to test any developments in Raspberry Pi, R36S and other portable consoles 😻

[yf13]

Without describing your problem in more detail and why you think you need DRM/KMS support, it sounds like a solution looking for a problem.

@darksylinc sorry that my Github settings were wrong and email notifications just came recently.

My use case was not for typical desktop or server distributions, but for embedded devices like DVD player as you said. Those embedded devices often has only one purpose thus one GUI app is enough. They often run on customized kernels which dropped a lot unnecessary things but needed drivers shall be available before kicking off the GUI app.

[Calinou]

but for embedded devices like DVD player as you said.

Keep in mind the note about Godot's system requirements on the Custom platform ports documentation though:

Godot is a modern engine with modern requirements. Even if you only intend to run simple 2D projects on the target platform, it still requires an amount of memory that makes it unviable to run on most retro consoles. For reference, in Godot 4, an empty project with nothing visible requires about 100 MB of RAM to run on Linux (50 MB in headless mode).

If you want to run Godot on heavily memory-constrained platforms, older Godot versions have lower memory requirements. The porting process is similar, with the exception of DisplayServer not being split from the OS singleton.

[Cebion]

There is godot4sdl by efornaralabs
https://www.patreon.com/posts/unofficial-4-3-110167921

Which works fine aarch64 sbc without x11 and only a sdl2 kms/drm build.
But unfortunetaly not open source :(

He wrote on his site "As a stopgap until Godot 4 supports KMS/DRM or SDL2, I also release an Unofficial SDL2 Runtime for Godot 4." https://efornaralabs.web.app/

[cjd166]

There was some interest in #988 for adding EGL/DirectFB support, as it can help with performance on ARM SBCs.

See also https://github.com/efornara/frt for Godot 3.x.

In Godot 4, this should not be implemented as a platform but as a display driver that can be used with the linuxbsd platform (this is how X11 is implemented now).

Do you know the steps for this for this implementation of frt for Godot 4?