Target System

The target system was based on x86 motherboard, dual core CPU, 6GB of RAM and big data storage (for the photos). Whole system is running Arch Linux distro with set of apps inside. System CPU is rather resource-constrained. There is also an onboard GPU available with HDMI output. 

Abandoned approaches


Well, I had no small HDMI-enabled device... 

STM32 Devkit

I started with perhaps too complicated approach. My first concept was based on STM32 devkit with display and USB port. The solution was supposed to implement the firmware for STM kit, showing nice gauges and stats. The stats would be provided by small application running in monitored system, providing the data per request... 

The issue was that I would have to write two apps (one for STM and one for server)... 

VoCore Screen

Its been some time that I ran across this thing:  VoCore Screen I haven't obtained it specifically for this project but since the other project was scrapped, I had nice tiny USB display. It turned to be very simple to have it running with Arch Linux (just few minutes with driver module Makefile to compile it) thanks to ready-to-use driver available for this thing. Next portion of whole process was to select appropriate SW to provide data.

X Server

Well, when we speak about showing something on Linux, the first thing that comes up is probably X server. I was thinking that maybe X server is just overkill so I decided to pursue another approach idea: Raw QT on top of framebuffer...

QT with Framebuffer

I learned that QT is capable of running in framebuffer without assistance of X server. I considered writing a new application doing exactly what I wanted but when exploring capabilities, I found out that under QT it is possible to run standalone web browser component and based on which there is Falkon Browser. Nice and smart. I was thinking that if I used a web-based monitoring tool, e.g. Linux-dash, I could deliver my stats on the screen pretty easily. It worked like a charm, but on my target system it consumed 60-80% of CPU time mainly due to QT overhead. So, another approach to abandon. :-)

Final solution: FBCON

Well, for someone this might be absolutely obvious solution, but sometimes obvious ideas are just ignored... So, what did I do? Well, I already had a console on which I tried to make QT run. So how about some application capable of printing status on console? YEAH.... that was the way. There is bunch of these tools:

Since I am using Arch Linux, I created restricted user just for monitoring purpose, with automated login on defined console. After bootup and login, script is executed and monitoring is started. To avoid wear-out of the display, I configured console blanking timeout, which switches display off after a minute of inactivity - using setterm command. Would be great if I could wakeup the display on event of touch screen tap, but it is topic for later. So far, I have a USB keyboard, which wakes-up screen upon keypress.