I am using upstream coreboot with top-of-tree depthcharge and vboot on kevin (Chromebook Plus from Samsung) and I've patched depthcharge[0] to display text messages instead of looking up bitmaps in the GBB/cbfs.
I noticed that corebootfb is using[1] a fixed 8x16 font for showing text there. In addition, the RK3399 eDP code will always go with the "recommended resolution" from the EDID, which is the highest one.
The result of this is that the displayed text looks really small on- screen, which does not really provide a great user experience.
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 * Scaling the font to reach a particular DPI (e.g. based on the physical screen size reported from the EDID) * Reducing the resolution, by optionally providing a preferred one from the config
Among these, which ones do you think is the way to go? I think the question is also whether we want a generic way to handle this or to do it per-device (and also keep in mind that not every device has EDID available, but may have a single hardcoded resolution, which could still superseded by the suggested config option).
I like the idea of reducing the resolution. It may however also break compatibility with e.g. ChromeOS that expects the framebuffer to be set at the max resolution by coreboot.
[0]: http://git.code.paulk.fr/gitweb/?p=libettereboot.git;a=tree;f=projects/depth... [1]: https://review.coreboot.org/cgit/coreboot.git/tree/payloads/libpayload/drive...
Cheers,
2017-07-16 11:32 GMT+02:00 Paul Kocialkowski contact@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 enough. No need for any fancy scaling algo either, just duplicate the pixels in all directions.
- 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.
Patrick
Paul Kocialkowski wrote:
I am wondering what the best way to solve this would be.
..
- Having larger fonts for hi-dpi displays
This should be the top priority, because it provides the best user experience. (Ie. it looks the best.)
- Scaling the font to reach a particular DPI (e.g. based on the physical screen size reported from the EDID)
This is a great fallback solution which will make sure that a font is *always* available. As others wrote, upscale only once during init. If upscaling fails for whatever reason, fallback to the fallback is to simply use the 8x16 font as-is. Better small text than no text.
- Reducing the resolution, by optionally providing a preferred one from the config
I consider this an unacceptable alternative. Not only is it unreliable (it may not always work) but even more importantly it is likely to provide a worse user experience (uglier scaling) than upscaling the font, when the panel driver does scaling at all, otherwise the result will be as Patrick described; black border around small part of panel.
Among these, which ones do you think is the way to go?
Panels only have one native resolution, and that one is what they are optimized for. It's a bad idea to try to use anything else. Use hardware the way it was optimized for to get the best possible user experience - "less than best possible user experience" isn't a great goal.
I think the question is also whether we want a generic way to handle this
Yes, please. This is not unique to any device, but has been a generic problem since the VGA BIOS was invented.
//Peter
-
Patrick Georgi -
Paul Kocialkowski -
Peter Stuge