Re: New VGA console coming

[Petr V. <van...@vc...>]

On Sun, Aug 27, 2000 at 10:26:55AM -0400, James Simmons wrote:
> > > call int 10h, ah=18h, al=0,1 which can get/set a font pattern. This leads
> > > to me to believe it might be possible for VGA to support double byte
> > > fonts. This of course would mean a rethinking of how the shadow buffer
> > > should be done. Any ideas anyone?
> 
> It is there. Int 10/AH=18h. Their is also a AH=19h (Japanese VIDEO -
> DOUBLE-BYTE CHARACTER SET SHIFT). Not much info tho :-( As for the 
> text modes (mode 52h) that support 16 bit characters appears to be
> actually vga 16 color graphics modes. I still like to know where those
> extra fonts are stored. Maybe in regular memory. We do have vgafb which

If you'll insist on 8x16 font (16 bytes per character) and only 65536
characters, it is 1MB only... Yes, if you want different character
sets (different font slices) on each VT, it can get memory consuming,
but in such case - create kernel thread which will have access to
swappable memory and swap unused characters out. Or leave whole
font delivery on userspace...

> could be made to support 16 bit characters. Since vgafb is supported on 
> any platform that vgacon is this expands the range of languages linux can
> support. The only problem is ...
 
> ... how to handle so many fonts. I like the idea of a cache of X amount of
> characters. Even for fbcon this would be useful. As for the layout of the
> shadow buffer. We really need to reconsider its layout. With the idea of
> a font cache how about this. 16 bits is used to represent each character. 
> The high 8 bits are a index to different font caches. This allows 256
> different font caches. The lower 8 bits acts as a index into the font
> cache. Now what to do with the attributes? The idea of having 24 bits to
> represent a text charachter botehrs me. I prefere if it was 32 bits. We
> have to do alot of shifting bits around to get to work otherwise. 

I do not think that font cache idea is best... Leave it on user - if he
has hardware which is not capable of displaying more than 512 different
characters simultaneously, give him two choices:
(1) select which 512 characters he'll use or
(2) limit his screen to 512 characters only and change character generator
    instead of screen contents

Yes, shadow buffer layout needs to be changed. Do not forget Martin Mares
ideas when doing it - currently slowest thing during screen scroll is
shifting buffer in memory. Having array of pointers to lines can
make this operation much faster.

For character, either make it 4:4:24, where
first 4=one of 16 currently selected colors,
      4=one of 16 currently selected colors,
     24=character number; either Unicode 0-10FFFF, or arbitrary font
encoding..., or, if you want, 32:32:32:32,
where 32=reserved,
      32=foreground color, 8:8:8:8 RGBA or 16:5:6:5 or 24unused:8 or...
      32=background color,
      32=character number
I do not think that anything else is reasonable. And do not forget that
for 32:32:32:32 one on-screen character consumes 16 bytes, 80x25 screen
then consuming 32K instead of current 4KB...
					Petr Vandrovec
					van...@vc...