With a few small source changes I got inkvt to read from the BT kb evdev without issues. The device seems to lock or die when screen-drawing terminal apps run, which I'm guessing is because of inkvt's very simple buffering logic.
Rather than try to reinvent the wheel I went looking for other options & cross-compiled Debian's patched fbterm (+ deps freetype, fontconfig).
fbterm seems like it could work great: beautiful freetype font rendering w/ DejaVu mono & the emulator didn't choke on 2 tmux buffers + 1 running top. That said, some obvious UI stuff needs rearranging:
- fbterm itself never asks the eink panel to redraw from the framebuffer, so I had to do it myself blindly in the background with `watch -n 0.2 "fbink --refresh" &`. Maybe fbterm needs a new renderer that calls to NiLuJe FBInk for on-demand local redraw.
- fbterm input wasn't listening to the BT kb evdev; really it was taking inputs from the SSH tty (ultimately, my host PC's keyboard). Reassuring to see how responsive it is even with this extra hop. Not sure the right way to fix this, but a simple way is to start fbterm with an IM server that grabs the BT keyboard connected to the Kobo.
- It draws all over the native UI, which itself draws back over fbterm. Wifi disconnects often, Bluetooth turns itself off after a bit, device falls asleep. Other apps are managing this just fine, a helper script could fix all this.
Fixing these seems like a viable path towards a responsive terminal.