> Date: Tue, 17 Oct 1995 16:06:31 -0500
> From: Michael K. Johnson <johnsonm@nigel.vnet.net>
> To: Dan Merillat <harik@accessorl.net>
> Cc: linux-kernel@vger.rutgers.edu
> Subject: Re: vc scrollback
>
>
> Dan Merillat writes:
>
> It might make sense for you to look into the implementation before
> suggesting "changes". You have just suggested that VCs be changed
> to ack like they already do...
>
> The kernel changes VCs on its own *only* if no application has
> requested to control changing either to the VC in question or
> from the current VC. Otherwise, the app(s) requesting control
> have control.
>
> Read my series of articles in issues 3 and 4 of Linux Journal
> on Programming the VT Interface if you want more details.
>
> michaelkjohnson
My point was to extend this to non-console functions, so that
weather you are local, or telnetted in, you get multiplexing.
As it is, if you have a dumb-terminal hooked to your linux box,
it has one console (unless you run something like screen)
I was tired, I guess my point got lost in my message somewhere.
What I was _REALLY_ looking for was a buffer/switching mechanism
for _ANY_ text connection to a linux machine. If we had kernel
support for that (with the same hooks that an application can use
to switch vc's, no diff local or remote) it would be a major bonus
for those of us with stupid telnet programs w/ 1 session capability
and no multitasking. (what a waste of a 386)
As Is, I can get an approximation of the kernel's functionalty
with iscreen, but that's not the greatest program around. (nowhere close)
I hope this makes it clearer what I was talking about before.
Dan Merillat <Dan.Merillat@eola.accessorl.net>
Animaniac! Linux Activist and net.junkie
Also at: <drm89121@pegasus.cc.ucf.edu>