For about half a year I am now constantly working on a new project called kmscon. The idea emerged when reading on Jesse Barnes’ Blog about EGL+KMS. KMS stands for Kernel Mode Setting and is provided by the kernel DRM (Direct Rendering Manager) subsystem. The modesetting API (KMS) is a small part of the whole DRM API, but it works for all DRM drivers in the kernel. Therefore, with DRM you can get simple framebuffer access to all connected monitors. With udev you will also be notified about hot-plugged monitors. Perfect conditions for kmscon.
Kmscon is a small application that simply draws a VT220/VT102 compatible terminal emulator on all connected displays. A simple replacement for the kernel-console or for xterm. It is fully hot-plug capable and automatically detects all connected displays. It is multi-seat capable and only selects monitors that are assigned to the correct seat. It has only one mandatory dependency, which is libudev. This is used for device enumeration and hotplugging. All other dependencies are optional.
Main focus was not writing a decent VT220 emulator. There are lots of them out there (the guys from the Enlightenment project wrote one in under 1 month called terminology) and you can either include an existing one with kmscon or improve the kmscon vte layer. I rather focused on the integration with the operating system. kmscon runs without an X11 environment or any helpers. It needs to do everything on its own. No Gtk, no EFL, no Qt. Of course, they could be included and in fact, kmscon includes optional pango-font-renderers, however, at such a low level, you want at least the possibility to run kmscon without any of these dependencies. Therefore, bare kmscon uses a built-in static 8×16 font which is copied into the 2D framebuffers to draw a console.
Hardware-accelerated Rendering
If mesa is compiled with –with-egl-platforms=drm (which it is on all major distributions except Arch Linux) then we can get OpenGL contexts on bare DRM devices. This is done via EGL. kmscon includes an optional rendering backend for it when compiled with –enable-gles2. In combination with the Pango or Freetype2 font backends of kmscon, you get a hardware-accelerated console with anti-aliases fonts without any X11/Wayland/etc.
If you think this is overkill or if you have no idea why this is needed, then try running a console on a slower machine like the Intel Atom N450 or some Pentium III. Then use an application like “less” and scroll one screen at a time. This means, the whole console is redrawn on every keyboard input. My Atom N450 is fast enough to draw this but if I connect a second monitor, then this will get horribly slow very fast. Rendering both monitors takes about half a second here. When connecting 5 monitors via DisplayLink USB-devices, the performance will be horrible. Therefore, I am happy about every CPU-cycle I can safe by pushing rendering to the graphics-card.
The Use-Cases
I got much (often quite harsh) feedback that kmscon is again some software that is not needed as it replaces perfectly well-working software. Therefore, I want to explain what kmscon does better and why I need it. I compare it to the linux kernel-console as kmscon is a replacement for it:
- 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 in-kernel 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 BS).
- 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. I also think of some kind of “tabbed” consoles.
- 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.
- No CONFIG_VT. CONFIG_VT is the kernel config-option that enables the virtual-consoles. The reasons why I think it is bad are beyond the scope of this document, but kmscon was mainly designed to also work without VTs, that is, CONFIG_VT=n.
There are many more points, but these 5 points were important enough for me to start working on a replacement. However, I never tried making kmscon the main working console for your graphical environment. On the contrary, I personally still use xterm for my daily work, but as an emergency console I use kmscon. It works when everything else has failed and always provides me a safe fallback-console.
Furthermore, kmscon works perfectly well simultaneously with the kernel-console. So if you don’t like kmscon, then don’t use it. But if you want to give it a shot, you can use it in parallel with other VTs.
“The console belongs in the kernel so it can run under memory pressure and/or during system failure!”
I get this a lot. As a matter of fact the in-kernel linux console does not run under memory-pressure or during system failure, either. Therefore, there is almost 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.
And even if your video-driver fails, then your kernel-console cannot recover as you probably run fbcon which uses the same drivers as user-space. The only fallback would be vgacon which is only accessible from the kernel, but recovering via text-mode doesn’t work in most video-driver-failure-cases either. Therefore, this whole argument is simply wrong, but most of you probably know that already.
However, one needs to take into account that the kernel-console can also print kernel-panics/oopses. This cannot be done by kmscon or any replacement. But this feature does not require a terminal-emulator nor VTs so I wrote a replacement for this called fblog. This is in fact a very useful and prominent feature of the kernel-console which must remain in the kernel.
Kmscon facts
The current kmscon release is kmscon-3 which is still a development release. However, it works quite well on my machine and I would be glad to get some more testers. You can get more information on:
- WebPage: https://github.com/dvdhrm/kmscon/wiki
- Source-Code: https://github.com/dvdhrm/kmscon
- FAQ: https://github.com/dvdhrm/kmscon/wiki/FAQ
Kmscon has many features. Here is a list of the most important ones:
- Safe fallback rendering via /dev/fbX (simply run ./kmscon –fbdev)
- DRM dumb-fbs as 2D backend
- EGL+3D hardware-accelerated rendering when compiled with OpenGLESv2
- Full hotplug capable (monitors and input devices)
- Multi-seat capable
- Support for multiple monitors
- Almost full VT220 compatibility
- Modularized input/video/VT handling via libuterm
- Only libudev.so as mandatory dependency!
- Plain built-in optional keyboard backend
- Optional internationalized keyboard backend based on libxkbcommon.so
- Built-in VT-compatibility but also runs without VTs
- Fully Unicode/UTF8 compatible
- Fully internationalized terminal emulation
- …and more…
If you want to run kmscon, then please run it as root as it needs access to graphics hardware. By default, kmscon uses DRM devices as output devices. It does not use fbdev devices as many DRM devices also provide fbdev devices for the same physical monitor. If you pass “–fbdev” as command-line argument, then kmscon uses fbdev exclusively! kmscon also supports using DRM devices without OpenGL/EGL/etc.! If compiled kmscon without OpenGLESv2 support but with DRM support, then the DRM devices are used to get direct framebuffer access similar to fbdev. Only if OpenGLESv2 is enabled, kmscon uses hardware-acceleration.
Run “./kmscon -h” to get more information on command-line options. The “–debug” switch is very helpful and “–xkb-layout=de” will switch to a German keyboard layout (if you use the xkbcommon keyboard backend).
Kmscon is still experimental, but I would be glad about any feedback.
Ponyhof 
Smells like Lennart Poetering had something to do with this.
This kind of heresy is just like him, making me ditch my beautiful init scripts for those ini-like service files, and now YOU want to ditch my beautiful kernel VT-s for something new?
HOW DARE YOU TRY AND MODERNIZE MY DEAR OLD UNIX
No one is going to remove kernel VTs. The linux kernel is very strict about backwards-compatibility so you can always use them.
But kmscon gives you the ability to use them on other seats than seat0.
vroom i think that one went over your head bud 🙂
And compiile the kernel without them and use kmscon instead 🙂 I have got to say, I like this. Your idea about using logind to manage sessions and seats, however, I do not like as much.
Thanks! Doing my best. But regarding logind, you have take into account, that it is only an example. No-one forces you to use systemd and as mentioned in the article, logind is only a placeholder for any daemon that fits your needs. Whether it’s logind, uvtd, upstart or your homebrew session manager, all we need to do is agree on a common API.
Well played, sir!
Your comparison to Lennart Poettering is a serious disservice, as it either completely trashes David Herrmann, or it vastly elevates Lennart Poettering. Poettering isn’t despised because he ‘Modernised’ Linux, he’s despised because his solutions are genuinely terrible. PulseAudio is a perfect example of why Poettering’s solutions are unwelcome, but I’m still reserving personal judgment on systemd. If Poettering ‘Modernized’ the console, the solution would be some frankenstein user-space daemon inelegantly wrapped around vgacon/fbcon.
It seems you’ve been listening to too much FUD and BS from the Ubuntu camp. Next time Ubuntu/someone try to tell you something, ask yourself 2 questions:
1) Are you informed enough to judge it on merit, or only on guess-work, based on how confidently it was asserted?
2) Why would they lie to you. Is there some kind of economic/competitive motivation for it?
In this case, the answers are:
1) No, you are a dimwitted f*cktard with zero technical ability/judgement.
2) Yes, Ubuntu have a long track record of trying to game and control the Linux ecosystem and are in direct competition with Poettering’s employer.
“try running a console on a slower machine like the Intel Atom N450 or some Pentium III” — if you wanted a fast console, you’d use “nomodeset vga=0” on x86es, at least for machines where you won’t be needing X.
Good point, but that doesn’t work if you want internationalized fonts (with more than 256/512 different glyphs).
Most people accept that console is *meant* to be minimal, for every definition of “console”. (Note my view is specifically targeting server setups.)
– Serial console: principally slow in transmission, so you will switch to ssh-based connections once it’s running
– Local text console: can’t do CJK, so you will switch to local Xorg or ssh from a CJK-enabled dekstop.
– Similarly, VNC/RDP “console” was not really meant to play 3D games in it either.
If you compile kmscon without mesa, drm, xkbcommon, pango, freetype2, etc., then it is pretty minimal. Maybe about 5k lines of code. And it provides about the same features as the in-kernel console. So it’s really up to the user whether they want the features or not.
I am not going to bet “nomodeset vga=0” will save you so much, another replacement for a frame buffer terminal emulator (http://www.enlightenment.org/p.php?p=about/terminology) was benchmarked 55 times faster than the default one. The kernel version is definitively far from behing optimized at all…
Amazing
This is interesting, but how does this fit in with the rest of the puzzle? Assuming xorg somehow crashes or doesn’t boot up, who starts kmscon in its place? I assume you would want a minimal copy of kmscon in the initramfs, and a full version in /usr, but it’s not clear how the handoff would happen.
kmscon can support any VT replacement you want. If you use VTs, then you can simply switch to kmscon via ctrl+alt+fX (assuming Xorg hands over access).
However, kmscon also supports a mode where you simply press ctrl+mod4+f12 and kmscon becomes active, replacing whatever was active before.
This stuff still needs to be discussed further but you can add whatever mode you want. It is also possible to implement your own emergency process which sends SIGUSR1 to kmscon (this forces kmscon to bring up the console).
Oh, nice. That makes perfect sense.
Make it use
$ gsettings get org.gnome.desktop.background picture-uri
‘file:///home/alice/Firefox_wallpaper.png’
as background.
Then it will use the same wallpaper as GNOME.
I haven’t thought about background wallpapers, yet. I didn’t think of them as an important feature in the early days of the project. It’s on the TODO list, though. However, a gconf dependency is not really what I want. But configuring the picture in /etc/kmscon.conf or ~/.kmscon.conf should be fine, too.
Well, it would be pretty cool to have KMSCON use the same wallpaper as the desktop in GNOME/KDE or X/Wayland. So then when you switch its the same background.
Background wallpaper for a console? *Please* explain to me why that’s not the dumbest idea this side of GNOME3.
kmscon doesn’t support any background wallpapers. But as long as it is requested, I will try to _optionally_ support it. _Please_ tell me why this is a bad idea?
“Please_ tell me why this is a bad idea?”
Besides making the text hard to read, it’s extra code which is pointless fluff that’s nothing more than flame decals, fake chrome wheels and a spoiler on a Honda Civic.
Unless I’m completely missing the point/purpose of a virtual console.
Does it support the usage of a background wallpaper yet?
Is a text shadow supported yet?
How much of VT-xxx is supported yet?
No wallpaper, no text-shadow. Feel free to implement it but there is much more urgent stuff on the TODO list, sorry.
VT220 is almost entirely supported (except multi-line/column text and uploadable fonts). But many xterm features where added, too. So running –term=xterm-256color should give best results. But this is still a field that needs to be improved!
What xterm features?
It supports 256 colors at the same time? Cool! The thing Fedora has been working on?
Will VT525 be supported?
Na, Fedora is working on making this the default for all terminal-emulators. The technology exists for many years now.
VT525 will not be supported in its entirety, it contains a huge amount of stuff that no-one uses. As I said, xterm is the de-facto standard so its features are currently focused. You can find them here:
http://invisible-island.net/xterm/ctlseqs/ctlseqs.html
The category of “system failures” that allow switching to another virtual terminal and successfully recovering without rebooting is quite broad, certainly broader than the scenarios you discuss above. Off the top of my head: X/flash/opengl apps can screw up the screen; misbehaving apps (or users) can hog cpu/io bandwidth/input grabs; X/the desktop/the login screen may have a screwed up configuration.
Maybe kernel consoles are a red herring here – maybe the important part is some kind of (secure attention) key combo that always works to bring up the recovery console. It’s not clear to me how much of this kmscon offers/allows – to what extent do I have to choose between the benefits of kmscon and the security I describe above?
It’s also not clear to me whether you are just addressing a misconception about the degree of security of kernel consoles or whether you’re dismissing the use cases I described above.
That’s not really up to kmscon. Kmscon _does_ allow some limited emergency features (like ctrl+mod4+f12 bringing up kmscon conditionally if used with CONFIG_VT=n), however, this should rather be implemented by an emergency process, if you want it. This process listens for keyboard input or other events and takes the required steps to recover the system. This _can_ include bringing up kmscon (via SIGUSR1 signal), but can also include other steps like killing all processes that have an open FD to /dev/dri/cardX. Then you can also include the required security checks into this process.
Of course, you can add this all to kmscon, but that’s not really my intention. But feel free to provide a module for kmscon that does all this.
This looks like a project with enormous potential! I would love to see this coupled with systemd, wayland, and btrfs as part of a modern Linux distro in the future.
Thanks! It is very impressive!
It seems a sane debug / maint. console interface could be part of the kernel. By default, it would dump data to the kernel log. Hooks would allow replacing logging with serial or other i/o channels as needed. I envision a sort of Software Front panel interface. This interface be configured to drive a User Space console display or displays. People can accept the removal of the old VT cruft, much easier, if old VT type debugging can be done under the new setup.
The suggested Kernel Interface might only be be 6 dumb data streams, dumped somewhere. Let the users build out their own display / dump systems. One that uses 6 kmscon screens tied to one display buffer would duplicate most of the traditional kernel driven console.
I think you really confuse TTYs with VT here. The TTYs will still be available. serial-consoles, normal /dev/ttyXYZ and others can still be used. However, the vt102 terminal emulator in the kernel is what can be removed by setting CONFIG_VT=n.
The feature you describe is already available. Use ttyprintk to provide /dev/ttyprintk (and symlink it to /dev/ttyX). Then processes can open it like any other TTY and write data to it. This goes directly into the kernel log.
You can replace this tty with several other tty-drivers that are available. Wherever you want your data to go.
Way over my head, but it all sounds very cool.
Keep up the good work!
Cool!
Note setting COLORTERM env to anything (like ‘kmscon’) and TERM=xterm would allow the Fedora 18 256 color feature to auto enable 256 colors on this terminal.
You can use –term=xterm. However, default value is vt220 for now. I will change that when vte.c gets more stable. But thanks for the hint with COLORTERM. I will set that.
This is a very interesting idea. I like the idea of pulling things like fonts out of the kernel. Does this support a clean hand-off between a minimal build version that might be in an initramfs image and a full options linked version once all the support libs and fonts are available?
There was mention of UTF-8 support and a compiled in bit-map font. Does the compiled in font have good coverage? Have you looked at GNU unifont?
Full disclosure, I have not tried this yet, but I look forward to giving it a try tonight.
Fonts, renderers and input handling are modular, however, they’re currently all built in and loaded during initialization. But it’s like 10 lines of code to make them loadable via dlopen() etc. And like 10 more lines to make them the default after being loaded.
UTF8 support is always enabled. However, the built-in font includes only 256 glyphs and should be used for ASCII-only. GNU-unifont wasn’t used, yet, but it seems like a nice idea for a new font-module. Thanks!
What’re the prospects for integration with accessibility programs? (e.g. http://mielke.cc/brltty/ or http://linux-speakup.org/speakup.html) Sticking with the VTs is obviously one, but I wondered if there were suitable hooks in KMSCON.
Is there any plan to run this on top of Wayland? If Wayland gets used as a “system compositor”, with desktop logins as full-screen child-Waylands, having the option to log in to a terminal emulator as if it was a desktop session, and use Wayland screen-locking and switching instead of kernel virtual consoles would be nice. You’d get nice input handling, instead of GPM’s ASCII-mouse too. Also, code could be shared with windowed terminal emulators.
Yes, but as long as there is no stable wayland compositor, I will not add any functionality for it. It’s just too much work to keep up with the ever changing wayland API.
You don’t need wayland to access the mouse any modern toolkit with an frame buffer engine will do that properly. From your description, you want a terminal emulator that is the same, on X, Wayland and Framebuffer. I know only one : Terminology ( http://www.enlightenment.org/p.php?p=about/terminology ). It use EFL, is as fast as urxvt (use less memory than it) and is 55 times faster than the kernel one. It is also fully themable. The only drawback compared to KMScon is that it does have more dependencies and is more complex.
Sorry, but this is not true. Running an application without X is more than just drawing into a framebuffer and accessing input devices directly.
The main part of kmscon is that it integrates into the system, which means hotplug-capable, multi-seat capable, using the DRM-API for advanced monitor configuration, working with and without VTs, and more.
There is a reason why directfb exists because this is stuff you don’t want to do in _every_ application. And I doubt that EFL/terminology does all this. And there is also no reason to implement this in EFL. It’s just not what it should be used for.
The reason why a system-compositor like wayland is needed is _not_ to have fancy effects, but rather to have a controlled access to DRM devices and one DRM-master from early-boot until shutdown. This is a lot discussed topic but it definitely cannot be solved by making toolkits run without an X/wayland/directfb environment.
And if you want to write an EFL wayland compositor 😉
Have you though about putting something like tmux/screen into your new terminal? I wish the default terminal would offer such a feature so that you do not need reptyr, disown and friends.
No. Why would it be easier if the terminal supports it instead of using GNU-screen? I don’t think it would make any difference. However, you can use kind of “tabbed terminals”, that is, multiple terminals in one kmscon process. But that’s all it does. Or what did you have in mind?
Sometimes i forget to use screen or it turns out that a tasks takes longer than expected. There are many cases where it would be nice to attach a process to another shell without the need to set screen as default terminal or knowing in advance that the functionality is required. Google for “The Design of Job Control Was Badly Botched” to get a better description of what i mean:)