With this little SPI screen, there is no GPU behind, so no way to use DRM. If you want to run X, you also need to use framebuffer turbo driver. So everything goes through the framebuffer anyway.

The fun here was to use only Warp 10 database on the system, the only time series database that has built-in image creation function in the language. Normal use is to build heavy dataviz on the server, then return a base64 encoded png.

Even if this is true, isn’t that about drivers and not interfaces? Perhaps I am wrong but I was under the impression that the framebuffer userspace device worked on DRM-based drivers still, just it didn’t use fbdev internally.

I am not 100% sure either, but I think /dev/fbN does not exist without a fb driver. DRM uses /dev/dri/renderNNN

> DRM uses /dev/dri/renderNNN

It’s /dev/dri/card0 on my device.

DRM has a thing called “dumb framebuffer” which exposes a memory mapped file with the CPU-accessible frame buffer data. See DRM_IOCTL_MODE_CREATE_DUMB and DRM_IOCTL_MODE_MAP_DUMB IOCTLs. The only inconvenience, some boilerplate is required to find the correct GPU connector, and setup a supported video mode.