Re: New VGA console coming

[James S. <jsi...@ac...>]

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

Yeap. It should be handled as much as possible in userspace. I believe we
should allow only one font type per VT at boot time. If possible share 
that font with as many VTs as possible. This way we can use COW techniques
to save on memory consumation. In fact the new code in CVS points works
this way. I have a default font in struct vt_struct and every vc_data that
is attached to that vt_stuct have its own font point pointing to the
default font. When userland changes this then the pointer will point to
the new font. If the user uses the default font which is the most common
case then only one copy of the font exist in memory for all those VCs.

> 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

True if it is a harware limitation. If it is not then its gets a little
tricky. Maybe all we need is 512 to get threw the boot process for w_char
based languages. After boot time let userland handle it. 

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

Interesting idea. Also what is really slow is bmove. Inserting a character
and moving all the characters to the left of it can be pretty tricky. The
thing I never understood is way the shadow buffer is the exact same size
as the visible area of the display. Why not make it bigger and just move a
pointer in the shadow buffer. We can 99% of the time use harware panning
to move the characters up and then just read the buffer further down in
the buffer to display them. Yes sooner or later we have to flip this
shadow buffer.  

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

This is closer to what is really needed. We also need a byte for
attributes. Maybe we can squeeze it in 4 bits. This will consume less
memory as you pointed out.


MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsi...@li...]               ____/| 
fbdev/console/gfx developer                             \ o.O| 
http://www.linux-fbdev.org                               =(_)= 
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net