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 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 503BFECDFA1 for ; Tue, 25 Oct 2022 23:41:05 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id CBA6E10E1E6; Tue, 25 Oct 2022 23:40:49 +0000 (UTC) Received: from cavan.codon.org.uk (cavan.codon.org.uk [176.126.240.207]) by gabe.freedesktop.org (Postfix) with ESMTPS id 137F310E1A8; Tue, 25 Oct 2022 23:40:42 +0000 (UTC) Received: by cavan.codon.org.uk (Postfix, from userid 1000) id 9794340A8A; Wed, 26 Oct 2022 00:40:40 +0100 (BST) Date: Wed, 26 Oct 2022 00:40:40 +0100 From: Matthew Garrett To: Hans de Goede Message-ID: <20221025234040.GA27673@srcf.ucam.org> References: <20220825143726.269890-1-hdegoede@redhat.com> <20220825143726.269890-3-hdegoede@redhat.com> <42a5f2c9-a1dc-8fc0-7334-fe6c390ecfbb@redhat.com> <20221024203057.GA28675@srcf.ucam.org> <8f53b8b6-ead2-22f5-16f7-65b31f7cc05c@redhat.com> <20221025193248.GA21457@srcf.ucam.org> <144cd47e-42dc-2b84-1a90-ea5e080e08a3@redhat.com> <20221025204043.GA23306@srcf.ucam.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [Nouveau] [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2) X-BeenThere: nouveau@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Nouveau development list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Pan@freedesktop.org, "Rafael J . Wysocki" , nouveau@lists.freedesktop.org, Joonas Lahtinen , dri-devel@lists.freedesktop.org, platform-driver-x86@vger.kernel.org, Dmitry Osipenko , amd-gfx@lists.freedesktop.org, linux-acpi@vger.kernel.org, Ben Skeggs , David Airlie , Len Brown , Daniel Dadap , Jani Nikula , intel-gfx , Maarten Lankhorst , Jani Nikula , Mark Gross , Maxime Ripard , Rodrigo Vivi , Mika Westerberg , Andy Shevchenko , Tvrtko Ursulin , Xinhui , Alex Deucher , Christian =?iso-8859-1?Q?K=F6nig?= Errors-To: nouveau-bounces@lists.freedesktop.org Sender: "Nouveau" On Wed, Oct 26, 2022 at 01:27:25AM +0200, Hans de Goede wrote: > this code should actually set the ACPI_VIDEO_BACKLIGHT flag: > drivers/acpi/scan.c: > > static acpi_status > acpi_backlight_cap_match(acpi_handle handle, u32 level, void *context, > void **return_value) > { > long *cap = context; > > if (acpi_has_method(handle, "_BCM") && > acpi_has_method(handle, "_BCL")) { > acpi_handle_debug(handle, "Found generic backlight support\n"); > *cap |= ACPI_VIDEO_BACKLIGHT; > /* We have backlight support, no need to scan further */ > return AE_CTRL_TERMINATE; > } > return 0; > } Ah, yeah, my local tree no longer matches the upstream behaviour because I've hacked the EC firmware to remove the backlight trigger because it had an extremely poor brightness curve and also automatically changed it on AC events - as a result I removed the backlight code from the DSDT and just fell back to the native control. Like I said I'm a long way from the normal setup, but this did previously work. The "right" logic here seems pretty simple: if ACPI backlight control is expected to work, use it. If it isn't, but there's a vendor interface, use it. If there's no vendor interface, use the native interface. The problem you're dealing with is that the knowledge of whether or not there's a vendor interface isn't something the core kernel code knows about. What you're proposing here is effectively for us to expose additional information about whether or not there's a vendor interface in the system firmware, but since we're talking in some cases about hardware that's almost 20 years old, we're not realistically going to get those old machines fixed. So, it feels like there's two choices: 1) Make a default policy decision, but then allow that decision to be altered later on (eg, when a vendor-specific platform driver has been loaded) - you've said this poses additional complexities. 2) Move the knowledge of whether or not there's a vendor interface into the core code. Basically take every platform driver that exposes a vendor interface, and move the detection code into the core. I think any other approach is going to result in machines that previously worked no longer working (and you can't just make the vendor/native split dependent on the Coreboot DMI BIOS string, because there are some Coreboot platforms that implement the vendor interface for compatibility, and you also can't ask all Coreboot users to update their firmware to fix things) 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 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 38F34C38A2D for ; Tue, 25 Oct 2022 23:40:56 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 1D66010E1E4; Tue, 25 Oct 2022 23:40:48 +0000 (UTC) Received: from cavan.codon.org.uk (cavan.codon.org.uk [176.126.240.207]) by gabe.freedesktop.org (Postfix) with ESMTPS id 137F310E1A8; Tue, 25 Oct 2022 23:40:42 +0000 (UTC) Received: by cavan.codon.org.uk (Postfix, from userid 1000) id 9794340A8A; Wed, 26 Oct 2022 00:40:40 +0100 (BST) Date: Wed, 26 Oct 2022 00:40:40 +0100 From: Matthew Garrett To: Hans de Goede Subject: Re: [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2) Message-ID: <20221025234040.GA27673@srcf.ucam.org> References: <20220825143726.269890-1-hdegoede@redhat.com> <20220825143726.269890-3-hdegoede@redhat.com> <42a5f2c9-a1dc-8fc0-7334-fe6c390ecfbb@redhat.com> <20221024203057.GA28675@srcf.ucam.org> <8f53b8b6-ead2-22f5-16f7-65b31f7cc05c@redhat.com> <20221025193248.GA21457@srcf.ucam.org> <144cd47e-42dc-2b84-1a90-ea5e080e08a3@redhat.com> <20221025204043.GA23306@srcf.ucam.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Pan@freedesktop.org, Karol Herbst , "Rafael J . Wysocki" , nouveau@lists.freedesktop.org, dri-devel@lists.freedesktop.org, platform-driver-x86@vger.kernel.org, Dmitry Osipenko , amd-gfx@lists.freedesktop.org, linux-acpi@vger.kernel.org, Ben Skeggs , David Airlie , Len Brown , Daniel Dadap , Jani Nikula , intel-gfx , Mark Gross , Rodrigo Vivi , Mika Westerberg , Andy Shevchenko , Tvrtko Ursulin , Xinhui , Thomas Zimmermann , Alex Deucher , Christian =?iso-8859-1?Q?K=F6nig?= Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Wed, Oct 26, 2022 at 01:27:25AM +0200, Hans de Goede wrote: > this code should actually set the ACPI_VIDEO_BACKLIGHT flag: > drivers/acpi/scan.c: > > static acpi_status > acpi_backlight_cap_match(acpi_handle handle, u32 level, void *context, > void **return_value) > { > long *cap = context; > > if (acpi_has_method(handle, "_BCM") && > acpi_has_method(handle, "_BCL")) { > acpi_handle_debug(handle, "Found generic backlight support\n"); > *cap |= ACPI_VIDEO_BACKLIGHT; > /* We have backlight support, no need to scan further */ > return AE_CTRL_TERMINATE; > } > return 0; > } Ah, yeah, my local tree no longer matches the upstream behaviour because I've hacked the EC firmware to remove the backlight trigger because it had an extremely poor brightness curve and also automatically changed it on AC events - as a result I removed the backlight code from the DSDT and just fell back to the native control. Like I said I'm a long way from the normal setup, but this did previously work. The "right" logic here seems pretty simple: if ACPI backlight control is expected to work, use it. If it isn't, but there's a vendor interface, use it. If there's no vendor interface, use the native interface. The problem you're dealing with is that the knowledge of whether or not there's a vendor interface isn't something the core kernel code knows about. What you're proposing here is effectively for us to expose additional information about whether or not there's a vendor interface in the system firmware, but since we're talking in some cases about hardware that's almost 20 years old, we're not realistically going to get those old machines fixed. So, it feels like there's two choices: 1) Make a default policy decision, but then allow that decision to be altered later on (eg, when a vendor-specific platform driver has been loaded) - you've said this poses additional complexities. 2) Move the knowledge of whether or not there's a vendor interface into the core code. Basically take every platform driver that exposes a vendor interface, and move the detection code into the core. I think any other approach is going to result in machines that previously worked no longer working (and you can't just make the vendor/native split dependent on the Coreboot DMI BIOS string, because there are some Coreboot platforms that implement the vendor interface for compatibility, and you also can't ask all Coreboot users to update their firmware to fix things) 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 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id DBDD3ECDFA1 for ; Tue, 25 Oct 2022 23:40:47 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id E387A10E1B6; Tue, 25 Oct 2022 23:40:46 +0000 (UTC) Received: from cavan.codon.org.uk (cavan.codon.org.uk [176.126.240.207]) by gabe.freedesktop.org (Postfix) with ESMTPS id 137F310E1A8; Tue, 25 Oct 2022 23:40:42 +0000 (UTC) Received: by cavan.codon.org.uk (Postfix, from userid 1000) id 9794340A8A; Wed, 26 Oct 2022 00:40:40 +0100 (BST) Date: Wed, 26 Oct 2022 00:40:40 +0100 From: Matthew Garrett To: Hans de Goede Message-ID: <20221025234040.GA27673@srcf.ucam.org> References: <20220825143726.269890-1-hdegoede@redhat.com> <20220825143726.269890-3-hdegoede@redhat.com> <42a5f2c9-a1dc-8fc0-7334-fe6c390ecfbb@redhat.com> <20221024203057.GA28675@srcf.ucam.org> <8f53b8b6-ead2-22f5-16f7-65b31f7cc05c@redhat.com> <20221025193248.GA21457@srcf.ucam.org> <144cd47e-42dc-2b84-1a90-ea5e080e08a3@redhat.com> <20221025204043.GA23306@srcf.ucam.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [Intel-gfx] [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2) X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Pan@freedesktop.org, Karol Herbst , "Rafael J . Wysocki" , nouveau@lists.freedesktop.org, dri-devel@lists.freedesktop.org, platform-driver-x86@vger.kernel.org, Dmitry Osipenko , amd-gfx@lists.freedesktop.org, linux-acpi@vger.kernel.org, Ben Skeggs , David Airlie , Len Brown , Daniel Dadap , Jani Nikula , intel-gfx , Mark Gross , Maxime Ripard , Rodrigo Vivi , Mika Westerberg , Andy Shevchenko , Xinhui , Thomas Zimmermann , Alex Deucher , Christian =?iso-8859-1?Q?K=F6nig?= Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Wed, Oct 26, 2022 at 01:27:25AM +0200, Hans de Goede wrote: > this code should actually set the ACPI_VIDEO_BACKLIGHT flag: > drivers/acpi/scan.c: > > static acpi_status > acpi_backlight_cap_match(acpi_handle handle, u32 level, void *context, > void **return_value) > { > long *cap = context; > > if (acpi_has_method(handle, "_BCM") && > acpi_has_method(handle, "_BCL")) { > acpi_handle_debug(handle, "Found generic backlight support\n"); > *cap |= ACPI_VIDEO_BACKLIGHT; > /* We have backlight support, no need to scan further */ > return AE_CTRL_TERMINATE; > } > return 0; > } Ah, yeah, my local tree no longer matches the upstream behaviour because I've hacked the EC firmware to remove the backlight trigger because it had an extremely poor brightness curve and also automatically changed it on AC events - as a result I removed the backlight code from the DSDT and just fell back to the native control. Like I said I'm a long way from the normal setup, but this did previously work. The "right" logic here seems pretty simple: if ACPI backlight control is expected to work, use it. If it isn't, but there's a vendor interface, use it. If there's no vendor interface, use the native interface. The problem you're dealing with is that the knowledge of whether or not there's a vendor interface isn't something the core kernel code knows about. What you're proposing here is effectively for us to expose additional information about whether or not there's a vendor interface in the system firmware, but since we're talking in some cases about hardware that's almost 20 years old, we're not realistically going to get those old machines fixed. So, it feels like there's two choices: 1) Make a default policy decision, but then allow that decision to be altered later on (eg, when a vendor-specific platform driver has been loaded) - you've said this poses additional complexities. 2) Move the knowledge of whether or not there's a vendor interface into the core code. Basically take every platform driver that exposes a vendor interface, and move the detection code into the core. I think any other approach is going to result in machines that previously worked no longer working (and you can't just make the vendor/native split dependent on the Coreboot DMI BIOS string, because there are some Coreboot platforms that implement the vendor interface for compatibility, and you also can't ask all Coreboot users to update their firmware to fix things) 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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A0B30ECDFA1 for ; Tue, 25 Oct 2022 23:42:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233073AbiJYXl7 (ORCPT ); Tue, 25 Oct 2022 19:41:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49790 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232706AbiJYXlm (ORCPT ); Tue, 25 Oct 2022 19:41:42 -0400 Received: from cavan.codon.org.uk (cavan.codon.org.uk [176.126.240.207]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 900995D135; Tue, 25 Oct 2022 16:40:42 -0700 (PDT) Received: by cavan.codon.org.uk (Postfix, from userid 1000) id 9794340A8A; Wed, 26 Oct 2022 00:40:40 +0100 (BST) Date: Wed, 26 Oct 2022 00:40:40 +0100 From: Matthew Garrett To: Hans de Goede Cc: Dmitry Osipenko , Ben Skeggs , Karol Herbst , Lyude , Daniel Dadap , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Tvrtko Ursulin , Alex Deucher , Christian =?iso-8859-1?Q?K=F6nig?= , Pan@freedesktop.org, Xinhui , "Rafael J . Wysocki" , Mika Westerberg , Lukas Wunner , Mark Gross , Andy Shevchenko , linux-acpi@vger.kernel.org, Jani Nikula , nouveau@lists.freedesktop.org, intel-gfx , dri-devel@lists.freedesktop.org, platform-driver-x86@vger.kernel.org, amd-gfx@lists.freedesktop.org, David Airlie , Len Brown Subject: Re: [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2) Message-ID: <20221025234040.GA27673@srcf.ucam.org> References: <20220825143726.269890-1-hdegoede@redhat.com> <20220825143726.269890-3-hdegoede@redhat.com> <42a5f2c9-a1dc-8fc0-7334-fe6c390ecfbb@redhat.com> <20221024203057.GA28675@srcf.ucam.org> <8f53b8b6-ead2-22f5-16f7-65b31f7cc05c@redhat.com> <20221025193248.GA21457@srcf.ucam.org> <144cd47e-42dc-2b84-1a90-ea5e080e08a3@redhat.com> <20221025204043.GA23306@srcf.ucam.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org On Wed, Oct 26, 2022 at 01:27:25AM +0200, Hans de Goede wrote: > this code should actually set the ACPI_VIDEO_BACKLIGHT flag: > drivers/acpi/scan.c: > > static acpi_status > acpi_backlight_cap_match(acpi_handle handle, u32 level, void *context, > void **return_value) > { > long *cap = context; > > if (acpi_has_method(handle, "_BCM") && > acpi_has_method(handle, "_BCL")) { > acpi_handle_debug(handle, "Found generic backlight support\n"); > *cap |= ACPI_VIDEO_BACKLIGHT; > /* We have backlight support, no need to scan further */ > return AE_CTRL_TERMINATE; > } > return 0; > } Ah, yeah, my local tree no longer matches the upstream behaviour because I've hacked the EC firmware to remove the backlight trigger because it had an extremely poor brightness curve and also automatically changed it on AC events - as a result I removed the backlight code from the DSDT and just fell back to the native control. Like I said I'm a long way from the normal setup, but this did previously work. The "right" logic here seems pretty simple: if ACPI backlight control is expected to work, use it. If it isn't, but there's a vendor interface, use it. If there's no vendor interface, use the native interface. The problem you're dealing with is that the knowledge of whether or not there's a vendor interface isn't something the core kernel code knows about. What you're proposing here is effectively for us to expose additional information about whether or not there's a vendor interface in the system firmware, but since we're talking in some cases about hardware that's almost 20 years old, we're not realistically going to get those old machines fixed. So, it feels like there's two choices: 1) Make a default policy decision, but then allow that decision to be altered later on (eg, when a vendor-specific platform driver has been loaded) - you've said this poses additional complexities. 2) Move the knowledge of whether or not there's a vendor interface into the core code. Basically take every platform driver that exposes a vendor interface, and move the detection code into the core. I think any other approach is going to result in machines that previously worked no longer working (and you can't just make the vendor/native split dependent on the Coreboot DMI BIOS string, because there are some Coreboot platforms that implement the vendor interface for compatibility, and you also can't ask all Coreboot users to update their firmware to fix things) 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 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 6F7BAFA373D for ; Wed, 26 Oct 2022 07:14:53 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 9642610E47D; Wed, 26 Oct 2022 07:14:48 +0000 (UTC) Received: from cavan.codon.org.uk (cavan.codon.org.uk [176.126.240.207]) by gabe.freedesktop.org (Postfix) with ESMTPS id 137F310E1A8; Tue, 25 Oct 2022 23:40:42 +0000 (UTC) Received: by cavan.codon.org.uk (Postfix, from userid 1000) id 9794340A8A; Wed, 26 Oct 2022 00:40:40 +0100 (BST) Date: Wed, 26 Oct 2022 00:40:40 +0100 From: Matthew Garrett To: Hans de Goede Subject: Re: [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2) Message-ID: <20221025234040.GA27673@srcf.ucam.org> References: <20220825143726.269890-1-hdegoede@redhat.com> <20220825143726.269890-3-hdegoede@redhat.com> <42a5f2c9-a1dc-8fc0-7334-fe6c390ecfbb@redhat.com> <20221024203057.GA28675@srcf.ucam.org> <8f53b8b6-ead2-22f5-16f7-65b31f7cc05c@redhat.com> <20221025193248.GA21457@srcf.ucam.org> <144cd47e-42dc-2b84-1a90-ea5e080e08a3@redhat.com> <20221025204043.GA23306@srcf.ucam.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Mailman-Approved-At: Wed, 26 Oct 2022 07:14:45 +0000 X-BeenThere: amd-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion list for AMD gfx List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Pan@freedesktop.org, Karol Herbst , "Rafael J . Wysocki" , nouveau@lists.freedesktop.org, Joonas Lahtinen , dri-devel@lists.freedesktop.org, platform-driver-x86@vger.kernel.org, Dmitry Osipenko , amd-gfx@lists.freedesktop.org, linux-acpi@vger.kernel.org, Ben Skeggs , David Airlie , Len Brown , Daniel Dadap , Jani Nikula , intel-gfx , Maarten Lankhorst , Jani Nikula , Mark Gross , Maxime Ripard , Rodrigo Vivi , Mika Westerberg , Andy Shevchenko , Tvrtko Ursulin , Xinhui , Lukas Wunner , Thomas Zimmermann , Alex Deucher , Christian =?iso-8859-1?Q?K=F6nig?= Errors-To: amd-gfx-bounces@lists.freedesktop.org Sender: "amd-gfx" On Wed, Oct 26, 2022 at 01:27:25AM +0200, Hans de Goede wrote: > this code should actually set the ACPI_VIDEO_BACKLIGHT flag: > drivers/acpi/scan.c: > > static acpi_status > acpi_backlight_cap_match(acpi_handle handle, u32 level, void *context, > void **return_value) > { > long *cap = context; > > if (acpi_has_method(handle, "_BCM") && > acpi_has_method(handle, "_BCL")) { > acpi_handle_debug(handle, "Found generic backlight support\n"); > *cap |= ACPI_VIDEO_BACKLIGHT; > /* We have backlight support, no need to scan further */ > return AE_CTRL_TERMINATE; > } > return 0; > } Ah, yeah, my local tree no longer matches the upstream behaviour because I've hacked the EC firmware to remove the backlight trigger because it had an extremely poor brightness curve and also automatically changed it on AC events - as a result I removed the backlight code from the DSDT and just fell back to the native control. Like I said I'm a long way from the normal setup, but this did previously work. The "right" logic here seems pretty simple: if ACPI backlight control is expected to work, use it. If it isn't, but there's a vendor interface, use it. If there's no vendor interface, use the native interface. The problem you're dealing with is that the knowledge of whether or not there's a vendor interface isn't something the core kernel code knows about. What you're proposing here is effectively for us to expose additional information about whether or not there's a vendor interface in the system firmware, but since we're talking in some cases about hardware that's almost 20 years old, we're not realistically going to get those old machines fixed. So, it feels like there's two choices: 1) Make a default policy decision, but then allow that decision to be altered later on (eg, when a vendor-specific platform driver has been loaded) - you've said this poses additional complexities. 2) Move the knowledge of whether or not there's a vendor interface into the core code. Basically take every platform driver that exposes a vendor interface, and move the detection code into the core. I think any other approach is going to result in machines that previously worked no longer working (and you can't just make the vendor/native split dependent on the Coreboot DMI BIOS string, because there are some Coreboot platforms that implement the vendor interface for compatibility, and you also can't ask all Coreboot users to update their firmware to fix things)