areiner at tph.tuwien.ac.at
Wed Feb 18 10:42:55 PST 2004
Thanks for your reply:
> > - the pseudo terminals use a ridiculously small font (48 lines, 128
> > characters wide),
> I think these are the real (console) terminals. You're using a
> framebuffer in a 1024x768 pixel display, right ? Each framebuffer uses
> different syntax to set it up, but from experience if you don't tell it
> a setting, or one that it recognises, most default to 80x30 or perhaps
It seems I mixed up virtual consoles (TTY) with pseudo terminals (that
is under X, I gather).
Anyway, mentioning framebuffer sent me on a different (right?) track:
The (possibly) relevant parts of dmesg are:
,----[ dmesg ]
| Kernel command line: root=/dev/hdc2 ro vga=791 apm=power-off hda=scsi hdb=scsi hdc=scsi hdd=scsi hde=scsi hdf=scsi hdg=scsi hdh=scsi nomce initrd=initrd.gz BOOT_IMAGE=vmlinuz
| Initializing CPU#0
| Detected 2600.133 MHz processor.
| Console: colour dummy device 80x25
| Calibrating delay loop... 5190.45 BogoMIPS
| Memory: 513080k/522176k available (1262k kernel code, 8708k reserved, 534k data, 132k init, 0k highmem)
| vesafb: framebuffer at 0xe8000000, mapped to 0xe080d000, size 3072k
| vesafb: mode is 1024x768x16, linelength=2048, pages=1
| vesafb: protected mode interface info at c000:e5c0
| vesafb: scrolling: redraw
| vesafb: directcolor: size=0:5:6:5, shift=0:11:5:0
| Console: switching to colour frame buffer device 128x48
| fb0: VESA VGA frame buffer device
| pty: 256 Unix98 ptys configured
| blk: queue c0334dcc, I/O limit 4095Mb (mask 0xffffffff)
| cs: IO port probe 0x0c00-0x0cff: clean.
| cs: IO port probe 0x0820-0x08ff: clean.
| cs: IO port probe 0x0800-0x080f: clean.
| cs: IO port probe 0x0100-0x04ff: excluding 0x1c0-0x1cf 0x378-0x37f 0x480-0x48f 0x4d0-0x4d7
| cs: IO port probe 0x0a00-0x0aff: clean.
| Vesafb does not support changing the video mode
(I don't know what the blk: and cs: lines mean, whether they are
connected to the final vesafb note, and what exactly the significance
of that one is.)
So it seems that initially I have 80x25 (and indeed, the "boot:"
prompt is easy to read); later on, vesafb gets loaded (indeed, with
1024x768 pixels), which calls some BIOS routines and thereby locks me
into the slow 128x48 mode:
,----[ /usr/src/linux-2.4.22/Documentation/fb/vesafb.txt ]
| The idea is simple: Turn on graphics mode at boot time with the help
| of the BIOS, and use this as framebuffer device /dev/fb0, like the m68k
| (and other) ports do.
| This means we decide at boot time whenever we want to run in text or
| graphics mode. Switching mode later on (in protected mode) is
| impossible; BIOS calls work in real mode only. VESA BIOS Extensions
| Version 2.0 are required, because we need a linear frame buffer.
| * It provides a nice large console (128 cols + 48 lines with 1024x768)
| without using tiny, unreadable fonts.
(but they *are* unreadable...)
> > - scrolling is extremely sluggish (to the point that I have turned to
> > switching consoles when some process produces a lot of output),
> Or maybe just build the kernel without framebuffers if you only want
If I do so, will I still be able to use X on those rare occasions when
I need to?
> Framebuffers definitely seem to slow things down a bit, but on most
> hardware they'll still comfortably outpace what you can read.
Well, even the 288 lines of dmesg output take around 6.5 seconds to
scroll by - not that I can read that fast, but I am used to seeing the
end of so short a file immediately. Searching in less is extremely
painful, and I have also noticed that switching to a different console
greatly speeds up compilations etc when the make output goes to the
> What cpu,
> memory, which framebuffer ? The "lowest common denominator" (VESA, I
> think) seems to be particularly slow.
This is an Acer Aspire 1703SM_2.6 notebook:
- CPU: Intel(R) Pentium(R) 4 CPU 2.60GHz
- MemTotal: 513356 kB
- /proc/fb: 0 VESA VGA
So it seems I am running the least common denominator on my host, and
I can live with that for the moment.
However, where in the book do I have to make sure I don't end up with
the same problem on the new LFS? I gather it is the "make menuconfig"
step in Chapter 8, "Installing Linux-...".
So, if Vesa is particularly slow, what about other framebuffers? How
can I find out which one will work with my hardware (there is a
sticker mentioning "nVIDIA GeForce FX Go5600, 64MB" on the notebook)?
I see that Knoppix has a great many of them as modules - can I just
modprobe something and see what happens, or might that have adverse
Also, what about Chapter 6, "Installing LFS-Bootscripts-...": does the
switching to Vesa VGA framebuffer occur before or after the
/etc/init.d/ scripts are run?
Thanks a lot for your help!
More information about the lfs-support