From: Andy Ross <andy.ross@windriver.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Jiri Slaby <jslaby@suse.cz>, Pavel Machek <pavel@ucw.cz>,
"Rafael J. Wysocki" <rjw@sisk.pl>,
Len Brown <len.brown@intel.com>,
linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org
Subject: Re: [PATCH v2] vt: add init_hide parameter to suppress boot output
Date: Wed, 20 Feb 2013 08:54:47 -0800 [thread overview]
Message-ID: <5124FFD7.8070708@windriver.com> (raw)
In-Reply-To: <20130220044506.GA2728@kroah.com>
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
next prev parent reply other threads:[~2013-02-20 16:54 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-19 15:53 [PATCH v2] vt: add init_hide parameter to suppress boot output Kirill A. Shutemov
2013-02-20 1:45 ` Greg Kroah-Hartman
2013-02-20 4:04 ` Andy Ross
2013-02-20 4:45 ` Greg Kroah-Hartman
2013-02-20 16:54 ` Andy Ross [this message]
2013-02-20 18:12 ` Greg Kroah-Hartman
2013-02-20 20:57 ` Pavel Machek
2013-02-20 22:08 ` Andy Ross
2013-02-20 22:18 ` Pavel Machek
2013-02-21 1:12 ` Greg Kroah-Hartman
2013-02-21 17:01 ` Andy Ross
2013-02-20 17:57 ` [PATCH v3] " Andy Ross
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=5124FFD7.8070708@windriver.com \
--to=andy.ross@windriver.com \
--cc=gregkh@linuxfoundation.org \
--cc=jslaby@suse.cz \
--cc=kirill.shutemov@linux.intel.com \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=rjw@sisk.pl \
/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;
as well as URLs for NNTP newsgroup(s).