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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/