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

2017-03-22 Thread Adam Borowski
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=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!


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

2017-03-22 Thread Adam Borowski
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=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!


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

2017-03-22 Thread Greg Kroah-Hartman
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


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

2017-03-22 Thread Greg Kroah-Hartman
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


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

2017-03-22 Thread Austin S. Hemmelgarn

On 2017-03-22 09:50, Tim Gardner wrote:

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

Signed-off-by: Tim Gardner 
Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
Cc: Adam Borowski 
Cc: Scot Doyle 
---

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





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

2017-03-22 Thread Austin S. Hemmelgarn

On 2017-03-22 09:50, Tim Gardner wrote:

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

Signed-off-by: Tim Gardner 
Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
Cc: Adam Borowski 
Cc: Scot Doyle 
---

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