[systemd-devel] [RFC 00/12] Bugfixes for CONFIG_VT=n

David Herrmann dh.herrmann at gmail.com
Wed Nov 27 10:48:35 PST 2013


So booting without VTs is still a horrible experience on desktop-linux. If
anyone tried, they were presumably running away in tears. This series is a new
attempt to fix that.

The first 4 patches are just small fixes/helpers. Patch 5 to 8 introduce sd-gfx
and patch 9-11 add tests/examples for sd-gfx. The final patch adds a first user
of sd-gfx to replace the kernel-internal terminal-emulator. The commit-msgs
should explain each change at length so I won't repeat it here.

To anyone interested in testing: If you apply this series, you can run
"./test-kbd" to test keyboard handling, "./test-gfx" to test graphics rendering
and "./systemd-consoled" to run the terminal-emulator. Note that you must run
all these from *within* an existing logind-session. That usually means from a
TEXT-VT. Also note that all these programs currently ignore the underlying VT
entirely (in case you run with CONFIG_VT=y). This has the side-effect, that all
keystrokes go to both, the VT and the application. This will obviously be
changed in later versions, but I wanted to avoid any VT calls in these helpers.
I currently work on logind to fix that.

I had to strip the font-patches due to ML size-constraints. The full series is
always available on the-often-rebased-console-branch at:

Notes on where this is going, and *why*, below..

Happy Testing!

What is wrong with CONFIG_VT?

The VT layer in the kernel implements a rather complex keyboard layer (similar
to XKB, but less powerful), implements hard-coded device hotplug filters, input
handling, graphics-pipeline handling, font-rendering, terminal-emulation,
cursor handling and more. All this is used to render a basic text-UI *in the
However, moving UI handling into the kernel has a lot of disadvantages (the
same reason why user-space exists.. look it up). For completeness, some rather
obvious reasons are:
 - non-swappable memory (even if you have no swap-partition, user-space apps
   can avoid loading all fonts/keymaps into memory, which kernel-space cannot)
 - security critical (any bug in the UI layer may allow *kernel-level*
   privileges to attackers)
 - stability (user-space apps can be easily restarted on failure; in
   kernel-space, all kinds of memory may get overwritten..)
 - code-duplication (we already have all this code in user-space, why copy it
   into kernel-space?)
 - simplicity (we wanna keep the kernel simple and slim, which prevents adding
   more complex features like fully internationalized fonts and keymaps, which
   are *required* for emergency consoles with given keyboards)
 - configurability/controllability (ever tried assigning more/less CPU-time
   to a given VT?)
 - ...

So what reasons exist to have a UI layer in kernel-space? I only found 3
reasons, if someone knows more, let me know. I highly doubt there's more..
 1) Early boot debugging
 2) Panic/Oops screen
 3) kdb kernel debugging
For 1) and 2) we have an experimental fblog/drmlog kernel module which just
prints the kernel log to all screens. This only requires ASCII glyphs and raw
access to DRM FBs. All the VT cruft can be dropped..
For 3): You're welcome to enable CONFIG_VT if you need a terminal-emulator for
kernel-debugging. My experience is that a serial-console is far more helpful and
reliable and avoids calling DRM modesetting in atomic-context (ugh? This fact
really makes me doubt anyone uses kdb.. Use kgdb!).

Long-term plan

So the long-term plan for this series is to set CONFIG_VT=n. This actually
already works and you can boot your machine and start sessions like kmscon.
Even Xorg works if you apply a one-line patch. However, without VTs, legacy
sessions like Xorg will run in exclusive mode. To allow session switching, you
need systemd-logind. But even session-switching is already implemented. Though,
no real application uses that, yet (except for weston and some example code).

So most of the work is to fix all these applications to support VT-less mode.
This is already ongoing and will work soon (hopefully..).

So what does this series implement?
Well, if you run without VTs, you lack any kind of fallback console or fallback
login-screen. To guarantee that even without VTs there's a system-console and
login-screen, this series adds the most basic implementations of those to
systemd. This will *never* turn into a full-blown full-featured console. No
eye-candy, no useless features, NO BACKGROUND IMAGES!!!
The idea is to provide a fallback in systemd. If you want a fancy console with
more features, install kmscon and it will simply replace the systemd-fallback.
However, that means more memory-footprint, more CPU-requirements and a lot more

sd-gfx is a helper library in systemd to unify all the graphics, screen and font
handling. All following applications will use it, including:
 (daemon-names are subject to change!)
 - systemd-consoled: A systemd console (basic terminal emulator) used as
                     fallback session/console.
 - systemd-splashd: A boot-splash for initrds. This will not include eye-candy
                    but is only required to accept password-input for
                    encrypted root-partitions. Use Plymouth if you want
 - systemd-welcomed: A login-screen to spawn sessions. This basically replaces
                     /sbin/agetty and /bin/login on a VT. After login it spawns
 - systemd-er: The emergency-room helper. Basically an even-more stripped down
               systemd-consoled designed for developers. It avoids
               session-management, seat-assignments, privilege-separation and
               is just an hopefully-always-working-emergency-console. It's not
               enabled by default. Think of it as a userspace-variant of
               "magic sysrq".

