> 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
sequence?)
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