Trade-offs

Posted Oct 10, 2025 9:48 UTC (Fri) by WolfWings (subscriber, #56790)
In reply to: Trade-offs by nim-nim
Parent article: Last-minute /boot boost for Fedora 43

The 'tiny font on a 4K screen' is just because most distro's don't enable the Terminus 16x32 console font or otherwise aren't switching to it.

fbcon=font:TER16x32 as a kernel command-line argument will switch to it, and honestly it should likely be the default these days unless dealing with something smaller than a 1280x800 screen where you'd drop below 80x25.

Trade-offs

Posted Oct 10, 2025 12:56 UTC (Fri) by nim-nim (subscriber, #34454) [Link] (6 responses)

While you’re sort of right, most users won’t do it, or discover that whatever special font is needed is broken encoding-wise, or they will hit another problem that prevents usable output on their hardware. Traditional driver-less console is a walking corpse that has not noticed it’s dead yet.

Trade-offs

Posted Oct 10, 2025 14:25 UTC (Fri) by intelfx (subscriber, #130118) [Link] (4 responses)

> <...> or they will hit another problem that prevents usable output on their hardware. Traditional driver-less console is a walking corpse <...>

The "tiny font on a 4K screen" problem actually won't go away just because you swap the UEFI GOP driver for a proper one. The only thing it might help with is if the proper driver communicates the physical screen dimensions/DPI, which in turn might prompt the splash screen renderer to adjust its scaling factor. However, I have no idea if this is actually implemented anywhere; my bet is "no".

Trade-offs

Posted Oct 10, 2025 15:27 UTC (Fri) by farnz (subscriber, #17727) [Link] (3 responses)

It's not even implemented reliably in screens - I've had more than one screen report itself as 16cm x 9cm, even though the diagonal is very obviously a lot more than that (even a 11" laptop screen is 25cm diagonal).

If the very screen itself misreports its dimensions, you're stuck.

Trade-offs

Posted Oct 10, 2025 15:44 UTC (Fri) by daroc (editor, #160859) [Link]

I wonder whether it would make sense for LUKS screens and similar to unconditionally scale themselves to be as large as possible — it would result in comically large password entry fields on big monitors, but better a too-large user interface than a too-small one.

Trade-offs

Posted Oct 10, 2025 17:57 UTC (Fri) by WolfWings (subscriber, #56790) [Link] (1 responses)

For a boot/text console the dimensions flatly do not matter, nothing except the reported screen resolution matters for font selection IMHO.

If it's at least 1280x800? Chuck the 16x32 font at it. Always. 8x16 fonts were from the 640x400 days, not even 640x480. And the 4x6 kernel font was added to handle early low-res 320x200 and similar micro-screens.

I don't want my letters to be 4x6 pixels just because I'm on a cheap hotel 40" 720p TV for the night and it tries to pick the font closest to 12 points tall.

If I've got the pixel budget for large, readable fonts the text console should use it as long as I get at least 80x25, or some other tunable if Linux decides a larger console is the minimum now.

Trying to match to a specific physical size is a printing/publishing issue and only tangentially a window-manager one, not a text console one. If anything I'm constantly fighting the "fixed physical size" attempts because they result in blurry webpages and other things from trying to force-rescale bitmaps by single digit percentages.

Font size on the text console

Posted Oct 13, 2025 15:55 UTC (Mon) by farnz (subscriber, #17727) [Link]

Arguably, you should always be aiming for the largest font that gets you a usable row by column size up until the user logs in and can configure the console to suit themselves. Yes, having 80x25 text on my big monitor results in huge characters, but that's a better failure case than having 564x250 on a smartphone screen and being unable to read it without a magnifying glass.

And it's worth noting that physical dimensions aren't enough to know what the "right" font scale is for a screen - you need not just the size of the monitor (in mm) and resolution (in pixels), but also the viewing distance to determine whether this should be treated as a "retina" display or not, since the relevant physical fact is how many pixels affect the same cone/rod on the retina, not how many pixels there are in an inch. A screen that's very close to your eyes (AR glasses, VR headset) needs a much higher pixel density than a monitor at arm's length to look good with a given set of decisions around anti-aliasing and font shaping.

Trade-offs

Posted Oct 10, 2025 17:53 UTC (Fri) by WolfWings (subscriber, #56790) [Link]

The 16x32 font supports the exact same character encodings as all the other built-in Linux framebuffer console fonts, so encoding concerns are moot.

If the framebuffer console works (which on anything remotely recent that has working UEFI it will) then the font will display properly.

They literally added it to deal with the 'retina macbook' issue of a 15" 4K screen becoming common on laptops, so the console was readable again.

Just a lot of distro's decided "It's not VGA! YEET!" and it's taken a while to get them to leave it enabled like they should have from the start.

tiny font on a 4K screen

Posted Oct 13, 2025 14:57 UTC (Mon) by adobriyan (subscriber, #30858) [Link]

> tiny font on a 4K screen

Playing roguelike which scales map with terminal size was the most entertaining thing I've done in text console on 4K monitor.

Unfortunately, scrollback neved worked properly so it was doubly unusable without screen/tmux.