lkml.org 
[lkml]   [2012]   [Jan]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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


\
 
 \ /
  Last update: 2012-01-09 23:23    [W:0.116 / U:0.348 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site