Deprecating CONFIG_VT

CONFIG_VT is the kernel configuration option for the VT subsystem of the linux kernel. It enables the in-kernel VT102 emulator which is also known as “linux kernel console” or “VT-1 to VT-6” or “<ctrl>+<alt>+<F1-F6>” or whatever you call it. It has been in the kernel since the beginning and people started integrating it into all parts of the system. This makes it much harder to remove it. But lets first look at the reasons why I think CONFIG_VT should be removed (or shorter: CONFIG_VT=n):

  • No multi-seat capabilities: The VT system is highly incompatible with multi-seat environments. Current multi-seat implementations simply bind all VTs to the default-seat (or “seat0”) and all other seats just ignore all VTs. Therefore, you can think of all other seats already running with CONFIG_VT=n.
  • No Unicode support: The linux console has very limited Unicode support. It can support UTF-8, but the fonts are too limited to even display all European languages (don’t let me even start talking about CJK…). This definitely needs to be replaced by a more internationalized console.
  • No internationalized keyboards: Similar to the bad Unicode support the keyboard-handling is bad, too. Xkb provides many more features that are needed to support fully internationalized keyboards. This definitely needs to be improved, too.
  • No Hardware-accelerated rendering: The linux console draws everything via simple 2D blitting operations directly into the framebuffer. This has been optimized with partial-redraws to improve performance. However, running linux on a slower machine with many monitors will horribly slow down your system. User-space can take advantage of OpenGL to draw consoles much faster.
  • Limited modesetting support: Modern graphics cards can run multiple monitors simultaneously. With the “DisplayLink” technology you can even add more via USB. The linux-console runs once per framebuffer and does not provide any mode-setting configuration. With the DRM API user-space can provide all this out-of-the-box.
  • Limited VT102 support: xterm, gnome-terminal, konsole, xfce-terminal, … all support much more than the limited VT102 functionality. The linux console does not even support the full VT100 specs. Moreover, it introduced many control-sequences that conflict with known control-sequences from other terminal emulators. Dropping the linux-console will help reducing conflicts between terminal-emulators.
  • Misdesigned VT API: This is kind of a personal issue, but I never liked the VT API. Synchronization is done via signals, acknowledgement requests are used and overall, it’s horrible to work with. The VT allocation/deallocation-logic is a mess and I never want to work with it again.
  • No AA-fonts: Anti-aliasing can enhance readability a lot even though some people might disable it for the same reasons. But linux is all about choice so lets support it.
  • Many more…

Some of the issues can be solved by improving the existing code. But this is not the solution as no-one wants the stuff in the kernel. Think of Xkb, pango, freetype2, mesa, etc. being in the kernel. No way that will be done. Terminal emulators might not be seen as GUI, but I think of them as UI. Hence, why would the kernel implement an UI? UIs belong to user-space, so do all terminal-emulators.

The curious reader might have noticed that many of the points are related to the linux-console, but the graphical VT API is independent of it. Technically, it would be much work splitting them off as they are tight strongly together in the kernel code. But many points also apply to the VT-API so getting rid of all of it seems to be the right way to me.


First of all, is there really a need for replacement? Graphical environments provide many terminal emulators and remote devices can be controlled via ssh. So I can only think of 2 obvious reasons why one wants the linux-console:

  1. Emergency console: In the past the xorg-server was often known to be buggy with new or fancy hardware. I think that this has improved considerably over the last years, but some might not agree. A safe fallback like the linux-console is nice to have to recover a system without rebooting. Or to fix your graphical-setup when your xorg-server won’t start up. However, please take into account that the kernel-console has no advantages over a console implemented in user-space. In fact, without a working user-space you will not be able to do anything with the kernel-console, either. It may be able to display information, but you cannot interact with it as your shell runs in user-space and every command that you execute runs in user-space, too.
  2. Lightweight UI: The xorg-server is heavy. It has lots of dependencies and many terminal emulators pull in a lot more. Even though I think that this can be reduced to a very lightweight xorg-server, the linux-console comes without any dependencies which is really nice for smaller systems and debugging.

I think both points are quite important but aren’t tightly bound CONFIG_VT. I recently started working on kmscon, a terminal-emulator implemented in user-space which integrates perfectly well with multi-seat and/or non-graphical environments. It can be built without any dependencies but has optional support for all the feature mentioned above including hardware-accelerated rendering and full internationalization support. It serves on my machines as emergency-console and replaces the linux-console. It is also very lightweight if built without all the optional extensions, but still provides more features than the linux console. It is still experimental, though.

Then there is also fblog. It is a kernel driver which I recently posted to the LKML for inclusion into mainline. It is still under development but is a nice kernel-log-display and replacement for fbcon. It cannot be used with CONFIG_VT enabled as it conflicts with the kernel-console and provides a subset of the features. When enabled, fblog prints the in-kernel log-buffer onto all connected framebuffers. This allows debugging of kernel errors, kernel boot, kernel panics, kernel oopses and more when user-space failed. Without CONFIG_VT there is no driver displaying this information and one would have to use a serial-console or similar. fblog comes in handy by displaying this information to all connected framebuffers. It can be enabled during boot/shutdown and when requested. It can be disabled when starting a graphical-environment and re-enabled when stopping it.


