UVesaFB - The Successor to VesaFB-TNG (Bootsplash)

[soroh6]

I did a search for uvesafb and there were no results, so I thought I wanted to let everyone know what it is.

spock has stopped development on vesafb-tng that a lot of you use for bootsplash, and now works on uvesafb, which is located at:
http://dev.gentoo.org/~spock/projects/uvesafb/

Long story short (sorry, I have to leave suddenly), the instructions for installation worked perfectly and my amd64 is happily running gensplash/splash-utils now. I extracted the v86d to /usr/src/v86d-0.1 and set the Initramfs source to /usr/src/v86d-0.1/misc/initramfs as instructed, and everything worked fine on the first reboot. You da' man, Spock.

If anyone else wants to continue this thread about uvesafb please do so, support or how-to questions etc, or just general talk about uvesafb.

PATCHES:

• Update 6/24/2009: I didn't realize this thread was so popular; sorry for the long-expired links. If anyone wants something in the first post here, just PM me.

INSTALL:

Code: Select all

mv uvesafb-patch.diff.bz2 /usr/src/linux
bunzip2 uvesafb-version.diff.bz2
patch -p1 < uvesafb-version.diff

..and view http://dev.gentoo.org/~spock/projects/uvesafb/ for the rest of the instructions.

EXTRAS:

• Vampire Theme by star.dancer

Regards,

[Abraxas]

Awesome. I was waiting for this. Now I just have to get my framebuffer to actually use the right resolution.

[i92guboj]

Finally an alternative to vesafb for non-x86 users.

Let's see if it does any better. For now, it fails to patch cleanly against
2.6.21-gentoo-r3, though that is not strange. The reject is on a Makefile,
easy enough to fix, though.

After that, compilation fails due to a duplicated symbol, that you need to
fix in drivers/video/modedb.c. Just edit the file and comment line 943, so
it looks like this:

Code: Select all

//EXPORT_SYMBOL_GPL(fb_destroy_modelist);

Now it should compile ok. (It did here), so I am going to read the docs,
change grub.conf or whatever needs to be changed and reboot. Cross your
fingers

EDIT,

It seems to work ok, in case someone cares. I am using 1600x1200, something
I never could use with vesafb, which was the only option until now on amd64.
It is much faster when scrolling on the console, though being this a vesa
driver, I can't explain why... Maybe it is just that my graphics card like
this mode more than it likes 1200x1024. I don't really know.

I could make a patch to automate all the above, but I don't think it is
necesary, since only a few persons will be using this stuff, and possibly,
most of them will have any other kernel sources anyway. The fixes are simple
enough, I think.

So, for me, everything is working beautifully. Thanks for this lovely
stuff. I've been loging for this.

[soroh6]

Yup, everything worked great for me too. Perhaps I can create some .diff's for the various gentoo-sources kernels when I get home from work.

Finally an alternative to vesafb for non-x86 users.

Let's see if it does any better. For now, it fails to patch cleanly against
2.6.21-gentoo-r3, though that is not strange. The reject is on a Makefile,
easy enough to fix, though.

After that, compilation fails due to a duplicated symbol, that you need to
fix in drivers/video/modedb.c. Just edit the file and comment line 943, so
it looks like this:

Code: Select all

//EXPORT_SYMBOL_GPL(fb_destroy_modelist);

I think I had to fix up some rej files as well, but barely anything, for me at least. Yes, I also had to comment/remove the EXPORT_SYMBOL_GPL line.

I'm really amazed nobody knew about this!

[IvanMajhen]

Does this driver detects 1280x800 resolution on intel cards?
I'm curently running staticaly compiled 915resolution before modprobing vesafb-tng in initramfs.

[zxy]

I can't wait until i come home and try this on amd64, eventhough i reboot very very rarely .

[swimmer]

Does this patch only work with the vanilla kernel or with the gentoo-sources as well?

Greetz
swimmer

[soroh6]

I patched my gentoo sources with it, although you will get a rej file or two.

I think tomorrow or the next day I will emerge -f some of the gentoo-sources and create patches for people to download and cleanly patch their gentoo-sources or etc.

[enderandrew]

Wouldn't this likely pop up in the next Gentoo sources?

[soroh6]

I would hope so! Would be a pain to do it again next release

[jonnevers]

I would hope so! Would be a pain to do it again next release

