Salvatore Bonaccorso dixit:
>FTR, there is some progress in
>https://lists.debian.org/debian-kernel/2025/12/msg00293.html (which
Interesting.
No, fonts don’t always have 256 or 512 glyphs, they can have less.
On the laptop where this happens, I use one compiled by
console-fonts, so glyph order is essentially random, but
a patched version thereof with my own 9×18 variant as base,
not the standard fonts from Debian, so that’s likely the
reason I get the currency sign, not the copyright sign.
And, looking at /etc/console-setup/cached_Uni1-Fixed18x9.psf.gz
in hex editor mode, I can indeed see that the unimap for the
first glyph is \xC2\xA4, the currency sign.
I think at this point it is clear that we’re talking about three
separate bugs. Adding the console-setup maintainers to To:.
The one we discovered here is that the fonts autocompiled by
console-setup do not place a blank glyph at index 0, which is
probably expected here.
⚠ Note that using the LAST glyph of a font would be even worse!
This expectation was useful in times when fonts had codepages,
but it is not sensible for PSFU fonts with an unimap. This is the
second bug: the kernel must not use glyph #0 or #32 or so but the
glyph that corresponds to U+0020 in its encoding. (For PSF fonts,
without an unimap, continuing to use a numbered glyph is likely
still the best thing.)
(Given this, I’m not sure console-setup needs to change here, but
it’s not entirely unlikely that something may wish to use these
fonts without the unimap, so IMHO the compilation process should
make sure that the glyphs #33‥#126 should be their ASCII counter‐
parts, and that either #32 or #0 should be the empty glyph. I’d
slightly argue in favour of #32 here, which Linux should then make
its numbered fallback glyph for unimap-less fonts.)
The third bug, however, is that the consoles are spilled full of
those glyphs and that the normal expected output (hostname, the
text "login:", and the shell output when running the shell) does
not show up. That’s the one reported as #1123750. Given it only
occurs on the bullseye kernels, it may be a bug introduced when
backporting the referenced commit.
Helge wrote:
> visible), we could try replacing it by:
> ch = 0x20; /* use ASCII space character */
Looking at (after over three minutes of Anubis overheating my
laptop to 73+°C) https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/patch/?id=18c4ef4e765a798b47980555ed665d78b71aeadf
I see that this won’t fly.
“ch” here is not an ASCII codepoint but the glyph index of the
font, which doesn’t need to have an ASCII-based encoding. (In fact,
many don’t because you don’t need to have blank glyphs at 0, 32,
160 for latin1, and 255 for cp437; one blank glyph and an unimapping
suffice.) There belongs some code that looks up the glyph corresponding
to U+0020 and using that instead (ideally, do that at font load time
and store the “blank glyph index” in the font-specific struct).
But, again, that’s just a side bug. This is something I can avoid by
loading a font with a blank glyph at index #0. In fact, let me switch
to Ctrl-Alt-F2 (I’m currently in X) and do that.
… having done that, this results in a mostly blank screen, only the
very first character of the shell prompt is visible, nothing else
at all. That’s the real bug that needs fixing.
My /etc/console-setup/cached_Uni1-Fixed18x9.psf.gz is attached, for
easier reproducing; you can use “setfont cached_Uni1-Fixed18x9.psf.gz”
on a text console you logged in to activate it, or set it as
FONT=/pathto/cached_Uni1-Fixed18x9.psf.gz in /etc/default/console-setup.
I’ve also attached the other font I tested with, which results in
the mostly blank screen.
bye,
//mirabilos, who’s written enough software for fonts himself that
he can handle most common formats
PS: Source for these is in contrib/fonts/fixed/ in MirBSD CVS.
PPS: Mail between me and Googlemail users is extremely likely to fail.
I fully blame Google.
--
<cnuke> den AGP stecker anfeilen, damit er in den slot aufm 440BX board passt…
oder netzteile, an die man auch den monitor angeschlossen hat und die dann für
ein elektrisch aufgeladenes gehäuse gesorgt haben […] für lacher gut auf jeder
LAN party │ <nvb> damals, als der pizzateig noch auf dem monior "gegangen" istAttachment:
cached_Uni1-Fixed18x9.psf.gz
Description: Binary data
Attachment:
mirf16v8.psfu
Description: Binary data