Re: OpenGL-based framebuffer concepts

[Antonino A. Daplas]

Jon Smirl wrote:
> On 5/30/06, Antonino A. Daplas <adaplas@xxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/