2017-07-16 11:32 GMT+02:00 Paul Kocialkowski <cont...@paulk.fr>:

> So I am wondering what the best way to solve this would be. I see a few
> options:
> * Having larger fonts for hi-dpi displays
I'd go with that. Plus, maybe, a function to select the right font given a
few constraints (display resolution, desired terminal grid size)

There are a bunch of font options with higher resolutions in the Linux
sources (lib/fonts) that could be lifted into libpayload.

* Scaling the font to reach a particular DPI (e.g. based on the physical
> screen size reported from the EDID)
This could be a reasonable fallback (eg in case payloads are storage
constrained and can't ship x fonts, or if even the largest font is
intolerably small).
Going for integer multiples (and statically generating the fonts in the
internal format, registering it just like any shipped font) should be good
No need for any fancy scaling algo either, just duplicate the pixels in all

> * Reducing the resolution, by optionally providing a preferred one from
> the config
Besides the potential dependency on resolution in later stages that you
mentioned, the panel may or may not work well with a lower resolution, or
might just show the same tiny pixels - just fewer of them with a nice,
shiny, black border.

Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
coreboot mailing list: coreboot@coreboot.org

Reply via email to