Raymii.org

Table of Contents

• Second screen?
• x11vnc one window and a reverse SSH port forward
• directvnc
• fbvnc
  • How does teams run?

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, fbvnc and directvnc.

Microsoft Teams running on a coffee machine?!?

Recently I removed all Google Ads from this site due to their invasive tracking, as well as Google Analytics. Please, if you found this content useful, consider a small donation using any of the options below:

I'm developing an open source monitoring app called Leaf Node Monitoring, for windows, linux & android. Go check it out!

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 $200 credit for 60 days. Spend $25 after your credit expires and I'll get $25!

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:

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 localhost only (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

The -geometry and -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 localhost:5900 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 gcc (apt install build-essential) and follow along.

directvnc

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 directfb did work on the entire screen, no issues running the examples. directvnc used 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, fbvnc.

If you're compiling yourself, you can clone the repository (git clone https://github.com/drinkmilk/directvnc) and run autoreconf -vfi then automake, 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 compilation required:

apt install directvnc

fbvnc

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!

A 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 directfb, saves 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 init 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 stop x11vnc.

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