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=-2.4 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no 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 78F6CC3A59E for ; Wed, 21 Aug 2019 14:16:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 400C622D6D for ; Wed, 21 Aug 2019 14:16:25 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="jmZFwO7a" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729306AbfHUOQY (ORCPT ); Wed, 21 Aug 2019 10:16:24 -0400 Received: from mail-wr1-f65.google.com ([209.85.221.65]:40746 "EHLO mail-wr1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726371AbfHUOQW (ORCPT ); Wed, 21 Aug 2019 10:16:22 -0400 Received: by mail-wr1-f65.google.com with SMTP id c3so2200209wrd.7 for ; Wed, 21 Aug 2019 07:16:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.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=cdtuJEJPiRHYBRkWLphaMlBKW6Qllc1jRrn7Evl95W0=; b=jmZFwO7aPbSPs4T3u6HFT7/UzQEynyx3CLoy6cPRt8GFo+A0DNBZKk7hz3rjw22uVC uJadNeGBW0V5GinSEgjuPf3kwqOUTeenRZvKcchdVxltfYwFSCRv0tWFoYws6SLI5hUf RUzh2AMZp4k+OkvBYlRTcvH/evX96Zb20+IupWV+atHwY9RS5NoM0+/03tP7MYVjfIMo 0Af1Xka7SljkMAGPasYem64gsOBd+9foTNIpBUu2Duybs1OqZAosGxlUqHumHbYp9C3E NMx3eiNgPewmBOVXvNhD4WWzws5NHWBEP4KY8S/GVTWk3DdNPq9yLsLk67u3Z/u7vQpE Bdow== 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=cdtuJEJPiRHYBRkWLphaMlBKW6Qllc1jRrn7Evl95W0=; b=qIpSUqp4og7rUzv5/WOz80QkxMM1o/0X+hupZNIeybwDaolRRwMlLN2Uwshm5463l0 +8tKh4X72ybUDGw114A5hDGUzWd78jh4pLW2OAk76v/XalBbTMn1HDwk6ZqVzZ8+yG6V F/UqQjf5MlNJvsXPCkFXB0g2aTcN2Y06wxUTTpgjh0ukb+B0GAt1F18kzB8kaoKeOnBI fpFi4CYloXvPG1rcMwq8HMTjj+qdLDxQ3zaFq7Y9BE7n+FkSxVGN2e1UhHRIvtHCnWbK SrIKMi9YFamjBd7LVbdHq1Cc/SEUebPucU7fJ2trLpomJn4kbRIHigyd7/IWabfzq4Yq kafA== X-Gm-Message-State: APjAAAXPh4Z/VFx6eqBY4/tdiTPpujUpT19RxYIO6BZ2xQg28Fh/bM3z 0s8WvacLXikPSKpXuh4C5HIdRw== X-Google-Smtp-Source: APXvYqyWXU+FCJwHRqtC9ZXeDqIM9kre79CXAhUyQKtWQkywMQ1AtsuSunZHdIngi7gFPJHEJ0plDw== X-Received: by 2002:adf:82d4:: with SMTP id 78mr38474896wrc.85.1566396980736; Wed, 21 Aug 2019 07:16:20 -0700 (PDT) Received: from holly.lan (cpc141214-aztw34-2-0-cust773.18-1.cable.virginm.net. [86.9.19.6]) by smtp.gmail.com with ESMTPSA id g7sm203936wmg.8.2019.08.21.07.16.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Aug 2019 07:16:19 -0700 (PDT) Date: Wed, 21 Aug 2019 15:16:17 +0100 From: Daniel Thompson To: Daniel Vetter Cc: Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= , linux-pwm , Linux Fbdev development list , Sascha Hauer , Bartlomiej Zolnierkiewicz , Jingoo Han , Brian Norris , Linux Kernel Mailing List , dri-devel , Douglas Anderson , Matthias Kaehlcke , Thierry Reding , Jacek Anaszewski , Pavel Machek , Enric Balletbo i Serra , Lee Jones Subject: Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs Message-ID: <20190821141617.e5avfbyvooddixcd@holly.lan> 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> <20190816211051.GV250418@google.com> <20190819054628.asw3cxp46w3rpml7@pengutronix.de> <20190819095037.h3gig3quyhnzshm7@holly.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20180716 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 20, 2019 at 04:49:21PM +0200, Daniel Vetter wrote: > On Mon, Aug 19, 2019 at 11:50 AM Daniel Thompson > wrote: > > On Mon, Aug 19, 2019 at 07:46:28AM +0200, Uwe Kleine-König wrote: > > > And the big upside is that in the end (i.e. when all kernel drivers and > > > userspace applications are adapted to provide/consume the "correct" > > > curve) the result is simpler. > > > > My view is that this convergence will eventually be achieved but it will > > happen through the obsolescence of the backlight sysfs interface. The > > sysfs interface has other flaws, in particular no integration with the > > DRM connector API. > > > > Thus I would expect an alternative interface to emerge, most likely as > > part of the DRM connector API. I'd expect such a new API to a > > perceptual scale and to have a fixed max brightness with enough > > steps to support animated backlight effects (IIRC 0..100 has been > > proposed in the past) > > > > In the mean time getting the existing collection of backlight drivers > > marked up as linear/logarithmic/etc will ease the introduction of that > > API because, within the kernel, we might have gathered enough knowledge > > to have some hope of correctly mapping each backlight onto a > > standardized scale. > > In case people wonder why the drm connector based backlight interface > hasn't happened ages ago, some more context: > > - userspace (well libbacklight) selects the right backlight, using > some priority search. Plus blacklists in drivers to make sure they're > not overriding the real backlight driver (e.g. acpi has higher > priority in libbacklight, but on modern system it's not the backlight > driver you want. If we move that into the kernel it's going to be > somewhat a mess, since defacto you never know when loading is complete > and you actually have the right backlight driver. > > This isn't a problem on DT platforms, but really just for x86/acpi > platforms. But if we don't fix them, then userspace adoption of these > new interfaces will likely be too low to matter. > > - second issue is that right now the kms client is supposed to handle > backlight around modeset, like fbdev does through the fb notifier. > Except for drivers which do handle the backlight across modesets, but > maybe not the right backlight. If we move the backlight interface to > drm connectors then the right thing would be for the drm driver to > handle backlight enable/disable across modesets. But to make that > work, userspace needs to stop touching it (otherwise userspace first > disables, then the kernel and then on restore the two fight and > usually black screen wins), and that's a bit a tricky uapi problem of > not breaking existing userspace. > > - finally there's some userspace which assumes the lowest backlight > setting is actually off, and uses that to do fast modesets. This > doesn't work on most ACPI backlights, so I think that problem isn't > widespread. > > Anyway from watching from afar, I think this clarification on what the > backlight scale means internally should at least help us somewhat in > the long term. But the long term solution itself needs someone with > way too much time I fear, so lets not hold up anything on that. Thanks for sharing your views on this. Daniel. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Thompson Subject: Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs Date: Wed, 21 Aug 2019 15:16:17 +0100 Message-ID: <20190821141617.e5avfbyvooddixcd@holly.lan> 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> <20190816211051.GV250418@google.com> <20190819054628.asw3cxp46w3rpml7@pengutronix.de> <20190819095037.h3gig3quyhnzshm7@holly.lan> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Daniel Vetter Cc: linux-pwm , Linux Fbdev development list , Pavel Machek , Bartlomiej Zolnierkiewicz , Jingoo Han , Brian Norris , Linux Kernel Mailing List , dri-devel , Douglas Anderson , Matthias Kaehlcke , Thierry Reding , Jacek Anaszewski , Sascha Hauer , Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= , Enric Balletbo i Serra , Lee Jones List-Id: linux-pwm@vger.kernel.org T24gVHVlLCBBdWcgMjAsIDIwMTkgYXQgMDQ6NDk6MjFQTSArMDIwMCwgRGFuaWVsIFZldHRlciB3 cm90ZToKPiBPbiBNb24sIEF1ZyAxOSwgMjAxOSBhdCAxMTo1MCBBTSBEYW5pZWwgVGhvbXBzb24K PiA8ZGFuaWVsLnRob21wc29uQGxpbmFyby5vcmc+IHdyb3RlOgo+ID4gT24gTW9uLCBBdWcgMTks IDIwMTkgYXQgMDc6NDY6MjhBTSArMDIwMCwgVXdlIEtsZWluZS1Lw7ZuaWcgd3JvdGU6Cj4gPiA+ IEFuZCB0aGUgYmlnIHVwc2lkZSBpcyB0aGF0IGluIHRoZSBlbmQgKGkuZS4gd2hlbiBhbGwga2Vy bmVsIGRyaXZlcnMgYW5kCj4gPiA+IHVzZXJzcGFjZSBhcHBsaWNhdGlvbnMgYXJlIGFkYXB0ZWQg dG8gcHJvdmlkZS9jb25zdW1lIHRoZSAiY29ycmVjdCIKPiA+ID4gY3VydmUpIHRoZSByZXN1bHQg aXMgc2ltcGxlci4KPiA+Cj4gPiBNeSB2aWV3IGlzIHRoYXQgdGhpcyBjb252ZXJnZW5jZSB3aWxs IGV2ZW50dWFsbHkgYmUgYWNoaWV2ZWQgYnV0IGl0IHdpbGwKPiA+IGhhcHBlbiB0aHJvdWdoIHRo ZSBvYnNvbGVzY2VuY2Ugb2YgdGhlIGJhY2tsaWdodCBzeXNmcyBpbnRlcmZhY2UuIFRoZQo+ID4g c3lzZnMgaW50ZXJmYWNlIGhhcyBvdGhlciBmbGF3cywgaW4gcGFydGljdWxhciBubyBpbnRlZ3Jh dGlvbiB3aXRoIHRoZQo+ID4gRFJNIGNvbm5lY3RvciBBUEkuCj4gPgo+ID4gVGh1cyBJIHdvdWxk IGV4cGVjdCBhbiBhbHRlcm5hdGl2ZSBpbnRlcmZhY2UgdG8gZW1lcmdlLCBtb3N0IGxpa2VseSBh cwo+ID4gcGFydCBvZiB0aGUgRFJNIGNvbm5lY3RvciBBUEkuIEknZCBleHBlY3Qgc3VjaCBhIG5l dyBBUEkgdG8gYQo+ID4gcGVyY2VwdHVhbCBzY2FsZSBhbmQgdG8gaGF2ZSBhIGZpeGVkIG1heCBi cmlnaHRuZXNzIHdpdGggZW5vdWdoCj4gPiBzdGVwcyB0byBzdXBwb3J0IGFuaW1hdGVkIGJhY2ts aWdodCBlZmZlY3RzIChJSVJDIDAuLjEwMCBoYXMgYmVlbgo+ID4gcHJvcG9zZWQgaW4gdGhlIHBh c3QpCj4gPgo+ID4gSW4gdGhlIG1lYW4gdGltZSBnZXR0aW5nIHRoZSBleGlzdGluZyBjb2xsZWN0 aW9uIG9mIGJhY2tsaWdodCBkcml2ZXJzCj4gPiBtYXJrZWQgdXAgYXMgbGluZWFyL2xvZ2FyaXRo bWljL2V0YyB3aWxsIGVhc2UgdGhlIGludHJvZHVjdGlvbiBvZiB0aGF0Cj4gPiBBUEkgYmVjYXVz ZSwgd2l0aGluIHRoZSBrZXJuZWwsIHdlIG1pZ2h0IGhhdmUgZ2F0aGVyZWQgZW5vdWdoIGtub3ds ZWRnZQo+ID4gdG8gaGF2ZSBzb21lIGhvcGUgb2YgY29ycmVjdGx5IG1hcHBpbmcgZWFjaCBiYWNr bGlnaHQgb250byBhCj4gPiBzdGFuZGFyZGl6ZWQgc2NhbGUuCj4gCj4gSW4gY2FzZSBwZW9wbGUg d29uZGVyIHdoeSB0aGUgZHJtIGNvbm5lY3RvciBiYXNlZCBiYWNrbGlnaHQgaW50ZXJmYWNlCj4g aGFzbid0IGhhcHBlbmVkIGFnZXMgYWdvLCBzb21lIG1vcmUgY29udGV4dDoKPiAKPiAtIHVzZXJz cGFjZSAod2VsbCBsaWJiYWNrbGlnaHQpIHNlbGVjdHMgdGhlIHJpZ2h0IGJhY2tsaWdodCwgdXNp bmcKPiBzb21lIHByaW9yaXR5IHNlYXJjaC4gUGx1cyBibGFja2xpc3RzIGluIGRyaXZlcnMgdG8g bWFrZSBzdXJlIHRoZXkncmUKPiBub3Qgb3ZlcnJpZGluZyB0aGUgcmVhbCBiYWNrbGlnaHQgZHJp dmVyIChlLmcuIGFjcGkgaGFzIGhpZ2hlcgo+IHByaW9yaXR5IGluIGxpYmJhY2tsaWdodCwgYnV0 IG9uIG1vZGVybiBzeXN0ZW0gaXQncyBub3QgdGhlIGJhY2tsaWdodAo+IGRyaXZlciB5b3Ugd2Fu dC4gSWYgd2UgbW92ZSB0aGF0IGludG8gdGhlIGtlcm5lbCBpdCdzIGdvaW5nIHRvIGJlCj4gc29t ZXdoYXQgYSBtZXNzLCBzaW5jZSBkZWZhY3RvIHlvdSBuZXZlciBrbm93IHdoZW4gbG9hZGluZyBp cyBjb21wbGV0ZQo+IGFuZCB5b3UgYWN0dWFsbHkgaGF2ZSB0aGUgcmlnaHQgYmFja2xpZ2h0IGRy aXZlci4KPiAKPiBUaGlzIGlzbid0IGEgcHJvYmxlbSBvbiBEVCBwbGF0Zm9ybXMsIGJ1dCByZWFs bHkganVzdCBmb3IgeDg2L2FjcGkKPiBwbGF0Zm9ybXMuIEJ1dCBpZiB3ZSBkb24ndCBmaXggdGhl bSwgdGhlbiB1c2Vyc3BhY2UgYWRvcHRpb24gb2YgdGhlc2UKPiBuZXcgaW50ZXJmYWNlcyB3aWxs IGxpa2VseSBiZSB0b28gbG93IHRvIG1hdHRlci4KPiAKPiAtIHNlY29uZCBpc3N1ZSBpcyB0aGF0 IHJpZ2h0IG5vdyB0aGUga21zIGNsaWVudCBpcyBzdXBwb3NlZCB0byBoYW5kbGUKPiBiYWNrbGln aHQgYXJvdW5kIG1vZGVzZXQsIGxpa2UgZmJkZXYgZG9lcyB0aHJvdWdoIHRoZSBmYiBub3RpZmll ci4KPiBFeGNlcHQgZm9yIGRyaXZlcnMgd2hpY2ggZG8gaGFuZGxlIHRoZSBiYWNrbGlnaHQgYWNy b3NzIG1vZGVzZXRzLCBidXQKPiBtYXliZSBub3QgdGhlIHJpZ2h0IGJhY2tsaWdodC4gSWYgd2Ug bW92ZSB0aGUgYmFja2xpZ2h0IGludGVyZmFjZSB0bwo+IGRybSBjb25uZWN0b3JzIHRoZW4gdGhl IHJpZ2h0IHRoaW5nIHdvdWxkIGJlIGZvciB0aGUgZHJtIGRyaXZlciB0bwo+IGhhbmRsZSBiYWNr bGlnaHQgZW5hYmxlL2Rpc2FibGUgYWNyb3NzIG1vZGVzZXRzLiBCdXQgdG8gbWFrZSB0aGF0Cj4g d29yaywgdXNlcnNwYWNlIG5lZWRzIHRvIHN0b3AgdG91Y2hpbmcgaXQgKG90aGVyd2lzZSB1c2Vy c3BhY2UgZmlyc3QKPiBkaXNhYmxlcywgdGhlbiB0aGUga2VybmVsIGFuZCB0aGVuIG9uIHJlc3Rv cmUgdGhlIHR3byBmaWdodCBhbmQKPiB1c3VhbGx5IGJsYWNrIHNjcmVlbiB3aW5zKSwgYW5kIHRo YXQncyBhIGJpdCBhIHRyaWNreSB1YXBpIHByb2JsZW0gb2YKPiBub3QgYnJlYWtpbmcgZXhpc3Rp bmcgdXNlcnNwYWNlLgo+IAo+IC0gZmluYWxseSB0aGVyZSdzIHNvbWUgdXNlcnNwYWNlIHdoaWNo IGFzc3VtZXMgdGhlIGxvd2VzdCBiYWNrbGlnaHQKPiBzZXR0aW5nIGlzIGFjdHVhbGx5IG9mZiwg YW5kIHVzZXMgdGhhdCB0byBkbyBmYXN0IG1vZGVzZXRzLiBUaGlzCj4gZG9lc24ndCB3b3JrIG9u IG1vc3QgQUNQSSBiYWNrbGlnaHRzLCBzbyBJIHRoaW5rIHRoYXQgcHJvYmxlbSBpc24ndAo+IHdp ZGVzcHJlYWQuCj4gCj4gQW55d2F5IGZyb20gd2F0Y2hpbmcgZnJvbSBhZmFyLCBJIHRoaW5rIHRo aXMgY2xhcmlmaWNhdGlvbiBvbiB3aGF0IHRoZQo+IGJhY2tsaWdodCBzY2FsZSBtZWFucyBpbnRl cm5hbGx5IHNob3VsZCBhdCBsZWFzdCBoZWxwIHVzIHNvbWV3aGF0IGluCj4gdGhlIGxvbmcgdGVy bS4gQnV0IHRoZSBsb25nIHRlcm0gc29sdXRpb24gaXRzZWxmIG5lZWRzIHNvbWVvbmUgd2l0aAo+ IHdheSB0b28gbXVjaCB0aW1lIEkgZmVhciwgc28gbGV0cyBub3QgaG9sZCB1cCBhbnl0aGluZyBv biB0aGF0LgoKVGhhbmtzIGZvciBzaGFyaW5nIHlvdXIgdmlld3Mgb24gdGhpcy4KCgpEYW5pZWwu Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmRyaS1kZXZl bCBtYWlsaW5nIGxpc3QKZHJpLWRldmVsQGxpc3RzLmZyZWVkZXNrdG9wLm9yZwpodHRwczovL2xp c3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RyaS1kZXZlbA== From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Thompson Date: Wed, 21 Aug 2019 14:16:17 +0000 Subject: Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs Message-Id: <20190821141617.e5avfbyvooddixcd@holly.lan> List-Id: 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> <20190816211051.GV250418@google.com> <20190819054628.asw3cxp46w3rpml7@pengutronix.de> <20190819095037.h3gig3quyhnzshm7@holly.lan> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: Daniel Vetter Cc: linux-pwm , Linux Fbdev development list , Pavel Machek , Bartlomiej Zolnierkiewicz , Jingoo Han , Brian Norris , Linux Kernel Mailing List , dri-devel , Douglas Anderson , Matthias Kaehlcke , Thierry Reding , Jacek Anaszewski , Sascha Hauer , Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= , Enric Balletbo i Serra , Lee Jones On Tue, Aug 20, 2019 at 04:49:21PM +0200, Daniel Vetter wrote: > On Mon, Aug 19, 2019 at 11:50 AM Daniel Thompson > wrote: > > On Mon, Aug 19, 2019 at 07:46:28AM +0200, Uwe Kleine-K=F6nig wrote: > > > And the big upside is that in the end (i.e. when all kernel drivers a= nd > > > userspace applications are adapted to provide/consume the "correct" > > > curve) the result is simpler. > > > > My view is that this convergence will eventually be achieved but it will > > happen through the obsolescence of the backlight sysfs interface. The > > sysfs interface has other flaws, in particular no integration with the > > DRM connector API. > > > > Thus I would expect an alternative interface to emerge, most likely as > > part of the DRM connector API. I'd expect such a new API to a > > perceptual scale and to have a fixed max brightness with enough > > steps to support animated backlight effects (IIRC 0..100 has been > > proposed in the past) > > > > In the mean time getting the existing collection of backlight drivers > > marked up as linear/logarithmic/etc will ease the introduction of that > > API because, within the kernel, we might have gathered enough knowledge > > to have some hope of correctly mapping each backlight onto a > > standardized scale. >=20 > In case people wonder why the drm connector based backlight interface > hasn't happened ages ago, some more context: >=20 > - userspace (well libbacklight) selects the right backlight, using > some priority search. Plus blacklists in drivers to make sure they're > not overriding the real backlight driver (e.g. acpi has higher > priority in libbacklight, but on modern system it's not the backlight > driver you want. If we move that into the kernel it's going to be > somewhat a mess, since defacto you never know when loading is complete > and you actually have the right backlight driver. >=20 > This isn't a problem on DT platforms, but really just for x86/acpi > platforms. But if we don't fix them, then userspace adoption of these > new interfaces will likely be too low to matter. >=20 > - second issue is that right now the kms client is supposed to handle > backlight around modeset, like fbdev does through the fb notifier. > Except for drivers which do handle the backlight across modesets, but > maybe not the right backlight. If we move the backlight interface to > drm connectors then the right thing would be for the drm driver to > handle backlight enable/disable across modesets. But to make that > work, userspace needs to stop touching it (otherwise userspace first > disables, then the kernel and then on restore the two fight and > usually black screen wins), and that's a bit a tricky uapi problem of > not breaking existing userspace. >=20 > - finally there's some userspace which assumes the lowest backlight > setting is actually off, and uses that to do fast modesets. This > doesn't work on most ACPI backlights, so I think that problem isn't > widespread. >=20 > Anyway from watching from afar, I think this clarification on what the > backlight scale means internally should at least help us somewhat in > the long term. But the long term solution itself needs someone with > way too much time I fear, so lets not hold up anything on that. Thanks for sharing your views on this. Daniel.