This is stupid, why do you..

..add so many dependencies and code to systemd?
    You should consider that currently all that code is part of the *kernel*.
    All this does is moving it out of the kernel. The first place that comes to
    mind is systemd (and I couldn't imagine a better place, can you?).
    Knowing that systemd already depends on the kernel, technically this doesn't
    increase the codebase of systemd at all.

..kill my beloved kernel-console / linux-console?
  I don't. Just set CONFIG_VT=y.

..duplicate kmscon?
    Well, I wrote that and I consider it a successfull research project. Now
    it's time to write something useful based on the lessons learned with
    kmscon. No first attempt ever succeeds, right?

..miss the fact that a kernel-console is more reliable than user-space?
    It's not. Why do you think that? You need a running shell to do anything
    useful with a console. Where do you think this shell runs? (Hint: it's not
    kernel-space.. and not outer space.. I wonder what "space" is left? Oh,
    none, because your in-kernel fonts are non-swappable!)

..kill my panic/oops screen?
    I don't. See above. I wrote fblog/drmlog for that.

..change a running system?
    To make it better!

..add useful features like full-BMP-range Unicode-fonts, properly
  internationalized keymaps, readable fonts on high-DPI displays,
  access-separation, accessibility helpers and more to the system console?
    Wait.. that's obvious, isn't it?

Besides, coding is fun!

David Herrmann (12):
  event: allow EPOLLET as event flag
  ring: add basic ring-buffer helper
  bus: add two new bus_*_map_*_properties() helpers
  build: add target to link binary sources
  gfx: add sd-gfx library with unifont section
  gfx: add keyboard layer
  gfx: add graphics layer
  gfx: add monitor
  gfx: add kbd test
  gfx: add graphics test
  gfx: add unbuilt GL test
  console: add systemd-consoled

 .gitignore                       |     4 +
 Makefile.am                      |   129 +
 configure.ac                     |    38 +
 make-unifont.py                  |   138 +
 src/console/Makefile             |     1 +
 src/console/consoled-pty.c       |   391 +
 src/console/consoled-screen.c    |   170 +
 src/console/consoled-terminal.c  |   371 +
 src/console/consoled.c           |   278 +
 src/console/consoled.h           |   128 +
 src/libsystemd-bus/bus-util.c    |    87 +-
 src/libsystemd-bus/bus-util.h    |     6 +
 src/libsystemd-bus/sd-event.c    |     4 +-
 src/libsystemd-gfx/.gitignore    |     1 +
 src/libsystemd-gfx/Makefile      |     1 +
 src/libsystemd-gfx/gfx-drm.c     |  2551 ++
 src/libsystemd-gfx/gfx-kbd.c     |   629 +
 src/libsystemd-gfx/gfx-monitor.c |  1767 ++
 src/libsystemd-gfx/gfx-unifont.c |   273 +
 src/libsystemd-gfx/test-gfx.c    |   302 +
 src/libsystemd-gfx/test-gl.c     |   342 +
 src/libsystemd-gfx/test-kbd.c    |   314 +
 src/libsystemd-gfx/unifont.bin   |   Bin 0 -> 2162688 bytes
 src/libsystemd-gfx/unifont.hex   | 63488 +++++++++++++++++++++++++++++++++++++
 src/shared/ring.c                |   213 +
 src/shared/ring.h                |    54 +
 src/systemd/sd-gfx.h             |   405 +
 27 files changed, 72058 insertions(+), 27 deletions(-)
 create mode 100755 make-unifont.py
 create mode 120000 src/console/Makefile
 create mode 100644 src/console/consoled-pty.c
 create mode 100644 src/console/consoled-screen.c
 create mode 100644 src/console/consoled-terminal.c
 create mode 100644 src/console/consoled.c
 create mode 100644 src/console/consoled.h
 create mode 100644 src/libsystemd-gfx/.gitignore
 create mode 120000 src/libsystemd-gfx/Makefile
 create mode 100644 src/libsystemd-gfx/gfx-drm.c
 create mode 100644 src/libsystemd-gfx/gfx-kbd.c
 create mode 100644 src/libsystemd-gfx/gfx-monitor.c
 create mode 100644 src/libsystemd-gfx/gfx-unifont.c
 create mode 100644 src/libsystemd-gfx/test-gfx.c
 create mode 100644 src/libsystemd-gfx/test-gl.c
 create mode 100644 src/libsystemd-gfx/test-kbd.c
 create mode 100644 src/libsystemd-gfx/unifont.bin
 create mode 100644 src/libsystemd-gfx/unifont.hex
 create mode 100644 src/shared/ring.c
 create mode 100644 src/shared/ring.h
 create mode 100644 src/systemd/sd-gfx.h


More information about the systemd-devel mailing list