Re: Console mapping problems? [I hear about these - I wanna know!]

Teunis Peters (
Wed, 10 Sep 1997 14:04:59 -0600 (MDT)

On Wed, 10 Sep 1997, H. Peter Anvin wrote:

> > > Is it possible to make it locale-based (if userspace)?
> > > IMHO it SHOULD be per-user and changeable ONLY on explicit request... That
> > > make sense?
> >
> > Per user has no sense. Per console has a better one.

True - I keep forgetting the console maps/fonts/et al only apply to local
console users, not to network users (or X).

> Also would be very expensive in terms of kernel memory.

The _FONT_ is loaded into the videocard - when necessary...
... this could be stored in virtual-mem and reloaded if necessary...

FWIW the font remapping and font itself are quite small: 8bitx16x256 chars
being normal == 4096 bytes per font (1 page). though there ARE 2-page
fonts I would guess.

Unfortunately, font reloading requires knowledge about the hardware. All
I know about are:
VGA - walk lightly - some cards aren't very nice (Trident 8900)
[tested my code in S3-805,Trident 8900C/D,9660,S3-Trio64V+]
- based on svgalib + XFree86 + vgadocs + demosources
TGA - a snap. This is a graphical card - as a result the kernel
does text here
MDA - the (I've never seen one) text-only display for IBM-PC
CGA(/EGA?) - no font remapping... Assume IBM-PC chars
Hercules - no font remapping... Assume IBM-PC chars
Other platforms? I always assumed they were all graphical...

With the exception of MDA, building a graphical console rather than text
is quite simple (see the TGA source in drivers/console). And with the
exception of the Trident 8900 no special info really has to be known about
the card (AFAIK).

Please don't say GGI - even though (if it worked <sigh>) that would be an
ideal solution to font reloading.

Perhaps there's a solution AKA kerneld for handling fonts/remapping?
(it'd be pretty easy unlike kerneld - could pretty much be done from
userspace with one (signal?) from the kernel - and two responses:
[unsupported operation] or [OKAY])

(actually - that would fit in well with what I want to do to the console :)

> > > Uhmm... Loading/unloading fonts is ioctl, right? <sigh> - this makes it
> > > REALLY hard to emulate console under, say, X (I _REALLY_ don't like
> > > Xterm's keyboard/display/font mapping).
> >
> > Yes, it's hard to emulate, but I know of no better way how to do it.
> Well there is escape sequences (very easy to emulate, works across
> telnet etc.; disadvantage: makes it easy to utterly scramble someone
> else's console.) That is a reasonable thing to do if it is
> per-console.
> If we want a more "out-of-band" solution I suggest creating a
> libconsole which maps to ioctl() for the kernel console; X and other
> user-space solutions can use sockets or X resources or whathaveyou to
> communicate. This separates the API from the IPC method used.

Or (as kerneld) use SysV RPC from the console to control the libconsole?
[be easier to do this than rewrite all programs that use the console
ioctls.... perhaps.. (other than kbd-utils, what programs?)]

> > > VGA/text can handle up to 512 characters (some can handle more though -
> >
> > Yes, but at the expense of having only 8 background colors.

Is life - but a possible help to countries with big (but not too big)
charsets (such as non-kanji Japanese perhaps? [a bit silly])

> YM "foreground" HTH.


> > The kernel should surely use only ASCII for its messages and the Latin-1
> > set should be only a default setting of the translation tables, but they
> > must be fully reloadable by user programs.
> Actually, the Latin-1 table in the kernel, selectable with ESC ( B is
> fine, but the ISO 2022 codes for other charsets should be honoured,
> and Latin-1 shouldn't be the automatic default.

Perhaps compile-time default? (default console character set)
Doesn't make much sense when a startup script can handle this.

Alright, already <g>.. But ARE there any problems with the 8bit -> Unicode
-> console mappings?

G'day, eh? :)
- Teunis