[{"id":1763216,"web_url":"http://patchwork.ozlabs.org/comment/1763216/","msgid":"<239c9153-c0ea-319c-b554-3c727b75c8cd@linaro.org>","list_archive_url":null,"date":"2017-09-05T11:05:45","subject":"Re: [RFC 0/2] backlight: pwm_bl: support linear brightness to human\n\teye","submitter":{"id":63942,"url":"http://patchwork.ozlabs.org/api/people/63942/","name":"Daniel Thompson","email":"daniel.thompson@linaro.org"},"content":"On 04/09/17 16:35, Enric Balletbo i Serra wrote:\n> Dear all,\n> \n> This patch series is a first RFC to know your opinion about implement\n> support to create brightness levels tables dinamically. I tried to argue\n> in every patch the specific reasons we think this can be interesting, to\n> sumup, the idea behind these patches is be able to pass via device tree\n> two parameters to the driver so it can calculate the brightness levels\n> based on the CIE 1931 lightness formula, which is what actually describes\n> how we perceive light.\n> \n> I think that at least the maths involved can be improved, and I've still\n> some doubts. With current code if you create a table with a max PWM\n> value of 255 and 127 steps, the first numbers are repeated so I'm thinking > that maybe we should skip/remove the repeated values. i.e. have a table\n> like this,\n> \n> [0, 1, 2, 3 ... 235, 240, 245, 250, 255]\n> \n> instead of\n> \n> [0, 0, 0, 1, 1, 1, 1, 2, 2, 2, 2, 2, 3 ... 235, 240, 245, 250, 255]\n> \n> Well, I know there are things to improve but lets see your feedback first\n> before dedicate more time on it. The patches were tested on a couple of\n> devices but I'll test on more devices meanwhile we discuss about it.\n\nI'm not fully decided on this one but my initial reaction isn't to \nquestion the concept so much as to ask why the number of levels should \ngo in the devicetree at all! We could just make brightness-levels \noptional and get the driver to pick sane curves by default.\n\nI'm sure we can debate what \"sane\" means for a couple of e-mails yet but \nin principle, given it knows the PWM max counter value, the driver \nshould be able to calculate the \"right\" number of steps too. If we have \nthat your core code remains but we don't have to complexify the device\n\n\nBasically we prefer X (?100 like some of the Intel DRM drivers do for \nconnector properties?) steps but we reduce the number of steps if the \nPWM is rather course and we can't get sufficiently different steps.\n\n\nI guess the summary of what I'm saying is that if we can \nprogrammatically derive brightness curves then the number of steps is \nnot really a property of the hardware and doesn't belong in devicetree.\n\n\nDaniel.\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=linaro.org header.i=@linaro.org\n\theader.b=\"b/KkKdc9\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xmkS716NWz9sPk\n\tfor ;\n\tTue, 5 Sep 2017 21:06:47 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1750989AbdIELFv (ORCPT\n\t);\n\tTue, 5 Sep 2017 07:05:51 -0400","from mail-wm0-f46.google.com ([74.125.82.46]:37540 \"EHLO\n\tmail-wm0-f46.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1750762AbdIELFt (ORCPT\n\t); Tue, 5 Sep 2017 07:05:49 -0400","by mail-wm0-f46.google.com with SMTP id u26so17467216wma.0\n\tfor ;\n\tTue, 05 Sep 2017 04:05:49 -0700 (PDT)","from [192.168.1.124]\n\t(cpc87211-aztw31-2-0-cust196.18-1.cable.virginm.net. [82.46.60.197])\n\tby smtp.googlemail.com with ESMTPSA id\n\tt200sm276742wme.34.2017.09.05.04.05.46\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tTue, 05 Sep 2017 04:05:47 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google;\n\th=subject:to:cc:references:from:message-id:date:user-agent\n\t:mime-version:in-reply-to:content-language:content-transfer-encoding; \n\tbh=/hMwUCrJVQYLehdNH7HVNKxRftNuGZHfx9beo3Nz/tc=;\n\tb=b/KkKdc9Hj3zM0JWVZN4fCqRTcuaaQErHOfi4/PANkkemGkx6zC+JLkp02sB1fJ+I1\n\tISNQyMJ9rvy4LKqX2loeOhqx8h4JbdMvLyJrtW04ZWDsWN8VRPnRs8ETKv9u3TudWQNJ\n\tGDJv8IxSwY0F6mb3Pqm5A7Uir0S0bXwNjzOP8=","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:subject:to:cc:references:from:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-language\n\t:content-transfer-encoding;\n\tbh=/hMwUCrJVQYLehdNH7HVNKxRftNuGZHfx9beo3Nz/tc=;\n\tb=tG5FmSCx/xYQoCjM/HCsRI8Ni/cvbHV9OMf9qnujbDF2/Td5Sx4GbC5ENRHm/kAO0g\n\tYe66pT9jqBQaPowhwGXbwTFLGkeU4ASyZo4/x7Xu8jS2EAt024jw9a516Cq4W7J4RGc5\n\tcQrqfy5osdcT2czyh7KVIlv9ZRpteW4yQ1F/vzxYcHtJaKznjMkGdVEkaP4Vzdp/bolu\n\ttpvOPNCXZhB/CAFwIa4xFJoAMuZ8yxPwzoz0xz5n6ISqllN5ccGkaPLISFKuyykEHCso\n\t+x7t0JXv9GXx2sRcj6mZGcFJ96eXUQntnBiMVPIk9XsIhi3uJmiDnHBOd4tlQ+PwJH2v\n\tocJw==","X-Gm-Message-State":"AHPjjUjGQ2vwoeFh+baFgShW03zZ1Q+9Gd7ooM+5Vg+3ikETVzbwJ+uo\n\thDqgQwsqUtx+k/ejvZs7xg==","X-Google-Smtp-Source":"ADKCNb6uHlclsOcjVp+laOlhEDfblpSwtOM0teBJpmDxoT24h7U8USjXMjECrzp/c3xvrzhPp0vb6A==","X-Received":"by 10.28.74.74 with SMTP id x71mr2402337wma.94.1504609548403;\n\tTue, 05 Sep 2017 04:05:48 -0700 (PDT)","Subject":"Re: [RFC 0/2] backlight: pwm_bl: support linear brightness to human\n\teye","To":"Enric Balletbo i Serra ,\n\tLee Jones , Jingoo Han , \n\tRichard Purdie ,\n\tJacek Anaszewski ,\n\tPavel Machek , Rob Herring ,\n\tMark Rutland ,\n\tDoug Anderson , \n\tBrian Norris , Guenter Roeck ","Cc":"linux-leds@vger.kernel.org, devicetree@vger.kernel.org,\n\tlinux-kernel@vger.kernel.org","References":"<20170904153504.27963-1-enric.balletbo@collabora.com>","From":"Daniel Thompson ","Message-ID":"<239c9153-c0ea-319c-b554-3c727b75c8cd@linaro.org>","Date":"Tue, 5 Sep 2017 12:05:45 +0100","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"<20170904153504.27963-1-enric.balletbo@collabora.com>","Content-Type":"text/plain; charset=utf-8; format=flowed","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1763221,"web_url":"http://patchwork.ozlabs.org/comment/1763221/","msgid":"","list_archive_url":null,"date":"2017-09-05T11:09:20","subject":"Re: [RFC 0/2] backlight: pwm_bl: support linear brightness to human\n\teye","submitter":{"id":63942,"url":"http://patchwork.ozlabs.org/api/people/63942/","name":"Daniel Thompson","email":"daniel.thompson@linaro.org"},"content":"On 05/09/17 12:05, Daniel Thompson wrote:\n> On 04/09/17 16:35, Enric Balletbo i Serra wrote:\n>> Dear all,\n>>\n>> This patch series is a first RFC to know your opinion about implement\n>> support to create brightness levels tables dinamically. I tried to argue\n>> in every patch the specific reasons we think this can be interesting, to\n>> sumup, the idea behind these patches is be able to pass via device tree\n>> two parameters to the driver so it can calculate the brightness levels\n>> based on the CIE 1931 lightness formula, which is what actually describes\n>> how we perceive light.\n>>\n>> I think that at least the maths involved can be improved, and I've still\n>> some doubts. With current code if you create a table with a max PWM\n>> value of 255 and 127 steps, the first numbers are repeated so I'm \n>> thinking > that maybe we should skip/remove the repeated values. i.e. \n>> have a table\n>> like this,\n>>\n>> [0, 1, 2, 3 ... 235, 240, 245, 250, 255]\n>>\n>> instead of\n>>\n>> [0, 0, 0, 1, 1, 1, 1, 2, 2, 2, 2, 2, 3 ... 235, 240, 245, 250, 255]\n>>\n>> Well, I know there are things to improve but lets see your feedback first\n>> before dedicate more time on it. The patches were tested on a couple of\n>> devices but I'll test on more devices meanwhile we discuss about it.\n> \n> I'm not fully decided on this one but my initial reaction isn't to \n> question the concept so much as to ask why the number of levels should \n> go in the devicetree at all! We could just make brightness-levels \n> optional and get the driver to pick sane curves by default.\n> \n> I'm sure we can debate what \"sane\" means for a couple of e-mails yet but \n> in principle, given it knows the PWM max counter value, the driver \n> should be able to calculate the \"right\" number of steps too. If we have \n> that your core code remains but we don't have to complexify the device\n\n... tree\n\nSorry. ;-)\n\n\nDaniel.\n\n\n> \n> \n> Basically we prefer X (?100 like some of the Intel DRM drivers do for \n> connector properties?) steps but we reduce the number of steps if the \n> PWM is rather course and we can't get sufficiently different steps.\n> \n> \n> I guess the summary of what I'm saying is that if we can \n> programmatically derive brightness curves then the number of steps is \n> not really a property of the hardware and doesn't belong in devicetree.\n> \n> \n> Daniel.\n\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=linaro.org header.i=@linaro.org\n\theader.b=\"YzVbb/qY\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xmkWY5Wp5z9sPk\n\tfor ;\n\tTue, 5 Sep 2017 21:09:45 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751296AbdIELJ3 (ORCPT\n\t);\n\tTue, 5 Sep 2017 07:09:29 -0400","from mail-wm0-f41.google.com ([74.125.82.41]:35467 \"EHLO\n\tmail-wm0-f41.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751578AbdIELJX (ORCPT\n\t); Tue, 5 Sep 2017 07:09:23 -0400","by mail-wm0-f41.google.com with SMTP id h144so3692911wme.0\n\tfor ;\n\tTue, 05 Sep 2017 04:09:23 -0700 (PDT)","from [192.168.1.124]\n\t(cpc87211-aztw31-2-0-cust196.18-1.cable.virginm.net. [82.46.60.197])\n\tby smtp.googlemail.com with ESMTPSA id\n\tl19sm325231wrl.47.2017.09.05.04.09.20\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tTue, 05 Sep 2017 04:09:21 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google;\n\th=subject:from:to:cc:references:message-id:date:user-agent\n\t:mime-version:in-reply-to:content-language:content-transfer-encoding; \n\tbh=uwbjI0Yqkr0lsr4WRD1JlHKg/x2hSrhWVPNofrtGkcw=;\n\tb=YzVbb/qYHo36iNkxmni6pwih2gMIkTmrukTHSc8gYYxGrv4JQ8kAF6cBja/Sifcj75\n\tAdz3fB0gukJfJwaOqRSuFp7u9MQJszfhxIqMXo1OXD2mM+nziTJihmRYLzz8mVmBRdM3\n\tuq5SyImCZg3ktO1jGN4OtLmDw8gx2MB6UCdLM=","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:subject:from:to:cc:references:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-language\n\t:content-transfer-encoding;\n\tbh=uwbjI0Yqkr0lsr4WRD1JlHKg/x2hSrhWVPNofrtGkcw=;\n\tb=Ywyu15rbqa5I8hTJwijYatFWpJMM0eCg9wqkb1QFT8x9dXW/WyXt6j/1DfbcOy8yme\n\t5VtQGqwJIo8YDAjisKJeZjiazCWxuYrqEdv/2ttLXbrrkoJoMRps7FfsUtYydGsARNSh\n\tGFx38GwmM0kL1m/2fyz6OlkQqVywKA01YEI0NkxrbSQXUCEfV5f+tmLTg++ycNrwPNFf\n\tbvLuguDfd94QJ4FZtFF1ep0yfxT+7z2vSZCd623i2/mW5Sb8+H9AzfK4w7ngPXU6n0Ot\n\t4XNtCNBh3VnQRCdeyWpGstUVZZv+m/pmz/UErMb/1R/AyBob7vE6phXQdSyuLQ54DJrC\n\tXUiA==","X-Gm-Message-State":"AHPjjUgT0xxKBsAX+2JcfbsiDwaAoTXk0+aplBkqE5Rs8MmNwTSeDq/h\n\tQwMEwtxFBuncd09R","X-Google-Smtp-Source":"ADKCNb5BLfc4mBRTCfDKpDSgrJcO0QC3a3LoGK5uUDVh87eVRzqS7pXMdhiTycME9nb4nWNGyTN6HA==","X-Received":"by 10.28.211.77 with SMTP id k74mr1305171wmg.147.1504609762464; \n\tTue, 05 Sep 2017 04:09:22 -0700 (PDT)","Subject":"Re: [RFC 0/2] backlight: pwm_bl: support linear brightness to human\n\teye","From":"Daniel Thompson ","To":"Enric Balletbo i Serra ,\n\tLee Jones , Jingoo Han , \n\tRichard Purdie ,\n\tJacek Anaszewski ,\n\tPavel Machek , Rob Herring ,\n\tMark Rutland ,\n\tDoug Anderson , \n\tBrian Norris , Guenter Roeck ","Cc":"linux-leds@vger.kernel.org, devicetree@vger.kernel.org,\n\tlinux-kernel@vger.kernel.org","References":"<20170904153504.27963-1-enric.balletbo@collabora.com>\n\t<239c9153-c0ea-319c-b554-3c727b75c8cd@linaro.org>","Message-ID":"","Date":"Tue, 5 Sep 2017 12:09:20 +0100","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"<239c9153-c0ea-319c-b554-3c727b75c8cd@linaro.org>","Content-Type":"text/plain; charset=utf-8; format=flowed","Content-Language":"en-US","Content-Transfer-Encoding":"8bit","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1763494,"web_url":"http://patchwork.ozlabs.org/comment/1763494/","msgid":"<000001d32664$db62b2a0$922817e0$@gmail.com>","list_archive_url":null,"date":"2017-09-05T16:34:33","subject":"Re: [RFC 0/2] backlight: pwm_bl: support linear brightness to human\n\teye","submitter":{"id":66657,"url":"http://patchwork.ozlabs.org/api/people/66657/","name":"Han Jingoo","email":"jingoohan1@gmail.com"},"content":"On Tuesday, September 5, 2017 7:06 AM, Daniel Thompson wrote:\n> \n> On 04/09/17 16:35, Enric Balletbo i Serra wrote:\n> > Dear all,\n> >\n> > This patch series is a first RFC to know your opinion about implement\n> > support to create brightness levels tables dinamically. I tried to argue\n> > in every patch the specific reasons we think this can be interesting, to\n> > sumup, the idea behind these patches is be able to pass via device tree\n> > two parameters to the driver so it can calculate the brightness levels\n> > based on the CIE 1931 lightness formula, which is what actually\n> describes\n> > how we perceive light.\n> >\n> > I think that at least the maths involved can be improved, and I've still\n> > some doubts. With current code if you create a table with a max PWM\n> > value of 255 and 127 steps, the first numbers are repeated so I'm\n> thinking > that maybe we should skip/remove the repeated values. i.e. have\n> a table\n> > like this,\n> >\n> > [0, 1, 2, 3 ... 235, 240, 245, 250, 255]\n> >\n> > instead of\n> >\n> > [0, 0, 0, 1, 1, 1, 1, 2, 2, 2, 2, 2, 3 ... 235, 240, 245, 250, 255]\n> >\n> > Well, I know there are things to improve but lets see your feedback\n> first\n> > before dedicate more time on it. The patches were tested on a couple of\n> > devices but I'll test on more devices meanwhile we discuss about it.\n> \n> I'm not fully decided on this one but my initial reaction isn't to\n> question the concept so much as to ask why the number of levels should\n> go in the devicetree at all! We could just make brightness-levels\n> optional and get the driver to pick sane curves by default.\n> \n> I'm sure we can debate what \"sane\" means for a couple of e-mails yet but\n> in principle, given it knows the PWM max counter value, the driver\n> should be able to calculate the \"right\" number of steps too. If we have\n> that your core code remains but we don't have to complexify the device\n> \n> \n> Basically we prefer X (?100 like some of the Intel DRM drivers do for\n> connector properties?) steps but we reduce the number of steps if the\n> PWM is rather course and we can't get sufficiently different steps.\n> \n> \n> I guess the summary of what I'm saying is that if we can\n> programmatically derive brightness curves then the number of steps is\n> not really a property of the hardware and doesn't belong in devicetree.\n\nYep, I agree with Daniel's opinion. I cannot find the reason\nthis feature can be added to the device tree.\n\nIn my opinion, this feature can be handled by upper user level layer,\nnot backlight framework level. However, we can discuss this topic to\nfind how to handle it.\n\nBest regards,\nJingoo Han\n\n> \n> \n> Daniel.\n\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"UqKHcLh3\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xmskR1l6Rz9sD9\n\tfor ;\n\tWed, 6 Sep 2017 02:34:39 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751959AbdIEQeh (ORCPT\n\t);\n\tTue, 5 Sep 2017 12:34:37 -0400","from mail-qt0-f171.google.com ([209.85.216.171]:38870 \"EHLO\n\tmail-qt0-f171.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751863AbdIEQeg (ORCPT\n\t); Tue, 5 Sep 2017 12:34:36 -0400","by mail-qt0-f171.google.com with SMTP id q8so9089104qtb.5;\n\tTue, 05 Sep 2017 09:34:35 -0700 (PDT)","from DESKTOP3JAHB13 ([2001:468:c80:4311:5808:185:6d1f:d664])\n\tby smtp.gmail.com with ESMTPSA id\n\tk2sm644045qtk.53.2017.09.05.09.34.33\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tTue, 05 Sep 2017 09:34:34 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=from:to:cc:references:in-reply-to:subject:date:message-id\n\t:mime-version:content-transfer-encoding:thread-index\n\t:content-language;\n\tbh=ftnSE05H9pexnxo96nEO5nuTUiyY0RTlFSf7Ih5zTpk=;\n\tb=UqKHcLh3+3nsKEo3mJ3AdbbK8FEgyy/bnIDPwXs+89TC46R+NrI7h8tbjk9t87Wjfe\n\t6yLB9kQlJOiptjqwyvjSf4upKco/5BbrcmOauZ1x/kY+oh7qBx6mfiPHkzarJvkZ8CZ7\n\tjKnT50BXa7kq+JfjwxkDxCSKM9ufZ3DrsdNwVuCpSs3+vldUx++Qy6Hxg6JOztg+tZ7A\n\tb80goPBQsWPOxU7dfM5x/tx+WO8UVegQVrOhDg7i82Ihscvw/UwceCR2kPnMxyZc8hhV\n\tNcZhlhtFM110CI0s+ByW4arIBORdzk8AojyaoybtS9l3k8ecdwCHgeM2EeqCMZn+RlvN\n\ti3fw==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date\n\t:message-id:mime-version:content-transfer-encoding:thread-index\n\t:content-language;\n\tbh=ftnSE05H9pexnxo96nEO5nuTUiyY0RTlFSf7Ih5zTpk=;\n\tb=XOtIOd4A2IKBtwrhutkyMQcRC+q+qBYJk0Ck/pUuIEdxobR6menwLlpNxYVT2vZq1D\n\tKLfzWoxDcbMunV4GlhCZOCATbwvmWb7/u/sH1J3/3m7C6BczcFxRe58Su7vAZI9KLvFp\n\thmVqnhcb58W26xdWHN8vgMMKBVTTxE8wmum5pyupfV5sif7i5th7AnX7/ClPRPv91qCK\n\tA4Tt7HATC391muJegkUlWdgvq0WJMfCkt7xL3ajNtuP9g6Jjhx0yld+PozKL1Cns9+Fw\n\tl2UHn3G6LdCR5RGpfdOmo3ZbPOlboXIFGlWl4Y9Uy82FnlOJ2HaYzPvBZiorEOROE3GN\n\tFl1A==","X-Gm-Message-State":"AHPjjUg6moaVdeaNyMUKuFYNEvTGegfKWpMenKNzJGQvTIg0+eazy+XT\n\thLht3vfQY/1TvA==","X-Google-Smtp-Source":"ADKCNb4evhaJWu6eYtTbRBsASNbmpd7twlWSSWz3vLUtm5ne9ccOw5WuQ6ZY4Y2Fs4poD3iVoBbWQw==","X-Received":"by 10.200.15.8 with SMTP id e8mr6010902qtk.315.1504629275409;\n\tTue, 05 Sep 2017 09:34:35 -0700 (PDT)","From":"\"Jingoo Han\" ","To":"\"'Daniel Thompson'\" ,\n\t\"'Enric Balletbo i Serra'\" ,\n\t\"'Lee Jones'\" ,\n\t\"'Richard Purdie'\" ,\n\t\"'Jacek Anaszewski'\" ,\n\t\"'Pavel Machek'\" , \"'Rob Herring'\" ,\n\t\"'Mark Rutland'\" ,\n\t\"'Doug Anderson'\" ,\n\t\"'Brian Norris'\" ,\n\t\"'Guenter Roeck'\" ","Cc":", ,\n\t","References":"<20170904153504.27963-1-enric.balletbo@collabora.com>\n\t<239c9153-c0ea-319c-b554-3c727b75c8cd@linaro.org>","In-Reply-To":"<239c9153-c0ea-319c-b554-3c727b75c8cd@linaro.org>","Subject":"Re: [RFC 0/2] backlight: pwm_bl: support linear brightness to human\n\teye","Date":"Tue, 5 Sep 2017 12:34:33 -0400","Message-ID":"<000001d32664$db62b2a0$922817e0$@gmail.com>","MIME-Version":"1.0","Content-Type":"text/plain;\n charset=\"utf-8\"","Content-Transfer-Encoding":"7bit","X-Mailer":"Microsoft Outlook 16.0","Thread-Index":"AQGBNB8QYjyAmr7JGaiewwnzDxxFEgJ84ig7ozZ5mNA=","Content-Language":"en-us","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1764870,"web_url":"http://patchwork.ozlabs.org/comment/1764870/","msgid":"","list_archive_url":null,"date":"2017-09-07T18:04:22","subject":"Re: [RFC 0/2] backlight: pwm_bl: support linear brightness to human\n\teye","submitter":{"id":11501,"url":"http://patchwork.ozlabs.org/api/people/11501/","name":"Doug Anderson","email":"dianders@google.com"},"content":"Hi,\n\nOn Tue, Sep 5, 2017 at 9:34 AM, Jingoo Han wrote:\n> On Tuesday, September 5, 2017 7:06 AM, Daniel Thompson wrote:\n>>\n>> On 04/09/17 16:35, Enric Balletbo i Serra wrote:\n>> > Dear all,\n>> >\n>> > This patch series is a first RFC to know your opinion about implement\n>> > support to create brightness levels tables dinamically. I tried to argue\n>> > in every patch the specific reasons we think this can be interesting, to\n>> > sumup, the idea behind these patches is be able to pass via device tree\n>> > two parameters to the driver so it can calculate the brightness levels\n>> > based on the CIE 1931 lightness formula, which is what actually\n>> describes\n>> > how we perceive light.\n>> >\n>> > I think that at least the maths involved can be improved, and I've still\n>> > some doubts. With current code if you create a table with a max PWM\n>> > value of 255 and 127 steps, the first numbers are repeated so I'm\n>> thinking > that maybe we should skip/remove the repeated values. i.e. have\n>> a table\n>> > like this,\n>> >\n>> > [0, 1, 2, 3 ... 235, 240, 245, 250, 255]\n>> >\n>> > instead of\n>> >\n>> > [0, 0, 0, 1, 1, 1, 1, 2, 2, 2, 2, 2, 3 ... 235, 240, 245, 250, 255]\n>> >\n>> > Well, I know there are things to improve but lets see your feedback\n>> first\n>> > before dedicate more time on it. The patches were tested on a couple of\n>> > devices but I'll test on more devices meanwhile we discuss about it.\n>>\n>> I'm not fully decided on this one but my initial reaction isn't to\n>> question the concept so much as to ask why the number of levels should\n>> go in the devicetree at all! We could just make brightness-levels\n>> optional and get the driver to pick sane curves by default.\n>>\n>> I'm sure we can debate what \"sane\" means for a couple of e-mails yet but\n>> in principle, given it knows the PWM max counter value, the driver\n>> should be able to calculate the \"right\" number of steps too. If we have\n>> that your core code remains but we don't have to complexify the device\n>>\n>> \n>> Basically we prefer X (?100 like some of the Intel DRM drivers do for\n>> connector properties?) steps but we reduce the number of steps if the\n>> PWM is rather course and we can't get sufficiently different steps.\n>> \n>>\n>> I guess the summary of what I'm saying is that if we can\n>> programmatically derive brightness curves then the number of steps is\n>> not really a property of the hardware and doesn't belong in devicetree.\n>\n> Yep, I agree with Daniel's opinion. I cannot find the reason\n> this feature can be added to the device tree.\n>\n> In my opinion, this feature can be handled by upper user level layer,\n> not backlight framework level. However, we can discuss this topic to\n> find how to handle it.\n\nWarning ahead of time: I'm not an expert. If something I'm saying is\nblatantly wrong (or even a little wrong), please correct me.\n\n--\n\nI'd agree that I don't think we should land Enric's series as-is.\n...but I think something has been missing from the discussion so far:\nthe fact that the backlight driver doesn't necessarily increase light\noutput (in Watts) linearly in response to a linear increase in PWM\nduty cycle.\n\nI think that we can all agree that the end result is to be able to\nhave a backlight that is easy to scale linearly with the human\nperception of brightness (aka in Lumens). Right? So how do we get\nthere?\n\nFor PWM backlight, there are two inputs to the system:\n\n1. PWM Frequency\n\n2. PWM Duty Cycle\n\nI think we all know that in (almost?) all cases scaling PWM Duty Cycle\nlinearly doesn't result in a linear increase of perceived brightness\nin Lumens.\n\n\nSo far in these discussions folks have been assuming that if we just\napply cie1931 to the PWM Duty Cycle then we're done and we have\nperceived brightness in Lumens. ...but I think that's not quite\nright. There are more factors. Let's use the datasheet for a random\nbacklight driver, like RT8561A. There appears to be a public\ndatasheet at .\n\nA) There may be a non-linear curve between PWM Duty Cycle and LED\nCurrent (mA). The particular curve is different based on mode\n(Digital Ctrl vs. Analog Ctrl) and also PWM Frequency. Sometimes this\ncurve is nearly linear for large parts of the curve but not the whole\ncurve. Sometimes even though the curve is nearly linear there is an\noffset (AKA 10% duty cycle could still produce nearly zero light\noutput).\n\nB) There may be a non-linear curve between LED current and light\noutput in Watts (I think?).\n\nC) The human perception model means there is a non-linear curve\nbetween light output in Watts and human perceived brightness in\nLumens.\n\n\nSo A and B are hardware dependent and _do_ belong in the device tree (IMHO).\n\n\n...then the question is whether the device tree should specify the\ncurve so that the Watts scales linearly (and then the kernel adjust\nfor human perception) or so that Lumens scales linearly (which is\nalready adjusted for human perception).\n\nHistorically I believe the device tree has always wanted it so that\nLumens scales linearly. So I guess the \"we don't do anything\" answer\nis that the device tree should help account for for A + B + C.\n\n\nIf someone can show that it's useful (for some reason) to specify \"A +\nB\" and have the cie1931 transformation happen in the kernel then we\ncan look at that. I don't personally know if this is a savings or\nnot. It depends on whether \"A + B\" is somehow easier to find (from\ndatasheets?) or is somehow more likely to be more linear.\n\n--\n\nSo you could say: the current device tree already says that we want to\ndefine a table that accounts for A + B + C, so why do we need to do\nanything?\n\n...we need to do something because currently the only way to specify\nthe curve in the device tree is to specify every single point in the\ncurve. Then you're only allows to set the backlight to one of those\nexact points. That's bad because:\n\n1. Specifying every point is a big waste of space. Specifying 256\npoints in the device tree wastes 1K.\n\n2. Ideally you'd want to specify more than 256 points. If you bump a\nbacklight up by 1 / 256 you can notice it and it seems jerky. If you\nchange the software to instead do 16 increases each by 1 / 4096 then\nit is a much smoother transition. ...but specifying 4096 points in\nthe device tree would waste 16 K (!).\n\n\n...one proposal to fix this is to add some way to specify\npiecewise-linear in the device tree. Using piecewise linear you can\nspecify a nearly arbitrary curve with not too many points. The idea\nhere is that you're not limiting yourself to only selecting the points\non the curve.\n\nHopefully Enric can try prototyping this up...\n\n--\n\nOne last note is that it would be nice to find some way to make it\neasier for people to get this right. I will take responsibility and\nadmit that I've been involved in device trees that just specified a\nlinear curve from 1 to 256. That's not quite right, but it's never\nbeen terribly easy to measure the correct curve (and never super\ncritical). On Chrome OS (where I've been working) historically I\nbelieve that the cie1931 transformation has historically happened in\nuserspace, so effectively above I've asserted that \"A + B\" was linear\nenough and then we've done \"C\" programmatically.\n\nI'm not saying what we've done in the past is terribly correct, but I\nam saying that we should definitely take into account making this very\neasy for people to get right. Possibly this could be as simple as\ndocumenting a good / cheap light meter and how exactly to generate a\ntable...\n\n\n-Doug\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=google.com header.i=@google.com\n\theader.b=\"D+xj/+sr\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xp7d82Wp0z9t2R\n\tfor ;\n\tFri, 8 Sep 2017 04:04:28 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1754601AbdIGSE0 (ORCPT\n\t);\n\tThu, 7 Sep 2017 14:04:26 -0400","from mail-wm0-f42.google.com ([74.125.82.42]:36182 \"EHLO\n\tmail-wm0-f42.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751634AbdIGSEZ (ORCPT\n\t); Thu, 7 Sep 2017 14:04:25 -0400","by mail-wm0-f42.google.com with SMTP id i189so1408470wmf.1\n\tfor ;\n\tThu, 07 Sep 2017 11:04:24 -0700 (PDT)","by 10.28.27.194 with HTTP; Thu, 7 Sep 2017 11:04:22 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;\n\ts=20161025; \n\th=mime-version:in-reply-to:references:from:date:message-id:subject:to\n\t:cc; bh=yItGGD2NL1m/RLJPCijVN5/2Dh3/+zlfmRvL6HW54ME=;\n\tb=D+xj/+sr6EO7xm87zBM6t9YaT2Lofy2mqqx+77RZ2WuarMKLbDePhOOwQ85SvyUkga\n\t4KRpe+24GO9AG6J6dnVc/Yc0KqYeQWajVMNhn+mU4DCk+kjLqzn+zsCbwL+X+Foy0lxn\n\tCQE0nEA7dDH8QZ6lod6DeU3KBRbDvNdYAiceE4LqwvwFC24JFA7JBtv6+xn2Rm5REJBP\n\tMKsp34YsLEGmWliSXhi0kOwdDaYoNIv703DOWT++LHGYf+cg6GfG8YbkRA1tIZvqIE+6\n\tr7cGLOQtKFDaAv5TC7b9qu7SaugsYJO44ut4yFZoi0l96HplPKZtfjYLD7IyjQrGbfAc\n\tTvyw==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc;\n\tbh=yItGGD2NL1m/RLJPCijVN5/2Dh3/+zlfmRvL6HW54ME=;\n\tb=EjMSF6Qbkdc0qx+DxVzme+a71ay4VKKkKsxuM6wtP7xNvqvyX3LJTpHPU686KBdkdx\n\tjq09Q2sSRHwG9Sm2zJ6N6gTwCyPvVDjGVBnmQswHoyXrkCMXyH7Evt7QrI72m47NuT08\n\tbOSQ2zFt+G7IWgrwyPC7DDIoBO/W0qFB1pTtHSkueMM1QFCPArsQiyvsI5MyfOZHskYA\n\tDInoqHh4QNzBE2wKxGto/x7c9uVPO+dSEgQczrG6n79OA9KO6gXpRl0FFGgwz+66g0/R\n\t2ZLhP7/UJ9KYXFGQuhRtbnb+i2xekXJ16Ky76zpCCFXBg8E475o8fEEGax2zZiOFXxDq\n\t72Dw==","X-Gm-Message-State":"AHPjjUhI7mPYch+ngyArrpWguTmGJM0pz6DeNEUEQXisSLezSOP/pnfJ\n\tQpbmck886jDT2x3SkbvvflB4WQ+DfypCJSZ1ccN9Fw==","X-Google-Smtp-Source":"AOwi7QBGUTtQkM+0OvSzULb5omtr+r5rgpnBcWuhqax/E7KqxykOr4v9U20chT+crn2ZCXxs8R9/k26iu7St9LNRuds=","X-Received":"by 10.28.61.134 with SMTP id k128mr101174wma.48.1504807463507;\n\tThu, 07 Sep 2017 11:04:23 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"<000001d32664$db62b2a0$922817e0$@gmail.com>","References":"<20170904153504.27963-1-enric.balletbo@collabora.com>\n\t<239c9153-c0ea-319c-b554-3c727b75c8cd@linaro.org>\n\t<000001d32664$db62b2a0$922817e0$@gmail.com>","From":"Doug Anderson ","Date":"Thu, 7 Sep 2017 11:04:22 -0700","Message-ID":"","Subject":"Re: [RFC 0/2] backlight: pwm_bl: support linear brightness to human\n\teye","To":"Jingoo Han ","Cc":"Daniel Thompson ,\n\tEnric Balletbo i Serra ,\n\tLee Jones , Richard Purdie , \n\tJacek Anaszewski ,\n\tPavel Machek , Rob Herring ,\n\tMark Rutland ,\n\tBrian Norris , \n\tGuenter Roeck , linux-leds@vger.kernel.org,\n\t\"devicetree@vger.kernel.org\" ,\n\t\"linux-kernel@vger.kernel.org\" ,\n\tAlexandru M Stan ","Content-Type":"text/plain; charset=\"UTF-8\"","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1765253,"web_url":"http://patchwork.ozlabs.org/comment/1765253/","msgid":"","list_archive_url":null,"date":"2017-09-08T11:18:42","subject":"Re: [RFC 0/2] backlight: pwm_bl: support linear brightness to human\n\teye","submitter":{"id":63942,"url":"http://patchwork.ozlabs.org/api/people/63942/","name":"Daniel Thompson","email":"daniel.thompson@linaro.org"},"content":"On 07/09/17 19:04, Doug Anderson wrote:\n > I'd agree that I don't think we should land Enric's series as-is.\n > ...but I think something has been missing from the discussion so far:\n > the fact that the backlight driver doesn't necessarily increase light\n > output (in Watts) linearly in response to a linear increase in PWM\n > duty cycle.\n >\n > I think that we can all agree that the end result is to be able to\n > have a backlight that is easy to scale linearly with the human\n > perception of brightness (aka in Lumens). Right? So how do we get\n > there?\n\nI'd suggest we avoid talking about watts (measure of power, not limited \nto visible light) and lumens (measure of visible light, preceptually \nweighted for colour but *not* for perceived brightness).\n\n\n> So far in these discussions folks have been assuming that if we just\n> apply cie1931 to the PWM Duty Cycle then we're done and we have\n> perceived brightness in Lumens. ...but I think that's not quite\n> right. There are more factors. Let's use the datasheet for a random\n> backlight driver, like RT8561A. There appears to be a public\n> datasheet at .\n> \n> A) There may be a non-linear curve between PWM Duty Cycle and LED\n> Current (mA). The particular curve is different based on mode\n> (Digital Ctrl vs. Analog Ctrl) and also PWM Frequency. Sometimes this\n> curve is nearly linear for large parts of the curve but not the whole\n> curve. Sometimes even though the curve is nearly linear there is an\n> offset (AKA 10% duty cycle could still produce nearly zero light\n> output).\n> \n> B) There may be a non-linear curve between LED current and light\n> output in Watts (I think?).\n> \n> C) The human perception model means there is a non-linear curve\n> between light output in Watts and human perceived brightness in\n> Lumens.\n>\n> So A and B are hardware dependent and _do_ belong in the device tree (IMHO).\n\nYou forgot to model how to screen size and its maximum light output of \nthe backlight impact pupil dilation ;-).\n\nOr... putting it another way, A and B are only relevant if they help us \neliminate significant sources of error.\n\n\n> ...then the question is whether the device tree should specify the\n> curve so that the Watts scales linearly (and then the kernel adjust\n> for human perception) or so that Lumens scales linearly (which is\n> already adjusted for human perception).\n> \n> Historically I believe the device tree has always wanted it so that\n> Lumens scales linearly. So I guess the \"we don't do anything\" answer\n> is that the device tree should help account for for A + B + C.\n\nI would interpret the history slightly differently (although I'm not an \nauthoritative historian here).\n\nThere is a problem with the backlight interfaces (but entirely unrelated \nto Enric'c patch). The units the backlight users are not defined and \nvaries from driver to driver.\n\nThe userspace has never been able to tell but since most PC backlight \ncontrols are perceptually weighted (through \"magic\" in the BIOS) we \ndidn't really discover the problems until lots of embedded folks had \nadded backlight drivers and many of these used linear controls.\n\nAnyhow we're stuck where we are... and we probably shouldn't bog down \ndiscussion of it (since Enric's patch only affects one of the many drivers.\n\n\n> ...one proposal to fix this is to add some way to specify\n> piecewise-linear in the device tree. Using piecewise linear you can\n> specify a nearly arbitrary curve with not too many points. The idea\n> here is that you're not limiting yourself to only selecting the points\n> on the curve.\n > Hopefully Enric can try prototyping this up...\n\nYou mean have an additional property that allows the driver to linearly \ninterpolate between steps in the brightness-levels table (so it can \nprovide more steps than are described)?\n\nSounds OK to me although I'm still interested in whether an automatic \ntable can be \"right enough\"...\n\n\n> One last note is that it would be nice to find some way to make it\n> easier for people to get this right.\n\n... and this is why.\n\nOne great aspect of Enric's current work is that it has the potential to \nallow the driver to get it \"right enough\" with little effort by the DT \nauthor.\n\nHaving said that allowing the driver to interpolate and having a \nreference table in the driver (to allow brightness-levels to be \noptional) would do the same thing and spare me having to review all the \nfixed point maths for the CIE 1931 mappings as it evolves ;-)\n\n\n> I will take responsibility and admit that I've been involved in\n> device trees that just specified a > linear curve from 1 to 256. That's\n > not quite right, but it's never\n> been terribly easy to measure the correct curve (and never super\n> critical). On Chrome OS (where I've been working) historically I\n> believe that the cie1931 transformation has historically happened in\n> userspace, so effectively above I've asserted that \"A + B\" was linear\n> enough and then we've done \"C\" programmatically.\n\nRight now I've been assuming the best a userspace can do is:\n\n - Assume the backlight is perceptually weighted (since IIRC most x86\n PCs are)\n\n - Use quirks tables (and perhaps also take a sneaky peak to identify\n \"lazy\" brightness-level tables in the DT) and do some kind of\n linear-to-perceptual mapping (where CIE 1931 is as good a model as\n anything else)\n\nIs ChromeOS doing anything like this is it just a bit of userspace \nconfiguration to decide whether or not to apply a perceptual model?\n\n\n> I'm not saying what we've done in the past is terribly correct, but I\n> am saying that we should definitely take into account making this very\n> easy for people to get right. Possibly this could be as simple as\n> documenting a good / cheap light meter and how exactly to generate a\n> table...\n\nAgain no objections... but TBH I just don't see many DT authors actually \nbreaking out the light meter and doing it.\n\n\nDaniel.\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=linaro.org header.i=@linaro.org\n\theader.b=\"PET7Bjup\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xpZZw3TbGz9sDB\n\tfor ;\n\tFri, 8 Sep 2017 21:19:04 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751675AbdIHLSt (ORCPT\n\t);\n\tFri, 8 Sep 2017 07:18:49 -0400","from mail-wm0-f46.google.com ([74.125.82.46]:45180 \"EHLO\n\tmail-wm0-f46.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751907AbdIHLSr (ORCPT\n\t); Fri, 8 Sep 2017 07:18:47 -0400","by mail-wm0-f46.google.com with SMTP id f199so2890379wme.0\n\tfor ;\n\tFri, 08 Sep 2017 04:18:46 -0700 (PDT)","from [192.168.1.124]\n\t(cpc87211-aztw31-2-0-cust196.18-1.cable.virginm.net. [82.46.60.197])\n\tby smtp.googlemail.com with ESMTPSA id\n\tw82sm1994691wme.5.2017.09.08.04.18.42\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tFri, 08 Sep 2017 04:18:44 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google;\n\th=subject:to:cc:references:from:message-id:date:user-agent\n\t:mime-version:in-reply-to:content-language:content-transfer-encoding; \n\tbh=7urKe16YA+Ii3quMmxvUXb7ukhHctb5dXkKw2cu5FRo=;\n\tb=PET7BjupGICnnWpa05J15Gsf3v71KPOoScnOV2fkslYx+apXHKrlOZV7RWbZOtpp22\n\tVDEIyUnWEqmhPXGevTTi3FX/0yxIvHUjohaKBL/DO9Hhxovo6XdIMF3qEOkijUhqAIgD\n\to3coZRYrq3KTLUlTMMTBxvMchdifu/BrSqz1o=","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:subject:to:cc:references:from:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-language\n\t:content-transfer-encoding;\n\tbh=7urKe16YA+Ii3quMmxvUXb7ukhHctb5dXkKw2cu5FRo=;\n\tb=fSl59p1S9Xsg+2YwHUPkXqCRw59U7O3Kgyklpm/jFyQREPN4Mp7bu5sdOmc5drYf/v\n\tpgVKAxZYQlBF2Xdq/ahXQJg/KmI5lJI+lo1idoXdcZ5n97p3J4dZG396njL2H4jg049a\n\t532Ml+KYuPjJblrfx2DizLsJlYccXzZDmojAFThJo0jOlLUZCRpTcy6k0eZhiGGb1SBq\n\te3amDAI2vyOTcATAaahKfQdwM/eE2D1wBKgk2VY7CreJGVh+HLmYKoHfNJjtWyCqnskO\n\tjLuYai1hscSipNjg0Tj1jM1+xlzapAs7bP+qBssQdAELe+2IP0ovtxQQm8O+FVE1JZtb\n\tfrRw==","X-Gm-Message-State":"AHPjjUirTEDZORH+HQB8YpUNRzobSqJKKCBX64JR2qynuiNsjO5sG+UG\n\t+JKqdqO/dCTGrq/x","X-Google-Smtp-Source":"AOwi7QBxca9/T5kSHborpQ00bsfS7bAk4IVX+TaBWQkAKHMGyPgHZCWAERetmC98zQ9ZjVU7PVL6YA==","X-Received":"by 10.28.159.77 with SMTP id i74mr1322679wme.22.1504869525719;\n\tFri, 08 Sep 2017 04:18:45 -0700 (PDT)","Subject":"Re: [RFC 0/2] backlight: pwm_bl: support linear brightness to human\n\teye","To":"Doug Anderson , Jingoo Han ","Cc":"Enric Balletbo i Serra ,\n\tLee Jones , Richard Purdie , \n\tJacek Anaszewski ,\n\tPavel Machek , Rob Herring ,\n\tMark Rutland ,\n\tBrian Norris , \n\tGuenter Roeck , linux-leds@vger.kernel.org,\n\t\"devicetree@vger.kernel.org\" ,\n\t\"linux-kernel@vger.kernel.org\" ,\n\tAlexandru M Stan ","References":"<20170904153504.27963-1-enric.balletbo@collabora.com>\n\t<239c9153-c0ea-319c-b554-3c727b75c8cd@linaro.org>\n\t<000001d32664$db62b2a0$922817e0$@gmail.com>\n\t","From":"Daniel Thompson ","Message-ID":"","Date":"Fri, 8 Sep 2017 12:18:42 +0100","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"","Content-Type":"text/plain; charset=utf-8; format=flowed","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1765544,"web_url":"http://patchwork.ozlabs.org/comment/1765544/","msgid":"","list_archive_url":null,"date":"2017-09-08T17:39:34","subject":"Re: [RFC 0/2] backlight: pwm_bl: support linear brightness to human\n\teye","submitter":{"id":11501,"url":"http://patchwork.ozlabs.org/api/people/11501/","name":"Doug Anderson","email":"dianders@google.com"},"content":"Hi,\n\nOn Fri, Sep 8, 2017 at 4:18 AM, Daniel Thompson\n wrote:\n> On 07/09/17 19:04, Doug Anderson wrote:\n>> I'd agree that I don't think we should land Enric's series as-is.\n>> ...but I think something has been missing from the discussion so far:\n>> the fact that the backlight driver doesn't necessarily increase light\n>> output (in Watts) linearly in response to a linear increase in PWM\n>> duty cycle.\n>>\n>> I think that we can all agree that the end result is to be able to\n>> have a backlight that is easy to scale linearly with the human\n>> perception of brightness (aka in Lumens). Right? So how do we get\n>> there?\n>\n> I'd suggest we avoid talking about watts (measure of power, not limited to\n> visible light) and lumens (measure of visible light, preceptually weighted\n> for colour but *not* for perceived brightness).\n\nAh, OK. I thought lumens accounted for perceived brightness? I was\nhaving a hard time following all the stuff I could find online about\nthis. Mostly I thought I saw people talking about Luminous Flux\n(measured in Lumens), but maybe I was mistaken.\n\n\n>> So far in these discussions folks have been assuming that if we just\n>> apply cie1931 to the PWM Duty Cycle then we're done and we have\n>> perceived brightness in Lumens. ...but I think that's not quite\n>> right. There are more factors. Let's use the datasheet for a random\n>> backlight driver, like RT8561A. There appears to be a public\n>> datasheet at\n>> .\n>>\n>> A) There may be a non-linear curve between PWM Duty Cycle and LED\n>> Current (mA). The particular curve is different based on mode\n>> (Digital Ctrl vs. Analog Ctrl) and also PWM Frequency. Sometimes this\n>> curve is nearly linear for large parts of the curve but not the whole\n>> curve. Sometimes even though the curve is nearly linear there is an\n>> offset (AKA 10% duty cycle could still produce nearly zero light\n>> output).\n>>\n>> B) There may be a non-linear curve between LED current and light\n>> output in Watts (I think?).\n>>\n>> C) The human perception model means there is a non-linear curve\n>> between light output in Watts and human perceived brightness in\n>> Lumens.\n>>\n>> So A and B are hardware dependent and _do_ belong in the device tree\n>> (IMHO).\n>\n>\n> You forgot to model how to screen size and its maximum light output of the\n> backlight impact pupil dilation ;-).\n\nSilly me... Oops, I also forgot to account for the absolute humidity\nof the room. Do you think we can require all backlights come with a\nhumidity sensor?\n\n\n> Or... putting it another way, A and B are only relevant if they help us\n> eliminate significant sources of error.\n\nRight. ...so your point is we can't model everything and we just need\nto choose what's important.\n\nI'll agree that \"B\" above might not be worth modelling (though I don't\nknow). ...but I think we need to do _something_ about A.\n\n>From the datasheet I point at looking at \"Figure 8. LED Current vs.\nACTL PWM Dimming Duty Cycle\", it seems like we at least need to do\nsomething to account for the curve if we happen to be running at 30\nkHz for whatever reason. Specifically if we do no other work then any\nduty cycle below 8% will result in no brightness. Eyeballing the\ngraph 10% duty cycle looks to be about 2% current.\n\nOne option to solve this type of problem is to to specify a minimum\noffset and assume things are linear after that offset. That might\nwork, but it also might prevent you from accessing some of those nice\nlow brightness points. Historically I have been frustrated when in\ndark rooms that I couldn't set the brightness to be dim enough...\n\nThe whole piecewise linear concept is that maybe you'd specify the\ncurve (in terms of milliPercent) like this (values found by measuring\ndatasheet curve with a ruler):\n\n<0 0>\n<10000 1800> # 10% duty cycle gives 1.8% current\n<12000 4300> # 12% duty cycle gives 4.3% current\n<17000 10000> # 17% duty cycle gives 10% current\n<93000 90000> # 93% duty cycle gives 90% current\n<100000 100000> # 100% duty cycle gives 100% current\n\n\n>> ...then the question is whether the device tree should specify the\n>> curve so that the Watts scales linearly (and then the kernel adjust\n>> for human perception) or so that Lumens scales linearly (which is\n>> already adjusted for human perception).\n>>\n>> Historically I believe the device tree has always wanted it so that\n>> Lumens scales linearly. So I guess the \"we don't do anything\" answer\n>> is that the device tree should help account for for A + B + C.\n>\n>\n> I would interpret the history slightly differently (although I'm not an\n> authoritative historian here).\n>\n> There is a problem with the backlight interfaces (but entirely unrelated to\n> Enric'c patch). The units the backlight users are not defined and varies\n> from driver to driver.\n>\n> The userspace has never been able to tell but since most PC backlight\n> controls are perceptually weighted (through \"magic\" in the BIOS) we didn't\n> really discover the problems until lots of embedded folks had added\n> backlight drivers and many of these used linear controls.\n>\n> Anyhow we're stuck where we are... and we probably shouldn't bog down\n> discussion of it (since Enric's patch only affects one of the many drivers.\n\nSee below discussion of how Chrome OS userspace deals with this today,\nbut it feels like we need to come up with a less hacky solution...\n\n\n>> ...one proposal to fix this is to add some way to specify\n>> piecewise-linear in the device tree. Using piecewise linear you can\n>> specify a nearly arbitrary curve with not too many points. The idea\n>> here is that you're not limiting yourself to only selecting the points\n>> on the curve.\n>\n>> Hopefully Enric can try prototyping this up...\n>\n> You mean have an additional property that allows the driver to linearly\n> interpolate between steps in the brightness-levels table (so it can provide\n> more steps than are described)?\n>\n> Sounds OK to me although I'm still interested in whether an automatic table\n> can be \"right enough\"...\n\nMy secret plan was that Enric could implement piecewise linear\nsupport, which really should be a very simple bit of code. This would\nallow people to model the non-linearlity of their hardware if they\nwanted but would add very little overhead if they didn't want to. AKA\nthe lazy way to specify your \"curve\":\n\n <0 0>\n <100000 100000> # 100% duty cycle gives 100% current\n\n...and of course you could just assume this \"curve\" if nothing was specified...\n\n...then there's the question of whether or not Enric's human\nperception work should be applied atop this or if the super-cool-elite\nstatus of pieceiwse linear subsumes the need. Said another way: once\nyou have piecewise linear it would be pretty easy to manually apply\nthe human perception model to your curve before putting it in the\ndevice tree...\n\nI guess the cop out answer is to add an attribute like\n\"apply-human-perception-factor\". The presence of this attribute will\ncause Enric's code to run. The lack of this attribute will cause it\nnot to run. Thus if you assume that hardware response is nearly\nlinear (without counting human perception) and you want human\nperceived output, you'd do:\n\n <0 0>\n <100000 100000> # 100% duty cycle gives 100% current\n apply-human-perception-factor\n\n\nIf you want to go whole-hog and get out the light meter, it's probably\npretty easy to just specify the full curve _after_ applying the human\nfactor...\n\n\n> One great aspect of Enric's current work is that it has the potential to\n> allow the driver to get it \"right enough\" with little effort by the DT\n> author.\n>\n> Having said that allowing the driver to interpolate and having a reference\n> table in the driver (to allow brightness-levels to be optional) would do the\n> same thing and spare me having to review all the fixed point maths for the\n> CIE 1931 mappings as it evolves ;-)\n\nRight. Essentially you'd be making the lazy solution currently\nimplied in many Chrome OS boards (assume mostly linear hardware\nresponse) easier to do.\n\n\n> Right now I've been assuming the best a userspace can do is:\n>\n> - Assume the backlight is perceptually weighted (since IIRC most x86\n> PCs are)\n>\n> - Use quirks tables (and perhaps also take a sneaky peak to identify\n> \"lazy\" brightness-level tables in the DT) and do some kind of\n> linear-to-perceptual mapping (where CIE 1931 is as good a model as\n> anything else)\n>\n> Is ChromeOS doing anything like this is it just a bit of userspace\n> configuration to decide whether or not to apply a perceptual model?\n\nRight now Chrome OS has what's a bit of a hack. You can see the code at:\n\nhttps://chromium.googlesource.com/chromiumos/platform2/+/master/power_manager/powerd/policy/internal_backlight_controller.cc\n\nBasically if the backlight has more than 100\n(kMinLevelsForNonLinearMapping) levels then it does some conversions\nto adjust things to be exponential. I guess the idea is that the\nmagic BIOS devices usually have < 100 levels and PWM backlights have\nmore?\n\n\nThe hope was that we could adjust the kernel to be consistent and then\nfix userspace to just drive everything the same way...\n\n\n-Doug\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=google.com header.i=@google.com\n\theader.b=\"PhPyO0/G\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xpl254hbcz9sBW\n\tfor ;\n\tSat, 9 Sep 2017 03:39:41 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1756634AbdIHRjj (ORCPT\n\t);\n\tFri, 8 Sep 2017 13:39:39 -0400","from mail-wm0-f45.google.com ([74.125.82.45]:44873 \"EHLO\n\tmail-wm0-f45.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1756636AbdIHRjh (ORCPT\n\t); Fri, 8 Sep 2017 13:39:37 -0400","by mail-wm0-f45.google.com with SMTP id 137so7679788wmj.1\n\tfor ;\n\tFri, 08 Sep 2017 10:39:37 -0700 (PDT)","by 10.28.27.194 with HTTP; Fri, 8 Sep 2017 10:39:34 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;\n\ts=20161025; \n\th=mime-version:in-reply-to:references:from:date:message-id:subject:to\n\t:cc; bh=fC3MwlBBYmrBJ9/lc/W7Sikau0mHUBlV031G1CzJ2S4=;\n\tb=PhPyO0/GKZ5Nxpgo7UJVZ1bjs15bQHNImsYtyUCB9p0iSHJKFlqynQHrN1zKa9SmhY\n\t837yIATJuJ+BsMHbUHKyygfRFIeFrZbIddDNR3cVJtHa5OiOh8v59HEvOiaMxhHtzzgn\n\tQhaHuqAib4qgnNx+Yw66+qgpBSzjEmVPH2skqLIhQpUeel0vVL/7y2GcB2C/hH9v4ULj\n\tHeKnzUYDxUrdsMxHFWxR05wlph0ePSNRHxSQPgWL5AmhglYM6BLa+eXQE5HvpwBjluIS\n\tTx41UGfI1ZLtHxtsmblQ0NqeZSMC0FwHIpYcls4LD/5sxHKYYRqgcESWoNVz+7GV+LnT\n\tFHig==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc;\n\tbh=fC3MwlBBYmrBJ9/lc/W7Sikau0mHUBlV031G1CzJ2S4=;\n\tb=ShzTj25xbcQmEhO3KKmCq1k4SiofdCZ08IKefc8bmtHVyLZvUOwg9ko9R346gg3hlP\n\tNIlqVcIlV4V5OYDCmzhui90r3JgCw+5lShCSCV07USkm33FmCBCgiZm7aGgw0uT/IGil\n\tduT6kWp0fKQEk3XeHOL/IeS+pDE+MhDQJzXu7hp2/RA8SDM/AeDRoIcqmS2R60doyInJ\n\tub4TkTvLisBpme5rsGSSoPztTw5jFrQ/G8ar5Fgp8x0/bln+t2kVT8b9eyOt7XhfiRKW\n\tKFl+WKoQxTBRfA43YerGFoDvjCzJYTrLCmuPic5zKtS8W+SYky6XovTkkkewY+XMUzGc\n\t/lpg==","X-Gm-Message-State":"AHPjjUjN0WcnJoSydz5/ckYj5XszKn8LT0LOFBsxpH3rCzeCbNjrZaxJ\n\tb36O4Y52ImSS0El+DRVxFT1O5etBPKOVo57h3q8n8w==","X-Google-Smtp-Source":"AOwi7QDcxYt6ofYZKQyKLhAcOncdPyM1QdAB4wk8ua++O46w3DJP7moo1XRbLrHPShyAEmRq10Vgj/Ls5BNOl3OI3Kg=","X-Received":"by 10.28.8.20 with SMTP id 20mr2110976wmi.96.1504892375702; Fri,\n\t08 Sep 2017 10:39:35 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"","References":"<20170904153504.27963-1-enric.balletbo@collabora.com>\n\t<239c9153-c0ea-319c-b554-3c727b75c8cd@linaro.org>\n\t<000001d32664$db62b2a0$922817e0$@gmail.com>\n\t\n\t","From":"Doug Anderson ","Date":"Fri, 8 Sep 2017 10:39:34 -0700","Message-ID":"","Subject":"Re: [RFC 0/2] backlight: pwm_bl: support linear brightness to human\n\teye","To":"Daniel Thompson ","Cc":"Jingoo Han ,\n\tEnric Balletbo i Serra ,\n\tLee Jones , Richard Purdie , \n\tJacek Anaszewski ,\n\tPavel Machek , Rob Herring ,\n\tMark Rutland ,\n\tBrian Norris , \n\tGuenter Roeck , linux-leds@vger.kernel.org,\n\t\"devicetree@vger.kernel.org\" ,\n\t\"linux-kernel@vger.kernel.org\" ,\n\tAlexandru M Stan ","Content-Type":"text/plain; charset=\"UTF-8\"","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1768505,"web_url":"http://patchwork.ozlabs.org/comment/1768505/","msgid":"","list_archive_url":null,"date":"2017-09-14T10:46:26","subject":"Re: [RFC 0/2] backlight: pwm_bl: support linear brightness to human\n\teye","submitter":{"id":4120,"url":"http://patchwork.ozlabs.org/api/people/4120/","name":"Enric Balletbo Serra","email":"eballetbo@gmail.com"},"content":"Hi,\n\n2017-09-08 19:39 GMT+02:00 Doug Anderson :\n> Hi,\n>\n> On Fri, Sep 8, 2017 at 4:18 AM, Daniel Thompson\n> wrote:\n>> On 07/09/17 19:04, Doug Anderson wrote:\n>>> I'd agree that I don't think we should land Enric's series as-is.\n>>> ...but I think something has been missing from the discussion so far:\n>>> the fact that the backlight driver doesn't necessarily increase light\n>>> output (in Watts) linearly in response to a linear increase in PWM\n>>> duty cycle.\n>>>\n>>> I think that we can all agree that the end result is to be able to\n>>> have a backlight that is easy to scale linearly with the human\n>>> perception of brightness (aka in Lumens). Right? So how do we get\n>>> there?\n>>\n>> I'd suggest we avoid talking about watts (measure of power, not limited to\n>> visible light) and lumens (measure of visible light, preceptually weighted\n>> for colour but *not* for perceived brightness).\n>\n> Ah, OK. I thought lumens accounted for perceived brightness? I was\n> having a hard time following all the stuff I could find online about\n> this. Mostly I thought I saw people talking about Luminous Flux\n> (measured in Lumens), but maybe I was mistaken.\n>\n>\n>>> So far in these discussions folks have been assuming that if we just\n>>> apply cie1931 to the PWM Duty Cycle then we're done and we have\n>>> perceived brightness in Lumens. ...but I think that's not quite\n>>> right. There are more factors. Let's use the datasheet for a random\n>>> backlight driver, like RT8561A. There appears to be a public\n>>> datasheet at\n>>> .\n>>>\n>>> A) There may be a non-linear curve between PWM Duty Cycle and LED\n>>> Current (mA). The particular curve is different based on mode\n>>> (Digital Ctrl vs. Analog Ctrl) and also PWM Frequency. Sometimes this\n>>> curve is nearly linear for large parts of the curve but not the whole\n>>> curve. Sometimes even though the curve is nearly linear there is an\n>>> offset (AKA 10% duty cycle could still produce nearly zero light\n>>> output).\n>>>\n>>> B) There may be a non-linear curve between LED current and light\n>>> output in Watts (I think?).\n>>>\n>>> C) The human perception model means there is a non-linear curve\n>>> between light output in Watts and human perceived brightness in\n>>> Lumens.\n>>>\n>>> So A and B are hardware dependent and _do_ belong in the device tree\n>>> (IMHO).\n>>\n>>\n>> You forgot to model how to screen size and its maximum light output of the\n>> backlight impact pupil dilation ;-).\n>\n> Silly me... Oops, I also forgot to account for the absolute humidity\n> of the room. Do you think we can require all backlights come with a\n> humidity sensor?\n>\n>\n>> Or... putting it another way, A and B are only relevant if they help us\n>> eliminate significant sources of error.\n>\n> Right. ...so your point is we can't model everything and we just need\n> to choose what's important.\n>\n> I'll agree that \"B\" above might not be worth modelling (though I don't\n> know). ...but I think we need to do _something_ about A.\n>\n> From the datasheet I point at looking at \"Figure 8. LED Current vs.\n> ACTL PWM Dimming Duty Cycle\", it seems like we at least need to do\n> something to account for the curve if we happen to be running at 30\n> kHz for whatever reason. Specifically if we do no other work then any\n> duty cycle below 8% will result in no brightness. Eyeballing the\n> graph 10% duty cycle looks to be about 2% current.\n>\n> One option to solve this type of problem is to to specify a minimum\n> offset and assume things are linear after that offset. That might\n> work, but it also might prevent you from accessing some of those nice\n> low brightness points. Historically I have been frustrated when in\n> dark rooms that I couldn't set the brightness to be dim enough...\n>\n> The whole piecewise linear concept is that maybe you'd specify the\n> curve (in terms of milliPercent) like this (values found by measuring\n> datasheet curve with a ruler):\n>\n> <0 0>\n> <10000 1800> # 10% duty cycle gives 1.8% current\n> <12000 4300> # 12% duty cycle gives 4.3% current\n> <17000 10000> # 17% duty cycle gives 10% current\n> <93000 90000> # 93% duty cycle gives 90% current\n> <100000 100000> # 100% duty cycle gives 100% current\n>\n>\n>>> ...then the question is whether the device tree should specify the\n>>> curve so that the Watts scales linearly (and then the kernel adjust\n>>> for human perception) or so that Lumens scales linearly (which is\n>>> already adjusted for human perception).\n>>>\n>>> Historically I believe the device tree has always wanted it so that\n>>> Lumens scales linearly. So I guess the \"we don't do anything\" answer\n>>> is that the device tree should help account for for A + B + C.\n>>\n>>\n>> I would interpret the history slightly differently (although I'm not an\n>> authoritative historian here).\n>>\n>> There is a problem with the backlight interfaces (but entirely unrelated to\n>> Enric'c patch). The units the backlight users are not defined and varies\n>> from driver to driver.\n>>\n\nBased on this seems reasonable maintain current implementation to not\nbreak backward compability. Even, I think makes sense improve current\nimplementation by adding somekind of piecewise linear concept to the\nbrightness levels, similar to Doug's suggestion. So if we want, i.e,\n256 levels or more, instead of specify the full table in the DT we can\nonly specify some points in DT but the driver can expose to userspace\nmore steps (how many?) between two brightness levels. Of course, this\ndoesn't makes the live of the future users easier but I think will\nmake the live of the current users of this interface more flexible\n(specially when you want lots of levels)\n\nThen, to make the user live easier, there is the thing about human\nperception, we can move brightness-levels to be optional and fall to\napply the human perception code if it's not specified. Here the thing\nand point of discussion is, if the cie1931 is the right algorithm to\ndo the 'magic' in the driver. From what I investigated seems that is\nbut I might be wrong.\n\nSeems reasonable apply both solutions? I can send a second RFC with\nboth approaches.\n\n>> The userspace has never been able to tell but since most PC backlight\n>> controls are perceptually weighted (through \"magic\" in the BIOS) we didn't\n>> really discover the problems until lots of embedded folks had added\n>> backlight drivers and many of these used linear controls.\n>>\n>> Anyhow we're stuck where we are... and we probably shouldn't bog down\n>> discussion of it (since Enric's patch only affects one of the many drivers.\n>\n> See below discussion of how Chrome OS userspace deals with this today,\n> but it feels like we need to come up with a less hacky solution...\n>\n>\n>>> ...one proposal to fix this is to add some way to specify\n>>> piecewise-linear in the device tree. Using piecewise linear you can\n>>> specify a nearly arbitrary curve with not too many points. The idea\n>>> here is that you're not limiting yourself to only selecting the points\n>>> on the curve.\n>>\n>>> Hopefully Enric can try prototyping this up...\n>>\n>> You mean have an additional property that allows the driver to linearly\n>> interpolate between steps in the brightness-levels table (so it can provide\n>> more steps than are described)?\n>>\n>> Sounds OK to me although I'm still interested in whether an automatic table\n>> can be \"right enough\"...\n>\n> My secret plan was that Enric could implement piecewise linear\n> support, which really should be a very simple bit of code. This would\n> allow people to model the non-linearlity of their hardware if they\n> wanted but would add very little overhead if they didn't want to. AKA\n> the lazy way to specify your \"curve\":\n>\n> <0 0>\n> <100000 100000> # 100% duty cycle gives 100% current\n>\n> ...and of course you could just assume this \"curve\" if nothing was specified...\n>\n> ...then there's the question of whether or not Enric's human\n> perception work should be applied atop this or if the super-cool-elite\n> status of pieceiwse linear subsumes the need. Said another way: once\n> you have piecewise linear it would be pretty easy to manually apply\n> the human perception model to your curve before putting it in the\n> device tree...\n>\n> I guess the cop out answer is to add an attribute like\n> \"apply-human-perception-factor\". The presence of this attribute will\n> cause Enric's code to run. The lack of this attribute will cause it\n> not to run. Thus if you assume that hardware response is nearly\n> linear (without counting human perception) and you want human\n> perceived output, you'd do:\n>\n> <0 0>\n> <100000 100000> # 100% duty cycle gives 100% current\n> apply-human-perception-factor\n>\n>\n> If you want to go whole-hog and get out the light meter, it's probably\n> pretty easy to just specify the full curve _after_ applying the human\n> factor...\n>\n>\n>> One great aspect of Enric's current work is that it has the potential to\n>> allow the driver to get it \"right enough\" with little effort by the DT\n>> author.\n>>\n>> Having said that allowing the driver to interpolate and having a reference\n>> table in the driver (to allow brightness-levels to be optional) would do the\n>> same thing and spare me having to review all the fixed point maths for the\n>> CIE 1931 mappings as it evolves ;-)\n>\n> Right. Essentially you'd be making the lazy solution currently\n> implied in many Chrome OS boards (assume mostly linear hardware\n> response) easier to do.\n>\n>\n>> Right now I've been assuming the best a userspace can do is:\n>>\n>> - Assume the backlight is perceptually weighted (since IIRC most x86\n>> PCs are)\n>>\n>> - Use quirks tables (and perhaps also take a sneaky peak to identify\n>> \"lazy\" brightness-level tables in the DT) and do some kind of\n>> linear-to-perceptual mapping (where CIE 1931 is as good a model as\n>> anything else)\n>>\n>> Is ChromeOS doing anything like this is it just a bit of userspace\n>> configuration to decide whether or not to apply a perceptual model?\n>\n> Right now Chrome OS has what's a bit of a hack. You can see the code at:\n>\n> https://chromium.googlesource.com/chromiumos/platform2/+/master/power_manager/powerd/policy/internal_backlight_controller.cc\n>\n> Basically if the backlight has more than 100\n> (kMinLevelsForNonLinearMapping) levels then it does some conversions\n> to adjust things to be exponential. I guess the idea is that the\n> magic BIOS devices usually have < 100 levels and PWM backlights have\n> more?\n>\n>\n> The hope was that we could adjust the kernel to be consistent and then\n> fix userspace to just drive everything the same way...\n>\n>\n> -Doug\n\nBest regards,\n Enric.\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"km6YueZt\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xtFjg70Nzz9sRW\n\tfor ;\n\tThu, 14 Sep 2017 20:52:39 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751794AbdINKwi (ORCPT\n\t);\n\tThu, 14 Sep 2017 06:52:38 -0400","from mail-it0-f51.google.com ([209.85.214.51]:49865 \"EHLO\n\tmail-it0-f51.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751808AbdINKwg (ORCPT\n\t); Thu, 14 Sep 2017 06:52:36 -0400","by mail-it0-f51.google.com with SMTP id w204so286583itc.4;\n\tThu, 14 Sep 2017 03:52:36 -0700 (PDT)","by 10.79.128.140 with HTTP; Thu, 14 Sep 2017 03:46:26 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=mime-version:in-reply-to:references:from:date:message-id:subject:to\n\t:cc; bh=+wqhfoV+dDJv0bRuGz2/dgRtH+iQRrslATWasnJPbYA=;\n\tb=km6YueZtdKgiQTv2qsRyVVIuaT6ekHxXSwcYpx+97gfbX5fCHFLgylBgqa9Eh2WVFK\n\t7jObK7S4QscUlmlOk+Nx7NHglXTo1Lm4SyLNMOIZoQBa6rtmXvLggogbQPdkdqrtWIpK\n\trGKvTYsMA5yIW80vHunFMuE2YU6kL1BMvX+4cwaLIWxWGL1KkjV7+8o0/MlJJMI1aHCm\n\tDcr998iIVIXjxiPLyPEuPvcQr+SO1kQfunw4sJxipY/3SxenqDpye9JubBRHVGBe3qhB\n\t0dEickjOitUBHgA4wP+sK5QonlOIGJY7rI6QTwChL8X0wKuP5I6xlsW8ob7WJT0+Fv/B\n\tIXpQ==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc;\n\tbh=+wqhfoV+dDJv0bRuGz2/dgRtH+iQRrslATWasnJPbYA=;\n\tb=jc7ukwweNKChiAOdj++TWKLJFgyvWC+rr+M1kxLTrU4iftrhbP7p5sDrRjehx3RUCV\n\tbo1oS7Uc2xpKOI3QyeZuf8NjTezaZqZwywdExt2Dvf9o/3tqiesxju8BfwBvWzauIw3O\n\tdzSCYaK0KXB+VaOIbdBNjXQH2svYvljXEQ9Xpd/Z6RToVd8AZDttmbtyDmxNZzdfIZWn\n\tUFBPiJpIlYgmHEI4r51trUISEFa8AFL8CJt/ckCwEjekv4ZHmPK+GHnJOUKBd3vjaOxo\n\tYVEABzfhlzcb0SMtv3uc8XBOVdBkLG63AUt4GS+pUwB3OqzwFQHCG832Yjt+RjDt1QeE\n\tophQ==","X-Gm-Message-State":"AHPjjUiYo1Wag7rHHPYAjpvbpGVuHY0L5rsBxGoUqTn6EK0/kfqgs6sV\n\tqEdytFS0a5GraeHMiH4g24J2TwAiMUFVSwFAaeE=","X-Google-Smtp-Source":"AOwi7QCuhNIZiBh2V/KchJ5nc3lBr1yJKaAq5mIN4y8uB6ABgqx3qtczNYkA55CU8EwWeP6Rx0mrUMuE9DZk4BmxorU=","X-Received":"by 10.36.254.72 with SMTP id w69mr2397168ith.130.1505385987759; \n\tThu, 14 Sep 2017 03:46:27 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"","References":"<20170904153504.27963-1-enric.balletbo@collabora.com>\n\t<239c9153-c0ea-319c-b554-3c727b75c8cd@linaro.org>\n\t<000001d32664$db62b2a0$922817e0$@gmail.com>\n\t\n\t\n\t","From":"Enric Balletbo Serra ","Date":"Thu, 14 Sep 2017 12:46:26 +0200","Message-ID":"","Subject":"Re: [RFC 0/2] backlight: pwm_bl: support linear brightness to human\n\teye","To":"Doug Anderson ","Cc":"Daniel Thompson ,\n\tJingoo Han ,\n\tEnric Balletbo i Serra ,\n\tLee Jones , Richard Purdie , \n\tJacek Anaszewski ,\n\tPavel Machek , Rob Herring ,\n\tMark Rutland ,\n\tBrian Norris , \n\tGuenter Roeck , linux-leds@vger.kernel.org,\n\t\"devicetree@vger.kernel.org\" ,\n\t\"linux-kernel@vger.kernel.org\" ,\n\tAlexandru M Stan ","Content-Type":"text/plain; charset=\"UTF-8\"","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1768704,"web_url":"http://patchwork.ozlabs.org/comment/1768704/","msgid":"","list_archive_url":null,"date":"2017-09-14T16:01:33","subject":"Re: [RFC 0/2] backlight: pwm_bl: support linear brightness to human\n\teye","submitter":{"id":11501,"url":"http://patchwork.ozlabs.org/api/people/11501/","name":"Doug Anderson","email":"dianders@google.com"},"content":"Hi,\n\nOn Thu, Sep 14, 2017 at 3:46 AM, Enric Balletbo Serra\n wrote:\n> Based on this seems reasonable maintain current implementation to not\n> break backward compability. Even, I think makes sense improve current\n> implementation by adding somekind of piecewise linear concept to the\n> brightness levels, similar to Doug's suggestion. So if we want, i.e,\n> 256 levels or more, instead of specify the full table in the DT we can\n> only specify some points in DT but the driver can expose to userspace\n> more steps (how many?) between two brightness levels.\n\nIt seems sane to me. Personally I'd say that if you're using\npiecewise linear you just pick a number of levels to expose, perhaps\n16383, or 32767, or 65535) and expose that many levels for everyone.\nIt's possible that bumping the brightness up by \"1\" will not actually\nchange a hardware register, but that seems like it would be fine,\nright?\n\nProbably you'd want to require some sort of dt change to enable\npiecewise linear since it seems plausible that you could break\nexisting boards if you started interpolating.\n\n> Of course, this\n> doesn't makes the live of the future users easier but I think will\n> make the live of the current users of this interface more flexible\n> (specially when you want lots of levels)\n>\n> Then, to make the user live easier, there is the thing about human\n> perception, we can move brightness-levels to be optional and fall to\n> apply the human perception code if it's not specified. Here the thing\n> and point of discussion is, if the cie1931 is the right algorithm to\n> do the 'magic' in the driver. From what I investigated seems that is\n> but I might be wrong.\n\nI don't personally know, so hopefully someone else can comment.\n\n\n-Doug\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=google.com header.i=@google.com\n\theader.b=\"FzVvVxKX\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xtNZQ0rN9z9sPs\n\tfor ;\n\tFri, 15 Sep 2017 02:01:50 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751843AbdINQBk (ORCPT\n\t);\n\tThu, 14 Sep 2017 12:01:40 -0400","from mail-wr0-f174.google.com ([209.85.128.174]:43762 \"EHLO\n\tmail-wr0-f174.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1752028AbdINQBg (ORCPT\n\t); Thu, 14 Sep 2017 12:01:36 -0400","by mail-wr0-f174.google.com with SMTP id a43so6346375wrc.0\n\tfor ;\n\tThu, 14 Sep 2017 09:01:35 -0700 (PDT)","by 10.28.27.194 with HTTP; Thu, 14 Sep 2017 09:01:33 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;\n\ts=20161025; \n\th=mime-version:in-reply-to:references:from:date:message-id:subject:to\n\t:cc; bh=6vGCWmub0r1JrkpalmKIjMdkraJQzf86PwswHsYWyTg=;\n\tb=FzVvVxKXvH/jSgKhyfpEET2DcHTuBueyAz3OFZjqvbgRK2ZhHt7qdp92+bWJu+mDnG\n\ttDLVmTu2dRpKxcZkNdmJbt/zjlQHQYNlitkuJ6RPaPJV62OiCPRWBUpZ3n11XeGj/kQp\n\tIwqi860IM+dVO4ywv38aFi9cWvLp+8CAixRSiVt0WPbeJqzIkFpfB9a7Wv1ds9mkAE7P\n\t1NzfIWB+s+tZl7mgz0JSy9BBXH9T75tZgDwiXDFrxkgFFKhUzavnraffrNtkKmGgaMBz\n\tksgqzNneCNbR4dB+aeti22AEkXjn1P8w6z+5Mue91312ZZUQlhC5W8EI/2jQgxTLXfyF\n\tcPDg==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc;\n\tbh=6vGCWmub0r1JrkpalmKIjMdkraJQzf86PwswHsYWyTg=;\n\tb=fZo2f21/ljkBnJ6anxClmsvi1ePCsP0aY+qgiW6S7KBFCvA0YBNVYoTm3JVy7vRnZI\n\tA4BCzS+RjRAlBHOR1y2XX4L+gakb3Irv96890f5JN8a354BLyBTSjuoyu+t9gVPwDSZt\n\tcFGcYYN4DFEHtpqbSVkeVZxLBIbbhaWdkfnLvYpkbEjxov07+DkKtEEdyVEPQinvMArw\n\t2IHGqNkHVgf3KMGZmYWz8uG3pi8O9FgptRmZKYPYePP04kGrjWpBj4elxv5+GFUcOaY0\n\tv6yHy84nYY8xG61v7STdMVA6PiMSfiF6VSZ8Fc5qmMrzTASkhFoiK8mqoo7xqdgqFE7G\n\toM/w==","X-Gm-Message-State":"AHPjjUiMyUgmzls07ieJWAJny6RqvV1y6KjwUADaZuhzosG7jxyNBHsH\n\tCFn/d5tbdZ3WMhvutE/bEl3btrsmOAIRiMvhFPIc0Q==","X-Google-Smtp-Source":"ADKCNb7VBwN8TqVmDnXbbItVnLl2t7ntc/fYn9mOyeQgqbwDzDdysr/OIk33gMQi4a2x9mOGXdM+xdQBdskQddVS9QE=","X-Received":"by 10.223.153.106 with SMTP id\n\tx97mr18010147wrb.107.1505404894500; \n\tThu, 14 Sep 2017 09:01:34 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"","References":"<20170904153504.27963-1-enric.balletbo@collabora.com>\n\t<239c9153-c0ea-319c-b554-3c727b75c8cd@linaro.org>\n\t<000001d32664$db62b2a0$922817e0$@gmail.com>\n\t\n\t\n\t\n\t","From":"Doug Anderson ","Date":"Thu, 14 Sep 2017 09:01:33 -0700","Message-ID":"","Subject":"Re: [RFC 0/2] backlight: pwm_bl: support linear brightness to human\n\teye","To":"Enric Balletbo Serra ","Cc":"Daniel Thompson ,\n\tJingoo Han ,\n\tEnric Balletbo i Serra ,\n\tLee Jones , Richard Purdie , \n\tJacek Anaszewski ,\n\tPavel Machek , Rob Herring ,\n\tMark Rutland ,\n\tBrian Norris , \n\tGuenter Roeck , linux-leds@vger.kernel.org,\n\t\"devicetree@vger.kernel.org\" ,\n\t\"linux-kernel@vger.kernel.org\" ,\n\tAlexandru M Stan ","Content-Type":"text/plain; charset=\"UTF-8\"","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1770279,"web_url":"http://patchwork.ozlabs.org/comment/1770279/","msgid":"<478868b7-ff09-1332-5459-e788d0adae99@linaro.org>","list_archive_url":null,"date":"2017-09-18T16:00:47","subject":"Re: Re: [RFC 0/2] backlight: pwm_bl: support linear brightness to\n\thuman eye","submitter":{"id":63942,"url":"http://patchwork.ozlabs.org/api/people/63942/","name":"Daniel Thompson","email":"daniel.thompson@linaro.org"},"content":"On 14/09/17 11:46, Enric Balletbo Serra wrote:\n>>>> So far in these discussions folks have been assuming that if we just\n>>>> apply cie1931 to the PWM Duty Cycle then we're done and we have\n>>>> perceived brightness in Lumens. ...but I think that's not quite\n>>>> right. There are more factors. Let's use the datasheet for a random\n>>>> backlight driver, like RT8561A. There appears to be a public\n>>>> datasheet at\n>>>> .\n>>>>\n>>>> A) There may be a non-linear curve between PWM Duty Cycle and LED\n>>>> Current (mA). The particular curve is different based on mode\n>>>> (Digital Ctrl vs. Analog Ctrl) and also PWM Frequency. Sometimes this\n>>>> curve is nearly linear for large parts of the curve but not the whole\n>>>> curve. Sometimes even though the curve is nearly linear there is an\n>>>> offset (AKA 10% duty cycle could still produce nearly zero light\n>>>> output).\n>>>>\n>>>> B) There may be a non-linear curve between LED current and light\n>>>> output in Watts (I think?).\n>>>>\n>>>> C) The human perception model means there is a non-linear curve\n>>>> between light output in Watts and human perceived brightness in\n>>>> Lumens.\n>>>>\n>>>> So A and B are hardware dependent and _do_ belong in the device tree\n>>>> (IMHO).\n>>>\n>>>\n>>> You forgot to model how to screen size and its maximum light output of the\n>>> backlight impact pupil dilation ;-).\n>>\n>> Silly me... Oops, I also forgot to account for the absolute humidity\n>> of the room. Do you think we can require all backlights come with a\n>> humidity sensor?\n>>\n>>\n>>> Or... putting it another way, A and B are only relevant if they help us\n>>> eliminate significant sources of error.\n>>\n>> Right. ...so your point is we can't model everything and we just need\n>> to choose what's important.\n>>\n>> I'll agree that \"B\" above might not be worth modelling (though I don't\n>> know). ...but I think we need to do _something_ about A.\n>>\n>> From the datasheet I point at looking at \"Figure 8. LED Current vs.\n>> ACTL PWM Dimming Duty Cycle\", it seems like we at least need to do\n>> something to account for the curve if we happen to be running at 30\n>> kHz for whatever reason. Specifically if we do no other work then any\n>> duty cycle below 8% will result in no brightness. Eyeballing the\n>> graph 10% duty cycle looks to be about 2% current.\n>>\n>> One option to solve this type of problem is to to specify a minimum\n>> offset and assume things are linear after that offset. That might\n>> work, but it also might prevent you from accessing some of those nice\n>> low brightness points. Historically I have been frustrated when in\n>> dark rooms that I couldn't set the brightness to be dim enough...\n>>\n>> The whole piecewise linear concept is that maybe you'd specify the\n>> curve (in terms of milliPercent) like this (values found by measuring\n>> datasheet curve with a ruler):\n>>\n>> <0 0>\n>> <10000 1800> # 10% duty cycle gives 1.8% current\n>> <12000 4300> # 12% duty cycle gives 4.3% current\n>> <17000 10000> # 17% duty cycle gives 10% current\n>> <93000 90000> # 93% duty cycle gives 90% current\n>> <100000 100000> # 100% duty cycle gives 100% current\n>>\n>>\n>>>> ...then the question is whether the device tree should specify the\n>>>> curve so that the Watts scales linearly (and then the kernel adjust\n>>>> for human perception) or so that Lumens scales linearly (which is\n>>>> already adjusted for human perception).\n>>>>\n>>>> Historically I believe the device tree has always wanted it so that\n>>>> Lumens scales linearly. So I guess the \"we don't do anything\" answer\n>>>> is that the device tree should help account for for A + B + C.\n>>>\n>>>\n>>> I would interpret the history slightly differently (although I'm not an\n>>> authoritative historian here).\n>>>\n>>> There is a problem with the backlight interfaces (but entirely unrelated to\n>>> Enric'c patch). The units the backlight users are not defined and varies\n>>> from driver to driver.\n>>>\n> \n> Based on this seems reasonable maintain current implementation to not\n> break backward compability. Even, I think makes sense improve current\n> implementation by adding somekind of piecewise linear concept to the\n> brightness levels, similar to Doug's suggestion. So if we want, i.e,\n> 256 levels or more, instead of specify the full table in the DT we can\n> only specify some points in DT but the driver can expose to userspace\n> more steps (how many?) between two brightness levels. Of course, this\n> doesn't makes the live of the future users easier but I think will\n> make the live of the current users of this interface more flexible\n> (specially when you want lots of levels).\n\nIdeally I'd like the driver to derive the number of steps based on the \nPWM resolution it discovers (I don't entirely agree that having a large \nportion of the slider map to no change is a good thing... we should be \nable to estimate the smallest useful step size).\n\nHaving said that, I'm open to suggestions about why we cannot make such \nan estimate.\n\n\n> Then, to make the user live easier, there is the thing about human\n> perception, we can move brightness-levels to be optional and fall to\n> apply the human perception code if it's not specified. Here the thing\n> and point of discussion is, if the cie1931 is the right algorithm to\n> do the 'magic' in the driver. From what I investigated seems that is\n> but I might be wrong.\n\nIt's certainly more correct than linear ;-) .\n\nActually I don't recall you commenting on the idea that we could ditch \nthe fixed point code and simply have a default table built into the \ndriver that can be used if there is no brightness-levels property \n(interpreted by the same piecewise linear code as everything else).\n\nI suspect such a table could be fairly small.\n\n\n> Seems reasonable apply both solutions? I can send a second RFC with\n> both approaches.\n\nWorks for me.\n\n\nDaniel.\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=linaro.org header.i=@linaro.org\n\theader.b=\"OUo9Z5Yp\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xwrMY0wLQz9s7F\n\tfor ;\n\tTue, 19 Sep 2017 02:00:57 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1755849AbdIRQAz (ORCPT\n\t);\n\tMon, 18 Sep 2017 12:00:55 -0400","from mail-wr0-f177.google.com ([209.85.128.177]:46025 \"EHLO\n\tmail-wr0-f177.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1755838AbdIRQAx (ORCPT\n\t); Mon, 18 Sep 2017 12:00:53 -0400","by mail-wr0-f177.google.com with SMTP id m18so914008wrm.2\n\tfor ;\n\tMon, 18 Sep 2017 09:00:52 -0700 (PDT)","from [192.168.1.124]\n\t(cpc87211-aztw31-2-0-cust196.18-1.cable.virginm.net. [82.46.60.197])\n\tby smtp.googlemail.com with ESMTPSA id\n\tz51sm9124470wrb.22.2017.09.18.09.00.48\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tMon, 18 Sep 2017 09:00:49 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google;\n\th=subject:to:cc:references:from:message-id:date:user-agent\n\t:mime-version:in-reply-to:content-language:content-transfer-encoding; \n\tbh=s3LKKSC88+5/JZ7LgGircX1VkFTNVMoZ3sX3k1NL9yk=;\n\tb=OUo9Z5Ypeqy42NFlb+VtdPoKuOtkCFQm45msvYexcGN+C+VM5PSGBOalOATN9d7boO\n\t7adK7KJSPItucDZweFVch2vofAeVdBXIxkAzFR8/Xw8z4P2dLHgWSifbr8jTkdc6vY2N\n\tJlpsmET/MMtnZhTTHgquP/j5iuRCO5Bf7T0V4=","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:subject:to:cc:references:from:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-language\n\t:content-transfer-encoding;\n\tbh=s3LKKSC88+5/JZ7LgGircX1VkFTNVMoZ3sX3k1NL9yk=;\n\tb=IcPrC1HCGCKgp4/V0bvfhjh2KrDDsNWcIcSY3lscoTYCYdWOPx4ltUZW+eAhXV03pN\n\tTTiiN3zjZ7WHDrjHWU9/JoDnefWcf9oWW9VCH1SZnPpGSbQoMZ1kXaLzIDU1bToT9/at\n\t8t2hApAk0tJHYsAI9XaLtgdiUhhRGiucUKRbEofNPP475RONsuV4/NMUiXTTL3VFLpQE\n\t3LBzq3vMUzJwziKNyoXx38heVD4msW6Y5s7f5Ndk6plwGuLOVzsLpX8cm34eDstnG8fA\n\tL1Lx25zfJ78d8d6LrsvJwZ4T+ZrjYuz8xTWdNvVzAOvaxvhmo0eDN1gH7tIi5a6TkiwE\n\tJUPA==","X-Gm-Message-State":"AHPjjUimr8ZGsVtyr9pFBbItwWW/uZupPHHKytXcxmXyNT8XvU1kR/ew\n\tIa00EPQubvf0tnGB","X-Google-Smtp-Source":"ADKCNb4mbThPktdzyYuzA1yoSE2Lb/udI/MBqCu6LkHcOpcUhoeYEeQDBoYbbeI3FDjA96bICLVa1Q==","X-Received":"by 10.223.184.161 with SMTP id\n\ti30mr29475659wrf.147.1505750451564; \n\tMon, 18 Sep 2017 09:00:51 -0700 (PDT)","Subject":"Re: Re: [RFC 0/2] backlight: pwm_bl: support linear brightness to\n\thuman eye","To":"Enric Balletbo Serra ,\n\tDoug Anderson ","Cc":"Jingoo Han ,\n\tEnric Balletbo i Serra ,\n\tLee Jones , Richard Purdie , \n\tJacek Anaszewski ,\n\tPavel Machek , Rob Herring ,\n\tMark Rutland ,\n\tBrian Norris , \n\tGuenter Roeck , linux-leds@vger.kernel.org,\n\t\"devicetree@vger.kernel.org\" ,\n\t\"linux-kernel@vger.kernel.org\" ,\n\tAlexandru M Stan ","References":"<20170904153504.27963-1-enric.balletbo@collabora.com>\n\t<239c9153-c0ea-319c-b554-3c727b75c8cd@linaro.org>\n\t<000001d32664$db62b2a0$922817e0$@gmail.com>\n\t\n\t\n\t\n\t","From":"Daniel Thompson ","Message-ID":"<478868b7-ff09-1332-5459-e788d0adae99@linaro.org>","Date":"Mon, 18 Sep 2017 17:00:47 +0100","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"","Content-Type":"text/plain; charset=utf-8; format=flowed","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1771432,"web_url":"http://patchwork.ozlabs.org/comment/1771432/","msgid":"","list_archive_url":null,"date":"2017-09-19T22:27:13","subject":"Re: Re: [RFC 0/2] backlight: pwm_bl: support linear brightness to\n\thuman eye","submitter":{"id":4120,"url":"http://patchwork.ozlabs.org/api/people/4120/","name":"Enric Balletbo Serra","email":"eballetbo@gmail.com"},"content":"Hi Daniel,\n\n2017-09-18 18:00 GMT+02:00 Daniel Thompson :\n> On 14/09/17 11:46, Enric Balletbo Serra wrote:\n>>>>>\n>>>>> So far in these discussions folks have been assuming that if we just\n>>>>> apply cie1931 to the PWM Duty Cycle then we're done and we have\n>>>>> perceived brightness in Lumens. ...but I think that's not quite\n>>>>> right. There are more factors. Let's use the datasheet for a random\n>>>>> backlight driver, like RT8561A. There appears to be a public\n>>>>> datasheet at\n>>>>> .\n>>>>>\n>>>>> A) There may be a non-linear curve between PWM Duty Cycle and LED\n>>>>> Current (mA). The particular curve is different based on mode\n>>>>> (Digital Ctrl vs. Analog Ctrl) and also PWM Frequency. Sometimes this\n>>>>> curve is nearly linear for large parts of the curve but not the whole\n>>>>> curve. Sometimes even though the curve is nearly linear there is an\n>>>>> offset (AKA 10% duty cycle could still produce nearly zero light\n>>>>> output).\n>>>>>\n>>>>> B) There may be a non-linear curve between LED current and light\n>>>>> output in Watts (I think?).\n>>>>>\n>>>>> C) The human perception model means there is a non-linear curve\n>>>>> between light output in Watts and human perceived brightness in\n>>>>> Lumens.\n>>>>>\n>>>>> So A and B are hardware dependent and _do_ belong in the device tree\n>>>>> (IMHO).\n>>>>\n>>>>\n>>>>\n>>>> You forgot to model how to screen size and its maximum light output of\n>>>> the\n>>>> backlight impact pupil dilation ;-).\n>>>\n>>>\n>>> Silly me... Oops, I also forgot to account for the absolute humidity\n>>> of the room. Do you think we can require all backlights come with a\n>>> humidity sensor?\n>>>\n>>>\n>>>> Or... putting it another way, A and B are only relevant if they help us\n>>>> eliminate significant sources of error.\n>>>\n>>>\n>>> Right. ...so your point is we can't model everything and we just need\n>>> to choose what's important.\n>>>\n>>> I'll agree that \"B\" above might not be worth modelling (though I don't\n>>> know). ...but I think we need to do _something_ about A.\n>>>\n>>> From the datasheet I point at looking at \"Figure 8. LED Current vs.\n>>> ACTL PWM Dimming Duty Cycle\", it seems like we at least need to do\n>>> something to account for the curve if we happen to be running at 30\n>>> kHz for whatever reason. Specifically if we do no other work then any\n>>> duty cycle below 8% will result in no brightness. Eyeballing the\n>>> graph 10% duty cycle looks to be about 2% current.\n>>>\n>>> One option to solve this type of problem is to to specify a minimum\n>>> offset and assume things are linear after that offset. That might\n>>> work, but it also might prevent you from accessing some of those nice\n>>> low brightness points. Historically I have been frustrated when in\n>>> dark rooms that I couldn't set the brightness to be dim enough...\n>>>\n>>> The whole piecewise linear concept is that maybe you'd specify the\n>>> curve (in terms of milliPercent) like this (values found by measuring\n>>> datasheet curve with a ruler):\n>>>\n>>> <0 0>\n>>> <10000 1800> # 10% duty cycle gives 1.8% current\n>>> <12000 4300> # 12% duty cycle gives 4.3% current\n>>> <17000 10000> # 17% duty cycle gives 10% current\n>>> <93000 90000> # 93% duty cycle gives 90% current\n>>> <100000 100000> # 100% duty cycle gives 100% current\n>>>\n>>>\n>>>>> ...then the question is whether the device tree should specify the\n>>>>> curve so that the Watts scales linearly (and then the kernel adjust\n>>>>> for human perception) or so that Lumens scales linearly (which is\n>>>>> already adjusted for human perception).\n>>>>>\n>>>>> Historically I believe the device tree has always wanted it so that\n>>>>> Lumens scales linearly. So I guess the \"we don't do anything\" answer\n>>>>> is that the device tree should help account for for A + B + C.\n>>>>\n>>>>\n>>>>\n>>>> I would interpret the history slightly differently (although I'm not an\n>>>> authoritative historian here).\n>>>>\n>>>> There is a problem with the backlight interfaces (but entirely unrelated\n>>>> to\n>>>> Enric'c patch). The units the backlight users are not defined and varies\n>>>> from driver to driver.\n>>>>\n>>\n>> Based on this seems reasonable maintain current implementation to not\n>> break backward compability. Even, I think makes sense improve current\n>> implementation by adding somekind of piecewise linear concept to the\n>> brightness levels, similar to Doug's suggestion. So if we want, i.e,\n>> 256 levels or more, instead of specify the full table in the DT we can\n>> only specify some points in DT but the driver can expose to userspace\n>> more steps (how many?) between two brightness levels. Of course, this\n>> doesn't makes the live of the future users easier but I think will\n>> make the live of the current users of this interface more flexible\n>> (specially when you want lots of levels).\n>\n>\n> Ideally I'd like the driver to derive the number of steps based on the PWM\n> resolution it discovers (I don't entirely agree that having a large portion\n> of the slider map to no change is a good thing... we should be able to\n> estimate the smallest useful step size).\n>\n> Having said that, I'm open to suggestions about why we cannot make such an\n> estimate.\n>\n>\n>> Then, to make the user live easier, there is the thing about human\n>> perception, we can move brightness-levels to be optional and fall to\n>> apply the human perception code if it's not specified. Here the thing\n>> and point of discussion is, if the cie1931 is the right algorithm to\n>> do the 'magic' in the driver. From what I investigated seems that is\n>> but I might be wrong.\n>\n>\n> It's certainly more correct than linear ;-) .\n>\n> Actually I don't recall you commenting on the idea that we could ditch the\n> fixed point code and simply have a default table built into the driver that\n> can be used if there is no brightness-levels property (interpreted by the\n> same piecewise linear code as everything else).\n>\n\nSounds a good idea, was on my mind improve the fixed point code, but\nthis is better, indeed. I'm not sure if one table will be enough\nthough, maybe we need a table for every PWM resolution? I'll try to do\nsome tests on some different boards.\n\nEnric\n\n> I suspect such a table could be fairly small.\n>\n>\n>> Seems reasonable apply both solutions? I can send a second RFC with\n>> both approaches.\n>\n>\n> Works for me.\n>\n>\n> Daniel.\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"KzyckUNk\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xxcv957gmz9sBW\n\tfor ;\n\tWed, 20 Sep 2017 08:27:33 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751800AbdISW1S (ORCPT\n\t);\n\tTue, 19 Sep 2017 18:27:18 -0400","from mail-io0-f177.google.com ([209.85.223.177]:56651 \"EHLO\n\tmail-io0-f177.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751797AbdISW1P (ORCPT\n\t); Tue, 19 Sep 2017 18:27:15 -0400","by mail-io0-f177.google.com with SMTP id m103so2417025iod.13;\n\tTue, 19 Sep 2017 15:27:14 -0700 (PDT)","by 10.79.128.140 with HTTP; Tue, 19 Sep 2017 15:27:13 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=mime-version:in-reply-to:references:from:date:message-id:subject:to\n\t:cc; bh=LeXrGTfw6Ck7dx4r7cD5dCzWmRImntODotWQocoPcbM=;\n\tb=KzyckUNkN1iF8cv3doRTOdnstujOVe+k77Qu+tRaRjdHlSc06DwbPz6LJTHO5yTsTN\n\tMmwH3yYAessLokJkeh+ks3sqxECA4nfe310oJqGljNUypMdBSJFduLPsub4MSzM/bAgw\n\tjoW3EtEqr/m18CbT/TOnoEsX1aZDIWEXSNH/RLTqbrzQxtULRWsFbRjpZoABesVc/0/E\n\ttHtfqWLBliy9da4CjpNsAQ+VTgvt3b0Bxbz+4Pr8YX5J9qtpJh1O1tet9ZtIkLU/JUEq\n\tE7XYJ+UZzptD30EKAT3Z7Gqm4VWt6rwtJ1wtJZq1Ry9fnt8RiQrSlyPiqpkQHwY5Qqa2\n\t3rlQ==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc;\n\tbh=LeXrGTfw6Ck7dx4r7cD5dCzWmRImntODotWQocoPcbM=;\n\tb=ZO9GLNeGCGORMB1GgeYXTsyHmGZPDMkDMPS7pJHBnJl7WWZLiMLcjsSNEs6Uce5pgl\n\tJkHFRNtq3TJPB5QAm5FqAOOG6zyombCnhEbOFu9dW5vpcZ+Ur79/ZTqrENdvN6VoKn/Q\n\t0NgmSbl7+vlMGmYS0NJkbvZ0zwNDr9wLaG/I9aQugOVyDvzl9wxsi8b2Lgoro5rBaC44\n\tOftMv0v/3NZ+YRSdZyEzszW8yH0ShS7tG1l7G8K90J4kJTRHk8kLJX9pPbhE7zERwHof\n\tZ2fFTGXVLErkMkCw9E0MI4N4VWM1aFqW9VBSPKHeAh3sxf4eAhiVO1F1BWfEZnMmeUfc\n\tmlWA==","X-Gm-Message-State":"AHPjjUj19QN5Vv2n/Hmhwh9TXfaFoS1jYEdVto0eUL05TavyL7QwUkDS\n\tkRAqBr75NBUIjCC0cV8ghO8PJl/abpUeGEiFeWk=","X-Google-Smtp-Source":"AOwi7QBWV5cE5MsM7BKl+pyswJbllxpDANDJWcEb3Q8ojlLEgL2MiW0OVX5nenvJ1wSqRZcKBhtWP1mJYa7Zy/3cMfI=","X-Received":"by 10.107.152.207 with SMTP id\n\ta198mr4132871ioe.168.1505860034272; \n\tTue, 19 Sep 2017 15:27:14 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"<478868b7-ff09-1332-5459-e788d0adae99@linaro.org>","References":"<20170904153504.27963-1-enric.balletbo@collabora.com>\n\t<239c9153-c0ea-319c-b554-3c727b75c8cd@linaro.org>\n\t<000001d32664$db62b2a0$922817e0$@gmail.com>\n\t\n\t\n\t\n\t\n\t<478868b7-ff09-1332-5459-e788d0adae99@linaro.org>","From":"Enric Balletbo Serra ","Date":"Wed, 20 Sep 2017 00:27:13 +0200","Message-ID":"","Subject":"Re: Re: [RFC 0/2] backlight: pwm_bl: support linear brightness to\n\thuman eye","To":"Daniel Thompson ","Cc":"Doug Anderson , Jingoo Han , \n\tEnric Balletbo i Serra ,\n\tLee Jones , Richard Purdie