[PATCH v2] vt: add init_hide parameter to suppress boot output

[PATCH v2] vt: add init_hide parameter to suppress boot output

[Kirill A. Shutemov]

From: Andy Ross <andy.ross@windriver.com>

When vt.init_hide is set, suppress output on newly created consoles until
an affirmative switched to that console.  This prevents boot output from
displaying (and clobbering splash screens, etc...) without disabling the
console entirely.

Signed-off-by: Andy Ross <andy.ross@windriver.com>
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
--
 v2:
  - style: add space after if keyword;
  - change init_hide from int to bool;
---
 drivers/tty/vt/vt.c            |    7 +++++++
 include/linux/console_struct.h |    3 ++-
 include/linux/vt.h             |    2 ++
 kernel/power/console.c         |    2 --
 4 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 8fd8968..c68322c 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -165,6 +165,9 @@ module_param(global_cursor_default, int, S_IRUGO | S_IWUSR);
 static int cur_default = CUR_DEFAULT;
 module_param(cur_default, int, S_IRUGO | S_IWUSR);
 
+static bool init_hide;
+module_param(init_hide, bool, S_IRUGO);
+
 /*
  * ignore_poke: don't unblank the screen when things are typed.  This is
  * mainly for the privacy of braille terminal users.
@@ -734,6 +737,7 @@ static void visual_init(struct vc_data *vc, int num, int init)
 	__module_get(vc->vc_sw->owner);
 	vc->vc_num = num;
 	vc->vc_display_fg = &master_display_fg;
+	vc->vc_hidden = init_hide;
 	vc->vc_uni_pagedir_loc = &vc->vc_uni_pagedir;
 	vc->vc_uni_pagedir = 0;
 	vc->vc_hi_font_mask = 0;
@@ -2336,6 +2340,9 @@ static void console_callback(struct work_struct *ignored)
 	if (want_console >= 0) {
 		if (want_console != fg_console &&
 		    vc_cons_allocated(want_console)) {
+			if (want_console != SUSPEND_CONSOLE &&
+					fg_console != SUSPEND_CONSOLE)
+				vc_cons[want_console].d->vc_hidden = 0;
 			hide_cursor(vc_cons[fg_console].d);
 			change_console(vc_cons[want_console].d);
 			/* we only changed when the console had already
diff --git a/include/linux/console_struct.h b/include/linux/console_struct.h
index 7f0c329..fc96691 100644
--- a/include/linux/console_struct.h
+++ b/include/linux/console_struct.h
@@ -91,6 +91,7 @@ struct vc_data {
 	unsigned int	vc_can_do_color	: 1;
 	unsigned int	vc_report_mouse : 2;
 	unsigned char	vc_utf		: 1;	/* Unicode UTF-8 encoding */
+	unsigned int    vc_hidden	: 1;    /* Set by vt.init_hide */
 	unsigned char	vc_utf_count;
 		 int	vc_utf_char;
 	unsigned int	vc_tab_stop[8];		/* Tab stops. 256 columns. */
@@ -134,6 +135,6 @@ extern void vc_SAK(struct work_struct *work);
 
 #define CUR_DEFAULT CUR_UNDERLINE
 
-#define CON_IS_VISIBLE(conp) (*conp->vc_display_fg == conp)
+#define CON_IS_VISIBLE(conp) (*conp->vc_display_fg == conp && !conp->vc_hidden)
 
 #endif /* _LINUX_CONSOLE_STRUCT_H */
diff --git a/include/linux/vt.h b/include/linux/vt.h
index b186e04..0dc3e89 100644
--- a/include/linux/vt.h
+++ b/include/linux/vt.h
@@ -11,6 +11,8 @@
 #define VT_UPDATE		0x0004 /* A bigger update occurred */
 #define VT_PREWRITE		0x0005 /* A char is about to be written to the console */
 
+#define SUSPEND_CONSOLE	(MAX_NR_CONSOLES-1)
+
 #ifdef CONFIG_VT_CONSOLE
 
 extern int vt_kmsg_redirect(int new);
