bjy@mogua.org said:
> Does it mean the first argument void *v of vga_load_font() should be
> removed? 

No, not the handle. The third argument, currently "struct wsdisplay_font *",
would be replaced by a single string which is interpreted just like
"data->name" currently.
As you have probably seen, the meaning of the "load_font" entry is
somehow overloaded: if no "scr" (=screen) is passed, it loads fonts
into the adapter memory. With "scr", it selects one (or two) of the
fonts for an actual screen. This is ugly.
The plan is that only the selection function remains; the card
has to get fonts which are not built in from the "wsfont" pool.
(So the "wsfontload" utility would feed that pool instead of some
adapter RAM then.)

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

We would want to have it anyway sooner or later for the benefit
of raster console drivers.

> 80x50 font can also be loaded from VGA ROM.

Can you point me at sone documentation?

> Will 'wsfont' have support for multiwidth fonts like CJK?

wsfont can deal with "all kinds of fonts" - there is already
a 16x29 font for instance.

> How 
> about merging `uwscons' work into the new wscons

I've just downloaded your latest patches. Looks quite well...
I have yet to understand the details. What I'm a bit worried about are
interactions of multibyte fonts with vt100 escape sequences. Can this happen?
Is this "DCS94" sequence used by japanese vt100 versions?

best regards
Matthias