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 3E25AC67871 for ; Thu, 27 Oct 2022 08:51:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234509AbiJ0Ivw (ORCPT ); Thu, 27 Oct 2022 04:51:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60542 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233850AbiJ0Ivv (ORCPT ); Thu, 27 Oct 2022 04:51:51 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B43FC15D0B2 for ; Thu, 27 Oct 2022 01:51:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1666860710; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=piG9yqT6xAhiMXdKpX5Y3Qo1FGMuiTJ1yFwdVO4p5IY=; b=dwYz04UHrcf076Jv8JUz4W+UlHiqJpRkLArwBwh941B4c60JCcws4VKI3lrXPKHIrPipNN PSzjnMNiqHj0lTgV8iq+z9JITdG5PxlAevhXNPbCit9kI+ryXfrbSgm94zSPEF+EC5o3fi xf5oRbDnfe3FY92iAKZxWszEUnHssNM= Received: from mail-ed1-f72.google.com (mail-ed1-f72.google.com [209.85.208.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-558-Uscknc19M4S1jPoJ8HCicQ-1; Thu, 27 Oct 2022 04:51:48 -0400 X-MC-Unique: Uscknc19M4S1jPoJ8HCicQ-1 Received: by mail-ed1-f72.google.com with SMTP id b13-20020a056402350d00b0045d0fe2004eso640441edd.18 for ; Thu, 27 Oct 2022 01:51:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=piG9yqT6xAhiMXdKpX5Y3Qo1FGMuiTJ1yFwdVO4p5IY=; b=G4gep0Js/b36+aScV0Kd+ARj+I60Or+A9c3PNIlZi3IwmdOen1QHl1n9O1hGu6o5hV 2VvhJt0fQzdeFiL/bzJS9z7MxGfS3IrCpOmSmhruoXIbUGNJSQHQrtjFh3kzbEq6h8Cl fAOD1WmHCb021OH1suxF6amUFhOdVkoC5qr8Y3H8f/G08KCwI+xMuFgTk8AxcS7eqmSr nT6OArbTHSu/xvqcpYJXKFwD/cvj5xQAoS6Gs0mqCYP+rxb1GxBCsYzYreb/Jtw+n+LN OqE7dhEYHpxWrROJR2IbxA+0TVfft4ml2g61kybdWydCln9wk5XeMO5jc7MA/nkBknvC 5N+w== X-Gm-Message-State: ACrzQf2R7nhjTcIHFTYqUJsdBphraWkAHUh7RfNKOsGG/zRNcHHSj7w5 XbhhnUYL1UyHd/znRkuzpxRRn/4dW/y3O3N5jbmBl0NrDM7OK+cr5iZiuN1iH87vdtgnwC2jtLv vviUOAQBLvOhrvmNm5H21cw== X-Received: by 2002:a05:6402:ea0:b0:454:38bf:aa3d with SMTP id h32-20020a0564020ea000b0045438bfaa3dmr19108198eda.291.1666860707415; Thu, 27 Oct 2022 01:51:47 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4M97BY+DJtCFsy6QaUdWwayGL+u3zLh+pSJfoHcV6/8JnsSecEzthndHQaTneGvNUsC3XcVA== X-Received: by 2002:a05:6402:ea0:b0:454:38bf:aa3d with SMTP id h32-20020a0564020ea000b0045438bfaa3dmr19108164eda.291.1666860707189; Thu, 27 Oct 2022 01:51:47 -0700 (PDT) Received: from ?IPV6:2001:1c00:c1e:bf00:d69d:5353:dba5:ee81? (2001-1c00-0c1e-bf00-d69d-5353-dba5-ee81.cable.dynamic.v6.ziggo.nl. [2001:1c00:c1e:bf00:d69d:5353:dba5:ee81]) by smtp.gmail.com with ESMTPSA id w15-20020a056402268f00b004615bea1d5bsm635132edd.35.2022.10.27.01.51.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 27 Oct 2022 01:51:46 -0700 (PDT) Message-ID: <099dee98-8aeb-af36-828c-110f5ac6e9a3@redhat.com> Date: Thu, 27 Oct 2022 10:51:45 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.1 Subject: Re: [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2) To: Matthew Garrett 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 , =?UTF-8?Q?Christian_K=c3=b6nig?= , 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 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> <20221026204920.GA15326@srcf.ucam.org> Content-Language: en-US, nl From: Hans de Goede In-Reply-To: <20221026204920.GA15326@srcf.ucam.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org Hi, On 10/26/22 22:49, Matthew Garrett wrote: > 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. All vendor drivers that I'm aware of have: if (acpi_video_get_backlight_type() != acpi_backlight_vendor) return; In their backlight register paths and this has been present since circa 2015. So both before and after my 6.1 refactor vendor is only preferred on devices which don't implement the ACPI video bus control method. >>> 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 see. I agree that preferring native over vendor on machines which do not have ACPI video backlight control will cause issues on older machines. Avoiding this scenario is exactly why currently the native check is conditional on the presence of ACPI video backlight control. >> 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. I wish that that ("telling you whether they'd prefer vendor or native") were true. But that does not match my experience at all and I've been working on making the kernel pick the right backlight interface on laptops since 2014. Just because a vendor interface is present does not mean that it will work. Unfortunately for none of the 3 main native/acpi_video/vendor backlight control methods the control method being present also guarantees that it will work. Which completely sucks, but it is the reality we have to deal with. > , and you're not taking that into account > in the video_detect code. Regards, Hans 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 D3CF0C38A2D for ; Thu, 27 Oct 2022 08:51:55 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id D913310E586; Thu, 27 Oct 2022 08:51:54 +0000 (UTC) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by gabe.freedesktop.org (Postfix) with ESMTPS id 7D98010E582 for ; Thu, 27 Oct 2022 08:51:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1666860710; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=piG9yqT6xAhiMXdKpX5Y3Qo1FGMuiTJ1yFwdVO4p5IY=; b=dwYz04UHrcf076Jv8JUz4W+UlHiqJpRkLArwBwh941B4c60JCcws4VKI3lrXPKHIrPipNN PSzjnMNiqHj0lTgV8iq+z9JITdG5PxlAevhXNPbCit9kI+ryXfrbSgm94zSPEF+EC5o3fi xf5oRbDnfe3FY92iAKZxWszEUnHssNM= Received: from mail-ed1-f70.google.com (mail-ed1-f70.google.com [209.85.208.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-265-QjVz8ZCkN-qJ0ophp-WNrA-1; Thu, 27 Oct 2022 04:51:48 -0400 X-MC-Unique: QjVz8ZCkN-qJ0ophp-WNrA-1 Received: by mail-ed1-f70.google.com with SMTP id h9-20020a05640250c900b00461d8ee12e2so646665edb.23 for ; Thu, 27 Oct 2022 01:51:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=piG9yqT6xAhiMXdKpX5Y3Qo1FGMuiTJ1yFwdVO4p5IY=; b=U0YxnBuId0XtAjUaYl2ZaGsVHI3aV/5QBwaIsX4ulXezVJBpQWrOkRL901ldmCFQ5i kZNEV6iXAAckIq1ybhq/28/f66LYXPjwUzmwjZKnYT7DF8Y3lrKwxZYATwvtqiqpcp/R 7wqrYKmuBvm+9kGnKJVwfXVBi94TFquzx/Jb1gTk0g2BAgApFiqgGFsrQsuLNSRE5Hx5 gDnMHwtvj6K5pxPd2bZlgjJLW5mgmt0MUu6f1Lh2eVC+u1Ci4Ucr9rS34S7vNMW3Su1O HH21mj0BTHICu8QRj+UdLMyfJhCGCJ0eZ/Vl7xdfQCUx5YM26kTVotSoy6bGTyCQKE5m Phow== X-Gm-Message-State: ACrzQf307pNsNM0+ggP/Cqof5Er2S7hJGWC5ablVosyddJS7TXyp86RZ ST0PEYyCYOHs7x35exfw+Cm4gxYsOervj/HzWjzSkOsNUgefEs52YEfGyOke+5/HCF6scb2maSl 7FOdvRWF/vZuO1QW+5Y8OPKxDUg== X-Received: by 2002:a05:6402:ea0:b0:454:38bf:aa3d with SMTP id h32-20020a0564020ea000b0045438bfaa3dmr19108190eda.291.1666860707413; Thu, 27 Oct 2022 01:51:47 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4M97BY+DJtCFsy6QaUdWwayGL+u3zLh+pSJfoHcV6/8JnsSecEzthndHQaTneGvNUsC3XcVA== X-Received: by 2002:a05:6402:ea0:b0:454:38bf:aa3d with SMTP id h32-20020a0564020ea000b0045438bfaa3dmr19108164eda.291.1666860707189; Thu, 27 Oct 2022 01:51:47 -0700 (PDT) Received: from ?IPV6:2001:1c00:c1e:bf00:d69d:5353:dba5:ee81? (2001-1c00-0c1e-bf00-d69d-5353-dba5-ee81.cable.dynamic.v6.ziggo.nl. [2001:1c00:c1e:bf00:d69d:5353:dba5:ee81]) by smtp.gmail.com with ESMTPSA id w15-20020a056402268f00b004615bea1d5bsm635132edd.35.2022.10.27.01.51.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 27 Oct 2022 01:51:46 -0700 (PDT) Message-ID: <099dee98-8aeb-af36-828c-110f5ac6e9a3@redhat.com> Date: Thu, 27 Oct 2022 10:51:45 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.1 To: Matthew Garrett 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> <20221026204920.GA15326@srcf.ucam.org> From: Hans de Goede In-Reply-To: <20221026204920.GA15326@srcf.ucam.org> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US, nl Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 , =?UTF-8?Q?Christian_K=c3=b6nig?= Errors-To: nouveau-bounces@lists.freedesktop.org Sender: "Nouveau" Hi, On 10/26/22 22:49, Matthew Garrett wrote: > 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. All vendor drivers that I'm aware of have: if (acpi_video_get_backlight_type() != acpi_backlight_vendor) return; In their backlight register paths and this has been present since circa 2015. So both before and after my 6.1 refactor vendor is only preferred on devices which don't implement the ACPI video bus control method. >>> 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 see. I agree that preferring native over vendor on machines which do not have ACPI video backlight control will cause issues on older machines. Avoiding this scenario is exactly why currently the native check is conditional on the presence of ACPI video backlight control. >> 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. I wish that that ("telling you whether they'd prefer vendor or native") were true. But that does not match my experience at all and I've been working on making the kernel pick the right backlight interface on laptops since 2014. Just because a vendor interface is present does not mean that it will work. Unfortunately for none of the 3 main native/acpi_video/vendor backlight control methods the control method being present also guarantees that it will work. Which completely sucks, but it is the reality we have to deal with. > , and you're not taking that into account > in the video_detect code. Regards, Hans 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 49C22C67871 for ; Thu, 27 Oct 2022 08:51:59 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 7D71310E585; Thu, 27 Oct 2022 08:51:54 +0000 (UTC) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by gabe.freedesktop.org (Postfix) with ESMTPS id A2DC910E585 for ; Thu, 27 Oct 2022 08:51:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1666860709; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=piG9yqT6xAhiMXdKpX5Y3Qo1FGMuiTJ1yFwdVO4p5IY=; b=J0+4zbvXyTATgLNbua0dZp3QPkoqKjhr9lkoUkPgo1mvU5j+l+h6C8WCTNYiqUvZs/DVDy BwBNU/fZ/37vGepTdQxSkh0gd2FDxwXKENoPy6mIyPkwoImRyFbZFTroOsgc0bUq3WI81E E8Xf9uFnOHFjbdgXTgaZkrteK0aK4kE= Received: from mail-ed1-f69.google.com (mail-ed1-f69.google.com [209.85.208.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-286-vH9YJenGPbG6qoHHUyTc0A-1; Thu, 27 Oct 2022 04:51:48 -0400 X-MC-Unique: vH9YJenGPbG6qoHHUyTc0A-1 Received: by mail-ed1-f69.google.com with SMTP id f16-20020a056402355000b00461cf923fdcso649900edd.13 for ; Thu, 27 Oct 2022 01:51:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=piG9yqT6xAhiMXdKpX5Y3Qo1FGMuiTJ1yFwdVO4p5IY=; b=B+jX24VPEOcBKgX+tWVlJ3ecglKHK29gScA2+h2+MMS+Q/sytPfusLzmxQJnmk/pyJ pmIBf6Uvo80LTiC8XeAeRIEJXybHZVxd8II/Hjwfgmv5nH/WgLGwUbHJMCh+0NXezeP5 5xBthPiT6/XHKSNwrGUfsUCQH28qMHlpQ/r3JYHCGhHth+ngOkJy4AKMDwUFVeunqQPH WXzDsJOWHdqohBlGs4SX3xuYI3xG/gd4tGlT2xys8ECK1o2yYtzABcaRLkqLocpJ6Lmd TpDpc2po0TU7ZrDVzSzqpbirfNUC1GKQls4tcDGWGNg3vnSZrNNuhYVCIOvLaF+Apxol jP6w== X-Gm-Message-State: ACrzQf10qc/ga/zVpc8IGzgTZmi7jeeirbUJpgC4vDdpZjzGNFmh8ts5 mMk+g9iHK8OaYEAIsVO8pm9zreGrtPgecKCUgkaO1qBzziUlxs+nf7jFyn4kQGKgpqpysx5yDZ3 HPS5GKaRLIuA/Y8viQvWX5Is5c1th X-Received: by 2002:a05:6402:ea0:b0:454:38bf:aa3d with SMTP id h32-20020a0564020ea000b0045438bfaa3dmr19108209eda.291.1666860707458; Thu, 27 Oct 2022 01:51:47 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4M97BY+DJtCFsy6QaUdWwayGL+u3zLh+pSJfoHcV6/8JnsSecEzthndHQaTneGvNUsC3XcVA== X-Received: by 2002:a05:6402:ea0:b0:454:38bf:aa3d with SMTP id h32-20020a0564020ea000b0045438bfaa3dmr19108164eda.291.1666860707189; Thu, 27 Oct 2022 01:51:47 -0700 (PDT) Received: from ?IPV6:2001:1c00:c1e:bf00:d69d:5353:dba5:ee81? (2001-1c00-0c1e-bf00-d69d-5353-dba5-ee81.cable.dynamic.v6.ziggo.nl. [2001:1c00:c1e:bf00:d69d:5353:dba5:ee81]) by smtp.gmail.com with ESMTPSA id w15-20020a056402268f00b004615bea1d5bsm635132edd.35.2022.10.27.01.51.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 27 Oct 2022 01:51:46 -0700 (PDT) Message-ID: <099dee98-8aeb-af36-828c-110f5ac6e9a3@redhat.com> Date: Thu, 27 Oct 2022 10:51:45 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.1 Subject: Re: [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2) To: Matthew Garrett 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> <20221026204920.GA15326@srcf.ucam.org> From: Hans de Goede In-Reply-To: <20221026204920.GA15326@srcf.ucam.org> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US, nl Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 , =?UTF-8?Q?Christian_K=c3=b6nig?= Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" Hi, On 10/26/22 22:49, Matthew Garrett wrote: > 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. All vendor drivers that I'm aware of have: if (acpi_video_get_backlight_type() != acpi_backlight_vendor) return; In their backlight register paths and this has been present since circa 2015. So both before and after my 6.1 refactor vendor is only preferred on devices which don't implement the ACPI video bus control method. >>> 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 see. I agree that preferring native over vendor on machines which do not have ACPI video backlight control will cause issues on older machines. Avoiding this scenario is exactly why currently the native check is conditional on the presence of ACPI video backlight control. >> 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. I wish that that ("telling you whether they'd prefer vendor or native") were true. But that does not match my experience at all and I've been working on making the kernel pick the right backlight interface on laptops since 2014. Just because a vendor interface is present does not mean that it will work. Unfortunately for none of the 3 main native/acpi_video/vendor backlight control methods the control method being present also guarantees that it will work. Which completely sucks, but it is the reality we have to deal with. > , and you're not taking that into account > in the video_detect code. Regards, Hans 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 2EB0BC67871 for ; Thu, 27 Oct 2022 08:52:06 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id F2A7D10E588; Thu, 27 Oct 2022 08:51:55 +0000 (UTC) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by gabe.freedesktop.org (Postfix) with ESMTPS id A369A10E586 for ; Thu, 27 Oct 2022 08:51:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1666860709; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=piG9yqT6xAhiMXdKpX5Y3Qo1FGMuiTJ1yFwdVO4p5IY=; b=J0+4zbvXyTATgLNbua0dZp3QPkoqKjhr9lkoUkPgo1mvU5j+l+h6C8WCTNYiqUvZs/DVDy BwBNU/fZ/37vGepTdQxSkh0gd2FDxwXKENoPy6mIyPkwoImRyFbZFTroOsgc0bUq3WI81E E8Xf9uFnOHFjbdgXTgaZkrteK0aK4kE= Received: from mail-ed1-f72.google.com (mail-ed1-f72.google.com [209.85.208.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-44-aUKxsOxqOvaBg90N1vMqlg-1; Thu, 27 Oct 2022 04:51:48 -0400 X-MC-Unique: aUKxsOxqOvaBg90N1vMqlg-1 Received: by mail-ed1-f72.google.com with SMTP id m7-20020a056402430700b0045daff6ee5dso655066edc.10 for ; Thu, 27 Oct 2022 01:51:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=piG9yqT6xAhiMXdKpX5Y3Qo1FGMuiTJ1yFwdVO4p5IY=; b=AblLDzixUQsrzmEnwfOykOPPCWIqkw3ia78rc/VUWVu9O7h9cClZoV3oaWYtWlvo6n AH+2LtOeEmYKr4NptE/oLVs40g8Wq0n10IWb2H27HhW1nI8zSfB058c8NRi4WoD3wfVK vWfImIWGi7PDH33Dd/mCyCFNXAI8hWHF0i4IvERVjcPhhIKYo9J0nlkfaU1viX/CCtE2 SdC1B5uhlMIVA4KGKyfkuQpDBz/M4Ivo/Z6yeJXvcK1c9FRj3TNqqpxSXpcRRNtRL1BD IBtxqRWnL5CU4ICDJt9Yi1Q1BHDlZLaUWoXuWPkC4v9mB6PbHGXTox3OOf721+Kxen5b uPig== X-Gm-Message-State: ACrzQf14REGoHy4AaCSQ+9jzBCk6uGRv/QaSwPPydfm/1791rP3jxsgL Kv1bRwy2pt8cuDA/IherM2faMLaWCg4WF2eEgJT66g6EVPypqqc1NJmqAACcDsB7NM7HA8YYFyc MVEspect6vW/+K5qwSAvX6PJIon3C X-Received: by 2002:a05:6402:ea0:b0:454:38bf:aa3d with SMTP id h32-20020a0564020ea000b0045438bfaa3dmr19108206eda.291.1666860707445; Thu, 27 Oct 2022 01:51:47 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4M97BY+DJtCFsy6QaUdWwayGL+u3zLh+pSJfoHcV6/8JnsSecEzthndHQaTneGvNUsC3XcVA== X-Received: by 2002:a05:6402:ea0:b0:454:38bf:aa3d with SMTP id h32-20020a0564020ea000b0045438bfaa3dmr19108164eda.291.1666860707189; Thu, 27 Oct 2022 01:51:47 -0700 (PDT) Received: from ?IPV6:2001:1c00:c1e:bf00:d69d:5353:dba5:ee81? (2001-1c00-0c1e-bf00-d69d-5353-dba5-ee81.cable.dynamic.v6.ziggo.nl. [2001:1c00:c1e:bf00:d69d:5353:dba5:ee81]) by smtp.gmail.com with ESMTPSA id w15-20020a056402268f00b004615bea1d5bsm635132edd.35.2022.10.27.01.51.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 27 Oct 2022 01:51:46 -0700 (PDT) Message-ID: <099dee98-8aeb-af36-828c-110f5ac6e9a3@redhat.com> Date: Thu, 27 Oct 2022 10:51:45 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.1 To: Matthew Garrett 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> <20221026204920.GA15326@srcf.ucam.org> From: Hans de Goede In-Reply-To: <20221026204920.GA15326@srcf.ucam.org> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US, nl Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 , =?UTF-8?Q?Christian_K=c3=b6nig?= Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" Hi, On 10/26/22 22:49, Matthew Garrett wrote: > 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. All vendor drivers that I'm aware of have: if (acpi_video_get_backlight_type() != acpi_backlight_vendor) return; In their backlight register paths and this has been present since circa 2015. So both before and after my 6.1 refactor vendor is only preferred on devices which don't implement the ACPI video bus control method. >>> 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 see. I agree that preferring native over vendor on machines which do not have ACPI video backlight control will cause issues on older machines. Avoiding this scenario is exactly why currently the native check is conditional on the presence of ACPI video backlight control. >> 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. I wish that that ("telling you whether they'd prefer vendor or native") were true. But that does not match my experience at all and I've been working on making the kernel pick the right backlight interface on laptops since 2014. Just because a vendor interface is present does not mean that it will work. Unfortunately for none of the 3 main native/acpi_video/vendor backlight control methods the control method being present also guarantees that it will work. Which completely sucks, but it is the reality we have to deal with. > , and you're not taking that into account > in the video_detect code. Regards, Hans 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 5F740FA3742 for ; Thu, 27 Oct 2022 12:33:54 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 04DE110E5FD; Thu, 27 Oct 2022 12:33:47 +0000 (UTC) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by gabe.freedesktop.org (Postfix) with ESMTPS id 9E11310E582 for ; Thu, 27 Oct 2022 08:51:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1666860709; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=piG9yqT6xAhiMXdKpX5Y3Qo1FGMuiTJ1yFwdVO4p5IY=; b=J0+4zbvXyTATgLNbua0dZp3QPkoqKjhr9lkoUkPgo1mvU5j+l+h6C8WCTNYiqUvZs/DVDy BwBNU/fZ/37vGepTdQxSkh0gd2FDxwXKENoPy6mIyPkwoImRyFbZFTroOsgc0bUq3WI81E E8Xf9uFnOHFjbdgXTgaZkrteK0aK4kE= Received: from mail-ej1-f72.google.com (mail-ej1-f72.google.com [209.85.218.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-267-76EcJzw4O4286_AO8-UFmQ-1; Thu, 27 Oct 2022 04:51:48 -0400 X-MC-Unique: 76EcJzw4O4286_AO8-UFmQ-1 Received: by mail-ej1-f72.google.com with SMTP id gt15-20020a1709072d8f00b007aaac7973fbso593543ejc.23 for ; Thu, 27 Oct 2022 01:51:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=piG9yqT6xAhiMXdKpX5Y3Qo1FGMuiTJ1yFwdVO4p5IY=; b=dLIKfQS4iiu7gdWr7TND112GEsbAlbFdPcX5uYPHlSA4FJ2E1OHvIw9fdLwZMSEUVL BXsobgbt80k912Nezm8K7E8i2HREG1ZLjRVHVZhlztZYLUjyDc74uCg7biwKIc5b1VXA KNGt2o4pNAZ0C93Ac24BUYXVFX5y5Sr0uZYOtBzNLjH+ZBCIV+0Y7OJKKrZpw9r8i7Nm RpHNTeksXtVDaaW0zkrTpbxkT8U1KC13kjwjoDYup1si2WyETQJt8mJEO6iMcr2TtTHM Hd+LKzkCNEcXdN2VeaH0jmpZi+cTOBmPyjGU2pTOOreerLLXcVzCIf7U6wAoWoeYkHFJ ss0g== X-Gm-Message-State: ACrzQf3/DxnMz/ou2RDiyIKN5azMYZ5vMrmwE8ytdn/Z6vLcMpfKcW7H R8Lex5LVGNGW8UOjhbxlfpQnpr3FyfAURy+bg/1mXPmQ1gwYR2KrWalG2hxJLDfNu0P6ARSv7Z3 Xn+bJCV7AWWxQu9/9kz/dat3GeQ== X-Received: by 2002:a05:6402:ea0:b0:454:38bf:aa3d with SMTP id h32-20020a0564020ea000b0045438bfaa3dmr19108210eda.291.1666860707458; Thu, 27 Oct 2022 01:51:47 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4M97BY+DJtCFsy6QaUdWwayGL+u3zLh+pSJfoHcV6/8JnsSecEzthndHQaTneGvNUsC3XcVA== X-Received: by 2002:a05:6402:ea0:b0:454:38bf:aa3d with SMTP id h32-20020a0564020ea000b0045438bfaa3dmr19108164eda.291.1666860707189; Thu, 27 Oct 2022 01:51:47 -0700 (PDT) Received: from ?IPV6:2001:1c00:c1e:bf00:d69d:5353:dba5:ee81? (2001-1c00-0c1e-bf00-d69d-5353-dba5-ee81.cable.dynamic.v6.ziggo.nl. [2001:1c00:c1e:bf00:d69d:5353:dba5:ee81]) by smtp.gmail.com with ESMTPSA id w15-20020a056402268f00b004615bea1d5bsm635132edd.35.2022.10.27.01.51.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 27 Oct 2022 01:51:46 -0700 (PDT) Message-ID: <099dee98-8aeb-af36-828c-110f5ac6e9a3@redhat.com> Date: Thu, 27 Oct 2022 10:51:45 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.1 Subject: Re: [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2) To: Matthew Garrett 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> <20221026204920.GA15326@srcf.ucam.org> From: Hans de Goede In-Reply-To: <20221026204920.GA15326@srcf.ucam.org> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US, nl Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 27 Oct 2022 12:33:43 +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 , =?UTF-8?Q?Christian_K=c3=b6nig?= Errors-To: amd-gfx-bounces@lists.freedesktop.org Sender: "amd-gfx" Hi, On 10/26/22 22:49, Matthew Garrett wrote: > 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. All vendor drivers that I'm aware of have: if (acpi_video_get_backlight_type() != acpi_backlight_vendor) return; In their backlight register paths and this has been present since circa 2015. So both before and after my 6.1 refactor vendor is only preferred on devices which don't implement the ACPI video bus control method. >>> 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 see. I agree that preferring native over vendor on machines which do not have ACPI video backlight control will cause issues on older machines. Avoiding this scenario is exactly why currently the native check is conditional on the presence of ACPI video backlight control. >> 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. I wish that that ("telling you whether they'd prefer vendor or native") were true. But that does not match my experience at all and I've been working on making the kernel pick the right backlight interface on laptops since 2014. Just because a vendor interface is present does not mean that it will work. Unfortunately for none of the 3 main native/acpi_video/vendor backlight control methods the control method being present also guarantees that it will work. Which completely sucks, but it is the reality we have to deal with. > , and you're not taking that into account > in the video_detect code. Regards, Hans