BugLink: http://bugs.launchpad.net/bugs/869017
Signed-off-by: Tim Gardner <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Jiri Slaby <[email protected]>
Cc: Adam Borowski <[email protected]>
Cc: Scot Doyle <[email protected]>
---
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
On 2017-03-22 09:50, Tim Gardner wrote:
> BugLink: http://bugs.launchpad.net/bugs/869017
>
> Signed-off-by: Tim Gardner <[email protected]>
> Cc: Greg Kroah-Hartman <[email protected]>
> Cc: Jiri Slaby <[email protected]>
> Cc: Adam Borowski <[email protected]>
> Cc: Scot Doyle <[email protected]>
> ---
>
> 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);
>
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
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 <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Jiri Slaby <[email protected]>
Cc: Adam Borowski <[email protected]>
Cc: Scot Doyle <[email protected]>
---
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
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?
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!
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.
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