Hi 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: http://cgit.freedesktop.org/~dvdhrm/systemd/log/?h=console Notes on where this is going, and *why*, below.. Happy Testing! David 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 kernel*! 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 dependencies. 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 eye-candy! - systemd-welcomed: A login-screen to spawn sessions. This basically replaces /sbin/agetty and /bin/login on a VT. After login it spawns systemd-consoled. - 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 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 -- 1.8.4.2 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel