On 6/20/06, Antonino A. Daplas [off-list ref] wrote:

Jon Smirl wrote:

quoted

On 6/20/06, Antonino A. Daplas [off-list ref] wrote:

quoted

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