[lfs-support] Framebuffers

Ken Moffat zarniwhoop at ntlworld.com
Thu Mar 5 17:16:02 PST 2015


On Thu, Mar 05, 2015 at 03:53:23PM -0800, Paul Rogers wrote:
> If you want to cut to the chase: list the substantial benefits to using
> a framebuffer.
> 
> 1) some strange video card that still doesn't provide Linux drivers (or
> had them reverse engineered ;-)
> 
> 2) DRM for high performance graphics, i.e. games (on Linux?!)
> 
> 3) what else?
> 
For me, high performance graphics means something running under X -
in my case playing a video might use acceleration, but my main user
is probably xscreensaver.  But X is using a framebuffer anyway, I
guess.

Actually, the benefits of a framebuffer per-se are small (more
choice of display sizes), and with the downside that scrolling (e.g.
in tar -xvf) may be slower.  What really brings the benefit is KMS
(kernel modesetting) - in theory, an oops message will appear even
if you were in X (in practice I've only had that once, although I've
had many kernel crashes).

> > > 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?

Didn't actually reply to that part, sorry.  'fbcon' was some
userspace application, I think ?  I have vague memories of using it
for some reason or other in the distant past, perhaps on the awful
AmigaOne [ excuse me while I spit and then curse ].

And no, with modern udev the kernel loads the framebuffer
automatically, even if it is a module.  Probably also happens with
LFS-7.2, but I'm not certain.
> >
> >  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.
> 
> Sorry, I get the "daily digest" at noon, so many postings are all in one
> message, and that's the way I reply when it's all on one topic.
> 

 OK, I'll try to remember that.
> >  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.
> 
> Indeed it was.
> 
> So, AIUI that "video=" gets passed thru to the kernel, and presumably
> fbcon picks it up?  That seems to explain why it would work in LILO.  I
> guess that also means it's fbcon that also responds to the font.
> 

The bootscripts set the font - you do not use Bruce's version, but
you can still look at the LFS console script (some of it goes back
years, to when Alexander was here).
 
> And the size of the framebuffer defaults to whatever is laid out by the
> chipset/board design, as reduced by the kernel?  I expect it is out of
> system RAM these days, especially with onboard integrated graphics, so
> it may benefit one to specify the smallest size one needs?  I'm
> guessing that a larger framebuffer & font meaning letters have less
> noticable jaggies for console work, at the expense of less usable RAM--
> presuming one doesn't need to see pretty pictures.  (I'll let the other
> OS do that. ;-)
> 

I think the *monitor* controls the default size.  But even my oldest
monitor is LCD and presumably provides details of what it supports
(EDID, I think).  On a really old monitor, no doubt the kernel will
fall back to something it thinks is safe.
> > > >  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".
> 
> No, no offense taken.  The way I build my base is: build-in what is
> necessary to boot from any box I expect to be having.  Lots of
> chipset/HDD drivers, no sound, no SMP, no frills.  Then the Sysadmin,
> me, so far, is expected to pretty quickly rebuild the kernel for the
> box's HW after migration/installation.
> 

Ah, building for new hardware is always fun - had some of my own
this week, but the biggest problem was working out how the case
on/off switch worked! - really, there is a long 'panel' which looks
like it might be a switch, but it is hinged at one end and only
works if you press it near the other end.  And then the firmware
(this is a radeon), and trying to find out what hardware monitoring
is supported (effectively, none in this case).
> It's just that I've never found it necessary to mess with console fonts
> before.  Better things to do with my time--even now I'm only up to 7.2!
> It seems to be mostly necessary with xterm/rxvt.
> 
> > > 1280!  1600?
> >
> >  Run xrandr to see what is available to X, and what you are using. For
> >  the console, look in dmesg.
> 
> Whatever it is, I don't think I like it.  If there's good enough reason
> for me to go with the framebuffer, and so far it may be that getting the
> Nouveau driver instead of nv is the only thing, I'll be wanting to set
> it to something I do like--no more than 800x600, maybe old 640x480.
> 

