Virtual console on 20x4 using lcdproc and lcdvc

[Hrnek Bezucha]

Hello everyone,

There's this personal project of mine, having a 20x4 generic Hitachi-driven display (with I2C driver module) with a small keypad from Xbox controller addon (SPI) and all enclosed with a Raspberry pi zero and a lipo battery in 3D printed custom case. Think of it as a digital pocket teletype. Currently I'm in the "figuring out" stage, trying to come up with possible implementations. So far I found that trying to use a character LCD as the main console output device is really tricky. When I was losing hope, somebody mentioned this project and the lcdvc client, which made me super excited for it. I'm just reading through the documentation (0.5.7) and don't see that much about using the lcd as the main TTY output, which is what I'm after. 20x4 is woefully small for any serious use but this isn't a serious project ;). That's what the lcdvc client is for but there's not much to read up about it.

If you could evaluate whether this is a viable/reasonable approach to take versus a matrix LCD and nudge me in a direction to take. The I2C port connections and communication are nicely explained but I don't really know about the lcdvc, there's just an init.

This is my very first mailing list experience. Thanks for all of your replies,

Hrnek

[Harald Geyer]

Hi Hrnek,

welcome to lcdproc development!

I have never used lcdvc myself and I don't fully understand your
message, but the general idea seems sound. A few comments:

1) AFAIK lcdvc is not a terminal emulator. Instead it attaches to one
of the terminals already existing on the system. I believe this is
exactly what you are looking for anyway, so no need to mess with init
or anything.

2) Even if you display is only 20x4 the terminal can (and usually will)
be much larger. lcdvcs support scrolling the viewport to cover the entire
terminal it is attached to. I'm not sure if lcdvc can easily forward
keyboard input to the terminal it is attached to, but maybe it is better
to use the keypad as input device to linux directly instead of routing
it via lcdproc.

3) As lcdproc works over internet sockets, you can install lcdvc on our
embedded target system but install LCDd on your workstation using the
curses driver, for development/debugging purposes. This way you can
test the interaction of lcdvc with the system terminal and your general
workflow before needing to deal with any actual hardware.

BTW, I initially came to lcdproc because of a similar project, but never
went through with it (neiter with lcdproc nor with fbtft), but found
other uses for lcdproc along the way.

HTH,
Harald

--
If you want to support my work:
see http://friends.ccbib.org/harald/supporting/
or donate via CLAM to xASPBtezLNqj4cUe8MT5nZjthRSEjrRQXN
or via peercoin to P98LRdhit3gZbHDBe7ta5jtXrMJUms4p7w