diff --git a/kernel/power/console.c b/kernel/power/console.c
index b1dc456..b74bdb8 100644
--- a/kernel/power/console.c
+++ b/kernel/power/console.c
@@ -10,8 +10,6 @@
 #include <linux/module.h>
 #include "power.h"
 
-#define SUSPEND_CONSOLE	(MAX_NR_CONSOLES-1)
-
 static int orig_fgconsole, orig_kmsg;
 
 int pm_prepare_console(void)
-- 
1.7.10.4

Re: [PATCH v2] vt: add init_hide parameter to suppress boot output

[Greg Kroah-Hartman]

On Tue, Feb 19, 2013 at 05:53:44PM +0200, Kirill A. Shutemov wrote:
> From: Andy Ross <andy.ross@windriver.com>
> 
> When vt.init_hide is set, suppress output on newly created consoles until
> an affirmative switched to that console.  This prevents boot output from
> displaying (and clobbering splash screens, etc...) without disabling the
> console entirely.

What's wrong with the 'quiet' option we have?  And you forgot to
document this.

greg k-h

Re: [PATCH v2] vt: add init_hide parameter to suppress boot output

[Andy Ross]

On 02/19/2013 05:45 PM, Greg Kroah-Hartman wrote:
>> When vt.init_hide is set, suppress output on newly created consoles
>> until an affirmative switched to that console.  This prevents boot
>> output from displaying (and clobbering splash screens, etc...)
>> without disabling the console entirely.
>
> What's wrong with the 'quiet' option we have?  And you forgot to
> document this.

You're right about docs, obviously.  I'll write something up and send
it tomorrow morning.

But setting "quiet" controls logging.  It won't prevent the console
from doing a buffer clear or mode switch, nor will it prevent
userspace from writing to it, nor will the buffer rewrites due to the
console switches that happen on suspend and resume (which I didn't
know existed) be suppressed.

There's a (sort of) similar commonly-used option, vga=current, which
prevents a mode switch for the special case of VGA/vesa.  But that
doesn't work with the framebuffer console.

The idea here (and I'm clearly no domain expert) was to leave the
console enabled and active, but invisible by default.  So nothing
displays, the splash screen stays put, and nothing fights with other
users of the framebuffer.  And it stays that way until something
affirmatively switches to a different VT using chvt or Alt-Fn or
whatever.

To be fair, a lot of this could be managed in userspace with the VT_*
ioctl interface.  But the specific application here (Android's
surfaceflinger) isn't set up for that, and it's a non-trivial API (and
even doing it "right" involves racing against other users at startup).
This seemed like a much simpler metaphor that still meets the
requirements.

Andy

Re: [PATCH v2] vt: add init_hide parameter to suppress boot output

[Greg Kroah-Hartman]

On Tue, Feb 19, 2013 at 08:04:05PM -0800, Andy Ross wrote:
> On 02/19/2013 05:45 PM, Greg Kroah-Hartman wrote:
> >>When vt.init_hide is set, suppress output on newly created consoles
> >>until an affirmative switched to that console.  This prevents boot
> >>output from displaying (and clobbering splash screens, etc...)
> >>without disabling the console entirely.
> >
> >What's wrong with the 'quiet' option we have?  And you forgot to
> >document this.
> 
> You're right about docs, obviously.  I'll write something up and send
> it tomorrow morning.
> 
> But setting "quiet" controls logging.  It won't prevent the console
> from doing a buffer clear or mode switch, nor will it prevent
> userspace from writing to it, nor will the buffer rewrites due to the
> console switches that happen on suspend and resume (which I didn't
> know existed) be suppressed.
> 
> There's a (sort of) similar commonly-used option, vga=current, which
> prevents a mode switch for the special case of VGA/vesa.  But that
> doesn't work with the framebuffer console.

Why not?  Can't you fix that?

> The idea here (and I'm clearly no domain expert) was to leave the
> console enabled and active, but invisible by default.  So nothing
> displays, the splash screen stays put, and nothing fights with other
> users of the framebuffer.  And it stays that way until something
> affirmatively switches to a different VT using chvt or Alt-Fn or
> whatever.
> 
> To be fair, a lot of this could be managed in userspace with the VT_*
> ioctl interface.

Yes, that's what "normal" systems do :)

> But the specific application here (Android's surfaceflinger) isn't set
> up for that, and it's a non-trivial API (and even doing it "right"
> involves racing against other users at startup).

How could there be any other users at startup, you "own" the system
here, there should not be anyone to race with.

> This seemed like a much simpler metaphor that still meets the
> requirements.

I think you should use the ioctls, that is what they are there for, and
is what you need to implement if you want to use a console anyway,
right?

greg k-h

Re: [PATCH v2] vt: add init_hide parameter to suppress boot output

[Andy Ross]

On 02/19/2013 08:45 PM, Greg Kroah-Hartman wrote:
 > On Tue, Feb 19, 2013 at 08:04:05PM -0800, Andy Ross wrote:
 > > There's a (sort of) similar commonly-used option, vga=current, which
 > > prevents a mode switch for the special case of VGA/vesa.  But that
 > > doesn't work with the framebuffer console.
 >
 > Why not?  Can't you fix that?

I'd argue that's what this is.  If you were going to design a "shut up
the console" feature from scratch, would you choose to do it in one
particular display driver or would you do it in the device-independent
console code by forcing the already-existing "visible" flag to false?

 > > But the specific application here (Android's surfaceflinger) isn't set
 > > up for that, and it's a non-trivial API (and even doing it "right"
 > > involves racing against other users at startup).
 >
 > How could there be any other users at startup, you "own" the system
 > here, there should not be anyone to race with.

Tell that to the display hardware. :)

Seriously, every Linux box with a display (to first approximation,
obviously I didn't test them all while writing this message) spits
something to the screen between the moment where the bootloader hands
off control and the display driver is initialized.  Most of them
glitch a little at suspend time because of the console switch there.
I just reproduced both of these effects with a Fedora 18 live image.

This fixes almost all of that (vga=current is still required because
some early logging somewhere seems to write to the screen by banging
registers directly and not using the console), and it does it in a way
that works without having to modify existing userspace or (try to)
remove the framebuffer console entirely.

Andy

Re: [PATCH v2] vt: add init_hide parameter to suppress boot output

[Greg Kroah-Hartman]

On Wed, Feb 20, 2013 at 08:54:47AM -0800, Andy Ross wrote:
> On 02/19/2013 08:45 PM, Greg Kroah-Hartman wrote:
> > On Tue, Feb 19, 2013 at 08:04:05PM -0800, Andy Ross wrote:
> > > There's a (sort of) similar commonly-used option, vga=current, which
> > > prevents a mode switch for the special case of VGA/vesa.  But that
> > > doesn't work with the framebuffer console.
> >
> > Why not?  Can't you fix that?
> 
> I'd argue that's what this is.  If you were going to design a "shut up
> the console" feature from scratch, would you choose to do it in one
> particular display driver or would you do it in the device-independent
> console code by forcing the already-existing "visible" flag to false?

I don't know.  All I do know is that by adding yet-another-userspace
option, we will have to support it for 20+ years.  And I'm _really_
hesitant to do so, especially for a subsystem that, if all goes well, we
will be able to just entirely disable soon.

> > > But the specific application here (Android's surfaceflinger) isn't set
> > > up for that, and it's a non-trivial API (and even doing it "right"
> > > involves racing against other users at startup).
> >
> > How could there be any other users at startup, you "own" the system
> > here, there should not be anyone to race with.
> 
> Tell that to the display hardware. :)

On Android you own that as well, so there this isn't an excuse :)

> Seriously, every Linux box with a display (to first approximation,
> obviously I didn't test them all while writing this message) spits
> something to the screen between the moment where the bootloader hands
> off control and the display driver is initialized.  Most of them
> glitch a little at suspend time because of the console switch there.
> I just reproduced both of these effects with a Fedora 18 live image.

That's Fedora's issue, not Android's.

And it's really a DRM issue, and as mentioned above, one that people are
already working on resolving by just getting rid of this whole layer
entirely.  So adding new options to it are something that I really don't
want to do, especially as we already have working prototypes that don't
have this problem.

> This fixes almost all of that (vga=current is still required because
> some early logging somewhere seems to write to the screen by banging
> registers directly and not using the console), and it does it in a way
> that works without having to modify existing userspace or (try to)
> remove the framebuffer console entirely.

Then fix that early logging code, don't paper over it by doing something
like this please.  Or just remove the framebuffer entirely, it's not
needed, no one will miss it...

thanks,

greg k-h

Re: [PATCH v2] vt: add init_hide parameter to suppress boot output

[Pavel Machek]

Hi!

> > How could there be any other users at startup, you "own" the system
> > here, there should not be anyone to race with.
> 
> Tell that to the display hardware. :)
> 
> Seriously, every Linux box with a display (to first approximation,
> obviously I didn't test them all while writing this message) spits
> something to the screen between the moment where the bootloader hands
> off control and the display driver is initialized.  Most of them
> glitch a little at suspend time because of the console switch there.
> I just reproduced both of these effects with a Fedora 18 live image.
> 
> This fixes almost all of that (vga=current is still required because
> some early logging somewhere seems to write to the screen by banging
> registers directly and not using the console), and it does it in a way
> that works without having to modify existing userspace or (try to)
> remove the framebuffer console entirely.

I'm sure something creative can be done with fake init that shuts the console
up then execs previous init. No need to add more kernel knobs, I'd say.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH v2] vt: add init_hide parameter to suppress boot output

[Andy Ross]

On 02/20/2013 12:57 PM, Pavel Machek wrote:
> I'm sure something creative can be done with fake init that shuts
> the console up then execs previous init. No need to add more kernel
> knobs, I'd say.

Fair enough, but some last words:

That's argument is the "it's about logging" hypothesis again.  Even if
it were possible to completely shut up console output (something
that's awfully hard in the general case when running on PC hardware,
and IMHO from a developer's perspective not even a good thing), that's
not the whole problem.  The framebuffer console initialization does a
buffer clear and mode set, and that clobbers anything the bootloader
might have left on the screen prematurely, before userspace is ready
to throw up its own splash.  Splash screens may be a silly
requirement, but they're still a requirement.

And the suspend console problem is likewise at work: ideally you'd
like to know, for example, that the panel backlight is off before
suspending.  But what happens in practice is that the kernel does a VT
switch to/from console 63 and the backlight wakes up (I'm not going to
pretend I have this bit completely figured out, but the problem is/was
real and this patch fixed it by suppressing the console visibility).

Now, the point that an in-kernel console is "going away" and thus not
worth augmenting with new APIs is valid.  And this is a small patch
that's unlikely to be difficult to maintain in a custom tree.  And as
we all agree there are other mechanisms that can be used here (even if
AFAICT they don't completely solve the problem), and indeed I'd love
to get surfaceflinger working with VT_ACTIVATE et. al. if I get a
chance.  So I'm not going to cry if this isn't worth mainline.

But at the same time: all that other stuff doesn't quite meet the
requirements (which in this case are basically "nothing happens
visually between bootloader handoff and the surfaceflinger splash").
What you get with that is something like what you get with desktop
distros: you "mostly" never see the console, except when you do.

Andy

Re: [PATCH v2] vt: add init_hide parameter to suppress boot output

[Pavel Machek]

On Wed 2013-02-20 14:08:25, Andy Ross wrote:
> On 02/20/2013 12:57 PM, Pavel Machek wrote:
> >I'm sure something creative can be done with fake init that shuts
> >the console up then execs previous init. No need to add more kernel
> >knobs, I'd say.
> 
> Fair enough, but some last words:
> 
> That's argument is the "it's about logging" hypothesis again.  Even if
> it were possible to completely shut up console output (something
> that's awfully hard in the general case when running on PC hardware,
> and IMHO from a developer's perspective not even a good thing), that's

Is it really so hard? ... ... ... I'll comment below.

> not the whole problem.  The framebuffer console initialization does a
> buffer clear and mode set, and that clobbers anything the bootloader
> might have left on the screen prematurely, before userspace is ready
> to throw up its own splash.  Splash screens may be a silly
> requirement, but they're still a requirement.

Ok. "quiet" option already leaves the display as is, including tests on it -
at least in VGA text mode case. Would it make sense to behave the same on
framebuffers you care about?

That patch could be quite accepteble, AFAICT. It does not add a new interface,
just makes framebuffers behave similar way to legacy vga.

And now... how to shut off the logging.

/sbin/init:
chvt 99
cat /share/splash > /dev/fb0
exec /sbin/init

...here you go. No flickering, no distro messages on the screen. You have
to display your splash from /sbin/init, but that should not be bad. Hmm?

> And the suspend console problem is likewise at work: ideally you'd
> like to know, for example, that the panel backlight is off before
> suspending.  But what happens in practice is that the kernel does a VT
> switch to/from console 63 and the backlight wakes up (I'm not going to
> pretend I have this bit completely figured out, but the problem is/was
> real and this patch fixed it by suppressing the console visibility).

I believe someone is already fixing this for suspend. rjw would know more.
Lets treat it as separate problem?

> But at the same time: all that other stuff doesn't quite meet the
> requirements (which in this case are basically "nothing happens
> visually between bootloader handoff and the surfaceflinger splash").
> What you get with that is something like what you get with desktop
> distros: you "mostly" never see the console, except when you do.

I don't know what surfaceflinger splash is; if you can display it from
init (as above) or very soon after that you should be fine.
								Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH v2] vt: add init_hide parameter to suppress boot output

[Greg Kroah-Hartman]

On Wed, Feb 20, 2013 at 02:08:25PM -0800, Andy Ross wrote:
> On 02/20/2013 12:57 PM, Pavel Machek wrote:
> >I'm sure something creative can be done with fake init that shuts
> >the console up then execs previous init. No need to add more kernel
> >knobs, I'd say.
> 
> Fair enough, but some last words:
> 
> That's argument is the "it's about logging" hypothesis again.  Even if
> it were possible to completely shut up console output (something
> that's awfully hard in the general case when running on PC hardware,
> and IMHO from a developer's perspective not even a good thing), that's
> not the whole problem.  The framebuffer console initialization does a
> buffer clear and mode set, and that clobbers anything the bootloader
> might have left on the screen prematurely, before userspace is ready
> to throw up its own splash.  Splash screens may be a silly
> requirement, but they're still a requirement.

Yes, they are a requirement in some situations, and if you look most
distros have already solved this issue for you, by not using a
framebuffer at all.  Why not just do the same thing in your Android
system as you do have full control over the hardware and the boot
process.

> And the suspend console problem is likewise at work: ideally you'd
> like to know, for example, that the panel backlight is off before
> suspending.  But what happens in practice is that the kernel does a VT
> switch to/from console 63 and the backlight wakes up (I'm not going to
> pretend I have this bit completely figured out, but the problem is/was
> real and this patch fixed it by suppressing the console visibility).

My systems don't drop down to the framebuffer when suspending, I think
you need to look at using a better distro :)

> Now, the point that an in-kernel console is "going away" and thus not
> worth augmenting with new APIs is valid.  And this is a small patch
> that's unlikely to be difficult to maintain in a custom tree.  And as
> we all agree there are other mechanisms that can be used here (even if
> AFAICT they don't completely solve the problem), and indeed I'd love
> to get surfaceflinger working with VT_ACTIVATE et. al. if I get a
> chance.  So I'm not going to cry if this isn't worth mainline.

I don't see why this is even needed for surfaceflinger systems, as
again, you have full control over the hardware and system so you don't
even need a framebuffer console at all.

thanks,

greg k-h

Re: [PATCH v2] vt: add init_hide parameter to suppress boot output

[Andy Ross]

I know I said the last words were my last, but this message and
Pavel's gave me some vain hope that I might be able to win this one on
the merits, so I'm trying again just to make the situation clear:

On 02/20/2013 05:12 PM, Greg Kroah-Hartman wrote:
> I don't see why this is even needed for surfaceflinger systems, as
> again, you have full control over the hardware and system so you
> don't even need a framebuffer console at all.

The application here is Android on PC hardware (see 01.org, which is
carrying this patch at the moment), so sadly we don't.  And we want
the framebuffer console anyway; having a console is a good thing.

> if you look most distros have already solved this issue for you,
> [...]  My systems don't drop down to the framebuffer when
> suspending, I think you need to look at using a better distro

That's sorta, kinda, completely incorrect. :)

Just to be sure, I tried again (on my Sony Vaio Z 1311 and an Acer
X700 table, both Ivy Bridge boxes with i915 graphics) with live iso's
for Fedora 18, openSUSE 12.2, and Ubuntu 12.10:

+ Every one of them includes the framebuffer console

+ Every one of them displays at least some console content at boot
   (Ubuntu gets the cookie here for showing only a blinking cursor and
   no actual text).

+ Every one of them displays console content at suspend time (openSUSE
   gets a lemon here for multiple lines of spam, Ubuntu again almost
   gets a pass here because all they have is a cursor unless you have
   manually Alt-Fn'd to a console to put something in the buffer).

+ Every one of them shows console content during shutdown.

It's not like these are ugly, awful glitches.  It's just quick flashes
of text, and I frankly wouldn't care.  But honestly: the level of
support right now for glitch-free boot and suspend (in the presence of
the framebuffer console) just isn't at the level of spit and polish
demanded by consumer devices.

I *assure* you, that if this were as simple as "do what the distros
do" that this patch wouldn't exist. (Seriously: probably half my job
right now consists of picking up an integration glitch and asking "Why
doesn't this happen on Fedora?").  It's a real problem, and has to be
solved with code.

So let me make the case for this particular solution one last time:

1. The framebuffer console is useful and we don't want to disable it.

2. Console *output* is useful.  That junk is helpful sometimes, and in
    any case auditing logging for a whole system is terribly difficult.
    IMHO the correct solution to "I don't want users to see this
    internal detail" is not "no one should ever see this internal
    detail".

3. Console output on the *screen* is the thing that's undesirable, and
    even then only if the user hasn't requested it.

4. There's already a predicate in the console subsystem
    (CON_IS_VISIBLE()) which does exactly what we want.  All this does
    is allow it to be forced false even for the default consoles at
    boot.  But if the user wants to see the output, she just changes to
    a console and it's right there for her (though right now
    surfaceflinger will still fight for the display because it doesn't
    speak the VT_ACTIVATE protocol, but that's a separate bug).

Andy

Re: [PATCH v3] vt: add init_hide parameter to suppress boot output

[Andy Ross]

When vt.init_hide is set, suppress output on newly created consoles
until an affirmative switch to that console.  This prevents boot
output from displaying (and clobbering splash screens, etc...) without
disabling the console entirely.

Signed-off-by: Andy Ross <andy.ross@windriver.com>
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
---
  Documentation/kernel-parameters.txt | 8 ++++++++
  drivers/tty/vt/vt.c                 | 7 +++++++
  include/linux/console_struct.h      | 3 ++-
  include/linux/vt.h                  | 2 ++
  kernel/power/console.c              | 2 --
  5 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 6c72381..56bd2be 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -3149,6 +3149,14 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
  			            them quite hard to use for exploits but
  			            might break your system.

+	vt.init_hide=	[VT] Hide initial console
+			Format: <bool> (0 = visible (default), 1 = invisible)
+			When set, the console will be invisible initially.
+			This prevents mode switches, buffer clears, and screen
+			display from the console code during boot.  Switching
+			to a console device at runtime using the VT_ACTIVATE
+			ioctl will make its contents visible.
+
  	vt.cur_default=	[VT] Default cursor shape.
  			Format: 0xCCBBAA, where AA, BB, and CC are the same as
  			the parameters of the <Esc>[?A;B;Cc escape sequence;
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 8fd8968..c68322c 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -165,6 +165,9 @@ module_param(global_cursor_default, int, S_IRUGO | S_IWUSR);
  static int cur_default = CUR_DEFAULT;
  module_param(cur_default, int, S_IRUGO | S_IWUSR);

+static bool init_hide;
+module_param(init_hide, bool, S_IRUGO);
+
  /*
   * ignore_poke: don't unblank the screen when things are typed.  This is
   * mainly for the privacy of braille terminal users.
@@ -734,6 +737,7 @@ static void visual_init(struct vc_data *vc, int num, int init)
  	__module_get(vc->vc_sw->owner);
  	vc->vc_num = num;
  	vc->vc_display_fg = &master_display_fg;
+	vc->vc_hidden = init_hide;
  	vc->vc_uni_pagedir_loc = &vc->vc_uni_pagedir;
  	vc->vc_uni_pagedir = 0;
  	vc->vc_hi_font_mask = 0;
@@ -2336,6 +2340,9 @@ static void console_callback(struct work_struct *ignored)
  	if (want_console >= 0) {
  		if (want_console != fg_console &&
  		    vc_cons_allocated(want_console)) {
+			if (want_console != SUSPEND_CONSOLE &&
+					fg_console != SUSPEND_CONSOLE)
+				vc_cons[want_console].d->vc_hidden = 0;
  			hide_cursor(vc_cons[fg_console].d);
  			change_console(vc_cons[want_console].d);
  			/* we only changed when the console had already
diff --git a/include/linux/console_struct.h b/include/linux/console_struct.h
index 7f0c329..fc96691 100644
--- a/include/linux/console_struct.h
+++ b/include/linux/console_struct.h
@@ -91,6 +91,7 @@ struct vc_data {
  	unsigned int	vc_can_do_color	: 1;
  	unsigned int	vc_report_mouse : 2;
  	unsigned char	vc_utf		: 1;	/* Unicode UTF-8 encoding */
+	unsigned int    vc_hidden	: 1;    /* Set by vt.init_hide */
  	unsigned char	vc_utf_count;
  		 int	vc_utf_char;
  	unsigned int	vc_tab_stop[8];		/* Tab stops. 256 columns. */
@@ -134,6 +135,6 @@ extern void vc_SAK(struct work_struct *work);

  #define CUR_DEFAULT CUR_UNDERLINE

-#define CON_IS_VISIBLE(conp) (*conp->vc_display_fg == conp)
+#define CON_IS_VISIBLE(conp) (*conp->vc_display_fg == conp && !conp->vc_hidden)

  #endif /* _LINUX_CONSOLE_STRUCT_H */
diff --git a/include/linux/vt.h b/include/linux/vt.h
index b186e04..0dc3e89 100644
--- a/include/linux/vt.h
+++ b/include/linux/vt.h
@@ -11,6 +11,8 @@
  #define VT_UPDATE		0x0004 /* A bigger update occurred */
  #define VT_PREWRITE		0x0005 /* A char is about to be written to the console */

+#define SUSPEND_CONSOLE	(MAX_NR_CONSOLES-1)
+
  #ifdef CONFIG_VT_CONSOLE

  extern int vt_kmsg_redirect(int new);
diff --git a/kernel/power/console.c b/kernel/power/console.c
index b1dc456..b74bdb8 100644
--- a/kernel/power/console.c
+++ b/kernel/power/console.c
@@ -10,8 +10,6 @@
  #include <linux/module.h>
  #include "power.h"

-#define SUSPEND_CONSOLE	(MAX_NR_CONSOLES-1)
-
  static int orig_fgconsole, orig_kmsg;

  int pm_prepare_console(void)
-- 
1.7.11.7