At Sat, 22 Aug 2026 22:29:46 -0000 (UTC), mlelstv%serpens.de@localhost (Michael van Elst) wrote: Subject: Re: NetBSD vs. VirtualBox > > For a raster display, the kernel has only a couple of fixed size fonts > available and selects the "best" one to produce a 80x25 terminal. > You can compile more fonts into the kernel. Why is the genfb(4) driver trying to create an 80x25 terminal when it attaches!?!?!? It really shouldn't do _anything_ to the already working display hardware when it attaches! In a separate post Michael also wrote: > > It may not even know that there is a font that it should keep. The bootloader has already changed the resolution, and there is actually already a perfectly good font being used at that resolution to display the initial bootloader and kernel output. (On really high resolution screens the font might be rather tiny -- that's what happens under macos on my mac Pro with its big 6k monitor when you have it configured to boot verbosely, but it's still readable.) > And switching screen resolution without switching font can also be > ambitious. But again, genfb(4) shouldn't be switching the screen resolution -- it should simply be discovering what resolution the bootloader changed it to! It shouldn't be doing any font switching either. As-is in my view genfb(4) is behaving like some Windows/BIOS like monstrosity that believes it knows best and you'd better like it or shut up about it. It might not appear to be doing anything at all if one sticks to the minimal screen resolution and the default boot loader font is the same size as the one it chooses, but step outside that range with a "vesa" or "gop" command (as required by which firmware is used) and the result is a horrifically ugly visual mess (even when it is still more or less readable). If the "user" has configured different things to be done when the userland wscons configuration is done then that's a different story. I'm betting this part of the reason, if not the whole reason, that genfb(4) causes a scrambled mess of bits on the screen on my macbook-air when it attaches (thus so far making testing or further development on the macbook impossible). -- Greg A. Woods <gwoods%acm.org@localhost> Kelowna, BC +1 250 762-7675 RoboHack <woods%robohack.ca@localhost> Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgpCKaex1L9BL.pgp
Description: OpenPGP Digital Signature