Daedra, I haven't had time to try this out yet but I think it's worthy of a SlackWiki page...

Just an FYI for everyone. starting with kernel 2.6.28 the asm include files have been moved and because of that klibc will fail to compile. I used a patch I found that made it so that klibc would successfully compile, but then I found out that any programs that rely on klibc (like v86d) will fail to compile. The reason for this the fact that the asm include files have been moved in the 2.6.28 kernels and beyond. To fix this you have to do a little work around.

1) change to your /usr/src/linux directory and backup your .config file somewhere safe. Now we need to change the asm symlink. delete the current symlink at /usr/src/linux/include/asm and then create a new asm symlink like so

cd /usr/src/linux/include
ln -s /usr/src/linux/arch/x86/include/asm

You should now be able to cleanly compile klibc and v86d with klibc support. Be sure to save your packages because once there made you do not need to recompile them with every new kernel release, so once you do this once your done, SAVE YOUR PACKAGE

Because we changed the asm symlink we have now in a sense broken the kernel directory, to fix it change to /usr/src/linux and then run

make mrproper

this will revert your kernel directory back to original settings. Then copy back your .config file to /usr/src/linux and then

make oldconfig

After that your kernel directory will be back to normal and you done. Its definitely a kludge but its the only way I found to compile klibc with never kernels.


I am not sure if this has been fixed in newer kernels or not, I haven't tested it in a while, so any feedback is appreciated.

http://www.archlinux.org/pipermail/a...ry/003213.html

You should when you get time, its so worth it. Anyone out there that uses the console as much as I do then this really is a must IMO, I have a 28in monitor with the console running at 1920x1200, it makes thing so much nicer to work with.

I got it working. My laptop's native resolution wasn't supported though. It's an Asus A8Js with a Geforce Go 7700 card.

I had a custom 2.6.29.4 kernel with the source archive in my home directory, so this is how I did it.

First, I compiled uvesafb into the kernel.

Then, I downloaded klibc-1.5.15 from kernel.org (it's in /testing) and the klibc-fix-2.6.28-includes.patch file from Arch Linux. I compiled klibc like this:

Then I compiled v86d like this:
Then I compiled the initramfs image into the kernel, as per Spock's instructions.

DONE!

This wasn't very useful because my native resolution wasn't supported anyway, but now I know how to do it.

ignore - Nice I didn't know there was a patch for klibc, you got a link for it?

Nevermind, I was thinking of something else

Edited accordingly.

I had the same problem with my laptop, it didn't support any of the higher resolutions, I'm just glad my 8800GT did.

vbetest is a great utility and imho should be included on the installation CD. When I ran it on my T400, it gave me a mode number for 1280x800x24 (its native resolution). I added 512 to it and set the "vga=" line in lilo.conf to the result. It worked... with the stock kernel and the stock vesafb driver.

I wish I tried it before setting up uvesafb and not after <headdesk>.

Are you running current? I just tried installing lrmi and it failed to compile?

I am running -current. I googled for the error and found a patch.

lrmi on SlackBuilds.org already has a similar patch to make it build against newer kernels.
However, note that lrmi is unmaintained (unfortunately) and won't work/build on a 64bit system.
I've looked for a replacement to vbetest, that also works on slackware64, but so far no luck :/

That's very unfortunate. You only need to run vbetest once per video card bios, though, so you could find a livecd that has it and run it from there.

IIRC, the s2ram tool packaged for debian-esque systems comes complete with a pre-compiled vbetool binary. So if the issue is precisely that it won't build on a 64bit arch, but maybe it will execute then you could get vbetool this way.

If it won't work though, this becomes irrelevant, and as you suggest, we'd be stuck

Sasha

Ok, I did some more research today and may have something to replace lrmi/vbetest

The thing is called hwinfo and is the tool used by Opensuse for hardware detection (which means it's capable of far more than plain vesa mode detection).
Unfortunately those suse bast.. err developers forked off libx86, so you'll need libx86emu to compile hwinfo.

I have slackbuilds for both ready and would be happy if you could test these, preferably on -current. It seemed to run fine here on slack32 and slack64, but you never know...

Anyway, here are the links:
libx86emu.tar.gz
hwinfo.tar.gz

hwinfo --framebuffer should give you the same results as vbetest, albeit already in hexa-decimal

They built fine on my 32-bit slackware-current system.

And hwinfo --framebuffer worked.

I would have liked to know this though: