Several people have answered the parts of your question dealing with the kernel and putting images (rather than text) onto the framebuffer, but so far the rest remains unaddressed. Yes, you can use the kernel virtual terminal subsystem to make a so-called framebuffer console. But there are several tools that allow you to use the framebuffer device to make user-space virtual terminals. These include:
- zhcon (Debian) — a userspace virtual terminal geared towards handling CJK I/O far better than the kernel subsystem. Its particular strength is in handling ISO 2022 non-UTF encodings; its particular weakness is UTF encodings.
- fbterm (Debian) — a userspace virtual terminal that has spawned several forks including jfbterm. It has a bunch of CJK input method plug-ins.
- bogl-bterm (Debian) — a userspace virtual terminal that has spawned forks such as niterm.
- Ali Gholami Rudi's fbpad — a minimalist userspace virtual terminal that has no dependencies on X libraries.
console-fb-realizer tools in nosh — a userspace virtual terminal aimed at replicating Linux and FreeBSD/PC-BSD kernel virtual terminals. It too has no dependencies on X libraries.
- kmscon — a userspace virtual terminal that is closely linked to the
logind server in systemd and its notions of "seats".
Ali Gholami Rudi in particular has produced more than just a terminal emulator for framebuffer work. He also wrote a direct-to-framebuffer PDF viewer, VNC viewer, media player, and Quran reader.
A full side-by-side comparison is outwith the scope of this answer; but here are some points that are relevant to the question:
- As noted, several of the user-space virtual terminal programs make use of X libraries for font handling, keyboard mapping, CJK input methods, and so forth. They are not X clients, but they have dependencies from X libraries.
fbpad and the nosh tools by design do not make use of any X libraries.
- The programs that use X libraries for font handling do of course use X fonts. The others make other arrangements.
- bogl-bterm and fbpad both have their own idiosyncratic font formats. One converts BDF fonts to BOGL fonts with the
bdftobogl tool; and one converts TTF to the "tinyfont" fonts that are used by fbpad with the ft2tf (Arch) tool.
- The nosh
console-fb-realizer tool uses the same "vt" fonts as the new FreeBSD 10.1 kernel virtual terminal subsystem does, and thus shares the FreeBSD font manipulation tool
vtfontcvt for converting BDF fonts.
- The programs that use X libraries use X keyboard mapping. As for the others:
- The nosh tools have their own idiosyncratic keyboard map format, intended to provide a full ISO 9995-3 capable keyboard with the ISO "common" group 2. One converts BSD kbdmap files to this format with the
console-convert-kbdmap tool. Again, these kbdmap files are the ones used with the FreeBSD/PC-BSD vt subsystem.
- fbpad doesn't do its own keyboard mapping at all, and relies upon the presence of the kernel virtual terminal subsystem and its keyboard mapping mechanism for that.
- There's some variance in invocation and required privileges:
- zhcon, fbterm, bogl-bterm, fbpad, and kmscon work on the basis that the terminal emulator spawns the shell/login program on the terminal, directly, as a child process. They need superuser privileges in order to spawn
- The nosh tools were designed to integrate with an existing
/etc/inittab (Linux system 5
init), or other system, to which they leave the job of spawning getty/login/shell.
console-fb-realizer only needs enough privileges to open the framebuffer and input event devices, which need not be superuser privileges, and to access the FIFOs and ordinary files maintained by
console-terminal-emulator, which in turn doesn't need any special privileges at all.
All of these are terminal emulators of course. If you want to take the terminal emulation out and put text on the framebuffer more directly, you have some choices:
- bogl-bterm is of course based upon Ben Pfaff's Ben's Own Graphics Library a framebuffer I/O library designed for use in system setup/rescue environments (and "for GUIs in PDAs"). You can of course write programs that use that directly.
- For a halfway house between writing a program that makes use of a framebuffer library to do its own rendering and a program that spits out escape sequences to what it thinks is a terminal: The nosh user-space virtual terminal is modular, and splits apart into component pieces. One can simply not use
console-fb-realizer uses a display file with a character cell array, like
/dev/vcsa* but an ordinary file (not a character special device file) and with Unicode code points, ECMA-48 attributes, and 24-bit RGB colour. So one can run it up and just write character+attribute+colour directly into the character cell array file, letting
console-fb-realizer do the font rendering to the framebuffer.
As an aside: Observe that this is the opposite of integration with BRLTTY, which uses
console-terminal-emulator but doesn't run