First step would be to make the driver work. We would need to first know what "breaks" it. Best is to play around with the various command line options of the lcdproc client. As you mentioned, some client functions just call for characters, but others invoke big numbers, horizontal or vertical bars. These invoke a bit of contortion in the code involving swapping bitmaps for what is generally a very limited number of custom/graphic characters. Once we know what breaks, we can look into the best path forward for a code fix:

Have you tried running the lcdproc client just for load average? It is just text. Maybe the more complex displays involving histograms, etc. are not working quite right.

It looks like you are already running this with a high reporting level. Are you seeing any/all the messages on stderr? I would try all of this on the command line first, and do the VyOS cli later.

I need to reopen the code from the lcdproc project as well as the platform package from Lanner and "compare".

Tentative first-shot code change here:

Created pull requests #477 and #269

Documentation commit here: GitHub fmertz/vyos-documentation/commits/system-display

Update: After hooking up an actual EZIO device to my VM and working the code back and forth, I seem to have settled on this design:

FWIW, this integration package is coming along nicely. I was able to create the XML CLI. The python code is kept to a minimum by passing a dictionary of the Config to the template engine "render". At this point, I can generate the proper LCDd.conf and lcdproc.conf based on the CLI. I now need to work on start/stop/restart as well as (basic) config validation. I have nothing for lcdexec/menu this far.

OK, another approach question.

At this point, i could use a couple of wise words for the development process.

OK, question on the approach. Looking at LCDd.conf (check the link above), there are a few server options, but TONS of individual driver options. Doing some sort of complete support in VYOS would be fairly straightforward, but would lead to a massive XML file. The lcdproc project has been around a while, so there are many different devices that are supported, most possibly somewhat historic or even one-off. We can (artificially) categorize them in 2 groups:

Overview of the effort:

Virtualization would work fine. The daemon/server LCDd is just code, and can be configured to run a nCurses "driver". Some other drivers only do parallel port stuff so would do nothing in a virtual environment. Other drivers do serial port and I suppose the data stream could be monitored. The clients (lcdproc, lcdexec, etc) are just programs that push data to LCDd over TCP.