Monochrome terminal setup for an E-ink monitor

Small writeup about using a monochrome display in a modern environment.

Rationale

Several months ago I obtained my first e-ink device - Rakuten Kobo Libra 2. It is a small ebook reader with high resolution screen and and I immediately got enchanted by this crisp screen that can be used without any level of backlight whatsoever. It feels as natural and comfortable as reading something from a sheet of paper, so I thought that it would be awesome to use something similar for coding and reading from screen at my computer. Furthermore now I read way more than before - tablet or cellphone often sway me off to “cheap” content such as twitch/youtube videos or mindless web surfing, whereas an ebook keeps me away from distractions. Turns out it is easier to fight bad habits by artificially restricting access to them rather than by making a conscious mental effort of not doing something you later regret :)

So apart from purely ergonomic reasons I had an idea of abandoning some guilty pleasures - being able to properly concentrate sadly is no small task, at least for me.

Hardware

Regrettably there are not many consumer-oriented e-ink displays on the market yet. Essentially the only choices are BOOX Mira or Dasung Paperlike solutions; both vendors prices are quite high compared to the conventional (even good IPS ones) monitors. I was able to find a barely used Dasung Paperlike HD-FT 13.3" for about $750 on eBay.

The specs are mighty impressive: 2200x1650px resolution (4x3 aspect ratio), HDMI interface (+microUSB for power), digitizer (touchscreen) and two types of backlight (warm/cold). There are e-ink (or “e-paper” as they’re sometimes called) displays that do not require any additional power apart from HDMI current, sadly mine is not one of those - even with the backlight turned off it doesn’t work on HDMI connection alone.

I’m using that display with a generic x86_64 laptop running Fedora KDE spin. macOS connection went fine too; I have another arm64 machine with OpenBSD 7.2 but it wasn’t able to use the new monitor as is, needs some tinkering that I’ve postponed to another time.

Monitor setup panel shows the only available frequency at 40Hz but that is probably being used for internal processing inside of the display circuitry; albeit tunable the framerate of that particular e-ink monitor is about 15fps.

The quality and contrast is quite to my liking - there is some inevitable residual ghosting that can be cleared off with a dedicated button but I don’t resort to it much. I don’t turn on the backlight either because the whole point of that tech for me was to be able to use terminal and other software with natural light or desk lamp only.

Note that both photos were made with only external light - the text is crisp and the contrast is superb.

(Terminal) Software

Since most the of stuff I do happens in terminal (emulator) setting it up was my primary target. That’s where things got truly interesting - as it appears terminfo(5) terminal capabilities database varies quite a lot between different operating systems.

Basically different terminal emulators support different features varying from unicode support to 24bit colour or even graphics. Those capabilities are compiled into binary files that are queried in library functions calls to determine what is supported by the selected terminal. So we have a whole lot of terminal types - from vintage vt100 to modern ones such as xterm or kitty in a bunch of different files (usually in /usr/share/terminfo).

The type of the terminal used is set by the TERM environment variable - so program that uses the terminal output looks up into terminfo database - either via ncurses(3) library calls or via helper programs if it is a shell script. In order to determine how many colours supports the current terminal emulator the variable colors has to be read from the database file corresponding to the TERM.

The issue I’ve stumbled upon is that contents of said database are not exactly synchronized between various OS. My first TERM env choice was fairly straightforward "xterm-mono" and it worked perfectly on my main rig with Fedora - right until I’ve ssh-ed to my other machines. xterm-mono does not exist neither in OpenBSD 7.2 nor macOS Ventura - even though both are the latest versions released (at the time being). Apparent legacy version of that terminal type - xtermm - was not available everywhere too.

Luckily enough #cyberpals recommended me a vt220 - it is an old hardware terminal, and while it didn’t have color it still was quite feature rich and supported enough to use it even with modern systems.

What I did after was making a new konsole settings profile. I’ve put TERM=vt220 in its env vars option and configured the color scheme that so it only has two colors for entire palette. Now why would I do that if my terminal was already advertising everywhere that it is monochrome and everything rendered there acts accordingly without any colorcodes?

The answer is quite simple - a lot of programs ignore that info completely. To my big surprise even fairly respectable software like git does not query the terminal capabilities database and instead resorts to that (editor.c):

int is_terminal_dumb(void)
{
    const char *terminal = getenv("TERM");
    return !terminal || !strcmp(terminal, "dumb");
}

Interestingly enough git does not have any common --no-color command line option - it is present only in certain binaries (git log but not git status) of its package, another dangling inconsistently. To fully disable color output for any git command I’ve set a following option in global .gitconfig:

[color]
    ui = false

Speaking of syntax highlighting - I’ve thought that the lack of color would severely hinder me when coding, but as it turns out the most basic stuff like bold or italic suffices just fine. Couple of years ago I switched from bloated IDEs to more compact and portable nano - and by IDE I mean vim as well (that I’ve been using for more than a decade). The switch took some time to accommodate but overall I can’t say that my productivity worsened in any capacity. Moreover I feel like I remember more information from top of my head and try to implement stuff in self-explanatory way - partially because it is easier to comprehend and navigate such code with just plain text editor. In many ways my setup overlaps with UNIX as IDE series.

So in same sense losing color only seemed to be a big deal at first - for tasks such as reading and programming monochrome editor ends up just as effective as “colorful” environments. Additionally I was heavily impressed and inspired by jcs’ system6 programming series - the old Mac 512K has monochrome display but jcs is able to write so much good code with it that it becomes obvious that syntax highlighting doesn’t play as big of a role as it is believed to be.

(GUI) software

The official websites for e-ink monitors are full of videos and screenshots of programs such as Google Docs or MS Word or web browsers with fancy formatted articles, but in my experience even when you can tune up visuals to be displayed properly in monochrome the ability to fully control program with a keyboard is not always there. Quite often GUI expect you to interact with them fully with a mouse or a trackpad, and with extremely low framerate situation it becomes quite awkward.

Long story short - choppy mouse cursor and interfaces not always expecting the absence of color ceased any efforts of mine to use those beautiful modern hidpi interfaces on the Dasung.

I’m still using an LCD display for web-browsing and such but it is positioned at the angle that I can comfortably use only 1 display at time.

Full setup