You are not logged in.
Pages: 1
Hey everyone,
Kind of a "support" question that I know is gonna require some dev to properly fix, but..
I'd managed a couple of test installations on VMs and spare machines, but it was finally time to do the big install on aki. The biggest issue is that aki has a HiDPI monitor, and your friendly neighborhood knghtbrd has LoDPI eyes. I'm legally blind. On any other machine I could setfont -d or setfont ter-132b (the former is actually a slightly bolder outcome) and do the install, but this monitor … if that's as big as the font gets, it's not big enough to see mistakes.
I mean, I can kinda do gdisk /dev/nvme0n1, o, yes, n, 1, 2048, +4G, ef00, n, 2, \n, \n, 8309, w; mkfat -F32 -L -n boot /dev/nvme0n1p1; cryptsetup luksFormat /dev/nvme0n1p2, 12345; cryptsetup open /dev/nvme0n1p2 luks_lvm, 12345; pvcreate /dev/mapper/luks_lvm; vgcreate vg0 /dev/mapper/luks_lvm; lvcreate -L $((MEM + 2)) -n swap vg0; lvcreate -L 30G -n root vg0; lvcreate -l +100%FREE -n home vg0; mkfs.ext4 … just about blindfolded.
(well with separate EFI and /boot because Debianish distributions put symlinks in /boot … but still!)
Thing is though, as screens are getting stupidly high resolutions at smaller and smaller sizes, this is gonna start to be an issue for all y'all sooner or later. It's an issue for me now. I'd like to fix it if I can. I realize some work needs to be done to make it happen still. Is anyone working on it? How can I help? Does anyone have a brilliant suggestion in the meantime? Ideally one that will make initcpio's recovery console useful, if not also make it so I'm not typing root LUKS unlock passphrases blind? I've considered kmscon but … it has a lot of moving parts and I've seen it break before given that it's a VTE-based monster.
It might be just as easy as compiling a larger font into the kernel. Ideally though I'd love to see the install iso come with a solution, so that seems to require some userspace stuff. I'm happy to help wherever I'm needed to make that happen if someone's already working on it. If nobody is yet … well, I've been using Arch on my main machine for all of about 15 minutes (SLIGHT exaggeration) but I'll attempt to be a quick study if I've just volunteered myself. I'm just … not sure where to start just yet.
Suggestions welcome—feels like there might be multiple solutions depending on how permanent or applicable to others I want the solution to be. And as I actually give a crap about Linux accessibility, first my own and then everybody else's, I might want more than one of them. (I'm not convinced this was the best place to post this even, but I couldn't really come up with a better idea since I'm approaching the problem both as the Arch n00b and as the guy who's been using Linux and occasionally writing something that might pass for "code" over the past 28 years…)
Last edited by knghtbrd (2024-08-23 23:02:58)
Them: You will own nothing and be happy.
Me: How about … no.
Offline
The easiest fix is (if possible) to simply drive the output at a lower resolution.
Next to the grub-specific link I posted in response to your grrr, there's https://www.kernel.org/doc/Documentation/fb/modedb.rst
And you should™ be able to drive the output at least at VGA (though I have seen isolated panels scrapping that)
Have you tried "setfont -d ter-132b" ?
Other than that one would have to create bigger fonts.
Offline
Changing the resolution does work on my desktop, but it does not work on my laptop for some reason (at least as far as grub is concerned), so changing resolutions isn't likely a generalized solution prior to initcpio taking over due to idiotic hardware. (the intel/nv drivers are quite capable of changing resolutions once they take over.) What DOES work is the 80x25 text mode. I think systemd-boot on the live CD is set to prefer that, so that along with a menu option to pass a parameter to the initcpio to go low-res might do it. That's achievable I think.
The issue with trying to pass the instruction to use a lower resolution directly to the kernel is that it's display-dependent unless I missed something in that link (I've seen it before). I'm currently using DP-2, I actually didn't know that until I checked xrandr real quick. I was using DP-1 before I did some maintenance on aki the other day and I must have plugged the monitor into the other DP port. But that illustrates the problem. Either you'd have to know or the boot option would have to specify a dozen possibilities and how your display matches one of them. Not a fun solution. But I bet an initcpio hook could figure out which display or display or displays are active and set the resolution from there. Probably, I don't actually know how to change the framebuffer resolution on a booted system from a script anymore. That's an RTFM Joseph problem, though.
Once upon a time I had a Lenovo Nettop thing that Linux saw as having VGA and a ghost LVDS it thought was 1024x768. Until I figured out what the hell it was doing and told the kernel to disable the nonexistent netbook LCD panel, Linux would only use the top left 1024x768 rectangle of any resolution monitor. So specifying resolutions on phantom displays might do weird things on some machines if the resolutions don't all stay matching, but … should be fine for the text-based installer at least.
As for setfont -d with the large terminus 16x32 (or 32x16 as I've learned these things are recorded, booted from 6.10.6-arch1-1, I get:
[root@aki ~]# setfont -d ter-132b
setfont: ERROR kdfontop.c:211 put_font_kdfontop: ioctl(KDFONTOP): Invalid argument
free(): invalid next size (normal)
Aborted (core dumped)
Huh. A search suggests that KDFONTOP ioctl error is typically associated with trying to load a non-8xsomething font when you don't have a framebuffer. That's definitely not the case here, so I might have to run the command under a debugger to try and figure out what it's doing. Looking at /proc/config.gz suggests the kernel is set up for other fonts.
I then set out to try and make one out of Bitstream Vera Mono Bold. That didn't end well, I have no idea what I'm doing. I need to spend some time trying to understand some things here. But in the meantime I grabbed Debian's latest console-setup-linux 1.230 .deb file and extracted usr/share/consolefonts/Lat*-DejaVu*.gz. I am pleased to note that Lat15-DejaVuBold51x28.psf.gz was quite easy to setfont on tty2. I can have a nice 131 × … whatever … by sticking that into the appropriate directory and setting it as my console font. Neat!
I can actually pick apart the Debian source package to get the canned commands they used to generate those psf files. I still want to better understand this process but just duplicating it is enough for now. From there I guess read up on building packages for Arch. But at that point it's less about installation support and more about package development, so I'm migrating away from the installation support side of things now.
I think some combination of a low res boot menu option for the installer and having some super ridiculous large fonts available in the installer environment collectively solve the problem at either end. The only other thing that could be wanted is a kernel patch upstream that adds a larger font to the kernel directly.
Thanks for the response—it got me thinking about attacking the problem from both ends, which will provide a more robust set of options, and there's time to learn, do it, and submit the changes where they need to go before this is a problem for normal users to deal with. Much appreciated!
Them: You will own nothing and be happy.
Me: How about … no.
Offline
use a lower resolution directly to the kernel is that it's display-dependent
Not parameter-wise, you can just try "video=1024x768" (xga stands a usable chance of being supported by most panels), though
Linux would only use the top left 1024x768 rectangle of any resolution monitor
ymmv
A search suggests that KDFONTOP ioctl error is typically associated with trying to load a non-8xsomething font when you don't have a framebuffer.
https://man.archlinux.org/man/core/kbd/setfont.8.en#d
Due to kernel limitations, this is suitable only for 16x16 or smaller fonts.
"yay"
Offline
Pages: 1