I was once in the hackrrspace in Pristina, Kosovo, where ingenuity and DIY-culture reign supreme.. the group has a beer-brewing project, which turns out to be quite popular, and as a result the freshly brewed batches don't last long.
So they did the hacker thing and wired up the keg to an EPS8266, and gave everyone an RFID chip with which to gain their weekly beer rations.
I found this immensely amusing. Truly a wonderful hackrrspace .. if anyone ever gets a chance to visit Pristina, check them out .. and bring them some hardware to play with, while you're at it ..
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.
FWIW I think a more reasonable goto (than a browser) for a Raspberry Pi dashboard would be something along the lines of Qt QML, maybe with Python Qt bindings if you don’t want to write C++ code. It’s not really lightweight, but it can interface with the bare KMS EGL (no Xorg needed,) is hardware accelerated, and performance was acceptable when I last tried it on, I believe, a Pi 3.
I've been monkeying with a Qt/QML app recently on my desktop with an eye towards deploying it on a Pi based thing. One thing really stood out: the Pi support kinda sucks. Specifically, the binary situation is not great and Qt is a bit of a beast to compile (plus I'd have to setup a Linux VM to cross compile in a reasonable amount of time).
Raspbian comes with a fairly outdated version of Qt inherited from Debian, and there are no precompiled EGLFS binaries that I can find. Even the Qt folks don't distribute an installer. I could understand a complex beginners guide[1] if this were lower level stuff. It's not.
I had the same experience a couple of months ago. I spent a weekend banging my head against a wall following their documentation to cross-compile for pi3. Turns out it was out of date and there were also a couple of bugs. Since then they did fix one of the issues I reported. The other one already had a long open issue with no resolution (at the time). But I've lost all interest in trying again for the foreseeable future and I wouldn't recommend the experience.
How recent? Debian's latest stable, Buster, got released a couple of months ago. Raspbian's rebase on Debian Buster is recent, like a good month ago. Raspbian should sport Buster's Qt version.
Right, and Buster has Qt 5.11. Qt 5.14 is nearly out and there've been some fairly significant changes in .12 and .13 (and finally a JS native table model for .14 — Qt Quick 2 is really, really immature).
Of course Debian only bundles X11 versions of Qt so if you're looking for an EGLFS build, you're still stuck rolling your own. If the Qt folks distributed pre-built EGLFS binaries for the Pi this would be a huge usability win IMO.
Oh sure, you could go direct to fb. I think the default builds on Raspbian already support the KMS EGL path, though, so in theory it just gives you extra performance at little cost.
I wish someone would implement a bare metal DRM/KMS/GLES backend for https://github.com/AvaloniaUI/Avalonia, e.g. based on NanoVG C library for vector graphics and fonts. .NET core runs way faster than JavaScript in browsers, and C# is much higher level than C++ people use with QT.
I won’t redo the whole embedded GUI from custom NanoVG-based library to Avalonia, started much earlier than 2 months ago. For next embedded Linux project, or major version upgrade of the current one, I’ll definitely evaluate Avalonia.
Does it use GLES to render fonts and 2D graphics? Or they’re rendered on CPU?
Is there something comparable to WPF’s D3DImage to insert custom 3D content? In my custom library, I’ve implemented GlesInterop control which does nothing on the NanoVG render pass, but after the whole GUI is rendered, overlays a custom GLES content on top of the result.
How hard it is to implement custom touchscreen input? I’m currently generating touch events by reading from /dev/input/event0 with a FileStream class.
Is there on-screen keyboard in Avalonia? That’s probably the most complex piece of UI I’ve implemented in that project: input focus, modifier keys switching layouts, and that’s just for US English keyboard.
But the kiss approach was great here.
WarpScript includes all you need to render text, vectors, images... The limit is that I cannot use the touchscreen.
So they did the hacker thing and wired up the keg to an EPS8266, and gave everyone an RFID chip with which to gain their weekly beer rations.
I found this immensely amusing. Truly a wonderful hackrrspace .. if anyone ever gets a chance to visit Pristina, check them out .. and bring them some hardware to play with, while you're at it ..