public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Andy Ross <andy.ross@windriver.com>
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 10:12:58 -0800	[thread overview]
Message-ID: <20130220181258.GC6679@kroah.com> (raw)
In-Reply-To: <5124FFD7.8070708@windriver.com>

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

  reply	other threads:[~2013-02-20 18:12 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
2013-02-20 18:12         ` Greg Kroah-Hartman [this message]
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=20130220181258.GC6679@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=andy.ross@windriver.com \
    --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