[lfs-support] Framebuffers

Paul Rogers paulgrogers at fastmail.fm
Thu Mar 5 15:53:23 PST 2015

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?

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

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.

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

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. ;-)

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

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.

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

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

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

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

> You can read more here about forcing kernel modes
> http://nouveau.freedesktop.org/wiki/KernelModeSetting/

Got there twice yesterday.

> Our approach is to edit it manually.  Right now I use a grub.cfg that
> has 34 lines.  Compare that to my wife's system using Mint.  grub.cfg
> there is 220 lines -- and that is for only one real OS.  All that is
> junk for a screen that is only up for 5 seconds, if at all.

Me too.

> No, I don't think you're missing anything.  I don't use X much as most
> of my boxes are servers.  I have, however, always been fascinated by
> just how much can be achieved (in graphical terms) by using the
> framebuffer and ditching X.  As you say: "simpler is better".

Well, initially, LFS-4.1, I built KDE, but since have basically been
using a bare window manager.  Last time. 6.6, I tried an older version
of LXDE, but still rarely use it.  Something without all the old cruft
of X, Wayland, might be interesting.  But I doubt just a framebuffer
would do everything I need.  Firefox?

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

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

CMMI?  Configure, make, make install, I guess (finally!)?
Paul Rogers
paulgrogers at fastmail.fm
Rogers' Second Law: "Everything you do communicates."
(I do not personally endorse any additions after this line. TANSTAAFL :-)


http://www.fastmail.com - Does exactly what it says on the tin

More information about the lfs-support mailing list