Re: [PATCH linux-next] tty: Disable default console blanking interval
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
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
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
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
On 2017-03-22 09:50, Tim Gardner wrote: BugLink: http://bugs.launchpad.net/bugs/869017 Signed-off-by: Tim GardnerCc: 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
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);