![]() | |||||||||||||
Messages in this thread |
Jon Smirl wrote: > On 5/30/06, Antonino A. Daplas <adaplas@gmail.com> wrote: >> > Actually, vbetool is the piece of puzzle we currently use to >> > reinitialize graphics cards after resume. (suspend.sf.net). >> >> >> 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/) > > This is very similar to what I am proposing. I would just spawn the > app off each time instead of using a daemon; it's not like you are > changing mode every few seconds. By spawning each time you can avoid > the problem of the kernel trying to figure out if the daemon has died. I was thinking of reviving this patch, because of problems with suspend/ resume and mode setting. But if there is a plan to put an emulator as part of the kernel library, I'll hold off. I'm also thinking of using a different user-kernel interface. The old patch creates a misc device which the daemon opens, but can the kernel connector do the job? I don't know anything about this. Tony PS: This user helper need not just do x86 calls, it might use OF or even X. (I believe the Xen people have something similar). A userspace framebuffer driver usable by the kernel console is definitely possible. - 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/ | ||||||||||||
| Last update: 2006-05-31 03:26 [W:5.425 / U:0.300 seconds] ©2003-2008 Jasper Spaans | |||||||||||||