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

Teunis Peters (
Tue, 9 Sep 1997 17:48:31 -0600 (MDT)

On Tue, 9 Sep 1997, Martin Mares wrote:

> Hi,
> > > Can anyone describe WHAT is the problem with UTF-8 conversions in the
> > > console code? (AFAIK it's in consolemap.c - but what's happening?)
> > >
> >
> > I don't think there are any problems here; the problem is that the
> > current mapping of 8-bit character sets to Unicode (which is
> > subsequently mapped to fonts) is Latin-1-centric.
> The only problem I've seen is that it should be possible (but it isn't)
> to reload _all_ font->Unicode maps, not only the user one.
> In addition to this, it would be nice to allow setting of some map
> type as default to make applications _not_ reset the mapping during
> their console init.

So where is console init signalled? (userspace? specific normal reset

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?

Perhaps a new console sequence to reset the fonts.... either that or only
the font-set sequences be able to reset the font.

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).

I think the latin-1 centeredness is from having 4 pages of maps: (AFAIK)
1 - default latin-1
2 - graphical mapping
3 - IBM-PC mapping (for hysterical raisons :)
4 - userspace font

Hmm - I'm not all that sure on how these interact though...
[grabbing from 'console' source]

VGA/text can handle up to 512 characters (some can handle more though -
eg. Trident-8900 can handle 2048 characters AFAIK)

The source itself prolly shouldn't be so latin-1 centric (though having
ASCII as the only character set in the kernel would IMHO be a good idea -
and I mean for all kernel messages et al - that is until the kernel
supports more than textmode <sigh>)

G'day, eh?
- Teunis