Re: New VGA console coming

[Steffen S. <se...@ph...>]

James Simmons wrote:
> 
> Sorry I have been away but I was sick.
> 
> > The console layer handles the glyph information to be displayed using full
> > UNICODE-2.0 (or it's successor, the ISO norm for 32bit character codes).
> 
> Same here. By the way I have expanded the conmakehash.c program to
> generate a unicode->font map of up to 65,536 characters.
>
> > Using the font and attribute information, this is translated into a
> > font-specific code, which is stored in the shadow buffer using a pattern
> > defined by the graphics driver only. Then the graphics driver does the
> > rendering from the shadow buffer, it never gets involved with the
> > glyph-code -> font position translation. This way it is up to the graphics
> > driver, which attributes and how many font characters it supports.
> 
> So the shadow buffer is driver specific. Couldn't the shadow buffer get
> really huge for some types of hardware ? 

No, as the shadow buffers are limited to a certain size (e.g. currently 8K),
and the number of bits per character cell is fixed (16bit). However, the
driver may choose how to use these bits, e.g. if it wants 9 for glyph code,
7 for colors, etc.

> I do realize that my idea of
> making the shadow buffer a unicode buffer will not work since you might
> need more than one unicode to make one characters.

Correct. All you can do is to store font indices, which is what KGI does.
Of course the back-translation (e.g. for selections) into UNICODE is not
one-to-one, but there isn't much you can do about.

> So it has a be some
> type of glyph index. Do you use a seperate attribute buffer then?

No. All info (attributes, glyph position, etc) is stored in a kgi_u16_t array.
If there ever arises a urgent need for 32bit (e.g. 24bit glyph code, 8 bit
colors)
KGI can be easily extended to support 32bit wide buffers.

However, I don't see this need, as with about 500 Glyphs you can cover most
of the european languages (german, greek, ...) sufficiently. If you need
console support for Eastern (e.g. except Korean) languages, you are better of
to not implement this inside the kernel. Mainly because input requires a
dictionary search sometimes.

			Steffen

_______________________________________________________________________________
Steffen Seeger                              mailto:se...@ph...
TU-Chemnitz                                      http://www.tu-chemnitz.de/~sse