While calculating font size based on EDID data, we can end up
selecting too large font and too small terminal. Add check to
prevent it.
Details
Details
- Reviewers
manu trasz adrian - Commits
- rG5e25f7b09977: loader: loader can pick too large font
Diff Detail
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
Comment Actions
What happen if the reported size is plainly wrong ?
Like on my system, at the loader phase my screen is 800x600, and after the kms driver is loaded it goes to higher dimension: 1080p, 1440p.
Does the smallest font will work in this case ? Or there will be no font selected ?
Comment Actions
I tested this on my machine (2560x1600) and nothing bad happened (default font is still 32x64 producing a perfect 80x25).
Comment Actions
in this case the reported size is still not wrong, it is different what you will get later, when the kernel is running and the KMS is starting up. And it is the case we can not really handle with loader. My supermicro does only use 800x600 with UEFI (it does list better modes, it does allow to switch to better mode with BIOS, but with UEFI it is limited to 800x600). So in such case we can not use larger font in loader as it will mess up the loader console and with small font the kernel console will be unreadable due to font being too small. As the current kernel does not have ability to "autoload" the best font, it has to be configured via rc.conf. We do have the code in loader and it can certainly be ported for kernel/KMS case too.
| stand/common/gfx_fb.c | ||
|---|---|---|
| 2085 | what if it's too big in just one direction? | |
| stand/common/gfx_fb.c | ||
|---|---|---|
| 2085 |
yes, have bug there:) fortunately, with current fonts its not an issue, but need to fix it:) | |
| stand/common/gfx_fb.c | ||
|---|---|---|
| 2085 | the font isn't the only variable; screen geometry matters too, and that's far more variable today than it used to be. | |