uvesafb, as gotten from spock's website applies cleanly, to vanilla-sources-2.6.22 (obviously).

I haven't tried applying it to other sources yet.

boots and worked perfectly fine here!

[bubbl07]

Been waiting for this for a while. Just forgot about it in the mess of things, but I'm glad soroh6 brought it up.

Would anyone mind posting the kernel line from his/her grub.conf so I can see the arguments that need to be appended?

[sonicbhoc]

Does this driver detects 1280x800 resolution on intel cards?
I'm curently running staticaly compiled 915resolution before modprobing vesafb-tng in initramfs.

Yes, I'd like to know too. Is it possible?

And how do you configure initramfs to load 915resolution first?

[jonnevers]

Would anyone mind posting the kernel line from his/her grub.conf so I can see the arguments that need to be appended?

sure can:

Code: Select all

title vanilla-sources 2.6.22-vanilla
root (hd0,0)
kernel /boot/bzImage-2.6.22-vanilla root=/dev/sda3 video=uvesafb:1280x1024-32,mtrr:3,ywrap
initrd /boot/initrd-1280x1024

i'm not sure the initrd part is needed, but the video=uvesafb:1280x1024-32,mtrr:3,ywrap is what is important

you might also want to check out: /usr/src/linux/Documentation/fb/uvesafb.txt for it's official documentation. It explains every part of the kernel line in detail!

one thing that has me stumped is that I specify to use 'ywrap' on the kernel line but dmesg sez it's using redraw:

Code: Select all

host username # dmesg | grep -i uvesafb
Command line: root=/dev/sda3 video=uvesafb:1280x1024-32,mtrr:3,ywrap
Kernel command line: root=/dev/sda3 video=uvesafb:1280x1024-32,mtrr:3,ywrap
uvesafb: NVIDIA Corporation, G71 Board - c835f   , Chip Rev   , OEM: NVIDIA, VBE v3.0
uvesafb: VBIOS/hardware doesn't support DDC transfers
uvesafb: no monitor limits have been set
uvesafb: scrolling: redraw
uvesafb: framebuffer at 0xe0000000, mapped to 0xffffc20000080000, using 24576k, total 262144k

[RoundsToZero]

Nice, I'll be able to use it on x86_64 now! Hope it gets into gentoo-sources soon. I see that it's rc though so maybe it should brew for a while before going in.

[bubbl07]

Code: Select all

title vanilla-sources 2.6.22-vanilla
root (hd0,0)
kernel /boot/bzImage-2.6.22-vanilla root=/dev/sda3 video=uvesafb:1280x1024-32,mtrr:3,ywrap
initrd /boot/initrd-1280x1024

i'm not sure the initrd part is needed, but the video=uvesafb:1280x1024-32,mtrr:3,ywrap is what is important

you might also want to check out: /usr/src/linux/Documentation/fb/uvesafb.txt for it's official documentation. It explains every part of the kernel line in detail!

Thanks jonnevers. I'm very interested because I've never been able to get a framebuffer with resolution higher than 1024x768 since I went from x86 to amd64. I just read the uvesafb.txt (top portion of the patch), but it just looks like the documentation for vesafb. Has anyone tried this at a resolution of 1680x1050?

[jonnevers]

Thanks jonnevers. I'm very interested because I've never been able to get a framebuffer with resolution higher than 1024x768 since I went from x86 to amd64. I just read the uvesafb.txt (top portion of the patch), but it just looks like the documentation for vesafb. Has anyone tried this at a resolution of 1680x1050?

I don't have 1600x1050 listed as a vbe_mode:

Code: Select all

cat /sys/bus/platform/drivers/uvesafb/uvesafb.0/vbe_modes

[96140]

--

[soroh6]

uvesafb, as gotten from spock's website applies cleanly, to vanilla-sources-2.6.22 (obviously).

I haven't tried applying it to other sources yet.

boots and worked perfectly fine here!

It doesn't work with gentoo-sources yet, despite all my tinkering. I first started playing with uvesafb not long ago. I contacted spock about trying it with gentoo-sources, which requires grabbing the vesafb-tng patch from genpatches-extra (4205_vesafb-tng-1.0-rc2.patch). Patch -R should have pulled all that code from gentoo-sources, leaving a clean slate for the uvesafb patch, but unfortunately uvesafb will bail out during the compile, even if the reverse patching and repatching goes smoothly.

