Tag Archives: VT

Sane Session-Switching

In a previous article I talked about the history of VT switching. Created as a simple way to switch between text-mode sessions it has grown into a fragile API to protect one testosterone monster (also called XServer) from another. XServers used to poke in PCI bars, modified MMIO registers and messed around with DMA controllers. If they hauled out the big guns, it was almost absurd to believe a simple signal-flinging VT could ever successfully negotiate. Fortunately, today’s XServer is a repentant sinner. With common desktop hardware, all direct I/O is done in the kernel (thanks KMS!) and chances of screwing up your GPUs are rather minimal. This allows us to finally implement proper device-handover during session-switches.

If we look at sessions at a whole, the XServer isn’t special at all. A lot of session-daemons may run today that provide some service to the session as a whole. This includes pulseaudio, dbus, systemd –user, colord, polkit, ssh-keychain, and a lot more. All these daemons don’t need any special synchronization during session-switch. So why does the XServer require it?

Any graphics-server like the XServer is responsible of providing access to input and graphics devices to a session. When a session is activated, they need to re-initialize the devices. Before a session is deactivated, they need to cleanup the devices so the to-be-activated session can access them. The reason they need to do this is missing infrastructure to revoke their access. If a session would not cleanup graphics devices, the kernel would prevent any new session from accessing the graphics device. For input devices it is even worse: If a session doesn’t close the devices during deactivation, it would continue reading input events while the new session is active. So while typing in your password, the background session might send these key-strokes to your IRC client (which is exactly what XMir did). What we need is a kernel feature to forcibly revoke access to a graphics or input device. Unfortunately, it is not as easy at it sounds. We need to find some-one who is privileged and trusted enough to do this. You don’t want your background session to revoke your foreground session’s graphics access, do you? This is were systemd-logind enters the stage.

systemd-logind is already managing sessions on a system. It keeps track on which session is active and sets ACLs in /dev to give the foreground session access to device nodes. To implement device-handover, we extend the existing logind-API by a new function: RequestDevice(deviceNode). A graphics-server can pass a file-system path for a device-node in /dev to systemd-logind, which checks permissions, opens the node and returns a file-descriptor to the caller. But systemd-logind retains a copy of the file-descriptor. This allows logind to disable it as long as the session is inactive. During a session-switch, logind can now disable all devices of the old session, re-enable the devices of the new session and notify both of the session-switch. We now have a clean handover from one session to the other. With this technology in place, we can start looking at real scenarios.

1) Session-management with VTs

Session management using VTs for foreground control and logind for device management

Session management with VTs and logind

Based on the graphs for VT-switching, I drew a new one considering logind. VTs are still used to switch between sessions, but sessions no longer open hardware devices directly. Instead, they ask logind as described above. The big advantage is that VT-switches are no longer fragile. If a VT is active, it can be sure that it has exclusive hardware-access. And if a session is dead-locked, we can force a VT-switch and revoke their device-access. This allows to recover from situations where your XServer hangs without SSH’ing from a remote machine or using SysRq.

2) Session-management without VTs

Session management based solely on logind

Pure logind session management

While sane VT-switching is a nice feature, the biggest win is that we can implement proper multi-session support for seats without VTs. While previously only a single session could run on such seats, with logind device-management, we can now support session-switching on any seat.

Instead of using VTs to notify sessions when they are activated or deactivated, we use the logind-dbus-API. A graphics-server can now request input and graphics devices via the logind RequestDevice API and use it while active. Once a session-switch occurs, logind will disable the device file-descriptors and switch sessions. A dbus signal is sent asynchronously to the old and new session. The old session can stop rendering while inactive to save power.

3) Asynchonous events and backwards-compatibility

