
The Raspberry Beer’o’meter - telecoteco
https://blog.senx.io/the-raspberry-beerometer/
======
mmjaa
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 ..

------
dangxiaopin
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

[https://www.raspberrypi.org/forums/viewtopic.php?t=128736](https://www.raspberrypi.org/forums/viewtopic.php?t=128736)

[https://github.com/notro/fbtft/issues/432](https://github.com/notro/fbtft/issues/432)

~~~
jchw
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.

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

~~~
Const-me
> 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.

------
jchw
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.

~~~
inferiorhuman
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.

1:
[https://wiki.qt.io/Raspberry_Pi_Beginners_Guide](https://wiki.qt.io/Raspberry_Pi_Beginners_Guide)

~~~
Fnoord
> recently

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.

~~~
inferiorhuman
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.

