If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

KMSCON: A DRM-Based Terminal Emulator

03-28-2012, 09:30 AM

Phoronix: KMSCON: A DRM-Based Terminal Emulator

Announced yesterday was the release of kmscon, a terminal emulator for Linux that's similar to what's offered inside the kernel, but instead it's in user-space and relies upon the kernel's DRM interfaces as well as Mesa...

Comment

When shit locks up you can usually always access the TTY cuz its in the kernel.
The current terminal is very stable and proven.

It's best to have a serial console set up in advance for when the shit hits the fan. I think it's even more stable than VT. And you don't need keyboard and display. Unfortunately, most systems lately have been shipping without a serial port, although there's usually at least one exposed as a pin header on the motherboard so you only need a bracket with the appropriate connectors. At the client side you can hook a USB->Serial adapter to a notebook so you can connect to your headless server from the notebook. The only drawback is that you cannot change BIOS settings over serial line. I really wish someone would do this for UEFI.

I always set up a serial console for my servers which run without any video card installed in them for power saving reasons. GRUB and LILO can be configured to support serial line for boot image selection. And once the kernel takes over it's all roses.

Comment

It's best to have a serial console set up in advance for when the shit hits the fan. I think it's even more stable than VT. And you don't need keyboard and display. Unfortunately, most systems lately have been shipping without a serial port, although there's usually at least one exposed as a pin header on the motherboard so you only need a bracket with the appropriate connectors. At the client side you can hook a USB->Serial adapter to a notebook so you can connect to your headless server from the notebook. The only drawback is that you cannot change BIOS settings over serial line. I really wish someone would do this for UEFI.

I always set up a serial console for my servers which run without any video card installed in them for power saving reasons. GRUB and LILO can be configured to support serial line for boot image selection. And once the kernel takes over it's all roses.

I wasn't thinking about servers.
I was thinking about when something goes awry on my desktop computer.
I don't know about you, but I don't have any serial console, nor have I ever seen one. I don't have a laptop to plug into my desktop computer either. Nor do I have any serial port or any serial-to-usb adapter.

Comment

When shit locks up you can usually always access the TTY cuz its in the kernel.

If you can switch to a VT where the linux-console is running, why shouldn't you be able to switch to a VT where kmscon is running? Because it is running in the kernel? No. That is not true. The VTE layer is in the kernel and drawing is done in the kernel but to do anything useful you still need a running bash and all the binaries for the stuff you want to do. Therefore, kmscon is as safe as a fallback as the in-kernel VT. Furthermore, switching VTs is a job that is initiated by user-space so you need at least a working user-space to get to your "fallback-VT".

This kmscon seems like it has many dependencies (xproto, libxkbcommon, GLib, wtf?).

It has many dependencies? Where did you get that from? As far as I know it depends on mesa, udev, xkbcommon and a font renderer like
freetype2. Which one of them would you like to drop?
- Mesa is a graphics-renderer. Without it, we will never be able to access the graphics-card without using fbdev.
- udev is the basic hotplugging server on _every_ linux system. You can drop this but then you would not have hotplug-support.
- xkbcommon is a new approach to have a keyboard-handling library without X-dependencies. The kernel-VT has a similar library which is implemented in the kernel but provides far less functionality. kmscon can be compiled without xkbcommon, though. Just pass --disable-xkbcommon and you will get the most basic keyboard-handling you could imagine.
- freetype2 is a library that draws fonts. A console needs fonts. Therefore, You cannot drop it. The kernel uses the graphics framebuffer, VGA-font-handling and has also compiled-in fonts. I don't know why anyone would ever want to drop this dependency.

The xproto dependency is only a _build-time_ dependency so nobody
should care. It is needed to get keysym constants.
glib is only a temporary dependency to get UTF8 support, please read the README carefully. This will hopefully be replaced by new UTF8 calls in libc.

So if you think it has _a lot_ dependencies, then please elaborate a little bit more.

Also the terminal works on every single computer in existance locally and remotely, over serial, headless, etc. This would require a graphics card with a KMS driver.

As the name of "kmscon" suggests, it is a "KMS" console. It does not and probably never will replace remote consoles. This is not the intention. Furthermore, if ssh cannot be used, you will always be able to get the debug-console-output via serial.
Please do not confuse TTY and VT. The intention is to set CONFIG_VT=0. TTYs will always exist.

it works in x11, wayland and fbcon directly... no kms needed even. and you get all the shading, shadowing, wallpapers - hell even video wallpapers and popups. the whole works. it still is leaner than gnome-terminal too. so same term in x you use can lurk in your fb.