Michael Kelly, le mar. 13 oct. 2026 22:12:29 +0100, a ecrit: > On 10/10/2026 20:28, Samuel Thibault wrote: > > 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.
Sure, I was only taking 8x8 as an example :) A standard VGA font size would be fine :) > 1) bmpput and friends aren't in use. Can I just replace them or instead add > (for example) rgb32_put ? You can add whatever you need, yes. > 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. I'd say just throw whatever font format is simplest to throw. I mean, even hardcoded hex values would be fine enough to me, it's quite easy to modify so can be considered as source code. > 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. The likely ones will be enough, yes. Samuel
