Multiple consoles
I was considering some questions I read about setting up a multi-seat system where you have two separate sets of displays, keyboards, mice, and X servers. The problem someone noticed is that if you run the second X server on tty8, then you have to switch the console to tty8 to activate it, which disables the primary X server.
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.
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.
Does this make sense or am I missing something?
Quoted 1 line · Phillip Susi, le Mon 09 Jan 2012 16:11:36 -0500, a écrit :
Does this make sense or am I missing something?
It used to be planned, but nobody took the job, because X doesn't need this (see option -sharevts).
Samuel
Quoted 5 lines · Samuel Thibault
Quoted 1 line · Phillip Susi, le Mon 09 Jan 2012 16:11:36 -0500, a écrit :
Does this make sense or am I missing something?
It used to be planned, but nobody took the job, because X doesn't need this (see option -sharevts).
If you do that, you can't use vcs. AFAICS, there won't be any on the second seat, and if you switch the first seat back to a vc, it will read input from both keyboards. And what about magic-sysrq? A SAK on either keyboard will kill the primary X won't it?
Quoted 8 lines · Phillip Susi, le Mon 09 Jan 2012 16:32:14 -0500, a écrit :
Quoted 5 lines · Samuel Thibault
Quoted 1 line · Phillip Susi, le Mon 09 Jan 2012 16:11:36 -0500, a écrit :
Does this make sense or am I missing something?
It used to be planned, but nobody took the job, because X doesn't need this (see option -sharevts).
If you do that, you can't use vcs.
Yes, but it has usually been considered not being a problem.
Samuel
Quoted 20 lines · Phillip Susi
I was considering some questions I read about setting up a multi-seat system where you have two separate sets of displays, keyboards, mice, and X servers. The problem someone noticed is that if you run the second X server on tty8, then you have to switch the console to tty8 to activate it, which disables the primary X server.
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.
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.candkeyboard.cwould 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.
Quoted 1 line
Does this make sense or am I missing something?
The linux-console project tried to fix this (CC James added).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
Quoted 4 lines
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.
Quoted 8 lines
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.candkeyboard.cwould 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.
Quoted 1 line
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