Run MS Teams on a coffee machine?!? (Or: Embedded Linux Framebuffer VNC client)
Published: 08-04-2021 | Author: Remy van Elst | Text only version of this article
Table of Contents
To fill some time during compiling I tried to get a VNC client running on a coffee machine, specifically to show MS Teams. At work I develop software for these coffee machines in C++, which allows me to do such fun stuff, because from a software point of view, it's just an ARM PC running linux with a framebuffer for graphics. I compiled a few framebuffer VNC clients, fired up an SSH tunnel and used
x11vnc to share one specific window and after a few attempts, Teams was up and running on my 'new' second monitor.
This post contains my little adventure in framebuffer VNC clients, but it's not a comprehensive guide as most of my other articles. Showing you how to set up an Openembedded server with a VariScite specific toolchain is way too much work to cross-compile a simple C program, but since that's my day job, why not use it for fun. It contains some tips for
x11vnc and shows you two different framebuffer VNC clients,
Microsoft Teams running on a coffee machine?!?
Consider sponsoring me on Github. It means the world to me if you show your appreciation and you'll help pay the server costs.
You can also sponsor me by getting a Digital Ocean VPS. With this referral link you'll get $100 credit for 60 days.
Important disclaimer: this was a fun side project, neither acknowledged nor endorsed by my employer. Their coffee machines can not run custom software under normal circumstances.
The instructions in this post are applicable to any linux framebuffer device. It could be a raspberry pi or even your own machine.
Here is another picture with a keyboard attached, input works with fbvnc. The mouse is optional since the touchscreen works as well in fbvnc. I did not test user input (mouse/keyboard) much more, because I intended to use the device as a view only screen. Also, my spare board has a broken touch controller/screen, which is why I can re-use it as a second screen, otherwise it would be thrown out.
For local development, I sometimes do it the reverse way around, run the coffee machine UI on my local machine. Manual testing is a rare occurrence, since by far a large part of our codebase is covered by unit tests and there is an extensive HTTP API. But still, sometimes there is a need for local testing, we have stubs, can run the QT UI locally and even the flash UI still runs with some hoops. And of course a bunch of coffee machines to test with, but who likes walking and manually pressing buttons if you can automate that stuff away?
This is one of the Frankenstein just-enough-coffee-machines that serves as a second screen:
So why not get an actual second screen? Well, I personally use just one screen, because I try to do one thing at a time. That one thing usually requires all of my focus and attention, so a second screen with all kinds of distractions doesn't really work for me.
However, infrequently, I miss a second screen. During chat sessions or video call's where you're pair programming or to have a datasheet open. In such cases I would like a small screen which is easy to turn off when it's not needed anymore.
A friend of mine is a video editor and he has a separate 5" screen, for use with Final Cut. That thing was expensive (due to colour correctness) and on AliExpress I could only find these things, still expensive.
Then it occurred, our coffee machines all have 7" touch screens, they run linux and I have a bunch of Frankenstein just-enough-coffee-machines on my desk for testing. Why not use such a screen for the occasional chat window?
The machines run either
gnash with a flash UI, a
qt UI or a headless
UI for touchless, which uses MQTT and an internal HTTP API. The QT ui also
uses the HTTP API, flash still runs a custom communication protocol.
Both QT and Gnash run on the framebuffer, there is no X server, so a regular VNC client will not work. Or the actual teams binary for that matter.
x11vnc one window and a reverse SSH port forward
I use the following command to start a VNC server on
(because it runs without a password,
fbvnc does not support that). The
special thing is that that command allows me to pick one window which is shared
over VNC, not the entire desktop or a screen region.
x11vnc -id pick -viewonly -forever -localhost -geometry 800x600 -scale 800x600 -noxdamage
-scale parameters are given because the machine screen
has that resolution. It looks less weird that way.
Since the VNC server is only accessible via localhost, I use SSH to setup a secure tunnel to the coffee machine and forward my machine's VNC port to the coffee machine:
ssh -R 5900:127.0.0.1:5900 user@IP.OF.COFFEE.MACHINE
The coffee machines normally do not have SSH running or exposed. For local development we can turn it on, but it involves a signed package and UART.
Now, as far as the coffee machine is concerned, it has a port on
which is also a working VNC
display:0. Great! Let's continue on to VNC clients.
Both VNC clients for the framebuffer were cross-compiled with out specific toolchain,
instructions for that are not really applicable elsewhere. On a raspberry pi or
other ARM board, you can just install
apt install build-essential) and
The first client I found was directvnc. Over 9 years old, seemingly dead, but I could find an openembedded recipe for it which worked right away, so that was easy. Too easy it appeared, because it works partly. As you can see on the image below, one half of the screen was black and the colours are a bit off on the other (working) half:
I filed a github issue but I don't expect it will be fixed, since the
project seems dead. The curious thing was that other code using
work on the entire screen, no issues running the examples.
directfb for the framebuffer rendering.
I tried all the possible options in
/etc/directfbrc and took a quick look at
the code, but didn't find anything to make it work. And since it's a side
project in my spare time, I decided to move on to the next client I found,
If you're compiling yourself, you can clone the repository (
https://github.com/drinkmilk/directvnc) and run
autoreconf -vfi then
./configure and finish off with
make. There should be a
new binary in that folder. Make sure you have directfb installed as
well, it's a dependency.
On Debian (and Raspbian) you can install
directvnc as a package, no
apt install directvnc
fbvnc is a smaller, more bare-bones tool. The old Debian webpages are of course
offline, but archive.org still has copies. However, to my surprise, the
git repository has recent commits from its author, Ali Gholami Rudi - his homepage!
git clone and
make fbvnc in my cross-compile setup later I have a
working binary. The connection failed at first, because I had password
protected it. After removing the password, it worked right away. Way easier
compilation setup (no
autotools) and no dependency on
a lot of work.
fbvnc hard codes the host
127.0.0.1 and the port
5900, but you
can specify others on the command line:
fbvnc hostname port
There is no help or instructions, just a
connection failed or
failed. The source is small and readable so figuring out what happens when is
easy. After you start it,
CTRL+C to quit doesn't work, to stop it you must
Here is a screenshot of my entire KDE desktop running (scaled_ on the coffee machine, via VNC:
How does teams run?
Performance wise, it's better then I expected. A tad bit laggy, but usable and even for video calls, not that much stuttering. Since it's all running on my workstation and only the rendering is on the coffee machine, I didn't expect any less. If I have some more spare time, I'll try to make a video sometime showing the performance. For an occasional second screen, it's just perfect.Tags: autotools , blog , development , framebuffer , fun , linux , microsoft , vnc