| Message ID | 1361289224-10678-1-git-send-email-kirill.shutemov@linux.intel.com (mailing list archive) |
|---|---|
| State | Rejected, archived |
| Headers | show |
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 -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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
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 -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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)