[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: console plans
Re: console plans
Tue, 25 Jun 2002 03:31:34 +0200
On Mon, Jun 24, 2002 at 09:07:46PM -0400, Roland McGrath wrote:
> > I am unsure about this. Let's start with initialization. Currently, the
> > console can report back the size of the screen with TIOCGWINSZ, while
> > TIOCSWINSZ is ignored (changing the size of the screen is simply not
> > supported right now). However, nothing ever calls TIOCGWINSZ on the console
> > node. It seems to me that it is terms responsibility to call TIOCGWINSZ on
> > the underlying node at initialization.
> That is exactly the extension to the hurdio backend that I described in the
> first place.
The part I was confused about is if term would make an epxlicit call to
TIOCGWINSZ at start up, or if it would ever do this only in response to a
SIGWINCH. But it seems best to do it explicitely once at startup.
> > Ok. What about the client? Will that be started by console-run, or later?
Ok. I like the idea of redirecting term.
> The advantage of having the console server do it is that the switching can
> be visually seamless because the display's matrix contains the stuff that
> was printed before the console client started and so in the usual case it
> will take over and redraw the screen with the same contents. With the term
> backend-switching plan, nothing printed before the fancy console got going
> will be on the screen any more. But you have that issue with anything
> printed by the kernel or boot loader or init anyway. For visually seamless
> switching perhaps the thing to do is give the VGA client an option to read
> the state of the VGA hardware when it starts and fill that into the display.
Or the VGA client can just save the screen as it was when it was started and
restore it for inspection by the user on request, treating it like a "dead"
`Rhubarb is no Egyptian god.' Debian http://www.debian.org email@example.com
Marcus Brinkmann GNU http://www.gnu.org firstname.lastname@example.org