How do I set up a framebuffer terminal emulator and get more than 8 or 16 colors without running a display server?

General Discussion
1

What I am trying to do:

I am trying to build a lightweight computer powered by a Pi Zero 2 W, to be operated entirely from the command line with tmux and plug-ins, outputting to a permanently attached display connected by HDMI.

I would like to have more than 16 colors so that I can use nice color schemes in tux, nvim, and other text-based programs. I would also like to see Unicode characters like emojis. And in a pinch, it would be cool to be able to run lightweight graphical programs without a display server – I’m thinking viewing PDFs, for example.

Why I am attempting to run a terminal emulator without a display server:

I understand that the Linux kernel supports only 8 or 16 colors, so to do what I want, I understand that I’ll need to run a terminal emulator through a display interface.

Because I want to run as lean as possible, I don’t want to load Xorg or Wayland to do this – I understand that working directly on a framebuffer is a viable lightweight alternative.

Unfortunately, I do not yet understand enough about Linux initialization, tty, or addressing the framebuffer to set this all up correctly. It is also possible that my understanding thus far is incorrect.

Where I am stuck:

I have installed fbterm (framebuffer terminal emulator), but I can see only 8 colors (again, on the display connected by HDMI).

I have attempted to configure /usr/lib/systemd/system/getty@service to launch fbterm directly at login, but I do not know how to do that correctly, or even if that will accomplish my intended result.

tput colors through tmux in fbterm returns 256 but running this simple test script displays only 8 unique colors [https://askubuntu.com/questions/821157/print-a-256-color-test-pattern-in-the-terminal/821163#821163\].

Over ssh I can see 256 colors, and colors set by tmux plugins appear correct. My issue is that I intend to operate this machine primarily through its own physically attached display.

If anyone here is knowledgeable about doing things on the framebuffer, I would love some advice or even just corrections on any misunderstandings I may have.

2

Exactly, the linux console can only display 16 colors.
As far a I know fbterm also only supports 16 colors and the development is abondened.
To achieve your goal (256 colors, view PDFs and emoijs), without wayland or xserver, you would need to use

  • vc4-kms-v3d driver
  • use a wayland terminal like foot, but without using wayland (yes, this is possible) and build foot by your own, with the use of some special flags
  • create a systemd service to replace getty with foot

I will test this on my RPi 3B before I post a step-by-step guide

edit: It did not work

3

So kinda GUI terminal emulator without windowing system, using DRM/KMS directly. Sounds interesting.

I mean yeah, no witchcraft, just that the need for a console outside of a desktop environment, while the plain Linux console it not enough, is probably a rare thing.

foot has this client/server mode, where the server instance handles Wayland communication. So it is also starting a Wayland instance then I suppose, which starts drawing once you run footclient? Or is there really a way to use it without Wayland at all? :eyes:

4

All my attempts failed, foot is not working without wayland (the AI was hallucinating :sweat_smile:)
but I also got it not to work with fbterm, I only got 16 colors no matter what I tried.

There is also kmscon but I didn’t try it.

Edit:
kmscon is too old, it#s unmaintained for 12 years.
The build fails when trying to use SIGUNUSED which does not exist anymore on modern systems.

5

Ah, interesting – good to know but sad to hear. Thank you both for your insight and effort.

Terminology [https://github.com/borisfaure/terminology], based on the Enlightenment Foundation Libraries, purports to have the option to render directly to the framebuffer.

According to this post [ framebuffer support ? · kovidgoyal/kitty · Discussion #6098 · GitHub ], the Debian testing repository build is compiled with framebuffer support, but my naive attempt to run it from DietPi on the Pi Zero 2 W resulted in several errors (I don’t precisely recall them off-hand, but I believe they were about being unable to find or start Wayland) and no working terminology. Perhaps the aarch64 build isn’t compiled for framebuffer support? Or perhaps there’s another unmet dependency I did not see.

Has anyone here used Terminology (or Enlightenment generally) on DietPi?

6

I don’t have, but I will build by myself and give it a try.

edit:

Ah you have to build the enlightment core library with this, so I will not do this then. I thought it’s just about terminilogy itself.

Hmm maybe I will try to install it from debian repo, it’s even in stable:
https://packages.debian.org/trixie/terminology

Works in X11, Wayland and directly in the Linux framebuffer (fbcon)

1 Like
7 
root@TestPi3B:~# ls /usr/lib/aarch64-linux-gnu/ecore_evas/engines
drm extn fb wayland x 

root@TestPi3B:~# ls /usr/lib/aarch64-linux-gnu/evas/modules/engines
buffer gl_generic gl_x11 software_x11 wayland_egl wayland_shm

So it’s not build with fb support, fb is missing in the second output.
I fiddled with some other things but got only black screen with terminology :melting_face: