Bugzilla – Bug 1225526
Tumbleweed KDE install does not include terminus-bitmap fonts or set /etc/vconsole.conf properly on hiDPI systems
Last modified: 2024-06-20 09:04:34 UTC
terminus-bitmap fonts need to be included in the basic KDE install when the system is a hi res hiDPI system such as my ASUS Zenbook Pro 15 with a resolution of 3840x2160. Also, /etc/vconsole.conf needs to be set with FONT=ter-732n.psfu and not the current default of eurlatgr.psfu If not then the terminal font is so small its unreadable.
This is not at all installer related.
First of all, what packages get installed is a matter of the software patterns. The installer (YaST) uses the patterns that the project managers provide. If they are missing something, it's not the fault of the installer. As for default console font, that might depend on a gazillion factors. A laptop screen with 4k resolution is just about the worst case scenario; of course any font that would not be insanely huge on a normal screen will be much too tiny on that setup. If you have such a setup, it might be time for some manual interaction, especially for a graphical console. How large you want your fonts to be is also a matter of personal preferences and use case. You might have to edit some config file manually. Any attempt of a one-fits-all installer automatic is bound to fail, and one or the other group of users is always going to be mad at us.
That's also not a KDE issue. We have no reason to require this particular font.
Well,it seems to me if the laptop or pc screen resolution and dpi is properly detected, which should be a simple task, a decision can easily be made, no? The terminus-bitmap font can be installed by default - that's easy enough, then the selected font to use in /etc/vconsole.conf can be determined by the screen resolution. I guess I don't see a blocking issue to resolving this, which is going to help out a lot of people and will need to be dealt with sooner or later as hi res screens become more and more prevalent.
https://forums.opensuse.org/t/how-do-i-change-the-boot-terminal-font-size/175306 is the progenitor of this report. The target was a laptop with 4K screen. It was apparent in the thread that the installation failed to include any discoverable large font to substitute for the 9x16 font in /etc/vconsole.conf. Terminus-bitmap isn't necessarily required, just something on the installed system suitable for HiDPI. Placing whatever that would turn out to be in /etc/vconsole.conf with a comment why it's there would be a bonus if something more automatic isn't doable. With too big fonts it's not usually any material problem to perform some activity to make them smaller. It's quite the opposite with too small fonts. Too small fonts can make it painful or impossible to perform activity required to make them bigger. There really ought to be something in the installer that can take account of whether the target is a high DPI or not. Maybe (via separate report, as distinctly different issue) ask to have posed some simple questions on the first screen following license, e.g.: Are you eagle-eyed? Is it often hard for you to see what's on a computer screen? Is the target screen high density (often termed high resolution or 4K)? Is the target screen a small tablet?
There is https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=dfd19a5004eff03755967086aa04254c3d91b8ec, but I'm not sure how this is supposed to work if /etc/vconsole.conf already specifies eurlatgr, the default font in openSUSE. Is there some logic in systemd?
I'm not aware of any logic implemented in systemd, the font default is configured via /etc/vconsole.conf, which in its turn is created by the installer (I suppose). It seems that the logic implemented by the installer needs to be extended to deal with high resolution monitors.
(In reply to Franck Bui from comment #7) > I'm not aware of any logic implemented in systemd, the font default is > configured via /etc/vconsole.conf, which in its turn is created by the > installer (I suppose). > > It seems that the logic implemented by the installer needs to be extended to > deal with high resolution monitors. Arguably that needs to be a runtime decision (as done by the kernel apparently), to support monitor and resolution changes.
I'm not aware of such runtime support and until it happens it might make sense to init /etc/vconsole.conf so the fonts are at least readable by default after a fresh installation.
Surely we need a mechanism in the user-space. It'd be something like to choose a proper font depending on the current resolution and upload via ioctl, instead of a fixed file name in /etc/*.conf.
Please be advised that this also has to work for a deployed image or for similar scenarios where there is no installer that can automagically heal an obvious problem somewhere in the system. Relying on the installer to fix this is not a sustainable solution. Also, as Fabian correctly pointed out in comment #8, resolution shoud be taken into account.
(In reply to Stefan Hundhammer from comment #11) > Also, as Fabian correctly pointed out in comment #8, resolution shoud be ^^^^^^^^^^ a resolution change > taken into account.
This whole console font thing should really become independent of pixel size; it should be a millimeter-based size. It is known on the kernel side that the native resolution is insanely high, and the display's EDID information with the physical size in millimeters is also available. From that the DPI can be calculated, and then a font size in milimeters and then a lookup table can be used (or, better yet, a font can be scaled accordingly if scalable (TTF?) fonts are supported). This is basically what we are doing in the YaST startup scripts in the Qt/X11 case. In the NCurses case, you'll have to live with whatever tiny font the kernel uses for the resolution (but you can select a different console resolution in the installation medium's boot menu which linuxrc will process). As deployable images (e.g. Kiwi-based) are becoming more and more widely used, we will no longer be able to work around this problem area with some code in the installer. Get used to the idea that in many cases there won't be an installer.
EDID isn't always available. Imagine EFI framebuffer. So we cat have a rough estimation from the the console size. And the use of TTF is no way for the default kernel console. The rendering code runs in kernel, so we definitely don't want drag the complex rendering libraries into the party. If we really want to give more beauty, stop using the kernel vconsole and use own console on user-space once after the DRM device is set up. Then any complex rendering can be applied. But, of course, this will mean that you'll loose the messages if the console invocation doesn't work by some reason. Anyway: practically seen, there are a few options for this long-time problem. If we want some automatic choice of fonts in runtime: - Make systemd vconsole setup smarter to check the resolution and choose the right font from the given list (or some default choices) - Make systemd vconsole setup smarter to pass -d option to setfont for higher resolution (if the font size <= 16), or - Make setfont program smarter to double the size automatically for higher resolution The first one would need the list of fonts for different sizes. OTOH, for the original issue, it'd be rather a choice of the default value of /etc/vconsole.conf (as the laptop screen itself is HiDP, so always need a larger font), and this can be improved in the installer, too.