| The “right thing” here, if: • you’ve got a RasPi running Linux (Raspbian) • you want to drive a novel display with it • you want the contents of the display to be regular Linux text-mode console output, with regular Linux text-mode console input ...would be to just write a Linux kernel framebuffer driver for your novel display device, and then drop it into the Raspbian kernel tree, recompile, and deploy to your device, no? Then there’d be no other custom software needed. You’d just have a regular Linux system, with a regular Linux console TTY, mapped to a grid of pixels by the Linux framebuffer code (bonus: in whatever bitmap font you wish), in turn bit-banged to the display device’s IO port using your driver’s custom refresh sequences. Sure, this approach requires learning some new codebases (Linux kernel driver development!) but so does the “user-mode driver” approach in the article. |
Linux is an xNix. xNix was written for teletypes: a fundamentally scrolling medium.
E-ink does not scroll well. Updating the whole display is bad. It take a long time, it blurs into illegibility, it could even wear out the panel.
Compare to the behaviour of 1980s 8-bit machines.
Examples:
• Sinclair BASIC's knew that scrolling took a long time and was CPU-intensive, and so when it was happening, it was hard to interrupt -- it would be slow anyway, and if you kept polling for an interrupt keystroke it would be slower still. So, when the screen was about to scroll, they prompted: ... scroll? (Y/N) And you could say no.
• The Locoscript word-processor for the Amstrad PCW range (maybe the best-selling CP/M machines in history, with millions of units of only about 3 models). LocoScript was one of the most polished 8-bit WPs ever. The programmers knew that trying to move all the text along the screen live when inserting would be painfully slow, so when you went back to add a word, it split the text at that point. The next line was moved down a blank line, and so did not have to update or reformat. If you added more than a line, the text below only had to be scrolled once per line. When you were finished and moved the cursor past the insertion point, it reflowed and redrew the text from then on -- just once.
But these are specific niche programs. It's not possible to be so general on Linux because you don't know what program will write what to the screen.
The problem is this:
What you really want to do with e-ink is to fill the screen, either all at once -- no use for interactivity -- or one character at a time (which is doable), and then when it gets to the end.
So how about: a pseudo-terminal that detects when the console is about to scroll, and instead of scrolling, just resets the whole thing, clears the screen, and starts to redraw it again at top left.
Continuous output -- e.g. dmesg or catting a file -- would fill the screen, clear it, and redraw, over and over.
Full-screen editors would need to be aware of it but there are about a million FOSS text editors out there. This is not beyond the wit of mankind.