From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6C609C3A59D for ; Fri, 16 Aug 2019 21:10:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3F4FE21726 for ; Fri, 16 Aug 2019 21:10:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="njDzsoq5" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727746AbfHPVK4 (ORCPT ); Fri, 16 Aug 2019 17:10:56 -0400 Received: from mail-pg1-f196.google.com ([209.85.215.196]:34981 "EHLO mail-pg1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727714AbfHPVKz (ORCPT ); Fri, 16 Aug 2019 17:10:55 -0400 Received: by mail-pg1-f196.google.com with SMTP id n4so3541116pgv.2 for ; Fri, 16 Aug 2019 14:10:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=omJ8IItzAJQAPO3tmBsIeieU2u668VutyYMbYeYnfXY=; b=njDzsoq5Y3wMuR1vIA+MGdo+BzO+B/f9SdopkAr0xFHgrStJXA7Ik/UCP8qP6cVwv4 lzcubXnyj8uqy6qltZibMeg3xHuVhU5Jzu2yjdBrpex1+Y5E/vNWNcIBdyff7zVFbDPv S7ia2p8XxRtlv61pL9/W76ViOPP2pTn+6Amts= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=omJ8IItzAJQAPO3tmBsIeieU2u668VutyYMbYeYnfXY=; b=XLMkHo+vXu9cvXfW285W19CcKEN95vyKLS8kPIaDZHPww0tSmf780sxy/V+7nkeEfF 7h/TnHBaQbug0ndqLsE3GMbqzdwZ7OjyVQVfwx0cXwYJZSopxgww/npE6MQR7YEfz54l mF3swaJt8F5n1o1kA+Kf5eWh7kPB7Vgvl7ynQKoVb1gi2tCTB0Q1zhVbjNN9EI808sQo bwPQqwuQjNbrWO1ckUCUJpxt+HJdIzCe3bon/eHKCnrRQ7PDPfSdUuibwc52FT2O6Y9f ZXdy9pWMt9uwrCWv7hFN1QXF9Qp80C82z5sLVcbrfx/+ZEY229Rdog0oZ3sNre6s2uL6 Rdqg== X-Gm-Message-State: APjAAAXsEI1Z7Mg8gEnU6RyNPv9hbq/YkoeP19CBXmr0hy56rzhw/gmv LexD4EOHizc8LN3ZpzSnfWopjg== X-Google-Smtp-Source: APXvYqx/9biztZysWMeW6sR50lVpQxokVJNMUldAOC4JXEFv4e9JNEnzqyrf//WtPwGuqvJWoi3P2A== X-Received: by 2002:aa7:9293:: with SMTP id j19mr13113379pfa.90.1565989854997; Fri, 16 Aug 2019 14:10:54 -0700 (PDT) Received: from localhost ([2620:15c:202:1:75a:3f6e:21d:9374]) by smtp.gmail.com with ESMTPSA id c71sm7437581pfc.106.2019.08.16.14.10.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Aug 2019 14:10:54 -0700 (PDT) Date: Fri, 16 Aug 2019 14:10:51 -0700 From: Matthias Kaehlcke To: Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= Cc: Thierry Reding , Lee Jones , Daniel Thompson , Jingoo Han , Bartlomiej Zolnierkiewicz , linux-pwm@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org, Enric Balletbo i Serra , Douglas Anderson , Brian Norris , Pavel Machek , Jacek Anaszewski Subject: Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs Message-ID: <20190816211051.GV250418@google.com> References: <20190709190007.91260-1-mka@chromium.org> <20190709190007.91260-3-mka@chromium.org> <20190816165148.7keg45fmlndr22fl@pengutronix.de> <20190816175157.GT250418@google.com> <20190816194754.ldzjqy2yjonfvaat@pengutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20190816194754.ldzjqy2yjonfvaat@pengutronix.de> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Aug 16, 2019 at 09:47:54PM +0200, Uwe Kleine-König wrote: > On Fri, Aug 16, 2019 at 10:51:57AM -0700, Matthias Kaehlcke wrote: > > Hi Uwe, > > > > On Fri, Aug 16, 2019 at 06:51:48PM +0200, Uwe Kleine-König wrote: > > > On Tue, Jul 09, 2019 at 12:00:05PM -0700, Matthias Kaehlcke wrote: > > > > Backlight brightness curves can have different shapes. The two main > > > > types are linear and non-linear curves. The human eye doesn't > > > > perceive linearly increasing/decreasing brightness as linear (see > > > > also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED > > > > linearly to human eye"), hence many backlights use non-linear (often > > > > logarithmic) brightness curves. The type of curve currently is opaque > > > > to userspace, so userspace often uses more or less reliable heuristics > > > > (like the number of brightness levels) to decide whether to treat a > > > > backlight device as linear or non-linear. > > > > > > > > Export the type of the brightness curve via the new sysfs attribute > > > > 'scale'. The value of the attribute can be 'linear', 'non-linear' or > > > > 'unknown'. For devices that don't provide information about the scale > > > > of their brightness curve the value of the 'scale' attribute is 'unknown'. > > > > > > > > Signed-off-by: Matthias Kaehlcke > > > > > > I wonder what kind of problem you are solving here. Can you describe > > > that in a few words? > > > > The human eye perceives brightness in a logarithmic manner. For > > backlights with a linear brightness curve brightness controls like > > sliders need to use a mapping to achieve a behavior that is perceived > > as linear-ish (more details: http://www.pathwaylighting.com/products/downloads/brochure/technical_materials_1466797044_Linear+vs+Logarithmic+Dimming+White+Paper.pdf) > > > > As of now userspace doesn't have information about the type of the > > brightness curve, and often uses heuristics to make a guess, which may > > be right most of the time, but not always. The new attribute eliminates > > the need to guess. > > This is about backlights right? So the kernel provides to userspace an > interval [0, x] for some x and depending on the physics of the the > backlight configuring x/2 (probably?) either means 50% measured light or > 50% perceived light, right? correct > I wonder if it would be possible instead of giving different backlight > implementations the freedom to use either linear or logarithmic (or > quadratic?) scaling and tell userspace which of the options were picked > require the drivers to provide a (say) linear scaling and then userspace > wouldn't need to care about the exact physics. In an ideal world the backlight interface would be consistent as you suggest, however there are plenty of existing devices which use the 'other' scaling (regardless of which is chosen as the 'correct' one). Userspace still has to deal with these. And changing previously 'logarithmic' drivers to linear (or viceversa) may 'break' userspace, when it keeps using its 'old' scaling, which now isn't correct anymore.