Re: some console code checked in

[Marcus Brinkmann]

On Tue, Mar 19, 2002 at 09:06:33PM -0500, Roland McGrath wrote:
> Our chief concern to begin with is clean code reuse and consistency of the
> terminal emulation for standard display devices.  Turning the interface
> inside out doesn't lose that.

Yeah, sure.  I think it is important I get the keyboard driver ready and
the vga driver finished so it works.  I think I am going to worry a bit
less about n-to-m support for now than I planned for initially.

> You can have generic visual bell and screensaver modules that plug in at
> the higher level interface. 

Yes, I realized that.  I was satisfying myself with code reuse
(every driver could plug the bells and whistles its support into
itself).  But I see your point, and all of the features are much better
implemented with having the matrix layer above the device driver. 

Note however for efficiency concerns, every generic abstraction will be
slower than a native implementation (for example, vga can be faster if
you use interleaved addressing mode, where character/atribute pairs
are stored alternatively).  Indeed, the independance of the screen
matrix comes at a cost:  You have to
reconstruct the internal state at each virtual console switch, for
example.  For most generality, the abstract screen matrix would use
a wchar_t matrix and a generic representation of the attributes (color
etc).  The specific driver must convert this to the internal
representation (this includes font calculation, for example in my
dynamic font, which might be expensive).  The current implementation
relies on it that the driver notices all output to all virtual consoles
that might be displayed on this console.  In short:  There is a hard
binding of consoles to display drivers, and removing that will make
the driver less aware of the state.

> Second, I am still of two minds about what "the right thing" is for the
> console abstraction (actually, I'm two minds aware that in the end my mind
> will just go to little pieces).

:)  I am happy you raise these issues.  I think that there are schemes
were all of the issues fall together into a bigger picture.

> I was buying your argument for a while,
> thinking about applications a la conserver where you are treating the
> virtual console as you would a serial port (i.e. equivalent to a pty), as
> well as the speech/Braille examples you mentioned.  But now I am thinking
> more of applications a la screen, where there is a consistent virtual
> terminal screen image maintained that can be attached (sequentially or
> simultaneously) to multiple disparate players.  And for speech and Braille
> interfaces, they might well have a virtual screen image in the canonical
> sense and have in their own front ends scrolling or "panning" sort of
> interfaces (screen has support for some Braille devices that appear to work
> this way).

I should research this.  However, I don't want to give up the idea of
opaque display devices completely, which don't let you to attach or spy on the
display.  Note that currently, the console server includes the input and
output device drivers.  In the decomposed model, the natural thing to do
is to keep the input and output drivers in a seperate process, and
communicate with the console server over the filesystem.

INPUT  \____ CONSOLE SERVER ___ TERM SERVER
OUTPUT /     (one list of virtual consoles)

The input/output combo can switch to different consoles or virtual
consoles within a console, all from the outside.  This would lead to a
server and a client model, which might well be easier to implement.

What I am worried a bit about is that a display has a lot more
properties than an input stream, so it is more difficult to check if an
output display is compatible with the text screen matrix.  This includes
properties like number of colors and size.

The more I think about it, the more sense it makes to split it up into
two programs.  This was suggested before (for example by Nick on IRC),
but I rejected it because I was still attached to the opaque driver
model.  However, the interface between these programs would require some
careful thought.

> All these features are more than fancy enough not to worry about overmuch
> now. 

I am not so sure.  Of course it makes sense to finish the console server
I have started to make it functional, so oskit becomes usable.  but
instead trying harder to get the argument parsing, fsysopts hierarchy
and n-to-m support into place, I think it would be easier to go for the
above model.  I will have to do a lot more thinking, but the general
idea is clear now.  (Things to think about is stuff like: If it is in
seperate programs, how do we make sure that the input/output display
driver is kicked off at boot time?  We would need to start it in a boot
script, because the machine doesn't really require it to boot and be
functional at all (you could just as well attach from a remote machine
via VNC to see your console getty ;))

Thanks,
Marcus