bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

console plans


From: Marcus Brinkmann
Subject: console plans
Date: Tue, 12 Feb 2002 22:20:42 +0100
User-agent: Mutt/1.3.27i

Hi,

I am preparing for the console server, and here is sort of a rough outline,
call for comments, requests, and opinions, as well as some update on the
status.

The console will be built of several parts:
* A kernel driver to get the keyboard events from.  To reduce kernel code,
  raw scan code events will be consumed in the ix86 version.
  Status: GNU Mach can provide them, I have a hack for OSKit-Mach here that
  needs to be polished and integrated into the source (a cheesy kbd device
  that sets keyboard in raw mode when being opened).
* A way to access the VGA memory and map it into the console server.
  GNU Mach has it via a special device, OSKit-Mach has it by mapping /dev/mem.
  I don't remember if it works or if there are bugs, if there are bugs in
  the mem device in OSKit-Mach I have fixed them locally and can submit a
  fix (in other words: works for me).
* A way to access the bare VGA card's I/O ports.
  GNU Mach allows it by default :) and my I/O bitmap interface for
  OSKit-Mach is completed (except that it doesn't behave 100% correct
  on SMP systems), I have to polish it and submit the code for integration.
* A term that can access the console server.
  This was done recently, and committed.  It should work.
* A console server.
  I have a hacked colortext here that should work, but it provides only a
  minimal console.  Because I am going to fix it, I thought I would do it
  right from the start, and have the following in mind:

The console server emits characters in the local encoding, this might be
iso8859-1 or something similar common.  We are limited to 256 bytes and the
lower 128 should be plain 7-bit ASCII, but within that constraints
everything is fair game.  It receives characters likewise, and although the
encoding that is used to emit characters can be different from the encoding
that is received, usually this will not be the case.  Unicode support is not
feasible for us at this stage (for many reasons), but if you were to hack a
Hurd system that uses Unicode at the system level, this is the place where
you would implement it (and then the rest like term would just need to
handle it).

The console server will be modular, in particular the architecture specific
parts will be isolated from the generic parts.  So there will be backends
which are responsible to translate keyboard scan codes into characters, for
example.  I think for now I will limit every console server process to one
input device and one output device.  Note that you could start several
console servers if you have some useful distinct devices to use them for
(and drivers for them in the server).

The only input driver that will be initially supported is of course the PC
keyboard driver, which translates PC keyboard raw scan codes into
characters.  This will require a configuration file with a translation
table.  In this configuration file, keys could be also mapped to special
functions in the console server (like switching the virtual terminal, or the
screen resolution), or to complete strings (like F1 => "ls\n").  The format
of the file is not decided yet (GNU/Linux has some format, we might just
sneak that, but for special features we will not be compatible, and the
files are usually very simple).  It will be flexible enough, but specific
to the backend driver.  The internal interface will just require that the
backend driver feeds the input queue with characters in some sort of
encoding, and triggers special events when asked to do so by the user.
I expect to implement all the common features you would expect (shift,
ctrl, left alt, right alt, compose key etc).

Here it is possible to either encode directly into the desired system
encoding (like iso8859-1), or we could encode into an intermediate
encoding (Adobe Standard Encoding, Unicode).  The advantage of having an
intermediate encoding is that the configuration file becomes independant of
the system encoding, which is a good thing.