One thing changes almost unnoticed when using RequestDevice. An active graphics-server might be almost about to display an image on screen while a session-switch occurs. logind revokes access to graphics devices and sends an asynchronous event that the session is now inactive. However, the graphics-server might not have received this event, yet. Instead, it tries to invoke a system-call to update the screen. But this will fail with EACCES or EPERM as it doesn’t have access to it, anymore. Currently, for most graphics servers this is a fatal error. Instead of handling EACCES and interpreting it as “this device is now paused”, they don’t care for the error code and abort. We could fix all the graphics-servers, but to simplify the transition, we introduced negotiated session-switches.

Whenever logind is asked to perform a session-switch, it first sends PauseDevice signals for every open device to the foreground graphics-server. This must respond with a PauseDeviceComplete call to logind for each device. Once all devices are paused, the session-switch is performed. If the foreground session does not respond in a timely manner, logind will forcibly revoke device access and then perform the session-switch, anyway.

Note that negotiated session-switches are only meant for compatibility. Any graphics-server is highly encouraged to handle EACCES just fine!

All my local tests ran fine so far, but all this is still under development. systemd patches can be found at github (frequently rebased!). Most tests I do rely on an experimental novt library, also available at github (I will push it during next week; this is only for testing!). Feedback is welcome! The RFC can be found on systemd-devel. Now I need a day off..

Happy Switching!

How VT-switching works

Having multiple sessions on your system in parallel is a quite handy feature. It allows things like Fast User Switching or running two different DEs at the same time. Especially graphics developers like it, because they can test-run their experimental XServer/weston on the same machine they develop on.

To understand how it works, we need the concept of a session. See my previous introduction into session-management if you’re not familiar with it. I expect the reader to be familiar with basic session-management concepts (i.e., seats, systemd-logind, login-sessions, user-sessions, processes and daemons in a session).

1) Traditional text-mode VT-switching

Virtual terminals were introduced with linux-0.12. It’s the origin of multi-session support on linux. Before this, linux only supported a single TTY session (which was even available in the first tarball of linux-0.01). With virtual terminals, we have /dev/tty<num> devices, where <num> is between 1 and 63. They are always bound to seat0 and every session on seat0 is bound to a single VT. That means, there are at most 63 live sessions on seat0. Only one of them is active at a time (which can be read from /sys/class/tty/tty0/active).

Session management and device access with VTs in text-mode

Session management in text-mode

The kernel listens for keyboard events and switches between VTs on ctrl+alt+Fx shortcuts. Alternatively, you can issue a VT_ACTIVATE ioctl to politely ask the kernel to switch sessions.

In the old days, all sessions ran in text-mode. In text-mode, a process can get keyboard input by reading from a VT and can write onto the screen by writing to a VT. Some rather ugly control-sequences are supported to allow colors or other advanced features. The kernel interprets these and instructs the graphics hardware to print the given text.

Important to note is that in text-mode sessions don’t have direct hardware access. The kernel merges all keyboard events into one stream and a session cannot tell which device it came from. In fact, it cannot even tell how many devices there are. Same for graphics devices. As a VT has only a single output stream, there is only a single screen to write to. Multi-head support is not available. Neither are any advanced graphics-operations. But this allows the kernel to serialize access to hardware devices. Only the active VT gets input events and only the buffer of the active VT is displayed on the screen. No resource-conflicts can occur.

While there are ways to detect when a session is activated/deactivated, in text-mode a session normally doesn’t care. It just stops receiving keyboard input. If the session writes to the VT while deactivated, it will affect the internal buffer of the VT, but not the screen. Only the buffer of the active VT is shown on screen.

2) Session-switching in graphics-mode

System session management and device access with VTs in graphics mode

Session management in gfx-mode

Very soon it became clear that text-mode is not enough. We wanted more! That’s when the VT graphics mode was introduced. Graphics mode doesn’t change the setup, we still have 63 VTs and each session is bound to a VT. But a VT can now be switched from text-mode KD_TEXT into graphics-mode KD_GRAPHICS (via KDSETMODE ioctl). This doesn’t do anything spectacular. Really! The only effect is it disables the kernel-internal graphics routines. As long as a VT is in graphics-mode, the kernel will not instruct the graphics hardware to display the VT on screen. Once it is reset to text-mode and the VT is active, the kernel will display it again.

