> > > 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.
Hmm???
> > 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