vesafb and splashutils don't seem to work properly with the 2.6.13-gentoo-r3
kernel on an nVidia NV18. the framebuffer will only initialize at a single
resolution. at this resolution, the framebuffer is garbled -- the colum count
does not take into account the 4 characters that need to be subtracted for
proper display using the "emergence" theme. as a result, 4 characters are
wrapped to the next line. a detailed explanation is available at the
above-captioned URL on the gentoo forums.
Steps to Reproduce:
1.emerge, configure, compile gentoo-sources 2.6.13-r3 with vesafb and nVidia NV18
2. rebuild splashutils and the splash images
framebuffer at a single resolution. framebuffer text information uses improper
framebuffer at multiple resolutions. framebuffer text uses proper column spacing.
# emerge --info
Portage 18.104.22.168-r3 (default-linux/x86/2005.1, gcc-3.4.4, glibc-2.3.5-r1,
System uname: 2.6.13-gentoo-r3 i686 Intel(R) Pentium(R) 4 CPU 2.40GHz
Gentoo Base System version 1.6.13; Jackass! Toolkit 2005.1
distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled]
ccache version 2.3 [disabled]
dev-lang/python: 2.3.5, 2.4.1-r1
sys-devel/autoconf: 2.13, 2.59-r6
sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1
CFLAGS="-march=pentium4 -mtune=pentium4 -pipe -O3 -fweb -frename-registers
-fforce-addr -momit-leaf-frame-pointer -fomit-frame-pointer -ftracer"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config
CONFIG_PROTECT_MASK="/etc/gconf /etc/splash /etc/terminfo /etc/env.d"
CXXFLAGS="-march=pentium4 -mtune=pentium4 -pipe -O3 -fweb -frename-registers
-fforce-addr -momit-leaf-frame-pointer -fomit-frame-pointer -ftracer
FEATURES="autoconfig distcc distlocks sandbox sfperms"
USE="x86 X alsa apm arts avi berkdb bitmap-fonts crypt cups eds emboss encode
foomaticdb fortran gdbm gif gpm gstreamer gtk2 imlib ipv6 jpeg kde libg++ libwww
mad mikmod motif mp3 mpeg ncurses nls nptl ogg oggvorbis opengl oss pam pdflib
perl png python qt quicktime readline sdl spell ssl tcpd truetype truetype-fonts
type1-fonts vorbis xml2 xmms xv zlib userland_GNU kernel_linux elibc_glibc"
Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS
configuration information will be posted as attachments.
*** Bug 109242 has been marked as a duplicate of this bug. ***
Created attachment 70633 [details]
Created attachment 70634 [details]
Created attachment 70635 [details]
Created attachment 70636 [details]
Created attachment 70637 [details]
Created attachment 70638 [details]
the effected version of splashutils is:
[ebuild R ] media-gfx/splashutils-22.214.171.124
The framebuffer will work only with these resolutions that are supported by your
video BIOS (/proc/fb0/modes).
The wrapping effect you're experiencing is neither a bug nor a configuration
error -- it is simply what happens when you're resizing a tty. If you want to
avoid that, use an initramfs image to initialize the verbose splash from early
thank you for your help. i had been attempting to initialize the verbose splash
from the early userspace, as you have recommended. it turns out that the
initialization in early userspace was failing at 1024x768 and higher
resolutions, and the result was initialization 800x600 in late userspace. the
late userspace resizing did indeed cause the observed error that you had
mentioned was not a bug.
thanks also for pointing out the reference to /proc/fb0/modes.
now that the resizing problem has been solved, i would now like to reopen this
bug as a kernel problem related to kernel FB support.
quite surprisingly, my nVidia card is showing the following available modes:
# cat /proc/fb0/modes
there has got to be a problem here. why is the kernel showing that so few FB
modes are available, all at LOW RESOLUTION and LOW COLOR DEPTH?
interestingly, i am having the same problem with the kernel reporting
inappropriately low resolutions in the matrox fb bug thread, but number 109240.
for some reason, the 2.6.13 kernels are reporting a lack of support for FB at
higher video resolutions and color depths. i had always been able to do 24 and
32 bit color with 2.6.11, and this disappeared with one of the 2.6.12 kernels
and remains with 2.6.13-r3. now i have to drop to 800x600-16. there's got to
be a problem here.
maybe this bug needs to be reassigned?
I don't know why only such modes are reported. vesafb-tng gets the list of
supported modes from the Video BIOS and I have no way to tell how the Video BIOS
determines it. You might want to try emerging the 'lrmi' package and running
'vbetest' before and after starting X to see whether the list of supported modes
is the same as reported by vesafb-tng.
As explained in the previous comment, it's a VBIOS problem, not a vesafb-tng one.