zarniwhoop at ntlworld.com
Wed Mar 4 17:34:06 PST 2015
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
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
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,
> > 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.
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.
More information about the lfs-support