jmmv84@gmail.com wrote:

> This seems wrong to me, because it spreads "knowledge" of the problem  
> everywhere and also exposes it to the user by requiring him to add an  
> extra option to his kernels to preserve the "standard behavior".   
> Plus... if vga was an LKM (could it be?), this solution would not be  
> applicable.

I suggest an easier way to handle a minor MD quirk which affects
very few users. If we'd handle it in the "right" way, we have to
investigate actual problems more closely.

I think there are three independent problems:


(1) vga(4) assumes that builtin font is always WSDISPLAY_FONTENC_IBM

I don't know if userland programs refer this encoding value,
but if we possibly have some VGA device which has different
encoding from FONTENC_IBM, we should have some proper hook
(via proplib etc.) to override it.

I'm not sure if it will work even in consinit() since it's
often called before uvm_init(9) where we can't use malloc(9).


(2) vga(4) always uses the default wsfont in vga_no_builtinfont case

When I wrote vga_no_builtinfont code for Express5800/240 (arc),
I didn't make vga(4) use vt220 fonts because the machine
had no fonts in its ROM so any font could be enough.
If we really want to always use VGA-like font for vga(4),
we should make vga(4) depend on such vt220l fonts and specify
it explicitly (with options) even if it makes kernels bigger.
Making any VGA font default of wsfont is not correct because
if users specify some other fonts by options(4) even for
non-VGA devices they will get different fonts than
"standard" VGA's one on vga(4).


(3) the default "bold" wsfont is not so pretty

I agree with this, but there is no consensus that
vt220l8x16 is more appropriate for the default.
Someone may claim vt220iso8x16 is more generic,
others could prefer a different font like sony8x16
especially for non-VGA machines.


I avoided such (possibly less worth) discussions
when I added vga_no_builtinfont support because
there were only two users of such arc machine..
---
Izumi Tsutsui