Sheesh. Hopefully it would be trivial to modify screen to understand
F-key sequences; it would certainly have long-term benefits for screen
as well.
> if there were hooks in the kernel for it, then a dumb-terminal on
> the serial port could be sending _IT'S_ alt-f1 sequence, and pulling
> a vc that way. (perhaps like screen does, ttyq etc.)
The same trivial modification to screen works here too.
> besides, X needs the vc's as is, and I'm sure that everyone would
> _LOVE_ to have to recompile their x server to do the switching itself.
X doesn't need the VC's as is, legacy binaries do. We use X Inside's
X server for driving proprietary Matrox cards--it already works on
six (7? I lost count after 5) Unix variants without modifying the binaries
(!) so adding a new way to switch consoles won't cause much pain in the
long run.
I wish the people who keep saying "Take the VC crap out of the kernel,
replace it with something like screen" would finally _do_ it already.
You can already get a raw keyboard interface, raw screen access, and
console-context-switching (you'll need it for a while so you can be
backward compatible while we all migrate). Just implement something
like screen by stealing kernel sources (or hack screen itself) so that
it will run without any of the VC kernel code you want to eliminate.
Leave enough code in the kernel to support /dev/tty1, printk, 80x25 mono
text, console arbitration, a minimal termcap, and alphanumberic keys on
US keyboards (in short, everything you need to edit RC scripts with vi
or emacs until you get your pseudo-'screen' running, and to get kernel
bootup and crash messages).
You'd modify GNU screen so that it can handle clients that connect to an
arbitrary slave pty and automatically create virtual consoles for them, as
well as a whole lot of security enhancements not found in normal screen
(can't allow users to do "^A:screen /bin/bash -login" as root, can we?
Yet you'd want users to be able to create windows with getty on them).
This screen should also be able to spawn processes with SVGA IO
permissions (assuming you have some authenticated way for a user to
communicate to the screen daemon that it wants such a process started).
This might be a good time to get the "put VGA drivers into the kernel"
people on side--the code to set up VGA state for different VCs in graphics
mode can now live in the screen daemon. As far as I know, nobody really
wants to put this code into the kernel rather than a user-mode process;
people just want it all in one place, wherever that place is.
Graphics accelerators with DMA and interrupts might be a problem for a
user-mode virtual console daemon, but I suspect that all they require
is a device driver to queue commands from userland to make them happy.
You'd also have to support raw keyboard scan codes in screen, since the
kernel won't provide keyboard remapping any more (probably a good idea,
actually...I'd love to see that change propagated back into standard
screen as a general keyboard translation facility).
The screen daemon should be at least portable to ix86 Unixes that can
run XFree86--after all, it will be doing more or less the same thing as
XFree86 from the point of view of the kernel (i.e. take control of the
graphics card and read raw keyboard (and mouse?) input), so the
development cost can be spread out across multiple Unixes (although
the people who say "remove VCs from Linux" probably aren't interested
in adding VCs to other Unixes, and the people who say "add VCs to my
operating system" probably don't care about removing them from Linux).
After this inital step, we could all discuss removing the VC code
(redundant because it is now (hopefully) done in a user-level process
as well as it was done in the kernel).
Note you'd have to leave the VC arbitration code and device files in
the kernel long after you'd removed everything else, to handle legacy
binaries.