lkml.org 
[lkml]   [1997]   [Sep]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Console mapping problems? [I hear about these - I wanna know!]
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.

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

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

> CGA(/EGA?) - no font remapping... Assume IBM-PC chars
EGA font loading is identical to VGA (except for font height).

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

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

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

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

>
> G'day, eh? :)
> - Teunis
>

-=- James Mastros

---
I can now be reached again at abszero@epix.net or
root@jennifer-unix.dyn.ml.org.
"Shooting as [a] communications method is obsolete even here in Bosnia, so
I'll skip over it."
-=- Dragisha Durich


\
 
 \ /
  Last update: 2005-03-22 13:40    [W:0.102 / U:0.580 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site