console stuff (was: Re: argp limitation

[Marcus Brinkmann]

On Sun, Mar 10, 2002 at 07:47:23PM -0500, Roland McGrath wrote:
> If you wanted to do that, you could call another argp's parse_opt function
> from yours via the children pointers.

Ok.

> As to your particular option syntax plans for console, I can't even figure
> out what most of that means exactly.

;)  Most of the complexity actually comes from supporting n input devices to
m output devices.  But this is really necessary if we ever want to do that
properly (or we have to go the other way and split the input half from the
output half into different servers, which I have not considered in any
detail, though).

For multiple output devices, you need to have another level of indirection
in the filesystem hierarchy, so you get /$CONSOLE/$VTID for each virtual
console $VTID on a real console $CONSOLE.  For multiple input devices, you
don't want them to be independant completely.  Rather, if you switch the
focus of your keyboard to another virtual console, you want the mouse beside
you to follow focus.  So you need an ability to group input devices
together, and that is a focus group (so called by KGI).  Another good name
would be input group.

> (I don't think something other than
> options is better, presuming it would be either some stupid configuration
> file or a hairy set of state-setting RPCs/ioctls, both of which are worse.

Indeed.

> You'll have to remind me how precisely
> this is all structured and what all the options mean.

I am still working on the details, but the general set up is as above. 
Internally, there is a list of input groups, each with a list of input
devices.  An input group points to a virtual console input buffer.

Then there is the list of consoles, each with a list of virtual consoles.
Most of the state of these is actually encapsulated in the hardware driver,
which provides functions to create, destroy, activate, or output to virtual
consoles (it might only support one).

Output devices know nothing about input devices.  The converse is not true,
but the access of input devices to virtual consoles is limited to things
like: "switch to this virtual console, and give me its input buffer and the
encoding it expects".

I have ~150kb of code done, most of the output half and the vga driver, and
most of the generic part.  The big outstanding issues are configuration (thus
this mail) and xkb support (or something alternative).   I still don't know
enough about xkb, but I hope to be able to rip the parser in the X sources.

> I think the idea of presenting a virtual directory of nodes on which to
> fsysopts might be much easier to operate than a real hairy nesting option
> syntax.  That definitely makes it much easier to understand what is going
> on with an fsysopts query.  It's also about the only thing that makes sense
> for having separate logins on separate vts with each one allowed to control
> only its own settings.

That's true.
 
> That would be a somewhat strange thing to implement for using fsysopts,
> because given the fsys_set_options protocol each different node has to
> technically be its own filesystem.

D'oh!  Correct.  Good that this is not too hard to do.

> The other obvious thing to do is not use fsysopts at all (for the
> fine-grained controls anyway), but instead create new RPC protocols
> understood by the appropriate particular nodes in the virtual directory.
> (They could be ioctls if there are any interfaces worth being compatible
> with.)

I am not happy with either the Linux or BSD ioctls... maybe a small subset
of them can be appropriately taken over.  Otherwise they are very hardware
specific or otherwise strange.  Also, I have looked into the XFree86 console
switching code and it is so lean that we don't really need to do what
BSD/Linux do, if we don't want to.

> Using fsysopts is not a proper way to do things like font loading
> (or anything read from a file), anyway.  You really want the user making
> the configuration call to supply the data directly; it might not even exist
> in any filesystem the user and the console server have in common.  (For
> such things you can either define new RPC protocols or do overloaded
> virtual file things if those seem clean interfaces, such as a .../fontdata
> file that you just io_write a whole font to might not be bad.)

Mmmh.  You know, I considered supporting a subset of the X server protocol
for that, so that you can use an X font server which supplies the fonts to
the console server, and xkb to configure your keyboard map.  That will
definitely not be done in the first version, but hell, why not.

Thanks,
Marcus

 
-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de