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

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

[David Herrmann]

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_programs_with_egl_and_
[2] http://github.com/dvdhrm/kmscon

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

[Ville Syrjälä]

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?

-- 
Ville Syrjälä
Intel OTC

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

[David Herrmann]

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

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

[Jesse Barnes]

[-- Attachment #1.1: Type: text/plain, Size: 1122 bytes --]

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.

-- 
Jesse Barnes, Intel Open Source Technology Center

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Ville Syrjälä]

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.

-- 
Ville Syrjälä
Intel OTC

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

[David Herrmann]

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

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

[David Herrmann]

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

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

[Alan Cox]

> 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