Re: [PATCH 3/9] VT binding: Make VT binding a Kconfig option

["Jon Smirl" <jonsmirl@gmail.com>]

On 6/20/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
> Jon Smirl wrote:
> > On 6/20/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
> >> No it can't.  Once the card is in graphics mode, vgacon cannot go to
> >> text mode on its own.  It has to know how to write to other VGA
> >> registers which are unique per hardware.
> >
> > Might be a good place for a little call_usermodehelper example. VGAcon
> > could try calling vbetool to save it's state and restore it. GregKH
> > told me that the class firmware loader code was the place to start.
> >
>
> Yes, that's part of the plan. I'm still looking for the best inteface
> to do that. It must be a 2-way inteface, ie, kernel->user and user->kernel.
> Does the firmware loader code satisfy the above condition?

Currently the firmware loader  uses call_userhelper on a fixed helper
app. The code would need to be generalized so that you can call an
arbitrary app with your own parameters. Two communication while
running can be achieved via sysfs. Request firmware currently does two
way communication.

This thread should help.
http://marc.theaimsgroup.com/?l=linux-hotplug-devel&m=111129164916712&w=2

My thoughts are that it would be better to generalize the firmware
loader code that to build another version of it in the graphics code.

There are several later threads on the subject. Add me to the cc if
you start discussing this on hotplug-devel.

If I remember the discussions right request firmware is kind of broken
right now since it loads all of the firmware through a single place in
sysfs. Instead it should load the firmware by creating attributes on
the specific devices instead of having one attribute for everything.
Fixing it to allow parameters on the user space call is needed to tell
the user space script where to look for the device.

Request firmware is a very small amount of code and easy to modify.

--
Jon Smirl
jonsmirl@gmail.com
-
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/