For X, xrandr will tell you the name(s) of the outputs it can see -
usually only one of them in my experience, and the available sizes
(modes).  But for the desktop, with a framebuffer, either pass a
smaller size in the kernel bootargs (the video= and vga= stuff),
and/or specify a bigger font.
> > 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
> 
> There MIGHT be a box or two here that DOESN'T have multiple systems on
> it.  ;-)  I even made a Linux I can boot off one floppy!
> 

I thought that the kernel stopped fitting on a floppy in the 2.4
days, or else very early 2.6.  But I have not seen a reliably
working floppy drive for more than 10 years.
> > 3. play with it, and see if the gfx stuff is beneficial for you.
> 
> I still haven't heard of any substantial benefits for a framebuffer.
> Have I mentioned I'm pretty "old school"?  ;-)
> 
> > 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 infrequently as I can.  ;-)  I am thinking of putting CentOS-6.6 on
> this i7 and making it usable as a virtual machine sandbox.  (I ran a
> VM/SP4 system back in '86--about time!)  Even if I do, it won't be the
> only botable system on the box.
> 

Well, we have qemu in BLFS.  I _might_ end up running some distros
on test machines, but for the moment I only use them in VMs.
> >  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.
> 
> I wonder why it didn't seem to have any effect for me.
> 
No idea, but I would tend to blame grub ;-)
> >  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.
> 
> "De gustibus non disputandum", I guess.  I don't doubt some do, I just
> never thought it worth the effort.
> 
> > 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.
> 
> No, it's not.  But I've only ever switched from X to a standard console,
> usually when Firefox hangs.  Now, presumably both will talk to the
> framebuffer instead.  I read that process is easier.  Said to produce
> less "flashing screens".  That's an issue?  Still looking for
> substantial advantages to framebuffers....
> 
> > Well when the framebuffer is a module, you pass mode options when
> > loading the module. mode_option exists for uvesafb but I don't know
> > about other framebuffer modules. If I want a framebuffer, I build it
> > into the kernel.
> 
> OK, so you get it from the get-go, not when udev creates /dev/fb0?  But
> is there a real advantage to that?
> 
No, the framebuffer appears a little way into the boot, and the
screen is redrawn.  But that is a _long_ way ahead of the
bootscripts, and therefore udev.
[...]
> 
> > last year.  I find Syslinux much easier to build, configure and use.
> > It's small, light, and fast.  Surely, all we require of a bootloader
> > is to boot the system.  Again, as you say: "simpler is better".
> 
> I used it to boot my floppy Linux.  I suppose I'll investigate.  Does it
> handle UEFI?
> 

Why would you want to handle UEFI ?  Yes, I know that eventually we
will all be forced to, and my next machine will probably be UEFI,
but the motherboard I bought this week can do both bios and UEFI,
and is configurable.  I started with a SystemRescueCD from last year
to run memtest86+, later changed something in the bios and found
that the options for "floppy images" (including memtest86+) had
disappeared - changed it back, go the option to boot from bios CD as
well as UEFI CD and all was well.

More generally, people using UEFI with "other operating systems"
also on the disk have all sorts of problems (look in the archives
for the last year re EFI) - mostly in finding an approach which
works on their hardware.  Meanwhile, EFI in the kernel still seems
to have a lot of churn.

> > grub can be complicated, but we actually make it fairly easy.  The
> > build is CMMI with a few extra configure switches.  The configuration
> > file is about 10 lines long.  It's the commercial distros that make it
> > complicated.
> 
> It can't be called "simple" with that much junk in /boot/grub!  Legacy
> grub?  Sure.
> 

But legacy grub could not be compiled on 64-bit (it had i386
assembler instructions).  That was why I used to use lilo (and grub2
is actually better - I finally gave up lilo on my server when the
drives moved from /dev/hdX to /dev/sdX and lilo would not let me add
a new entry referencing the non-existent sdX drives for the new
kernel).
> CMMI?  Configure, make, make install, I guess (finally!)?

yes

ĸ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.


More information about the lfs-support mailing list