Multiple consoles

Multiple consoles

[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.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?

Re: Multiple consoles

[Samuel Thibault]

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

Re: Multiple consoles

[Phillip Susi]

On 1/9/2012 4:21 PM, Samuel Thibault wrote:
> 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?

Re: Multiple consoles

[Samuel Thibault]

Phillip Susi, le Mon 09 Jan 2012 16:32:14 -0500, a écrit :
> On 1/9/2012 4:21 PM, Samuel Thibault wrote:
> >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

Re: Multiple consoles

[Geert Uytterhoeven]

On Mon, Jan 9, 2012 at 22:11, Phillip Susi <psusi@cfl.rr.com> wrote:
> 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?

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 -- geert@linux-m68k.org

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

Re: Multiple consoles

[Alan Cox]

> 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