On 2017-03-22 09:50, Tim Gardner wrote:
BugLink: http://bugs.launchpad.net/bugs/869017
Signed-off-by: Tim Gardner <tim.gard...@canonical.com>
Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
Cc: Jiri Slaby <jsl...@suse.com>
Cc: Adam Borowski <kilob...@angband.pl>
Cc: Scot Doyle <lkm...@scotdoyle.com>
---
I'm not particularly knowledgable about console issues. Is a blaknking interval
relevant in a post CRT world ? The argument in the bug description seems
compelling.
Burn-in still happens on at least LCD screens (not sure about anything
else except DLP, where it doesn't happen unless it's a really crappy
display), but on many of those it happens regardless of the contents of
the display (I've actually got an old LCD display where the image is
constantly dark because of having displayed so many hours of a black
screen), but displaying a black screen instead of powering off the
display doesn't really save any power on most modern displays and the
fact that the screen isn't un-blanked when the kernel crashes is a
pretty compelling argument against having it enabled by default IMO.
drivers/tty/vt/vt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 5c4933b..9c99452 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -181,7 +181,7 @@ int console_blanked;
static int vesa_blank_mode; /* 0:none 1:suspendV 2:suspendH 3:powerdown */
static int vesa_off_interval;
-static int blankinterval = 10*60;
+static int blankinterval;
core_param(consoleblank, blankinterval, int, 0444);
static DECLARE_WORK(console_work, console_callback);