Re: OpenGL-based framebuffer concepts

["Antonino A. Daplas" <adaplas@gmail.com>]

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/