Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1606522 > unrolled thread

[PATCH linux-next] tty: Disable default console blanking interval

Back to article view | Back to linux.kernel

Contents

  [PATCH linux-next] tty: Disable default console blanking interval Tim Gardner <tim.gardner@canonical.com> - 2017-03-22 15:00 +0100
    Re: [PATCH linux-next] tty: Disable default console blanking interval "Austin S. Hemmelgarn" <ahferroin7@gmail.com> - 2017-03-22 15:20 +0100
    Re: [PATCH linux-next] tty: Disable default console blanking interval Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-03-22 16:00 +0100
    [PATCH linux-next V2] tty: Disable default console blanking interval Tim Gardner <tim.gardner@canonical.com> - 2017-03-22 16:10 +0100
      Re: [PATCH linux-next V2] tty: Disable default console blanking  interval Scot Doyle <lkml14@scotdoyle.com> - 2017-03-23 02:40 +0100
        Re: [PATCH linux-next V2] tty: Disable default console blanking  interval "Austin S. Hemmelgarn" <ahferroin7@gmail.com> - 2017-03-23 13:50 +0100
          Re: [PATCH linux-next V2] tty: Disable default console blanking  interval Scot Doyle <lkml14@scotdoyle.com> - 2017-03-24 03:30 +0100
    Re: [PATCH linux-next] tty: Disable default console blanking interval Adam Borowski <kilobyte@angband.pl> - 2017-03-23 03:10 +0100

#1606522 — [PATCH linux-next] tty: Disable default console blanking interval

BugLink: http://bugs.launchpad.net/bugs/869017

Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: Adam Borowski <kilobyte@angband.pl>
Cc: Scot Doyle <lkml14@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.

 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);
-- 
2.7.4

[toc] | [next] | [standalone]

#1606553

On 2017-03-22 09:50, Tim Gardner wrote:
> BugLink: http://bugs.launchpad.net/bugs/869017
>
> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Jiri Slaby <jslaby@suse.com>
> Cc: Adam Borowski <kilobyte@angband.pl>
> Cc: Scot Doyle <lkml14@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);
>

[toc] | [prev] | [next] | [standalone]

#1606621

On Wed, Mar 22, 2017 at 07:50:32AM -0600, Tim Gardner wrote:
> BugLink: http://bugs.launchpad.net/bugs/869017

I need more text than some random url in a changelog, sorry.  Please be
more descriptive, with enough information that if the link was not
there, it would be obvious why this was needed.

thanks,

greg k-h

[toc] | [prev] | [next] | [standalone]

#1606628 — [PATCH linux-next V2] tty: Disable default console blanking interval

BugLink: http://bugs.launchpad.net/bugs/869017

Console blanking is not enabling DPMS power saving (thereby negating any
power-saving benefit), and is simply turning the screen content blank. This
means that any crash output is invisible which is unhelpful on a server
(virtual or otherwise).

Furthermore, CRT burn in concerns should no longer govern the default case.
Affected users could always set consoleblank on the kernel command line.

Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: Adam Borowski <kilobyte@angband.pl>
Cc: Scot Doyle <lkml14@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.

V2 - expanded commit log with relevant context.

 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);
-- 
2.7.4

[toc] | [prev] | [next] | [standalone]

#1607115 — Re: [PATCH linux-next V2] tty: Disable default console blanking interval

On Wed, 22 Mar 2017, Tim Gardner wrote:
> BugLink: http://bugs.launchpad.net/bugs/869017
> 
> Console blanking is not enabling DPMS power saving (thereby negating any
> power-saving benefit), and is simply turning the screen content blank. This
> means that any crash output is invisible which is unhelpful on a server
> (virtual or otherwise).
> 
> Furthermore, CRT burn in concerns should no longer govern the default case.
> Affected users could always set consoleblank on the kernel command line.

Does screen blanking save some power by disabling the cursor blink?

[toc] | [prev] | [next] | [standalone]

#1607443 — Re: [PATCH linux-next V2] tty: Disable default console blanking interval

On 2017-03-22 21:32, Scot Doyle wrote:
> On Wed, 22 Mar 2017, Tim Gardner wrote:
>> BugLink: http://bugs.launchpad.net/bugs/869017
>>
>> Console blanking is not enabling DPMS power saving (thereby negating any
>> power-saving benefit), and is simply turning the screen content blank. This
>> means that any crash output is invisible which is unhelpful on a server
>> (virtual or otherwise).
>>
>> Furthermore, CRT burn in concerns should no longer govern the default case.
>> Affected users could always set consoleblank on the kernel command line.
>
> Does screen blanking save some power by disabling the cursor blink?
>
Unless you're dealing with ancient hardware, the difference in power 
usage is probably on the order of single digit micro-watts, which is not 
worth worrying about on almost anything you would expect to have a 
console display connected to.

