improved console interface (was: Re: some console code checked in

[Marcus Brinkmann]

On Tue, Mar 19, 2002 at 09:06:33PM -0500, Roland McGrath wrote:
> First are some feature concerns, with a garnish of efficiency concerns that
> are no doubt in fact negligible.  There are several things you get from
> having the virtual terminal (the screen matrix) maintained in a common
> layer independent of and "above" any particular display driver.  

I have pondered this a bit, and want to start to go into some details of
this.  I think the next step is hacking the current console to work at all,
but I want to plan ahead in parallel.

When seperating the code like this, we have to have an interface between the
generic screen matrix and the display driver.  This interface should be
filesystem based, asynchronous, and flexible enough to allow efficient
implementation of display drivers.

So we will have a mmap'able file which contains the screen content, line by
line from the top left to the bottom right.  The screen dimensions can be
retrieved with the tioctl_tiocswinsz RPC.  That much is pretty clear.
Now, there are a variety of issues.

1. Asynchronous update information.  We have the file_notice_changes RPC for
that.  For example, FILE_CHANGED_WRITE can be used to signal changes,
FILE_CHANGED_META can probably be used to signal size changes (if we don't
want to use the signal mechanism for that) etc.

However, I would like to add a new type here, FILE_CHANGED_SCREEN_RECTANGLE,
to signal that a rectangular area on the screen changed.  The start and end
position define the upper left and lower right corner of the rectangular
area.  And, I would also like to have scrolling types,
FILE_CHANGED_SCREEN_RECTANGLE_SCROLLED_UP, etc, for two reasons:
Scrolling can usually be optimized heavily on the display
driver side, it is useful information to have to implement the update.  Also
important, for some display drivers, like drivers for Braille terminals, it
would be very good to know about scrolling, because then the Braille
terminals panning window can be adjusted so that the scrolling does not
actually occur.  This would be an improvement over using a STOP signal or a
special button which implements something similar to STOP on the display
driver side.  (This is actually a feature request by Stephane Doyon, a
BRLTTY developer, who is actually a user of such devices).

2. Scroll back buffer.  It seems to me best to have the scroll back buffer
maintained in the generic component, so it is retained across detach/attach
and can be shared by many display drivers.  This requires that it is part of
the mmap'able file, so far no problem.  The actual screen content would be
at the end, which can be determined because the dimensions are known.
Here, a SCROLLED_UP notification is also very useful, because this is the
most common thing for a scrollback buffer to do.

However, I was a bit too quick by saying that the screen content is at the
end of the file.  Because this causes a serious performance problem:
Scrolling requires the whole file to change, and indeed, because the file
is mapped, we would need to move the whole buffer by one line.  This is not
acceptable.  It would be much better to treat the file as a ring buffer, and
provide the first line of the screen content by some other means.  Then
scrolling is easily achieved by clearing the next line in the buffer and
changing the metadata to point to one line lower (wrapping at the end).

However, this causes the problem that we need to pass metadata to the
caller.  Maybe an RPC is necessary for that, maybe the two unused fields in
winsize can be overloaded (ugly, ugly), maybe somewhere else we have a
suitable field to overload?  It doesn't seem so.

The length of the file can change.  When we clear the scrollback buffer, the
file will shrink to a screen full of data, when then new data is put into
it, the file will be extended.  We have notification messages for that. 
Maybe by being a bit more clever we can always make use of them?  But I
don't see a way right now.

3. Asynchronous updates again.  I have thought about a different issues, and
that is if display drivers should alwas get synchronous update info, or if
multiple rapid changes should be collected into a single notification
message.  This can make the display driver "sluggish", but it improves
performance in cases like where a lot of data scrolls over the screen. 
Maybe there should be options to fine tune such behaviour, maybe it should
be "intelligent" (eg, make it more synchronous when the user is typing, and
less synchronous when data is scrolling by, as far as you can detect this).
Maybe the timing can be chosen in a way to avoid the bad side effects.  We
know from the X Window system how asynchronous updates look and feel,
although I am sure that people would be surprised to see this effect on the
text console (I usually switch this feature off in an xterm, because I
often eye-ball flooding text for things I am looking for).

There are probably more points that I forgot now, but the above are probably
a good start to talk about such issues.  Let me know if I am completely off
the track.

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