Hi
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 information.
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! Regards David
[1] http://virtuousgeek.org/blog/index.php/jbarnes/2011/10/31/writing_stanalone_... [2] http://github.com/dvdhrm/kmscon
On Tue, Mar 27, 2012 at 04:57:29PM +0200, David Herrmann wrote:
It needs some more work in the VTE layer and on the UI but it's 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.
So you have a separate texture for each glyph? Doesn't sound very efficient. Did you try to use a texture atlas instead?
Hi
On Tue, Mar 27, 2012 at 5:59 PM, Ville Syrjälä ville.syrjala@linux.intel.com wrote:
On Tue, Mar 27, 2012 at 04:57:29PM +0200, David Herrmann wrote:
It needs some more work in the VTE layer and on the UI but it's 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.
So you have a separate texture for each glyph? Doesn't sound very efficient. Did you try to use a texture atlas instead?
Drawing a 80x24 screen with just a single glyph has the same effect even though this uses just a single texture which is drawn 1920 times. So a texture-atlas does not help here. Any other ideas? I will give pango-cairo a shot and see how well it performs. At least this runs smooth with libvte inside X here.
-- Ville Syrjälä Intel OTC
Thanks David
On Tue, 27 Mar 2012 16:57:29 +0200 David Herrmann dh.herrmann@googlemail.com wrote:
Hi
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).
Awesome! Now get the distros to pick this up and turn off CONFIG_VT! :)
Ville's comment about a texture atlas is a good one, if nothing else I think it should improve cache behavior.
But it may be better to just do the font rendering with the CPU anyway (though cairo-gl is supposedly getting better), and leave the GL for transition effects and such.
On Wed, Mar 28, 2012 at 10:30:20AM -0700, Jesse Barnes wrote:
On Tue, 27 Mar 2012 16:57:29 +0200 David Herrmann dh.herrmann@googlemail.com wrote:
Hi
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).
Awesome! Now get the distros to pick this up and turn off CONFIG_VT! :)
Ville's comment about a texture atlas is a good one, if nothing else I think it should improve cache behavior.
You could also render a large batch of glyphs with just a single glDrawElements()/glDrawArrays() call. Looks like the current code does a glDrawArrays() for each glyph.
Hi
On Wed, Mar 28, 2012 at 8:14 PM, Ville Syrjälä ville.syrjala@linux.intel.com wrote:
On Wed, Mar 28, 2012 at 10:30:20AM -0700, Jesse Barnes wrote:
On Tue, 27 Mar 2012 16:57:29 +0200 David Herrmann dh.herrmann@googlemail.com wrote:
Hi
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).
Awesome! Now get the distros to pick this up and turn off CONFIG_VT! :)
Ville's comment about a texture atlas is a good one, if nothing else I think it should improve cache behavior.
You could also render a large batch of glyphs with just a single glDrawElements()/glDrawArrays() call. Looks like the current code does a glDrawArrays() for each glyph.
I switched to cairo again and this works much better than my first attempt with freetype+GL (even with higher row/cols counts). I also switched to pango so I don't have to care for unicode combined-chacraters which are not supported by freetype2 out-of-the box and need to be emulated.
I might, though, give freetype+OpenGL another try with your approach to draw all glyphs with one glDrawArrays() call. However, I now wanna concentrate on the VTE layer for now.
-- Ville Syrjälä Intel OTC
Thanks looking over it! David
Hi
On Wed, Mar 28, 2012 at 7:30 PM, Jesse Barnes jbarnes@virtuousgeek.org wrote:
On Tue, 27 Mar 2012 16:57:29 +0200 David Herrmann dh.herrmann@googlemail.com wrote:
Hi
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).
Awesome! Now get the distros to pick this up and turn off CONFIG_VT! :)
Heh! It might take a few more weeks until the VTE layer is as good as the VT-emulation in the kernel. And then we still need to figure out a way to make the kernel spit console-log to the display while booting/etc. However, I plan to provide a prototype that works with CONFIG_VT=n to at least get some testing environment. I'll keep dri-devel informed if I think it's getting stable.
Ville's comment about a texture atlas is a good one, if nothing else I think it should improve cache behavior.
But it may be better to just do the font rendering with the CPU anyway (though cairo-gl is supposedly getting better), and leave the GL for transition effects and such.
That's what I did now and it works perfectly well. I might add other backends in the future, though.
-- Jesse Barnes, Intel Open Source Technology Center
Cheers David
the VT-emulation in the kernel. And then we still need to figure out a way to make the kernel spit console-log to the display while booting/etc. However, I plan to provide a prototype that works with CONFIG_VT=n to at least get some testing environment. I'll keep dri-devel informed if I think it's getting stable.
Nothing stops the DRI driver registering a console handler without being a VT. Just as we can use the parallel port.
Alan
dri-devel@lists.freedesktop.org
-
Alan Cox -
David Herrmann -
Jesse Barnes -
Ville Syrjälä