Re: [coreboot] Hi-DPI displays and showing text information for kevin in depthcharge
Le dimanche 23 juillet 2017 à 16:21 +0300, Paul Kocialkowski a écrit : > Le lundi 17 juillet 2017 à 22:11 +0200, Patrick Georgi via coreboot a > écrit : > > I wouldn't scale at compile time (as said, storage constrained > > payloads might not be happy about that). > > > > I wouldn't scale each character up on each access though (we won't > > hardware accelerate the scaling, and yes, that does get slow - > > framebuffers aren't always the fastest type of memory and that way > > the > > access pattern is the same set of memcpy()s as for any other huge > > font, so we won't need to deal with "fast fonts" and "slow fonts" > > beyond basic geometry characteristics), but synthesize a new font in > > the regular font table at init-time and then use it like any pre- > > existing font (just that it happened to be added after load). > > As it turns out, no scaling in memory is required, either at build > time > or run time. This is thanks to the fact that the font is coded with > each > bit representing a filled or blank pixel, so the font has to be > accessed > bit-by-bit to draw it. I simply modified the access logic to use a > scale > factor and I don't think it will impact performance much (that's still > two extra divisions for each pixel though). > > The changes are up for review at: > https://review.coreboot.org/#/c/20708/ > https://review.coreboot.org/#/c/20709/ > https://review.coreboot.org/#/c/20710/ > > Thanks everyone for the feedback and happy review! I forgot to mention: I tested this on kevin (with and without scaling) and the result looks great! > > 2017-07-17 21:47 GMT+02:00 Julius Werner : > > > I agree with most of what Patrick said, I think dynamic scaling to > > > integer multiples may be best. Scaling the font up at compile-time > > > seems like unnecessary bloat to the binary (although I'm not sure, > > > how big are these fonts?). If you do want to include them at > > > compile > > > time, you may as well include a real larger font rather than just > > > a > > > scaled one. -- Paul Kocialkowski, developer of free digital technology and hardware support. Website: https://www.paulk.fr/ Coding blog: https://code.paulk.fr/ Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/ signature.asc Description: This is a digitally signed message part -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Hi-DPI displays and showing text information for kevin in depthcharge
Le lundi 17 juillet 2017 à 22:11 +0200, Patrick Georgi via coreboot a écrit : > I wouldn't scale at compile time (as said, storage constrained > payloads might not be happy about that). > > I wouldn't scale each character up on each access though (we won't > hardware accelerate the scaling, and yes, that does get slow - > framebuffers aren't always the fastest type of memory and that way the > access pattern is the same set of memcpy()s as for any other huge > font, so we won't need to deal with "fast fonts" and "slow fonts" > beyond basic geometry characteristics), but synthesize a new font in > the regular font table at init-time and then use it like any pre- > existing font (just that it happened to be added after load). As it turns out, no scaling in memory is required, either at build time or run time. This is thanks to the fact that the font is coded with each bit representing a filled or blank pixel, so the font has to be accessed bit-by-bit to draw it. I simply modified the access logic to use a scale factor and I don't think it will impact performance much (that's still two extra divisions for each pixel though). The changes are up for review at: https://review.coreboot.org/#/c/20708/ https://review.coreboot.org/#/c/20709/ https://review.coreboot.org/#/c/20710/ Thanks everyone for the feedback and happy review! > 2017-07-17 21:47 GMT+02:00 Julius Werner : > > I agree with most of what Patrick said, I think dynamic scaling to > > integer multiples may be best. Scaling the font up at compile-time > > seems like unnecessary bloat to the binary (although I'm not sure, > > how big are these fonts?). If you do want to include them at compile > > time, you may as well include a real larger font rather than just a > > scaled one. -- Paul Kocialkowski, developer of free digital technology and hardware support. Website: https://www.paulk.fr/ Coding blog: https://code.paulk.fr/ Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/ signature.asc Description: This is a digitally signed message part -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Hi-DPI displays and showing text information for kevin in depthcharge
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 -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Hi-DPI displays and showing text information for kevin in depthcharge
I wouldn't scale at compile time (as said, storage constrained payloads might not be happy about that). I wouldn't scale each character up on each access though (we won't hardware accelerate the scaling, and yes, that does get slow - framebuffers aren't always the fastest type of memory and that way the access pattern is the same set of memcpy()s as for any other huge font, so we won't need to deal with "fast fonts" and "slow fonts" beyond basic geometry characteristics), but synthesize a new font in the regular font table at init-time and then use it like any pre-existing font (just that it happened to be added after load). 2017-07-17 21:47 GMT+02:00 Julius Werner : > I agree with most of what Patrick said, I think dynamic scaling to integer > multiples may be best. Scaling the font up at compile-time seems like > unnecessary bloat to the binary (although I'm not sure, how big are these > fonts?). If you do want to include them at compile time, you may as well > include a real larger font rather than just a scaled one. > -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Hi-DPI displays and showing text information for kevin in depthcharge
I agree with most of what Patrick said, I think dynamic scaling to integer multiples may be best. Scaling the font up at compile-time seems like unnecessary bloat to the binary (although I'm not sure, how big are these fonts?). If you do want to include them at compile time, you may as well include a real larger font rather than just a scaled one. -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Hi-DPI displays and showing text information for kevin in depthcharge
Le lundi 17 juillet 2017 à 10:55 +0200, Patrick Georgi a écrit : > 2017-07-16 11:32 GMT+02:00 Paul Kocialkowski : > > 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. Sounds reasonable enough! > > * 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. Yeah, that would totally do. > > * 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. Hehe, that is a very good point. This approach is too device-dependent anyways. I'll wait for more feedback before starting the work on this (I have a lot on my plate anyway so this probably won't be a priority for some time). If anyone else feels like starting an implementation, I'd be overly grateful though! Cheers, -- Paul Kocialkowski, developer of free digital technology and hardware support. Website: https://www.paulk.fr/ Coding blog: https://code.paulk.fr/ Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/ signature.asc Description: This is a digitally signed message part -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Hi-DPI displays and showing text information for kevin in depthcharge
2017-07-16 11:32 GMT+02:00 Paul Kocialkowski : > 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 -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] Hi-DPI displays and showing text information for kevin in depthcharge
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/depthcharge/patches;h=dd17766e4b5217456f1d8ae20619a08bd34e9be4;hb=HEAD [1]: https://review.coreboot.org/cgit/coreboot.git/tree/payloads/libpayload/drivers/video/corebootfb.c#n124 Cheers, -- Paul Kocialkowski, developer of free digital technology and hardware support. Website: https://www.paulk.fr/ Coding blog: https://code.paulk.fr/ Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/ signature.asc Description: This is a digitally signed message part -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
