Received: by 2002:a17:90a:b81:0:0:0:0 with SMTP id 1csp1330084pjr; Fri, 16 Aug 2019 12:49:04 -0700 (PDT) X-Google-Smtp-Source: APXvYqwjl2jNMv9ljKUeVdLjxMzUm/GL1F7PCSvjwjzVWROcQUUDmF794u9LQnIpCyxLVflcVFvy X-Received: by 2002:a63:2026:: with SMTP id g38mr9021892pgg.172.1565984944334; Fri, 16 Aug 2019 12:49:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1565984944; cv=none; d=google.com; s=arc-20160816; b=eE7YqPZp1WNxQQRXpyQmiiS03pG4lKCnncwhjfGiCBGixq0wiWsY8mDw19PqSzACiq /d9uA930DP8y97lMaCu8BwyY6upBTt2GkLbA5NFovYIPPF83WBEyuvvUISmEyORurSBN TOWGPxn5VspxlVK9eqP1fVnumcxpvf7HvsVwakGCYo+L5MqQrU9MpMqb2uyw/uzY5R98 6Ktq2hnbchmaVMLwHtCiPXMfSryCoei5QtJjkvKl59gMg6uYDjIPRWj+dbUwWDDPLkNP vuynPhDiDTytkGgK/4aeG2fD+ynHXlpclVrugbExqWbE7JgVFUT7lPso6ro7t13rWXDj EmGQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=hKj1wGEyDf5GT2TIe5qFfdCvFZz+4+MOEGUT5Tr6uhA=; b=b9n7k5Vip/DtDy30p9ksz0N6yqN/kzqNuQG+Pt5Kx62U45SqTuoSHpe/IcdqMcG4Eb 9hS7xa6lMgOIv7NayLjqsU/mBVL7Dz4VVfrAL3XHBgrEPfDV7SyiQTBc3e2by8YqRvE0 oFc4XWUvFXampT3YtTR+1TeR0pia8XYxJo0FrkqUlIoUz+GLA9vL+UgTTfPAjC6o15FM OCyXoSmU5tiIKzSKaG25cCqr0Nnb4pODiRBq6F0/ejOVyFx7rYNgSp3/m+TcnIgLfmOs +Nl0s8cTZW/p7usIm4EohtCfPskv4OtmtMpxqx0yGLCfcSI88ZF/hEkJxG6KlBlfleoy T/jg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r26si4461721pgv.189.2019.08.16.12.48.45; Fri, 16 Aug 2019 12:49:04 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727593AbfHPTsG (ORCPT + 99 others); Fri, 16 Aug 2019 15:48:06 -0400 Received: from metis.ext.pengutronix.de ([85.220.165.71]:33891 "EHLO metis.ext.pengutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726527AbfHPTsF (ORCPT ); Fri, 16 Aug 2019 15:48:05 -0400 Received: from pty.hi.pengutronix.de ([2001:67c:670:100:1d::c5]) by metis.ext.pengutronix.de with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1hyiCa-0000qu-4D; Fri, 16 Aug 2019 21:47:56 +0200 Received: from ukl by pty.hi.pengutronix.de with local (Exim 4.89) (envelope-from ) id 1hyiCY-0006aL-DA; Fri, 16 Aug 2019 21:47:54 +0200 Date: Fri, 16 Aug 2019 21:47:54 +0200 From: Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= To: Matthias Kaehlcke 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: <20190816194754.ldzjqy2yjonfvaat@pengutronix.de> References: <20190709190007.91260-1-mka@chromium.org> <20190709190007.91260-3-mka@chromium.org> <20190816165148.7keg45fmlndr22fl@pengutronix.de> <20190816175157.GT250418@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20190816175157.GT250418@google.com> User-Agent: NeoMutt/20170113 (1.7.2) X-SA-Exim-Connect-IP: 2001:67c:670:100:1d::c5 X-SA-Exim-Mail-From: ukl@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org 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 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? 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. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-K?nig | Industrial Linux Solutions | http://www.pengutronix.de/ |