Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758706AbdLRUWE (ORCPT ); Mon, 18 Dec 2017 15:22:04 -0500 Received: from mail-wm0-f53.google.com ([74.125.82.53]:35943 "EHLO mail-wm0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752855AbdLRUWA (ORCPT ); Mon, 18 Dec 2017 15:22:00 -0500 X-Google-Smtp-Source: ACJfBougV5b18WA/KBxun2gvyKpFdzvEYa/oCzlKW1i0+3wKPZ/OQDWLFRj0y1s6/8OyW1n2qb3KBQ== Date: Mon, 18 Dec 2017 20:21:55 +0000 From: Daniel Thompson To: Doug Anderson Cc: Enric Balletbo Serra , Enric Balletbo i Serra , Jingoo Han , Richard Purdie , Jacek Anaszewski , Pavel Machek , Rob Herring , Brian Norris , Guenter Roeck , Lee Jones , Alexandru Stan , linux-leds@vger.kernel.org, "devicetree@vger.kernel.org" , linux-kernel Subject: Re: [RFC v2 2/2] backlight: pwm_bl: compute brightness of LED linearly to human eye. Message-ID: <20171218202155.wzefxazbjakd2dhh@oak.lan> References: <20171116141151.21171-1-enric.balletbo@collabora.com> <20171116141151.21171-3-enric.balletbo@collabora.com> <20171215145120.2d2o33tqlechp45h@oak.lan> <20171218133138.smvnucfm44bgmdpw@oak.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2228 Lines: 61 On Mon, Dec 18, 2017 at 08:46:09AM -0800, Doug Anderson wrote: > Hi, > > On Mon, Dec 18, 2017 at 5:31 AM, Daniel Thompson > wrote: > > I think two different values on the userspace side should always map to > > different values on the kernel side. > > This is what I thought originally, but I believe I've convinced myself > that this contradicts other goals and therefore needs to be relaxed. > Specifically: > > Goal #1: A linear adjustment in the number exposed to userspace should > result in a linear increase in human perceived brightness. > > Goal #2: Don't needlessly throw away precision available to the > hardware. For instance, if the hardware only supports 64, 128 or 256 > levels, it seems like a worthy goal to make sure that userspace can > access each of these brightness levels. > > > So if we accept that #1 and #2 are goals, I'm not sure that I accept goal #1 for highly constrained hardware that is physically capable only of a very few steps. I think adopting Goal #1 favours the slider use-case too much over the hot-key use case. If you linearise a tiny space then the hot-key risks doing nothing then pressed. It's not that I don't think this is a real problem but I think it is one that must be solved in the ABI (e.g. by communicating the typical curve to userspace and revealing true hardware steps). > the only solution is to > expose a larger "virtual" space and have more than one user-exposed > value map to the same actual brightness. As a very simple example, > let's say we have a backlight that allows 8 levels: > > 0 = black > 1 = 20% user brightness > 2 = 40% user brightness > 3 = 60% user brightness > 4 = 75% user brightness > 5 = 85% user brightness > 6 = 90% user brightness > 7 = 95% user brightness > 8 = 100% user brightness Note that these patches are for the PWM backlight; these steps seem unlikely even for an 8-bit PWM. That leads us to a difficult question. When presented with a low-bit PWM then are automatic curves the right tool? With such low steps we probably need to compromise linearity to some extent (and maybe the DT author may be forced to tune for slider versus hotkey depending on what our form-factor is). Daniel.