Messages in this thread | | | Date | Tue, 19 Feb 2013 20:45:06 -0800 | From | Greg Kroah-Hartman <> | Subject | Re: [PATCH v2] vt: add init_hide parameter to suppress boot output |
| |
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
| |