On 10/10/2026 20:28, Samuel Thibault wrote:
Hello,
Michael Kelly, le sam. 10 oct. 2026 01:18:44 +0100, a ecrit:
3) My biggest worry was how to get a font loaded into the kernel. I think
that the multiboot module can do that and all that is needed is to strip out
a special 'boot_font' module from the list as they are translated from
multiboot2 to multiboot. No need to worry about file system access or
embedding a font in the kernel itself. The font could be unloaded after boot
when the user console takes over.
Embedding a basic font in the kernel looks fine enough to me. It can be
e.g. 8-byte per character, covering only ascii, that's just 1KB of data.
I have a working prototype with an embedded font of size 8x14 which adds
an array of 1344 bytes if the characters 32-128 have bitmaps and
characters outside this range show as '?'. It's obviously even smaller
with 8x8 but it didn't look too good although it was perfectly
readable. I'm now starting to progress it to something that can be merged.
1) bmpput and friends aren't in use. Can I just replace them or instead
add (for example) rgb32_put ? I haven't worked out what kind of
framebuffer the old code was intended for and it certainly needs
alteration for a 32 bpp one provided by the boot loader.
2) Similarly, do I need to maintain the font format that the code
currently expects? This is a sequence of character-set width scanlines.
The simple font definition that I've copied from the Seabios Qemu code
is in a different format. I can convert that if necessary so it's not a
problem really.
3) Which of the different frame buffer encodings that are possible with
multiboot do I need to support? I suggest just the likely case of RGB
and 32bpp for the moment.
Cheers,
Mike.
