Re: [Linuxconsole-dev] Municon

[Jim P. <ji...@ag...>]

Eric S. Raymond wrote:
> > Still, I'm open to suggestions -
> 
> One of our goals is to turn the emulation code into a module.  Perhaps
> the right way to do Municon would be as a combination of a module and
> a userspace daemon, the module being tailored to mediate between the
> daemon and the underlying console framebuffer.

At the moment I'm looking at Municon as a client to whatever you can get
into the kernel.  One client of many - it certainly wouldn't be suitable for
many graphical applications.  If you are planning to unify the input stream
from diverse devices, I can certainly use that.  I'll also be using whatever
you come up regarding multi-heading.

Municon could exist as just a user-space application, if you like.  However,
if you're going to get multiple terminal emulations into the kernel through
modules, it would be really nice to get Municon in at this level, so, for
example, I could say:

   set_tty_type municon
   export TERM=municon
   
To switch to it, and to switch back:

   set_tty_type linux     # or vt420, or whatever
   export TERM=linux

Without that, Municon's set of consoles would all have to be displayed
through one single real console (one real /dev/tty), using some other
key-combination to switch consoles than the ones people are used to.

Yes - this approach of having terminal emulation in modules makes everything
much more flexible, and much more integrated.  It also is going to
seamlessly take care of applications running on a Municon console that want
to use GGI or /dev/fb or whatever, directly.  If it works for the `linux'
console, it would also work for `municon' automatically.

Good news.

Jim

-- 
 Jim Peters         /             __   |  \              Aguazul
                   /   /| /| )| /| / )||   \
 jim@aguazul.      \  (_|(_|(_|(_| )(_|I   /        www.aguazul.
  demon.co.uk       \    ._)     _/       /          demon.co.uk