KMSCON: A DRM-Based Terminal Emulator

[phoronix]

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...

http://www.phoronix.com/vr.php?view=MTA3ODE

[uid313]

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

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

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.

What is the benefit of this?
I don't need anti-aliasing for my monospaced console font.

[kobblestown]

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.

[uid313]

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.

[dvdhrm]

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".

The current terminal is very stable and proven.

You can use this argument against any new software... I don't see your point. kmscon tries to provide new features that will never be added to the kernel-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.

What is the benefit of this?

Basically getting a console that is as powerful as an xterm. Full VT550 support. Dual-head support. Multiple seats. AA-fonts. And anything you every dreamed of, or not.

I don't need anti-aliasing for my monospaced console font.

Then don't use it. No-one cares.

Cheers
David

[uid313]

Basically getting a console that is as powerful as an xterm. Full VT550 support. Dual-head support. Multiple seats. AA-fonts. And anything you every dreamed of, or not.

Anything I can dream of? Okay, here is what I want.

The console background should be the same as my desktop wallpaper, but dimmed (as if there was a black layer over of 90% opacity).

A gray text shadow that is +1px below and to the right to cast a text shadow to give a nice subtle 3D effect. This may also increase readiabilty when using a background wallpaper.

[dfx.]

damn, that sounds like something i desired for quite a while.
i hope it will get major distributions' attention.

[raster]

Anything I can dream of? Okay, here is what I want.

The console background should be the same as my desktop wallpaper, but dimmed (as if there was a black layer over of 90% opacity).

A gray text shadow that is +1px below and to the right to cast a text shadow to give a nice subtle 3D effect. This may also increase readiabilty when using a background wallpaper.

You can have that now:

http://www.enlightenment.org/ss/e-4f...5.42968810.jpg
http://www.enlightenment.org/ss/e-4f...2.56123256.jpg

http://oi45.tinypic.com/35iyl5f.jpg

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.