Messages in this thread | | | Date | Wed, 31 May 2006 08:00:55 +0800 | From | "Antonino A. Daplas" <> | Subject | Re: OpenGL-based framebuffer concepts |
| |
Pavel Machek wrote: > Hi! > >>> Actually the suspend/resume has to be in userspace, X just re-posts >>> the video ROM and reloads the registers... so the repost on resume has >>> to happen... so some component needs to be in userspace.. >> I'd like to see the simple video POST program get finished. All of the >> pieces are lying around. A key step missing is to getting klibc added >> to the kernel tree which is being worked on. >> >> BenH has the emu86 code. I agree that is simpler to always use emu86 >> and not bother with vm86. He also pointed out that we need to copy the >> image back into the kernel after the ROM runs. Right now you can only >> read the ROM image from the sysfs attribute. The ROM code has support >> for keeping an image in RAM, it just isn't hooked up to the sysfs >> attribute for writing it. > > Actually, vbetool is the piece of puzzle we currently use to > reinitialize graphics cards after resume. (suspend.sf.net).
But vbetool can only handle primary cards, can't it?
> > We currently do it all in userspace; it would be cleaner to do it as > call_usermodehelper() from kernel.
I had a patch sometime before, vm86d. It's a daemon in userspace that accepts requests from the kernel which executes x86 instructions using lrmi, then pushes the result back to the kernel. I modified vesafb so that it uses this daemon which makes vesafb acquire the capability to do on the fly mode switching (similar in functionality with vesafb-tng which uses a different method).
I abandoned this patch, but it seems there's might be at least one user.
spblinux (http://spblinux.sourceforge.net/)
Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |