From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Phillip Susi <psusi@cfl.rr.com>
Cc: Greg KH <gregkh@suse.de>, linux-kernel@vger.kernel.org
Subject: Re: Multiple consoles
Date: Mon, 9 Jan 2012 22:22:34 +0000 [thread overview]
Message-ID: <20120109222234.6d34a7ad@pyramind.ukuu.org.uk> (raw)
In-Reply-To: <4F0B5808.2010900@cfl.rr.com>
> 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
prev parent reply other threads:[~2012-01-09 22:21 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-09 21:11 Phillip Susi
2012-01-09 21:21 ` Samuel Thibault
2012-01-09 21:32 ` Phillip Susi
2012-01-09 21:56 ` Samuel Thibault
2012-01-09 22:07 ` Geert Uytterhoeven
2012-01-09 22:22 ` Alan Cox [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120109222234.6d34a7ad@pyramind.ukuu.org.uk \
--to=alan@lxorguk.ukuu.org.uk \
--cc=gregkh@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=psusi@cfl.rr.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®