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.

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:

//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._________________Gentoo Handbook | My website

And how do you configure initramfs to load 915resolution first?_________________I'm too lazy to keep this stupid signature up to date, so here's something more interesting:
My friend Hetdegon can draw if you ask me.
Now using PClinuxOS on my laptop and Gentoo on my desktop and new laptop.

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?

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?

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_________________:: soroh -*~

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

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.

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

star.dancer wrote:

- 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_________________:: soroh -*~

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:

emerge -av gentoo-sources

Apply the uvesafb patch

Code:

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:

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:

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

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:

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:

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

Last edited by star.dancer on Thu Jul 12, 2007 11:28 pm; edited 4 times in total