So the graphics-mode itself is useless. But at the same time, the kernel started providing separate interfaces to input and graphics devices. So while a VT is in graphics-mode, a session can access the graphics devices directly and render whatever they want. It can also ignore input from the VT and instead read input-events directly from the input-event interfaces. This is how the XServer works today.

But it is pretty obvious that this becomes problematic during session switches. If the kernel switches away from a graphics VT, the session needs to release the graphics hardware before the new session can be activated. Otherwise, the new session is active, but you still get the images from the old one. Or worse, it might flicker between the images of both sessions. Without kernel-mode-setting it might even hang your graphics hardware.

(A similar interface to KDSETMODE exists for keyboards with KDSKBMODE.)

Unfortunately, the kernel has no interface to forcibly revoke graphics or input access. So VTs were extended by the VT_SETMODE ioctl. A process can issue VT_SETMODE on a VT and pass two signal-numbers (usually SIGUSR1 and SIGUSR2). If the kernel wants to perform a VT-switch, it sends one such signal to the active VT. This VT can cleanup resources, stop using graphics/input devices and acknowledge the VT-switch via the VT_RELDISP ioctl. If the process dead-locked and doesn’t acknowledge the request, the VT-switch will not happen! This is why a crashed XServer can hang your system. But if it correctly issues the VT_RELDISP ioctl, the kernel will perform the VT-switch. Once the kernel switches back to the given VT it sends the second signal as notification that it is now active again.

However, on every VT (precisely, on every session) only a single process can call VT_SETMODE. This already shows that the concept is flawed. For example, if the XServer takes the VT in posession for graphics and input devices, another audio-server in the session couldn’t do the same for audio-hardware. This applies to all other devices. An alternative involving logind is discussed in a followup article.

3) Seats without VTs

We discussed that VTs are always bound to seat0. So if you run a session on a seat other than seat0 or if you disabled VTs entirely, then the situation becomes pretty simple: no multi-session support is available. This is enforced by systemd-logind so the active session can run without interruptions.

Also important to note is that there is no text-mode. A session must run in graphics mode as the kernel facility to interpret text-commands is bound to VTs.

Single-session setup on seats without VTs

Session management without VTs

4) logind integration

As we discussed in the previous article, today systemd-logind tracks and manages sessions. But how does this integrate with VTs? VTs pre-date systemd by years, so to preserve backwards-compatibility, we need to keep the infrastructure as it is. That’s why logind watches /sys/class/tty/tty0/active for changes. Once a VT switch happens, logind notices it and marks the old session as inactive and the new as active. It also adjusts ACLs in /dev to keep access-restrictions in sync with the active session. However, this cannot be done properly without a race-condition. Therefore, logind provides a new dbus-API to replace the ageing VT API. New session-daemons are advised to use it in favor of VTs.

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.

Replacements

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.

Problems

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.

System-Compositor

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.

Outlook

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!

KMSCON: Linux KMS/DRM based Virtual Console

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:

Kmscon has many features. Here is a list of the most important ones:

  1. Safe fallback rendering via /dev/fbX (simply run ./kmscon –fbdev)
  2. DRM dumb-fbs as 2D backend
  3. EGL+3D hardware-accelerated rendering when compiled with OpenGLESv2
  4. Full hotplug capable (monitors and input devices)
  5. Multi-seat capable
  6. Support for multiple monitors
  7. Almost full VT220 compatibility
  8. Modularized input/video/VT handling via libuterm
  9. Only libudev.so as mandatory dependency!
  10. Plain built-in optional keyboard backend
  11. Optional internationalized keyboard backend based on libxkbcommon.so
  12. Built-in VT-compatibility but also runs without VTs
  13. Fully Unicode/UTF8 compatible
  14. Fully internationalized terminal emulation
  15. …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.