I've given up trying to make it work for now. I'll stick with the good ol' ugly 1024x768 on my 1440x900 monitor, sigh.

I use gentoo-sources ... and I also patched it into hardened-sources but then ended up using vesafb-tng instead for that older computer.

But uvesafb works great in my gentoo-sources and amd x86_64 .. I will go patch it into a clean gentoo-sources and make a .diff and post back here when I'm done.

Update: I've edited the first post with a patch for gentoo-sources-2.6.20-r8

[star.dancer]

It is not working for me. dmesg doesn't say anything at all about uvesafb, just that I called it on the kernel line. No failure messages, nothing, I just get no framebuffer at all.

I have a radeon 9550 on my AMD64 system. I patched gentoo-sources (2.6.22), fixed the rejects, everything else was per the instructions. I tried a genkernel build and also manually building and installing. I tried as many grub kernel lines as I could think of, everytime was nothing!

I will just wait until it gets more stable, looks like it is back to the good old rrc patch from 2.4!

Some notes:
- This builds an initramfs into the kernel using the initramfs file that comes with v86d as a source (as far as I can reckon), so the initramfs line should not be necessary in grub. I tried both ways, but it doesn't even get to that line.
- Did anyone else get a message asking to set the uid and guid of the initramfs source file when compiling the kernel? Which adds extra config options? I used the defaults (0 and 0 = root and root). I am not sure if that is why it doesn't work for me...

[soroh6]

I patched gentoo-sources (2.6.22), fixed the rejects, everything else was per the instructions. I tried a genkernel build and also manually building and installing. I tried as many grub kernel lines as I could think of, everytime was nothing!

Well, the latest gentoo stable for me is 2.6.20, and that's what my patch is for.. and that's what's working for me.

This is my grub.conf:

Code: Select all

title=Gentoo
root (hd0,4)
kernel /boot/gentoo-2.6.20-r8 root=/dev/sda3 video=uvesafb:1024x768-32@85,mtrr:3,ywrap splash=silent,theme:livecd-2007.0 CONSOLE=/dev/tty1
initrd /boot/livecd-1024x768

The important line being the CONSOLE=/dev/tty1 -- this is required to be on the kernel line. The patch file I put in the first post patches cleanly into gentoo-sources-2.6.20-r8

- This builds an initramfs into the kernel using the initramfs file that comes with v86d as a source (as far as I can reckon), so the initramfs line should not be necessary in grub. I tried both ways, but it doesn't even get to that line.
- Did anyone else get a message asking to set the uid and guid of the initramfs source file when compiling the kernel? Which adds extra config options? I used the defaults (0 and 0 = root and root). I am not sure if that is why it doesn't work for me...

It uses the initramfs from the v86d directory as far as I can tell. I don't think it gets "built in", but just used.
I did not have to set any uid/gid's.. my stuff is all root:root.. I put v86d into /usr/src/v86d-0.1 and told the kernel to use /usr/src/v86d-0.1/whatever/path/is/to/initramfs

[Bones McCracker]

I've been using vesafb because spock's site says it gets loaded earlier in the boot process than the others (thereby getting the splash screen up earlier).

How does uvesafb compare in this regard (i.e., will it load later in the boot process like vesafb-tng and the vendor-specific framebuffers)?

[star.dancer]

Ok, I gave it another try and it is working with gentoo-sources 2.6.22-r1! The problem before might have been related to my kernel config options, for some reason "support for the framebuffer splash" doesn't show up in gconfig unless you fiddle with it a little bit with the menus so I don't think I had this enabled.

In reponse to the question about how long it takes until the splash appears: it's great, as good as with the old vesafb patch - provided you use gensplash in the initramfs. Here is my understanding of the initramfs stuff. If you just use uvesafb and do not build gensplash into the initramfs, there will be a longer period of time when you are booting up that you can see kernel messages (ugly!). In order to have the nice "Kernel initalizing..." and "Preparing to boot..." screens that come up before you are really into usermode, you need to build gensplash into the initramfs, which is the same as with the vesafb patch anyway. You can do this by building the initramfs into the kernel or building an external one manually (ick, see the gensplash HOWTO) or build an external one using genkernel (which is nice and takes care of the details automatically, see instructions below). When you edit the initramfs source line, it provides an alternate template for building the initramfs (whether you use gensplash or not).

