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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 6/20/06, Antonino A. Daplas <[email protected]> wrote:
Jon Smirl wrote:
> On 6/20/06, Antonino A. Daplas <[email protected]> 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
[email protected]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux