On Wed, Mar 04, 2015 at 04:00:32PM -0800, Paul Rogers wrote: > > > > Look for information on video=, for example video=1024x768. The > > useful value(s) will depend on your monitor. > > Do I gather correctly these are arguments for fbcon and, since I've > built all the framebuffer stuff as modules, I put it in a > modprobe.d file?
This part looks like a reply to my reply - but I cannot tell that from your quoting style. But I will now reply to some things which were not a reply to my earlier post. > > > other systems on that box, I omit the video= specification and > > sometimes use a 12x22 console font. Unfortunately, there are no > > That would be where? And why? What's the advantage to either? > The video= goes in the bootargs (grub-2.00 for LFS-7.2, but I have used it on lilo), the console font is specified in /etc/sysconfig/console, the 12x22 font is within the kernel config - CONFIG_FONT_SUN12x22 : the number of pixels in the framebuffer is fixed by the time the kernel boots (for my main desktops, 1600x1200, 800x600, or 1024x768 in the past), so a bigger font uses more screen real-estate. Which was why you started this conversation, I thought. Earlier today, on my box where I pretend the screen is 800x600, I took a fresh look at the Terminus font - the -v variants are not all to my taste (square dot for "I don't have this glyph", sometimes accented capital A variants are visibly shorter than unaccented, various other issues, various languages I would like to read are omitted in favour of maths symbols), but it looks generally useful. But on that machine, which is set to use 8x16, 'showconsolefont' no longer fits onto the lines for any of the big sizes. > > If you want to use 12x22, you need to select it in the kernel, I > > think (Sun 12x22 font), otherwise trying to load a 12x22 font in kbd > > may fail. > > I don't recall venturing there. > It's only the kernel, we (LFS/BLFS) expect you to be willing to configure it. That was not intended to be rude, although it probably sounds like that. When you try a new option (framebuffer) you may have to alter/add other options so that "everything is for the best, in the best of all possible worlds". > > because a framebuffer on his screen gave him a _lot_ more than the > > 80x25 that he really wanted. Me, I'm happy to see the penguins and a > > few more character cells ;-) > > It was cute the first time I saw it on Knoppix 1 or 2. In X, I > generally run 800x600, and rxvt geometry of 80x39. But I'm not sure at > the moment what I'm getting on this Samsung 19" monitor, maybe more than > 1280! 1600? Run xrandr to see what is available to X, and what you are using. For the console, look in dmesg. > > > For 7.2, vga= is probably fine (although I think that the version of > > grub even that long ago claimed that vga= was deprecated). I > > Grub-2.00 seems to ignore it. It didn't seem to work when I tested it. > I don't want to add GFXPAYLOAD until I understand how everything is > supposed to work together. BTW, neither LFS-7.2 nor 7.6 speak to using > /etc/default/grub. > 1. save your current grub.cfg, e.g. as .bak 2. make sure you can fix things from a rescue CD : I use SystemRescueCD, although recent versions no longer bring up my network, which was why I originally used it (my backups are on nfs) but use whatever works for you 3. play with it, and see if the gfx stuff is beneficial for you. 4. And use your rescue method if needed - in the past few weeks I have screwed up grub.cfg twice (once adding submenu entries - I ended up with an unbalanced '}' at the end, grub could not boot, second time I deleted a chunk of entries to reuse a partition previously used for an old system - and made a similar mistake). For /etc/default/grub : no, we make grub.cfg writable, keep backups, and edit it. Have you seen the crap options which distros can end up with (typically, two versions of _every_ kernel for every available system) ? > > > As a point of information I could never get video= to work but vga=792 > > works for me. I should point out that I use Syslinux rather than > > Grub2, which is far too bloated for me. > > Yes, I'm beginning to come to that conclusion. One of the reasons I > moved to Linux--simpler is better. Grub has the systemd disease. ;-) > That one was not mine, but I still use vga= on my server (LFS-7.6 with 3.14 kernel) without any obvious problem. Certainly, the 1600x900 monitor which I recently attached to it gives a 1024x768 output which is quite readable. > > Hello Paul, > > Hi... > > > > > Archlinux wiki is usually a good place. For Grub2, the preferred way > > to set the resolution is using the gfx payload. vga= isn't supported. > > So I see, but I want to understand all the moving parts before I > change something and call it good. I may be fixing the symptom, not > the disease. > > > For the kernel messages, I get a small font, but change that in the > > boot scripts: > > > > In either /etc/sysconfig/rc.site (my preference) or > > As I just wrote, IMO "simpler is better", or as Einstein said, "As > simple as possible, but no simpler", and the (B)LFS bootscripts seemed > to me more complicated than they need be. I rewrote most of all of 'em. > It gets the operational stuff done, but the structure and coding are to > my mind and experience, simpler. I think you will find that *any* font change is comparatively simple - you may lose all the boot messages before that, or some of them, when the screen redraws - but even people only using the native tty (no framebuffer) have changed fonts - even to different sizes - for many years. > > > /etc/sysconfig/console I set FONT=ter-128n. That is a terminus font > > from http://terminus-font.sourceforge.net/. They have a lot of sizes > > available. > > Ok, that's another option. So how do all these compare if I'm > occasionally bouncing out of VT7 to another VT and back again? What > makes all the screen changes simpler and more glitch resistant? Ah, VT7 ;-) In 1.17.1 (and perhaps in 1.16.4) Xorg will bind to the tty from which it was invoked. You use a console font of XxY (the default is mostly 8x16) and get a readable screen. You then run 'startx' and X spews some messages before eventually going blank and then drawing a desktop (if all is well) with NxM pixels (which need not match the console screen pixels). You then decide to either switch to a different tty, or to close Xorg, and the screen redraws. If closing X already works, the only likely wrinkle (until you upgrade something) is that X will not start if /tmp is full. Oh, and for me (today), X will take *for ever* to start if the connection to upstream has gone down. None of this is new, even if it is new to you, and the processes are in common use. ĸen -- Nanny Ogg usually went to bed early. After all, she was an old lady. Sometimes she went to bed as early as 6 a.m. -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
