On Mon, May 14, 2001 at 09:17:11PM +0200, Matthias Drochner wrote:
> 
> For the font handling within the wscons framework, I'd propose
> the following:
> 
> -Change the "load_font" member of "struct wsdisplay_accessops"
>  to take a string only as argument. This string identifies
>  a font to _use_ for a certain screen. There wouldn't be a notion
>  of "loading" a font into a specific adapter anymore. Adapters
>  have to use builtin fonts, or to get it from "wsfont" or another
>  (private) source of font data.

Does it mean the first argument void *v of vga_load_font() should
be removed?

> -Extend "wsfont" to take over the "load font" function which was
>  per-adapter. Create a "pseudo-device" for the cdev interface.

What I'm worried about is things may get too complicated by 
introducing pseudo-device interface.

> Afaict, only the "vga" driver uses the "load_font" entrypoint
> at the moment. The change would allow to integrate "vga" better
> with the "wsfont" framework and to make things cleaner in general.
> 
> What I've tested so far is the first part; I'm running a "vga"
> driver which takes its fonts from the "wsfont" pool. If
> the needed fonts are compiled into the kernel (options FONT_xxx,
> see dev/wsfont/files.wsfont), screen types like 80x50 and 80x40
> can be used without loading a font from userspace before.

80x50 font can also be loaded from VGA ROM.

> Does anybody see problems with this direction of development?

Will 'wsfont' have support for multiwidth fonts like CJK? How 
about merging `uwscons' work into the new wscons (other features
such as ATI fontsel workaround, back-scroll, etc. as well)?

Jun-Young

-- 
Bang Jun-Young <bjy@mogua.org>