There are still problems when removing CONFIG_VT. If you want to run two applications (lets say kmscon and xorg-server) simultaneously on one seat, how does one application know when it is active and when to go into background. This was done with the VT-API but it is no longer available. Of-course, one could easily replace it with something newer, but many people think that this is not needed. Instead we should avoid the VT-logic entirely. Probably, we can use a system-compositor which is lightweight and synchronizes access to the graphics-devices.

I personally use another approach. I have a manager-daemon running in background which listens to keyboard-input. kmscon is automatically started on boot (but you could also easily make xorg-server the default) and if I press ctrl+mod4+F12 kmscon is notified by the manager-daemon to go into background and xorg-server is started. The xorg-server doesn’t include such a notification API and is very fragile when other applications access the graphics hardware at the same time. Therefore, I simply stop xorg-server and press ctrl+mod4+F12 again to get kmscon into foreground. Pressing ctrl+mod4+F12 twice very fast will attempt to kill all running xorg-servers or other graphical applications except kmscon and then push kmscon into foreground. This is some kind of emergency-helper when closing xorg-server is not possible.


The approach by the Wayland people is somewhat different. Without going into much detail about Wayland, you need to know that the Wayland API was designed to be stackable without any overhead. Or nearly no overhead. So you can run a system-compositor which has master-access to the graphics devices. All clients run full-screen and the windowing functionality is very limited. If you start kmscon, it should simply connect to the system-compositor and talk to the graphics-devices via the Wayland protocol. The same way should an xorg-server or normal Wayland-compositor (like Weston) connect to the system-compositor. Because every client is full-screen on the system-compositor it can simply forward the scan-out buffer to the hardware without copying any data. Hence, the system-compositor can be very lightweight and is super fast.

However, such an system-compositor is not yet available. The Weston compositor is still under heavy development and therefore, this is something where much work is still to do. But it looks like it will be the best replacement for CONFIG_VT and hopefully won’t take too long.


I think CONFIG_VT is dead. It hasn’t been updated for long and many better ideas have emerged. Many low-level projects are working towards making it obsolete and I hope I can continue contributing to this with fblog and kmscon. However, due to it’s tight integration into the whole system, it will be a hard task to replace CONFIG_VT entirely. As a first step it was already made optional by many applications due to multi-seat support. But the following work is much harder. Finding a good replacement which makes everyone happy. It will be interesting how people will accept it. Considering the hostility against the big changes in user-space that we have seen recently, it will be fun how people loose themselves to fight for their beloved linux-console. But maybe everyone is just happy about killing off CONFIG_VT. Lets hope for the best!

7 thoughts on “Deprecating CONFIG_VT

  1. Edward O'Callaghan

    I am hoping for the best, i.e. please kill CONFIG_VT !
    Also, could you please test your code with clang., if not already?
    All these patches keeping coming in to the linux kernel that break the linux built with clang project.
    Keep up your work!

    1. David Herrmann Post author

      Thanks! Regarding clang: If I use std-c89 only, then there shouldn’t be any reasons to test it, should there? But I will have a look. Thanks for the reminder.

  2. Meow

    Excited for kmscon and fblog. Is there any way to output kernel log information through kmscon without using a framebuffer? It’d be nice if there were a way to flag terminal connections at runtime for receiving kernel log messages. Kernel-fu’s a bit weak with me, so I’m not sure what the current state is, but being able to connect a terminal to the kernel log would help people learning about the kernel, too.

    1. David Herrmann Post author

      You mean some inline log? Like the kernel console does? Hm, there is no built-in functionality, yet. Feel free to file a bug/feature-report on github. However, you can run “kmscon -l — /bin/tail -f /var/log/messages” which will run kmscon showing the system log. As you can run kmscon multiple times (or you can run multiple terminals in a single process) you can put this log to tty12 or so. If you have no VTs, then this becomes more complex, but I am also working on this.

  3. navaati

    All of this is very interesting, and kmscon works perfectly, thanks for it (it enables me to have a full unicode console on a pc where X does glitch).
    But is it really possible at the moment to disable CONFIG_VT ? I’m trying to do it and it appears that FB depends on VT (and DRM depends on FB), so there’s no solution. Any idea about this ?

    1. David Herrmann Post author

      You need to enable CONFIG_EXPERT in the kernel to configure CONFIG_VT. I will send a patch removing the CONFIG_EXPERT dependency when I figured everything out. Until then it’s not really recommended to do it until you know exactly what it does.

      Anyway, if you still want to try it, you need to disable CONFIG_FRAMEBUFFER_CONSOLE and CONFIG_VGA_CONSOLE. You can then disable CONFIG_VT. CONFIG_FB cannot be disabled as all DRM drivers depend on it. I am working on making the FB dependency for DRM drivers optional, though. However, CONFIG_FB does not depend on VT, only FRAMEBUFFER_CONSOLE depends on VT. CONFIG_FB is independent of VTs and I am not planning on replacing it. Although, it _could_ be replaced easily with DRM drivers.

      If you want to try this, I recommend starting kmscon during bootup automatically (for instance via systemd). And I also recommend starting sshd automatically. Because if kmscon doesn’t start up you won’t have any other way than ssh to get a working shell on your system.

      I use a VT-less system here since several weeks now, but I haven’t written a tutorial, yet. I am working on new blog-posts about kmscon-6 which I released yesterday.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s