Skip to content
Aetf edited this page Sep 6, 2018 · 1 revision

This is a list of the most commonly asked questions and misconceptions.

The console belongs in the kernel so it can run under memory pressure and/or during system failure!

As a matter of fact the in-kernel linux console does not run under memory-pressure or during system failure, either. Therefore, there is no disadvantage in running the console in user-space. In fact, the kernel console and kmscon only implement the rendering pipeline for the text console. Anything you do with it or any program that you run on the console (including a shell like bash) runs in user-space! And when the system fails and user-space is no longer working correctly, then your bash won't run either so there is no point in having a working console layer when there is nothing to show.

Why replacing a working and fully functional console?

There are many different reasons why kmscon is needed. Some are only cosmetic reasons but others are solutions to big restrictions of the linux kernel console layer. The most notably ones include:

  • Full internationalization support. No-one wants (and we currently do not have) full internationalized keyboard handling in the kernel. There is also no way to print a full CJK character set or even the full Unicode character set on the linux console. Adding this to the kernel would mean having big character tables in non-swappable kernel memory. Therefore, implementing this in user-space is the only way.
  • Hardware accelerated drawing. With multi-seat becoming more and more common and multiple monitors connected to a single computer, we do not want to spend too much time drawing text on the CPU. However, using the GPU pipeline from the kernel would require new DRM APIs which are currently not available. With GPU-accelerated rendering we can also add anti-aliased fonts or soft-shadows which can enhance readability a lot (although others might consider this cosmetic changes).
  • Controllable Monitor/Console mapping. By using the DRM API we can have as many consoles simultaneously as we want and can map them to different monitors or clone the output. We can even span a console across multiple monitors.
  • Full vt220 to vt510 support. The kernel console supports only a small subset of the DEC VT APIs. It does not even correctly emulate the VT102 API (although it's pretty close to vt102). In user-space we can extend this to even support all the xterm supported escape sequences. This also includes a better scrollback-buffer which is pretty limited in the kernel console.

Another major point which does not have anything to do with functionality: UIs do not belong into the kernel. No one draws X11 GUIs or similar in the kernel so why should we draw text UIs in the kernel? User-space is responsible for that so lets move it there.

What happens to my boot-log, oops-log and emergency-log?

The in-kernel fbcon (or vgacon) driver is currently used for console handling and every other text output which includes the boot log (if enabled), the oops or kernel-panic log and other emergency logs. When disabling the built-in console the fbcon driver will not work anymore so these log-modes won't be available, either.

However, the kmscon repository includes an "fblog" called kernel driver that provides a simple text-output for exactly these cases. It will hopefully be merged into the mainline kernel, soon, so even with kmscon running you can get kernel-panics and boot-log displayed on the screen.

Is kmscon compatible with the kernel console?

Yes. Although kmscon was created to replace CONFIG_VT (the config option for the kernel console), it can smoothly run simultaneously with it. However, kmscon does not emulate the same terminal type as the linux console. There are several escape sequences and modes that only the linux console supports and no other emulator. But nearly no program requires them. So we decided to follow the xterm compatibility instead. That is, if you program runs under xterm (the de-facto standard in terminal emulators under linux) it should also run under kmscon (or at least that is the idea).

Is kmscon linux-only?

Yes. Feel free to port it to other platforms.

Kmscon has too many dependencies!

Kmscon has nearly no mandatory dependencies. Almost all dependencies are optional. However, without them you will lose functionality. But feel free to disable them if you do not require them.

  • libudev: Udev is used for hotplugging. It is a central part of almost every linux distribution and without it hotplugged devices will not be added to kmscon.
  • libsystemd-logind: Only used for multi-seat capable linux systems. If you do not use multiple seats, you can safely disable it.
  • mesa: Mesa is the OpenGL implementation for linux. If you don't want hardware accelerated drawing, you can disable it and use plain libdrm for modesetting. You can even disable libdrm and just use linux fbdev.
  • libxkbcommon: If you need keyboards with layouts other than US-ASCII, libxkbcommon is your friend. It handles everything which is keyboard related.
  • pango: Pango is used for text-rendering. Disable it and the built-in static 8x16 font will be used.