I did it with a genkernel build and it works fine! Here's a brief howto (I don't have time right now but I will try to update the gensplash howto wiki in a few days if nobody has by then). Note, here I show all the changes to spock's original patch to get it working with gentoo sources in case spock releases a new version. If you want, it would be easier to use soroh6's patch from the first post in this topic in the place of spocks uvesafb patch and skip step 3 and 4 below.

• Emerge gentoo-sources 2.6.22-r1

  Code: Select all

  emerge -av gentoo-sources

• Apply the uvesafb patch

  Code: Select all

  cd /usr/src/linux ; cat uvesafb-0.1-rc2-2.6.22-rc6.patch | patch -p1

• If the patch fails in drivers/video/Makefile, manually add the offending line. The line "obj-$(CONFIG_FB_UVESA) += uvesafb.o" goes just before the line "ifeq ($(CONFIG_FB_VESA_STD),y)"

  Code: Select all

  cd /usr/src/linux/drivers/video; gedit Makefile Makefile.rej

• There is one other change you need to make. In drivers/video/modedb.c there is a line "EXPORT_SYMBOL_GPL(fb_destroy_modelist);" that is in there twice. Do a search for it and if there is two instances of that line, delete one of them (not both).

  Code: Select all

  gedit /usr/src/linux/drivers/video/modedb.c

• Now configure and build the kernel. Make sure to select framebuffer support, framebuffer console support, framebuffer splash support, uvesafb support, and "Connector - unified userspace <-> kernelspace linker". (For me, the "Support for the framebuffer splash" didn't appear until I had opened and closed the gconfig menu a few times, no idea why that would be.)

  Code: Select all

  genkernel --gconfig kernel

• (re-) emerge klibc

  Code: Select all

  emerge klibc

• Unpack v86d to /usr/src

  Code: Select all

  tar -jxvf v86d-0.1-rc3.tar.bz2 /usr/src

• Compile and install v86d

  Code: Select all

  cd /usr/src/v86d-0.1
  ./configure --with-klibc
  make KDIR=/usr/src/linux
  make install

• Recompile the kernel with the correct initramfs stuff and gensplash info. Include "Initial RAM filesystem and RAM disk" and enter "/usr/src/v86d-0.1/misc/initramfs" for "Initramfs source file(s)". I use the GoGentooGo theme from bootsplash-themes, replace "GoGentooGo" with the theme you would like to use in the genkernel line below.

  Code: Select all

  genkernel --gconfig --gensplash=GoGentooGo all

• Add a proper grub entry. If you use an external initramfs (genkernel or manually built), you need the initrd line. My grub entry is as follows:

  Code: Select all

  title=Gentoo Linux 2.6.22
  root (hd1,0)
  kernel /boot/kernel-genkernel-x86_64-2.6.22-gentoo-r1 root=/dev/ram0 init=linuxrc ramdisk=8192 real_root=/dev/sda3 video=uvesafb:1024x768-32@60,mtrr:3,ywrap splash=silent,theme:GoGentooGo CONSOLE=/dev/tty1 quiet udev
  initrd /boot/initramfs-genkernel-x86_64-2.6.22-gentoo-r1
  

• Finished!

Now, I ran into three other problems which may be more related to the 2.6.22 kernel than to the uvesafb patch, but just as a warning:

1. madwifi-ng doesn't build against 2.6.22 without the newest patch in bugzilla
2. ati-drivers don't build against 2.6.22 without the newest patch in bugzilla
3. There is some sort of whacky interaction between uvesafb/the framebuffer, ati-drivers, and 2.6.22 (or a combination thereof) so that X won't start (it bails with the error "PreInitDAL" and "Screens found but none are suitable" and things like that. A workaround is to install vbetool and execute "vbetool vgamode" just before starting gdm or X. (see this topic).

[Genone]

Crap, first this thread gets me all excited about hgher resolutions on my box, and then I have to read that it requires a initrd, which is a no go for me

[star.dancer]

Crap, first this thread gets me all excited about hgher resolutions on my box, and then I have to read that it requires a initrd, which is a no go for me :(

There is a way to build the initramfs into the kernel (see here). I mean, it still exists but it is built in to kernel so you don't need an initrd line in grub.

Why can't you use an initrd? Just wondering.