Messages in this thread | | | Date | Mon, 9 Jan 2012 22:22:34 +0000 | From | Alan Cox <> | Subject | Re: Multiple consoles |
| |
> It occurred to me that there ought to be an entirely separate set of > virtual consoles bound to the second seat, and the second X server ought > to run on one of those vcs. Or of course, you could choose to log into > the console and not bother with X.
X can do it without consoles.
> Looking at drivers/tty/vt/vt.c, it appears that it was written assuming > that there is just one linux console. It appears to use global > variables for keeping track of which vc is active, etc, rather than > creating one or more console devices, and store the vc multiplexing > information in those devices. So to fix this, vt.c and keyboard.c would > need significantly refactored to remove the global variables and create > a console device to bind vcs, keyboards, and displays to, and then you > could create a second one if you wanted.
Yes - in theory (you'd also have to sort out some of the passing of variables around so that the code knew which 'console group' it belonged to.
> Does this make sense or am I missing something?
It makes sense but it's one of a set of three problems with the tty/vt layer IMHO
- A vt/tty is linked to a framebuffer of some sort, so you can't just create abstract ones plumbed into arbitary objects. Really the vt emulator ought to be separate from the consoles.
- You can only have one set of vts
- The locking needs a rework, particularly the handling of crashes where sometimes we deadlock on the oops reporting.
and the framebuffer layer has some problems with locking and mode setting, with hotplug, and with a complete inability to handle scatter-gather backed consoles.
Alan
| |