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 01046C38A2D for ; Wed, 26 Oct 2022 20:49:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234624AbiJZUtb (ORCPT ); Wed, 26 Oct 2022 16:49:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52996 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234612AbiJZUta (ORCPT ); Wed, 26 Oct 2022 16:49:30 -0400 Received: from cavan.codon.org.uk (cavan.codon.org.uk [176.126.240.207]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B6A39148FDC; Wed, 26 Oct 2022 13:49:22 -0700 (PDT) Received: by cavan.codon.org.uk (Postfix, from userid 1000) id CF10840A8A; Wed, 26 Oct 2022 21:49:20 +0100 (BST) Date: Wed, 26 Oct 2022 21:49:20 +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: <20221026204920.GA15326@srcf.ucam.org> References: <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> <20221025234040.GA27673@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 11:59:28AM +0200, Hans de Goede wrote: > Ok, so this is a local customization to what is already a custom BIOS > for a custom motherboard. There is a lot of custom in that sentence and > TBH at some point things might become too custom for them to be expected > to work OOTB. But it *did* work OOTB before. You broke it. I accept that I'm a ludicrously weird corner case here, but there are going to be other systems that are also affected by this. > I'm afraid things are not that simple. I assume that with > "if ACPI backlight control is expected to work" you mean don't > use ACPI backlight control when (acpi_osi_is_win8() && native_available) > evaluates to true because it is known to be broken on some of > those systems because Windows 8 stopped using it ? Correct. > Unfortunately something similar applies to vendor interfaces, > When Windows XP started using (and mandating for certification > IIRC) ACPI backlight control, vendors still kept their own > vendor specific EC/smbios/ACPI/WMI backlight interfaces around for > a long long time, except they were often no longer tested. The current situation (both before your patchset and with its current implementation) is that vendor is preferred to native, so if the vendor interface is present then we're already using it. > > 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. > > I don't understand why you keep talking about the old vendor interfaces, > at least for the chromebook part of this thread the issue is that > the i915 driver no longer registers the intel_backlight device which > is a native device type, which is caused by the patch this email > thread is about (and old vendor interfaces do not come into play > at all here). So AFAICT this is a native vs acpi backlight control > issue ? I'm referring to your proposed patch that changed the default from backlight_vendor to backlight_native, which would fix my machine and Chromebooks but break anything that relies on the vendor interfaces. > I really want to resolve your bug, but I still lack a lot of info, > like what backlight interface you were actually using in 6.0 ? Native. > { > .callback = video_detect_force_video, > /* ThinkPad X201s */ > .matches = { > DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"), > DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad X201s"), > }, > }, > > will trigger. In this case you'd break anyone else running the system who isn't using the hacked EC and different ACPI tables - obviously there's ways round this, but realistically since I'm (as far as I know) the only person in this situation it makes more sense for me to add a kernel parameter than carry around an exceedingly niche DMI quirk. I'm fine with that. But the point I'm trying to make is that the machines *are* telling you whether they'd prefer vendor or native, and you're not taking that into account in the video_detect code. 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 3B8FCC433FE for ; Wed, 26 Oct 2022 20:49:25 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 8992610E2BE; Wed, 26 Oct 2022 20:49:24 +0000 (UTC) Received: from cavan.codon.org.uk (irc.codon.org.uk [IPv6:2a00:1098:84:22e::2]) by gabe.freedesktop.org (Postfix) with ESMTPS id 54FA010E0D0; Wed, 26 Oct 2022 20:49:22 +0000 (UTC) Received: by cavan.codon.org.uk (Postfix, from userid 1000) id CF10840A8A; Wed, 26 Oct 2022 21:49:20 +0100 (BST) Date: Wed, 26 Oct 2022 21:49:20 +0100 From: Matthew Garrett To: Hans de Goede Message-ID: <20221026204920.GA15326@srcf.ucam.org> References: <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> <20221025234040.GA27673@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 11:59:28AM +0200, Hans de Goede wrote: > Ok, so this is a local customization to what is already a custom BIOS > for a custom motherboard. There is a lot of custom in that sentence and > TBH at some point things might become too custom for them to be expected > to work OOTB. But it *did* work OOTB before. You broke it. I accept that I'm a ludicrously weird corner case here, but there are going to be other systems that are also affected by this. > I'm afraid things are not that simple. I assume that with > "if ACPI backlight control is expected to work" you mean don't > use ACPI backlight control when (acpi_osi_is_win8() && native_available) > evaluates to true because it is known to be broken on some of > those systems because Windows 8 stopped using it ? Correct. > Unfortunately something similar applies to vendor interfaces, > When Windows XP started using (and mandating for certification > IIRC) ACPI backlight control, vendors still kept their own > vendor specific EC/smbios/ACPI/WMI backlight interfaces around for > a long long time, except they were often no longer tested. The current situation (both before your patchset and with its current implementation) is that vendor is preferred to native, so if the vendor interface is present then we're already using it. > > 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. > > I don't understand why you keep talking about the old vendor interfaces, > at least for the chromebook part of this thread the issue is that > the i915 driver no longer registers the intel_backlight device which > is a native device type, which is caused by the patch this email > thread is about (and old vendor interfaces do not come into play > at all here). So AFAICT this is a native vs acpi backlight control > issue ? I'm referring to your proposed patch that changed the default from backlight_vendor to backlight_native, which would fix my machine and Chromebooks but break anything that relies on the vendor interfaces. > I really want to resolve your bug, but I still lack a lot of info, > like what backlight interface you were actually using in 6.0 ? Native. > { > .callback = video_detect_force_video, > /* ThinkPad X201s */ > .matches = { > DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"), > DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad X201s"), > }, > }, > > will trigger. In this case you'd break anyone else running the system who isn't using the hacked EC and different ACPI tables - obviously there's ways round this, but realistically since I'm (as far as I know) the only person in this situation it makes more sense for me to add a kernel parameter than carry around an exceedingly niche DMI quirk. I'm fine with that. But the point I'm trying to make is that the machines *are* telling you whether they'd prefer vendor or native, and you're not taking that into account in the video_detect code. 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 26AF7C433FE for ; Wed, 26 Oct 2022 20:49:28 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id D9C1410E0D0; Wed, 26 Oct 2022 20:49:25 +0000 (UTC) Received: from cavan.codon.org.uk (irc.codon.org.uk [IPv6:2a00:1098:84:22e::2]) by gabe.freedesktop.org (Postfix) with ESMTPS id 54FA010E0D0; Wed, 26 Oct 2022 20:49:22 +0000 (UTC) Received: by cavan.codon.org.uk (Postfix, from userid 1000) id CF10840A8A; Wed, 26 Oct 2022 21:49:20 +0100 (BST) Date: Wed, 26 Oct 2022 21:49:20 +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: <20221026204920.GA15326@srcf.ucam.org> References: <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> <20221025234040.GA27673@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 11:59:28AM +0200, Hans de Goede wrote: > Ok, so this is a local customization to what is already a custom BIOS > for a custom motherboard. There is a lot of custom in that sentence and > TBH at some point things might become too custom for them to be expected > to work OOTB. But it *did* work OOTB before. You broke it. I accept that I'm a ludicrously weird corner case here, but there are going to be other systems that are also affected by this. > I'm afraid things are not that simple. I assume that with > "if ACPI backlight control is expected to work" you mean don't > use ACPI backlight control when (acpi_osi_is_win8() && native_available) > evaluates to true because it is known to be broken on some of > those systems because Windows 8 stopped using it ? Correct. > Unfortunately something similar applies to vendor interfaces, > When Windows XP started using (and mandating for certification > IIRC) ACPI backlight control, vendors still kept their own > vendor specific EC/smbios/ACPI/WMI backlight interfaces around for > a long long time, except they were often no longer tested. The current situation (both before your patchset and with its current implementation) is that vendor is preferred to native, so if the vendor interface is present then we're already using it. > > 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. > > I don't understand why you keep talking about the old vendor interfaces, > at least for the chromebook part of this thread the issue is that > the i915 driver no longer registers the intel_backlight device which > is a native device type, which is caused by the patch this email > thread is about (and old vendor interfaces do not come into play > at all here). So AFAICT this is a native vs acpi backlight control > issue ? I'm referring to your proposed patch that changed the default from backlight_vendor to backlight_native, which would fix my machine and Chromebooks but break anything that relies on the vendor interfaces. > I really want to resolve your bug, but I still lack a lot of info, > like what backlight interface you were actually using in 6.0 ? Native. > { > .callback = video_detect_force_video, > /* ThinkPad X201s */ > .matches = { > DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"), > DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad X201s"), > }, > }, > > will trigger. In this case you'd break anyone else running the system who isn't using the hacked EC and different ACPI tables - obviously there's ways round this, but realistically since I'm (as far as I know) the only person in this situation it makes more sense for me to add a kernel parameter than carry around an exceedingly niche DMI quirk. I'm fine with that. But the point I'm trying to make is that the machines *are* telling you whether they'd prefer vendor or native, and you're not taking that into account in the video_detect code. 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 5372AECDFA1 for ; Wed, 26 Oct 2022 20:49:25 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 66FC610E26F; Wed, 26 Oct 2022 20:49:24 +0000 (UTC) Received: from cavan.codon.org.uk (irc.codon.org.uk [IPv6:2a00:1098:84:22e::2]) by gabe.freedesktop.org (Postfix) with ESMTPS id 54FA010E0D0; Wed, 26 Oct 2022 20:49:22 +0000 (UTC) Received: by cavan.codon.org.uk (Postfix, from userid 1000) id CF10840A8A; Wed, 26 Oct 2022 21:49:20 +0100 (BST) Date: Wed, 26 Oct 2022 21:49:20 +0100 From: Matthew Garrett To: Hans de Goede Message-ID: <20221026204920.GA15326@srcf.ucam.org> References: <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> <20221025234040.GA27673@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 11:59:28AM +0200, Hans de Goede wrote: > Ok, so this is a local customization to what is already a custom BIOS > for a custom motherboard. There is a lot of custom in that sentence and > TBH at some point things might become too custom for them to be expected > to work OOTB. But it *did* work OOTB before. You broke it. I accept that I'm a ludicrously weird corner case here, but there are going to be other systems that are also affected by this. > I'm afraid things are not that simple. I assume that with > "if ACPI backlight control is expected to work" you mean don't > use ACPI backlight control when (acpi_osi_is_win8() && native_available) > evaluates to true because it is known to be broken on some of > those systems because Windows 8 stopped using it ? Correct. > Unfortunately something similar applies to vendor interfaces, > When Windows XP started using (and mandating for certification > IIRC) ACPI backlight control, vendors still kept their own > vendor specific EC/smbios/ACPI/WMI backlight interfaces around for > a long long time, except they were often no longer tested. The current situation (both before your patchset and with its current implementation) is that vendor is preferred to native, so if the vendor interface is present then we're already using it. > > 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. > > I don't understand why you keep talking about the old vendor interfaces, > at least for the chromebook part of this thread the issue is that > the i915 driver no longer registers the intel_backlight device which > is a native device type, which is caused by the patch this email > thread is about (and old vendor interfaces do not come into play > at all here). So AFAICT this is a native vs acpi backlight control > issue ? I'm referring to your proposed patch that changed the default from backlight_vendor to backlight_native, which would fix my machine and Chromebooks but break anything that relies on the vendor interfaces. > I really want to resolve your bug, but I still lack a lot of info, > like what backlight interface you were actually using in 6.0 ? Native. > { > .callback = video_detect_force_video, > /* ThinkPad X201s */ > .matches = { > DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"), > DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad X201s"), > }, > }, > > will trigger. In this case you'd break anyone else running the system who isn't using the hacked EC and different ACPI tables - obviously there's ways round this, but realistically since I'm (as far as I know) the only person in this situation it makes more sense for me to add a kernel parameter than carry around an exceedingly niche DMI quirk. I'm fine with that. But the point I'm trying to make is that the machines *are* telling you whether they'd prefer vendor or native, and you're not taking that into account in the video_detect code. 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 91ED9C38A2D for ; Wed, 26 Oct 2022 20:50:16 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 8133E10E2C2; Wed, 26 Oct 2022 20:50:15 +0000 (UTC) Received: from cavan.codon.org.uk (irc.codon.org.uk [IPv6:2a00:1098:84:22e::2]) by gabe.freedesktop.org (Postfix) with ESMTPS id 54FA010E0D0; Wed, 26 Oct 2022 20:49:22 +0000 (UTC) Received: by cavan.codon.org.uk (Postfix, from userid 1000) id CF10840A8A; Wed, 26 Oct 2022 21:49:20 +0100 (BST) Date: Wed, 26 Oct 2022 21:49:20 +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: <20221026204920.GA15326@srcf.ucam.org> References: <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> <20221025234040.GA27673@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 20:50:13 +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 11:59:28AM +0200, Hans de Goede wrote: > Ok, so this is a local customization to what is already a custom BIOS > for a custom motherboard. There is a lot of custom in that sentence and > TBH at some point things might become too custom for them to be expected > to work OOTB. But it *did* work OOTB before. You broke it. I accept that I'm a ludicrously weird corner case here, but there are going to be other systems that are also affected by this. > I'm afraid things are not that simple. I assume that with > "if ACPI backlight control is expected to work" you mean don't > use ACPI backlight control when (acpi_osi_is_win8() && native_available) > evaluates to true because it is known to be broken on some of > those systems because Windows 8 stopped using it ? Correct. > Unfortunately something similar applies to vendor interfaces, > When Windows XP started using (and mandating for certification > IIRC) ACPI backlight control, vendors still kept their own > vendor specific EC/smbios/ACPI/WMI backlight interfaces around for > a long long time, except they were often no longer tested. The current situation (both before your patchset and with its current implementation) is that vendor is preferred to native, so if the vendor interface is present then we're already using it. > > 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. > > I don't understand why you keep talking about the old vendor interfaces, > at least for the chromebook part of this thread the issue is that > the i915 driver no longer registers the intel_backlight device which > is a native device type, which is caused by the patch this email > thread is about (and old vendor interfaces do not come into play > at all here). So AFAICT this is a native vs acpi backlight control > issue ? I'm referring to your proposed patch that changed the default from backlight_vendor to backlight_native, which would fix my machine and Chromebooks but break anything that relies on the vendor interfaces. > I really want to resolve your bug, but I still lack a lot of info, > like what backlight interface you were actually using in 6.0 ? Native. > { > .callback = video_detect_force_video, > /* ThinkPad X201s */ > .matches = { > DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"), > DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad X201s"), > }, > }, > > will trigger. In this case you'd break anyone else running the system who isn't using the hacked EC and different ACPI tables - obviously there's ways round this, but realistically since I'm (as far as I know) the only person in this situation it makes more sense for me to add a kernel parameter than carry around an exceedingly niche DMI quirk. I'm fine with that. But the point I'm trying to make is that the machines *are* telling you whether they'd prefer vendor or native, and you're not taking that into account in the video_detect code.