lkml.org 
[lkml]   [1997]   [Sep]   [12]   [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, H. Peter Anvin wrote:

> > The _FONT_ is loaded into the videocard - when necessary...
> > ... this could be stored in virtual-mem and reloaded if necessary...
>
> There is no kernel facility for accessing virtual memory. Creating
> such a facility would be very expensive.

Definitely userspace then... (but one adjustment : can access virtual
memory [jump through hoops]; How about create?)

> > FWIW the font remapping and font itself are quite small: 8bitx16x256 chars
> > being normal == 4096 bytes per font (1 page). though there ARE 2-page
> > fonts I would guess.
>
> 8bit x 32 x {256,512} = 8192 or 16384 bytes.

Whoops - I was thinking of the TGA code (8bitx16).... Though FWIW VGA
only seems to use 8bit X 16....

> > Alright, already <g>.. But ARE there any problems with the 8bit -> Unicode
> > -> console mappings?
>
> No, I think it is the right thing to do.

I rephrase : Are there any known problems with the 8bit -> Unicode ->
console mapping code in the kernel?

> A graphical console is a good example of something that belong in
> userspace IMNSHO, both for complexity and flexibility.

Yes - but device access MUST be _moderated_ by the kernel!
(unlike X)
But that's neither here nor now - and noone is likely to allow this into
the kernel even if it worked <sigh>. Been through that fight before
(though I was a spectator the last time).

G'day, eh?
- Teunis



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