3 ms·

I'm kinda annoyed this is the case before the GBM/EGLStreams argument got resolved... I've done some programming against GBM directly (wanted an OpenGL ES appl

I'm kinda annoyed this is the case before the GBM/EGLStreams argument got resolved... I've done some programming against GBM directly (wanted an OpenGL ES application to be in a "kiosk mode," didn't want to have to install X / a Wayland compositor + configure it), and the whole DRM+GBM stack is kinda _terrible_. Generously, one could call it barely documented; the majority of the useful and correct documentation I found was on Mesa contributors' blogs, and there were still edge cases in the API that were getting ironed out in the 5.9 kernel release. I haven't needed to write against EGLStreams, but I might give it a try to see if it's as much of a pain or not; from the 1-page overview on the nvidia docs, I suspect not -- it sounds quite similar to the VK_KHR_swapchain extension.

Const-me 6y ago
Interesting, probably depends on hardware then. On Pi4, that same workflow (drm/kms without desktop managers, with GLES on top) delivers superior image with no tearing (tearing does happen in windowed mode under load), while consuming less resources than windowed mode. This library: https://github.com/Const-me/Vrmac https://github.com/Const-me/Vrmac
yissp 6y ago
NVIDIA's EGLDevice / EGLOutput / EGLStream API isn't too bad in and of itself. The annoying thing is trying to have backends for both it and DRM / GBM in the same application. The programming models are just so different.
emersion 6y ago
Yeah, the KMS docs need some love. I'm trying to help with that. But note that even with EGLStreams you'd still be using KMS. And GBM's API is pretty small, basically just gbm_bo_import/gbm_bo_create/gbm_bo_get_*.