The output half is similar.  The only driver initially will be a standard
VGA driver (Super VGA might be an option for later).  I have found some
documentation on VGA cards (FreeVGA Project), and we will do all the VGA
card programming in user space.  So we just map the VGA card memory and
program it's I/O ports.  This allows us to implement Text mode switching
(more interesting for SuperVGA, I am afraid), Font loading, and other
interesting stuff like that.  For now, I will settle with font loading, as
this is important for i18n.  The internal interface will certainly be a bit
more complex than just stuffing the characters into the output queue,
because if you change the screen mode, the dimensions need to be reported
back to the user (SIGWINCH anyone?  I think we are missing support for that
in the Hurd, and in term in particular).  The standard format for fonts will
be BDF (Adobe Bitmap Distribution Format, V2.2, 1993), because that is a
simple text format (CVS friendly) which is in widespread use (XFree86). 
Although BDF is often not directly used, but the compiled PCF is used
instead, I will stick with BDF for now.  PCF and gz support can be added
later at any time.  If you look for console fonts on other systems (PSF on
GNU/Linux, vfont on Solaris(or so?), some .FNT format on BSD), you will be
disappointed:  They are quite limited to that specific purpose, not well
defined and not particularly portable.  The BDF font format is independent
of the device used (a particular font is bitmapped and thus dependent on the
output device, althugh scaling information is included in the font),
always includes encoding information (which maps characters to glyphs),
is easy to parse, and can be used for other backend drivers as well.  For
example, if you were to write a framebuffer device, you could use your
X fonts on the console (you will be able to use X fonts on the normal
VGA text mode console, too, as long as the glyphs fit into 8x14 or so).
A BDF font has the additional advantage that it can contain many glyphs
(for example a Unicode BDF font can have tens of thousands of glyphs),
so you don't need to change the font configuration if you change the
character encoding.

Which leads me to the next configuration file needed, the mapping of
characters (ASCII, iso8859-1 or whatever) to the encoding used in the BDF
font (usually Adobe Standard Encoding, about which I have to get more info,
but it can be an internal encoding, too).  (An implementation detail: If you
preload a font to the vga buffer, you can hard code an encoding, so it might
be better to leave the decoding to the backend driver, inc ase it can
shortcut it).

So, a configuration of the console server could look like this:
/hurd/console --input pc-kbd:de --output vga --encoding iso8859-1 --font cm

(this assumes that the keymap table de maps from scan codes to an internal
encoding, that is than decoded to iso8859-1.  If you really want to confuse
things, we can provide --input-encoding and --output-encoding options).

The generic code will deal with virtual terminals, generic screen savers,
and similar stuff (like displaying a status bar or a clock).  That is the
place where you put all the gimmicks.

I am not sure how virtual consoles will work.  I don't think just creating a
new virtual console at every open is a good idea.  Instead, we should name
them.  Maybe the translator should provide a directory, and accessing 1, 2,
3, etc (or even names) accesses the virtual console with that number
(created on the fly if necessary).  What I am in particular not sure is how
we would get a getty on such virtual consoles (surely we would use some
/etc/ttys entry, maybe some support needs to be added there).

I am open to suggestions.  Surely everyone has his or her own ideas how the
console should behave and work.  For example, I would not clear the scroll
back buffer when the virtual console is switched (but have a hot key that
empties the buffer, for security reasons).  I have some ideas I did not
mention here, and I will see how many of these I get done in time.  I am
sure I will not be able to implement all your ideas, but I would not like to
miss a particular good one either.

The current status is:
* I have written a BDF parser.
* I have tried font switching, and verified that it works.  As a result,
  some header files for VGA programming exist now.
* The colortext program exists, of course, for a long time now.  AFAICR, it
  has not yet the level of seperation of the backend drivers from the
  generic parts that I desire.  I have a hacked up version that has some
  scan code mapping already, but it's very ugly.

What needs to be done:
* Submitting the pending patches for OSKit.
* BDF->VGA font converter.
* A proper keyboard driver (not the hacked up one that does only know the
  left shift key as a modifier :) with keymap support.
* A nice console font!  I will write a psf2bdf converter, so we can sneak
  the GNU/Linux fonts, but we should have a nice BDF font with many glyps as
  well.  I am considering ec fonts (european variant of computer modern by
  Knappen) and mftobdf.  But I will have to check if metafont produces
  usable results at such low resultions.  (I know that it produces some
  results, I have used a 4x5 font on a line printer once, it was
  surprisingly readable, but I would not use it daily :)
* Putting it all together.
* Virtual consoles.
* All the gimmicks and extras (many of them).

Thanks,
Marcus


-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de



reply via email to

[Prev in Thread] Current Thread [Next in Thread]