Re: OpenGL-based framebuffer concepts

[Jon Smirl]

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).
>
> But vbetool can only handle primary cards, can't it?

That is correct, but you can get the ROM image for all adapters out of
sysfs now so it is not really hard to change it.  Handling secondary
cards is another feature of the new tools that isn't finished yet.

The tool should also put the image back into the kernel after the ROM
is run. A lot of these ROM assume they are running out of shadow RAM
and make changes to the image.

> > 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/)

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.

--
Jon Smirl
jonsmirl@xxxxxxxxx
-
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/