home bbs files messages ]

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.   
   --    
    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 │  damals, als der pizzateig noch auf dem monior "gegangen"   
   ist   
   [SoupGate killed MIME-encoded file 00000000.ATT (5061 bytes)]   
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca