A word of caution if you are starting a small LCD project: the framebuffer approach is dead on Linux. The new approach is DRM (Direct Rendering Manager), that allows partial LCD updates from userspace. See
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.
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.
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.