Forums before death by AOL, social media and spammers... "We can't have nice things"
|    linux.debian.kernel    |    Debian kernel discussions    |    2,884 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 2,068 of 2,884    |
|    Thorsten Glaser to Helge    |
|    Bug#1123750: linux: regression: virtual     |
|    26 Dec 25 23:10:01    |
      XPost: linux.debian.bugs.dist, linux.debian.maint.boot       From: tg@debian.org               This message is in MIME format. The first part should be readable text,        while the remaining parts are likely unreadable without MIME-aware tools.              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/gi       /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.       --         |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca