Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1753172AbdCWCHX (ORCPT <rfc822;w@1wt.eu>);
        Wed, 22 Mar 2017 22:07:23 -0400
Received: from tartarus.angband.pl ([89.206.35.136]:50478 "EHLO
        tartarus.angband.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751503AbdCWCHS (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 22 Mar 2017 22:07:18 -0400
Date: Thu, 23 Mar 2017 03:06:52 +0100
From: Adam Borowski <kilobyte@angband.pl>
To: Tim Gardner <tim.gardner@canonical.com>
Cc: linux-kernel@vger.kernel.org,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Jiri Slaby <jslaby@suse.com>, Scot Doyle <lkml14@scotdoyle.com>
Subject: Re: [PATCH linux-next] tty: Disable default console blanking interval
Message-ID: <20170323020652.vfqsk2of5g22wtwi@angband.pl>
References: <1490190632-10464-1-git-send-email-tim.gardner@canonical.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1490190632-10464-1-git-send-email-tim.gardner@canonical.com>
X-Junkbait: aaron@angband.pl, zzyx@angband.pl
User-Agent: NeoMutt/20170113 (1.7.2)
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: kilobyte@angband.pl
X-SA-Exim-Scanned: No (on tartarus.angband.pl); SAEximRunCond expanded to false
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1847
Lines: 43

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!