[ANNOUNCE] kmscon: Lazy-web's DRM based terminal emulator

David Herrmann dh.herrmann at googlemail.com
Tue Mar 27 07:57:29 PDT 2012


Motivated by Jesse's letter to the lazyweb [1] I worked on a kmscon
program. It provides a
terminal-emulator similar to the in-kernel terminal-emulator based on
DRM. It is written
from scratch and needs as external dependencies only mesa (libdrm,
libgbm, libEGL, libGLESv2),
udev, xproto (build-time dep), libxkbcommon, freetype2 and currently
glib (only for unicode support).
It uses a very recent version of libxkbcommon but it should be easy to
fix ./src/kbd_xkb.c if
you use an older version (or use --disable-xkbcommon to use a very
basic keyboard handler).

If you're curious check it out at github [2].
"./autogen && ./configure --enable-debug [--disable-xkbcommon] && make
&& ./kmscon --debug --switchvt"
should be enough to get it running. "./kmscon --help" shows some usage

Current state:
 - Supports multiple displays through DRM (hotplugging works)
 - Full input support through libxkbcommon (thanks to Ran Benita for that)
 - Opens a separate VT and can run together with X, wayland, etc.
 - VTE layer is *very limited* and under development. You can use bash
but programs like vim will fail.
 - only one terminal is currently supported which is cloned to all displays

It needs some more work in the VTE layer and on the UI but it's
getting close to a first release.

I had several issues while writing it but most of them are fixed. One
thing I remember is a performance
issue running it on my Intel Atom N450. With 80x24 it works barely
fine, but more glyphs per frame are are not
possible. I currently use one texture for every glyph I draw, that is,
one screen-update
draws 80x24 = 1920 textures. "perf" shows me 19% in my
matrix-multiplication code (which is, I have
to admit, not optimized in any way) but also 21% in libdricore.so + 6%
in i915_core.so at some unknwon address.
Plus about 10% in _mesa_execute_program, _tnl_draw_prims,
_tnl_run_pipeline, _mesa_update_state_locked and
some others. Even if I optimize my matrix-code, I will never get
decent performance. Is it recommended to use
cairo (or similar 2D renderer) on machines like the Atom N450 or
slower? And then simply render a single texture?
On faster machines I don't have this problem.

Feedback is welcome!

[1] http://virtuousgeek.org/blog/index.php/jbarnes/2011/10/31/writing_stanalone_programs_with_egl_and_
[2] http://github.com/dvdhrm/kmscon

More information about the dri-devel mailing list