[toc] | [prev] | [next] | [standalone]

#1608083 — Re: [PATCH linux-next V2] tty: Disable default console blanking interval

On Thu, 23 Mar 2017, Austin S. Hemmelgarn wrote:

> On 2017-03-22 21:32, Scot Doyle wrote:

> > On Wed, 22 Mar 2017, Tim Gardner wrote:
> > > BugLink: http://bugs.launchpad.net/bugs/869017
> > > 
> > > Console blanking is not enabling DPMS power saving (thereby negating any
> > > power-saving benefit), and is simply turning the screen content blank.
> > > This
> > > means that any crash output is invisible which is unhelpful on a server
> > > (virtual or otherwise).
> > > 
> > > Furthermore, CRT burn in concerns should no longer govern the default
> > > case.
> > > Affected users could always set consoleblank on the kernel command line.
> > 
> > Does screen blanking save some power by disabling the cursor blink?
> > 
> Unless you're dealing with ancient hardware, the difference in power usage is
> probably on the order of single digit micro-watts, which is not worth worrying
> about on almost anything you would expect to have a console display connected
> to.
> 

Here's a little more information.

powertop estimates fb_flashcursor consumes 24 to 28 milliwatts on a 
Haswell laptop with drm framebuffer console.

Since some commercial virtual machine providers include an emulated vga 
card, this table shows power usage estimates of a KVM-accelerated QEMU 
2.8.0 vm using QEMU's default vga card. The host and guest are Debian 
Stretch with kernel 4.9.6.

        QEMU    QEMU
        w/ SDL  with no
Minute  display display
------  ------- -------
0       1500mW  1540mW
        1310    76.1
        292     0.403
1       266     57.1
        320     58.4
        307     56.6
2       318     55.9
        268     57
        329     56.1
3       263     54.7
        264     55.7
        265     55.5
4       313     56.1
        341     55.2
        311     55.6
5       317     55.8
        340     57
        342     55.6
6       342     55.3
        278     54.9
        260     55.8
7       261     55.3
        260     55.2
        261     55
8       307     55.8
        262     55.3
        259     55.9
9       260     56.7
        337     55.8
        270     56.2
10      224     27.2
        222     27.2
        220     27.5
11      221     27.8
        220     27.3
        220     27.6
12      220     27.6
        219     27
        218     26.9
13      218     27.7
        217     26.9
        220     27.7
14      220     27.5
        221     27.4
        220     27.7
15      221     27.1
        221     27.8
        220     28.3
16      221     26.7
        220     27.5
        220     27.2
17      221     26.8
        221     27.1
        219     27.6
18      219     27.1
        218     26.8
        218     27.4
19      220     27.4
        218     27.4
        218     27.6
20      220     26.6

[toc] | [prev] | [next] | [standalone]

#1607119

On Wed, Mar 22, 2017 at 07:50:32AM -0600, Tim Gardner wrote:
> BugLink: http://bugs.launchpad.net/bugs/869017
> 
> 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.

I have no direct knowledge about screen burn-in, but a quick search shows
that, while not as prevalent as in the CRT days, it's still an issue:
https://en.wikipedia.org/wiki/Screen_burn-in
https://encrypted.google.com/search?hl=en&q=lcd%20screen%20burn-in

> -static int blankinterval = 10*60;
> +static int blankinterval;

Thus, the current default might be safer: an even all-black image will keep
the display readable as there won't be any localized artefacts.  On the
other hand, the photos I see are nowhere as bad as it was the case on CRTs,
so this reason might be dismissed.


There is another concern, though: light pollution.  A white image makes the
room bright enough to read by.  Don't laugh but 20 years ago in the dorm I
used to print \e[37;47;1m then 2000 'X'es to the screen to do things[1] (the
overhead light would wake up the roommates).  That was a CRT, LCDs are
brighter.  Obviously, lightgrey text on a black background producess less
light than all-white, but a regular monitor probably still gives off a total
amount of light similar to that of an all-white smartphone.

I'm not sure how many non-X screens are placed in rooms where someone tries
to sleep, but it's not something to ignore entirely.


I'm not arguing a hard "no", but you should at least think of the above two
concerns.


[1]. Not reading obviously, I am not _that_ insane. :þ
-- 
⢀⣴⠾⠻⢶⣦⠀ Meow!
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Collisions shmolisions, let's see them find a collision or second
⠈⠳⣄⠀⠀⠀⠀ preimage for double rot13!

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web