> On Wed, 10 Sep 1997, Teunis Peters wrote:
> > On Wed, 10 Sep 1997, H. Peter Anvin wrote:
> > > 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...
>
> Somthing along the lines of setting the MMU to map the space where the VGA
> card looks for the font into where the font for that terminal is? No-go --
> the VGA card dosn't go through the MMU.
I know - I thought of some kind of trigger (eg. change console) to trigger
font reload (which would be handled either by a specific routine - or
even better, in userspace).
> > 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
> Odd. The worst you should get is flashing. (With non-duel-ported memory).
Trident goes hoopy (loses info about graphic res IIRC) if you don't handle
its fonts correctly.
> > 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
> I have. (It was born the same year I was, and that computer died already.
> Sad.) It's font is in ROM, no change without a REALLY small soddering iron
> <G>.
MDA still supported by linux :)
... but scary!
> > CGA(/EGA?) - no font remapping... Assume IBM-PC chars
> EGA font loading is identical to VGA (except for font height).
Thanks!
> > Hercules - no font remapping... Assume IBM-PC chars
> I wouldn't be surprised if it does, but I wouldn't know where to look.
> > 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).
> A non-graphical console would deffenitly be better though. Better
> resolution (lower mem requirements), faster (much handled by card, not CPU).
Yep - but in these days of fast accelerators et al, video-based console is
possible. 'sides, ever run 'kon' from the JE package? It's VGA based and
EXTREMELY fast (only slightly slower than hardware-based textmode).
It also supports large charactersets (EUC, JIS, SJIS)
> > Please don't say GGI - even though (if it worked <sigh>) that would be an
> > ideal solution to font reloading.
> True, true. Sigh...
I've been watching and annoyed with them - where is a coherent working
spec when you need it? I think they're going to complicated as well...
> > 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])
> Signal+data (what font). Also, giving a reason would be nice (bad font number,
> file not found, unable to access font buffer...), but I supose that you
> could log the reason and just return "error" to the kernel.
Actually - Yeah, I suppose. But returning variety of error would be
important for error recovery (Very Important for console!)
> > (actually - that would fit in well with what I want to do to the console :)
> As in registering a different process to handle requests to change the font
> for non-console terminals?
As in registering a process to take over from the console....
(handling display, fonts, et al).
> > > > > 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.
> You can do that now. Change the mapping, but not the font. Even just echo
> "Screw you!" to it continually, so that the real output scrolls off to fast
> to see. (Just tried this. VERY annoying!.) Either way, just type a command
> blind, and the bother is gone (easyer in this case: "setfont", rather than
> "/bin/echo \033]R" (reset palette from all black)). If you don't wan't this
> to happen, "mesg n". It's a feature, not a bug.
Okay - I can accept that :)
Can everyone else?
G'day, eh? :)
- Teunis
Sort of one last note : IIRC the console is kinda a 'special case' when it
comes to device support due to it being necessary before all of the device
support is setup.... is this possible to change?
Just curious....