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. Reproducible: Always 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 3. reboot Actual Results: framebuffer at a single resolution. framebuffer text information uses improper column count. Expected Results: framebuffer at multiple resolutions. framebuffer text uses proper column spacing. # emerge --info Portage 2.0.51.22-r3 (default-linux/x86/2005.1, gcc-3.4.4, glibc-2.3.5-r1, 2.6.13-gentoo-r3 i686) ================================================================= 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-apps/sandbox: 1.2.12 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 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.5.20 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium4 -mtune=pentium4 -pipe -O3 -fweb -frename-registers -fforce-addr -momit-leaf-frame-pointer -fomit-frame-pointer -ftracer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" 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 -fvisibility-inlines-hidden" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distcc distlocks sandbox sfperms" GENTOO_MIRRORS="http://grumpy.346net http://gentoo.osuosl.org http://www.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j7" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://grumpy.346net/gentoo-portage" 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] lspci
Created attachment 70634 [details] dmesg
Created attachment 70635 [details] kernel config
Created attachment 70636 [details] kernel config
Created attachment 70637 [details] dmesg
Created attachment 70638 [details] lspci
the effected version of splashutils is: [ebuild R ] media-gfx/splashutils-1.1.9.8
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 userspace.
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 640x400-8 640x480-8 800x600-8 320x200-16 320x200-32 640x480-16 640x480-32 800x600-16 800x600-32 320x200-8 320x400-8 320x400-16 320x400-32 320x240-8 320x240-16 320x240-32 640x400-16 640x400-32 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.
