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 AD972FA3742 for ; Thu, 27 Oct 2022 12:19:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234219AbiJ0MTs (ORCPT ); Thu, 27 Oct 2022 08:19:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54316 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229473AbiJ0MTr (ORCPT ); Thu, 27 Oct 2022 08:19:47 -0400 Received: from mail-qt1-f176.google.com (mail-qt1-f176.google.com [209.85.160.176]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D214546859; Thu, 27 Oct 2022 05:19:44 -0700 (PDT) Received: by mail-qt1-f176.google.com with SMTP id hh9so901767qtb.13; Thu, 27 Oct 2022 05:19:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=3e9j5Qwiqs/f1XbIA4ZFfx647JqImc8PuBMqMLRI+CY=; b=SuCrL2rtpYBvK8Wl0P56AnC6iI2HQOI0RYFULOli6vNW/IkHYrZhDniE9ouIZdZ7i5 WnbxpbOx//W7kMjdjy8IeHYV2HcGbAkNM9OxgCKU1daCKmzjePu2ttBKKEzHMCNsf5Mi sBxC/piUdVh3wzEBNBnRAmJ+MpDEoCLnNhMnM/aa1WjojETZ8UIh3OChf7fI07hIPqhd GmAt0p2xgQz9MwEEfEtAby9SoZ1oZshlMKJxHfFLQFDRDHZG946IwxsihTCshiO+eycU uufbPlwzqe5X7N6FInyqDsVrBDERYklrM/WzQd6DLQiols0N6tTjJvKiMS3x0Y0GWFYx z7dQ== X-Gm-Message-State: ACrzQf0GuL77I1EhpgXML3NNUi6TDdSohSL+Yxq/CvQZsLJ1dfVbfvcX I9jM1fBOTT4vnzzGYvG9CYy6L9K1XpwYT3CiOj0= X-Google-Smtp-Source: AMsMyM69RoU0FyynhwyvAcltO78mN8wnrxDaU0H42sOUgzVaxEwEWEEjpPn5ALxiGMgXKKWihZ8uqwTw9rMyl80ilzY= X-Received: by 2002:a05:622a:13c6:b0:39c:c34f:29ec with SMTP id p6-20020a05622a13c600b0039cc34f29ecmr40973105qtk.153.1666873183985; Thu, 27 Oct 2022 05:19:43 -0700 (PDT) MIME-Version: 1.0 References: <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> <099dee98-8aeb-af36-828c-110f5ac6e9a3@redhat.com> <20221027091123.GA28089@srcf.ucam.org> <933be908-0bc2-56cc-8d6f-38f2d208ef20@redhat.com> <20221027095249.GA28666@srcf.ucam.org> <6df2016d-ed2d-57fa-dcad-48537732895f@redhat.com> <526db9ed-bc39-b6be-c977-d4509ce22152@redhat.com> In-Reply-To: <526db9ed-bc39-b6be-c977-d4509ce22152@redhat.com> From: "Rafael J. Wysocki" Date: Thu, 27 Oct 2022 14:19:32 +0200 Message-ID: Subject: Re: [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2) To: Hans de Goede Cc: "Rafael J. Wysocki" , Matthew Garrett , 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?= , Xinhui , 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 Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org On Thu, Oct 27, 2022 at 2:17 PM Hans de Goede wrote: > > Hi, > > On 10/27/22 14:09, Rafael J. Wysocki wrote: > > On Thu, Oct 27, 2022 at 12:37 PM Hans de Goede wrote: > >> > >> Hi, > >> > >> On 10/27/22 11:52, Matthew Garrett wrote: > >>> On Thu, Oct 27, 2022 at 11:39:38AM +0200, Hans de Goede wrote: > >>> > >>>> The *only* behavior which actually is new in 6.1 is the native GPU > >>>> drivers now doing the equivalent of: > >>>> > >>>> if (acpi_video_get_backlight_type() != acpi_backlight_native) > >>>> return; > >>>> > >>>> In their backlight register paths (i), which is causing the native > >>>> backlight to disappear on your custom laptop setup and on Chromebooks > >>>> (with the Chromebooks case being already solved I hope.). > >>> > >>> It's causing the backlight control to vanish on any machine that isn't > >>> ((acpi_video || vendor interface) || !acpi). Most machines that fall > >>> into that are either weird or Chromebooks or old, but there are machines > >>> that fall into that. > >> > >> I acknowledge that their are machines that fall into this category, > >> but I expect / hope there to be so few of them that we can just DMI > >> quirk our way out if this. > >> > >> I believe the old group to be small because: > >> > >> 1. Generally speaking the "native" control method is usually not > >> present on the really old (pre ACPI video spec) mobile GPUs. > >> > >> 2. On most old laptops I would still expect there to be a vendor > >> interface too, and if both get registered standard desktop environments > >> will prefer the vendor one, so then we need a native DMI quirk to > >> disable the vendor interface anyways and we already have a bunch of > >> those, so some laptops in this group are already covered by DMI quirks. > >> > >> And a fix for the Chromebook case is already in Linus' tree, which > >> just leaves the weird case, of which there will hopefully be only > >> a few. > >> > >> I do share your worry that this might break some machines, but > >> the only way to really find out is to get this code out there > >> I'm afraid. > >> > >> I have just written a blog post asking for people to check if > >> their laptop might be affected; and to report various details > >> to me of their laptop is affected: > >> > >> https://hansdegoede.dreamwidth.org/26548.html > >> > >> Lets wait and see how this goes. If I get (too) many reports then > >> I will send a revert of the addition of the: > >> > >> if (acpi_video_get_backlight_type() != acpi_backlight_native) > >> return; > >> > >> check to the i915 / radeon / amd / nouveau drivers. > >> > >> (And if I only get a couple of reports I will probably just submit > >> DMI quirks for the affected models). > > > > Sounds reasonable to me, FWIW. > > > > And IIUC the check above can be overridden by passing > > acpi_backlight=native in the kernel command line, right? > > Right, that can be used as a quick workaround, but we really do > want this to work OOTB everywhere. Sure. My point is that if it doesn't work OOTB for someone, and say it used to, they can use the above workaround and report back. 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 78EA9ECAAA1 for ; Thu, 27 Oct 2022 12:19:56 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 461DE10E5E5; Thu, 27 Oct 2022 12:19:51 +0000 (UTC) Received: from mail-qt1-f176.google.com (mail-qt1-f176.google.com [209.85.160.176]) by gabe.freedesktop.org (Postfix) with ESMTPS id E1AF510E3F0; Thu, 27 Oct 2022 12:19:44 +0000 (UTC) Received: by mail-qt1-f176.google.com with SMTP id l28so930352qtv.4; Thu, 27 Oct 2022 05:19:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=3e9j5Qwiqs/f1XbIA4ZFfx647JqImc8PuBMqMLRI+CY=; b=nZs3hLafqLMV6OIkI1vFHA4+DfehZtA4SzMfNMQ0HMk0WhGBl5kc+fklGyUYZuf7hs k0BmOg3rfqQmdLktcfLulLjtP7lCqA3pp8Gl7w/YTkhvOiSu0vUcfPYm6t2TV8d0MdGO B/r3qT1YpCm/gOWtqZkA46oDdBVKhI429GnAfjZwmjnlXe25TMNyI9qHJrc3PwJvdKYb AOPN/1tVL0XH3RrIfzPmEmrOm8KwGf2rPs6T0Uc5BdCABZeRv2sQySYbN7LngD2IGZDy Y3BfbvCI0a/i1WoxYsJpIhIMjYPe+TqML9A+9rmiq1vBHRqURly5TY2DTgW//TcaLiOD kSCQ== X-Gm-Message-State: ACrzQf0HFekXoxMC5y22s24SQAuVFrs+9pAX9sfAWclFz8a6Wt7e3N4h ul0VvztpHKTsM8jUdg6QtFn31CMnPUJOy8tg3Fg= X-Google-Smtp-Source: AMsMyM69RoU0FyynhwyvAcltO78mN8wnrxDaU0H42sOUgzVaxEwEWEEjpPn5ALxiGMgXKKWihZ8uqwTw9rMyl80ilzY= X-Received: by 2002:a05:622a:13c6:b0:39c:c34f:29ec with SMTP id p6-20020a05622a13c600b0039cc34f29ecmr40973105qtk.153.1666873183985; Thu, 27 Oct 2022 05:19:43 -0700 (PDT) MIME-Version: 1.0 References: <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> <099dee98-8aeb-af36-828c-110f5ac6e9a3@redhat.com> <20221027091123.GA28089@srcf.ucam.org> <933be908-0bc2-56cc-8d6f-38f2d208ef20@redhat.com> <20221027095249.GA28666@srcf.ucam.org> <6df2016d-ed2d-57fa-dcad-48537732895f@redhat.com> <526db9ed-bc39-b6be-c977-d4509ce22152@redhat.com> In-Reply-To: <526db9ed-bc39-b6be-c977-d4509ce22152@redhat.com> From: "Rafael J. Wysocki" Date: Thu, 27 Oct 2022 14:19:32 +0200 Message-ID: To: Hans de Goede Content-Type: text/plain; charset="UTF-8" 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: "Rafael J. Wysocki" , nouveau@lists.freedesktop.org, Joonas Lahtinen , dri-devel@lists.freedesktop.org, platform-driver-x86@vger.kernel.org, Daniel Dadap , Dmitry Osipenko , amd-gfx@lists.freedesktop.org, linux-acpi@vger.kernel.org, Ben Skeggs , David Airlie , Len Brown , 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" On Thu, Oct 27, 2022 at 2:17 PM Hans de Goede wrote: > > Hi, > > On 10/27/22 14:09, Rafael J. Wysocki wrote: > > On Thu, Oct 27, 2022 at 12:37 PM Hans de Goede wrote: > >> > >> Hi, > >> > >> On 10/27/22 11:52, Matthew Garrett wrote: > >>> On Thu, Oct 27, 2022 at 11:39:38AM +0200, Hans de Goede wrote: > >>> > >>>> The *only* behavior which actually is new in 6.1 is the native GPU > >>>> drivers now doing the equivalent of: > >>>> > >>>> if (acpi_video_get_backlight_type() != acpi_backlight_native) > >>>> return; > >>>> > >>>> In their backlight register paths (i), which is causing the native > >>>> backlight to disappear on your custom laptop setup and on Chromebooks > >>>> (with the Chromebooks case being already solved I hope.). > >>> > >>> It's causing the backlight control to vanish on any machine that isn't > >>> ((acpi_video || vendor interface) || !acpi). Most machines that fall > >>> into that are either weird or Chromebooks or old, but there are machines > >>> that fall into that. > >> > >> I acknowledge that their are machines that fall into this category, > >> but I expect / hope there to be so few of them that we can just DMI > >> quirk our way out if this. > >> > >> I believe the old group to be small because: > >> > >> 1. Generally speaking the "native" control method is usually not > >> present on the really old (pre ACPI video spec) mobile GPUs. > >> > >> 2. On most old laptops I would still expect there to be a vendor > >> interface too, and if both get registered standard desktop environments > >> will prefer the vendor one, so then we need a native DMI quirk to > >> disable the vendor interface anyways and we already have a bunch of > >> those, so some laptops in this group are already covered by DMI quirks. > >> > >> And a fix for the Chromebook case is already in Linus' tree, which > >> just leaves the weird case, of which there will hopefully be only > >> a few. > >> > >> I do share your worry that this might break some machines, but > >> the only way to really find out is to get this code out there > >> I'm afraid. > >> > >> I have just written a blog post asking for people to check if > >> their laptop might be affected; and to report various details > >> to me of their laptop is affected: > >> > >> https://hansdegoede.dreamwidth.org/26548.html > >> > >> Lets wait and see how this goes. If I get (too) many reports then > >> I will send a revert of the addition of the: > >> > >> if (acpi_video_get_backlight_type() != acpi_backlight_native) > >> return; > >> > >> check to the i915 / radeon / amd / nouveau drivers. > >> > >> (And if I only get a couple of reports I will probably just submit > >> DMI quirks for the affected models). > > > > Sounds reasonable to me, FWIW. > > > > And IIUC the check above can be overridden by passing > > acpi_backlight=native in the kernel command line, right? > > Right, that can be used as a quick workaround, but we really do > want this to work OOTB everywhere. Sure. My point is that if it doesn't work OOTB for someone, and say it used to, they can use the above workaround and report back. 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 EEFD8FA3743 for ; Thu, 27 Oct 2022 12:19:50 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 76AC210E3B2; Thu, 27 Oct 2022 12:19:49 +0000 (UTC) Received: from mail-qt1-f176.google.com (mail-qt1-f176.google.com [209.85.160.176]) by gabe.freedesktop.org (Postfix) with ESMTPS id E1AF510E3F0; Thu, 27 Oct 2022 12:19:44 +0000 (UTC) Received: by mail-qt1-f176.google.com with SMTP id l28so930352qtv.4; Thu, 27 Oct 2022 05:19:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=3e9j5Qwiqs/f1XbIA4ZFfx647JqImc8PuBMqMLRI+CY=; b=nZs3hLafqLMV6OIkI1vFHA4+DfehZtA4SzMfNMQ0HMk0WhGBl5kc+fklGyUYZuf7hs k0BmOg3rfqQmdLktcfLulLjtP7lCqA3pp8Gl7w/YTkhvOiSu0vUcfPYm6t2TV8d0MdGO B/r3qT1YpCm/gOWtqZkA46oDdBVKhI429GnAfjZwmjnlXe25TMNyI9qHJrc3PwJvdKYb AOPN/1tVL0XH3RrIfzPmEmrOm8KwGf2rPs6T0Uc5BdCABZeRv2sQySYbN7LngD2IGZDy Y3BfbvCI0a/i1WoxYsJpIhIMjYPe+TqML9A+9rmiq1vBHRqURly5TY2DTgW//TcaLiOD kSCQ== X-Gm-Message-State: ACrzQf0HFekXoxMC5y22s24SQAuVFrs+9pAX9sfAWclFz8a6Wt7e3N4h ul0VvztpHKTsM8jUdg6QtFn31CMnPUJOy8tg3Fg= X-Google-Smtp-Source: AMsMyM69RoU0FyynhwyvAcltO78mN8wnrxDaU0H42sOUgzVaxEwEWEEjpPn5ALxiGMgXKKWihZ8uqwTw9rMyl80ilzY= X-Received: by 2002:a05:622a:13c6:b0:39c:c34f:29ec with SMTP id p6-20020a05622a13c600b0039cc34f29ecmr40973105qtk.153.1666873183985; Thu, 27 Oct 2022 05:19:43 -0700 (PDT) MIME-Version: 1.0 References: <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> <099dee98-8aeb-af36-828c-110f5ac6e9a3@redhat.com> <20221027091123.GA28089@srcf.ucam.org> <933be908-0bc2-56cc-8d6f-38f2d208ef20@redhat.com> <20221027095249.GA28666@srcf.ucam.org> <6df2016d-ed2d-57fa-dcad-48537732895f@redhat.com> <526db9ed-bc39-b6be-c977-d4509ce22152@redhat.com> In-Reply-To: <526db9ed-bc39-b6be-c977-d4509ce22152@redhat.com> From: "Rafael J. Wysocki" Date: Thu, 27 Oct 2022 14:19:32 +0200 Message-ID: Subject: Re: [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2) To: Hans de Goede Content-Type: text/plain; charset="UTF-8" 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: Karol Herbst , "Rafael J. Wysocki" , nouveau@lists.freedesktop.org, dri-devel@lists.freedesktop.org, platform-driver-x86@vger.kernel.org, Daniel Dadap , Dmitry Osipenko , amd-gfx@lists.freedesktop.org, linux-acpi@vger.kernel.org, Ben Skeggs , David Airlie , Len Brown , Matthew Garrett , 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" On Thu, Oct 27, 2022 at 2:17 PM Hans de Goede wrote: > > Hi, > > On 10/27/22 14:09, Rafael J. Wysocki wrote: > > On Thu, Oct 27, 2022 at 12:37 PM Hans de Goede wrote: > >> > >> Hi, > >> > >> On 10/27/22 11:52, Matthew Garrett wrote: > >>> On Thu, Oct 27, 2022 at 11:39:38AM +0200, Hans de Goede wrote: > >>> > >>>> The *only* behavior which actually is new in 6.1 is the native GPU > >>>> drivers now doing the equivalent of: > >>>> > >>>> if (acpi_video_get_backlight_type() != acpi_backlight_native) > >>>> return; > >>>> > >>>> In their backlight register paths (i), which is causing the native > >>>> backlight to disappear on your custom laptop setup and on Chromebooks > >>>> (with the Chromebooks case being already solved I hope.). > >>> > >>> It's causing the backlight control to vanish on any machine that isn't > >>> ((acpi_video || vendor interface) || !acpi). Most machines that fall > >>> into that are either weird or Chromebooks or old, but there are machines > >>> that fall into that. > >> > >> I acknowledge that their are machines that fall into this category, > >> but I expect / hope there to be so few of them that we can just DMI > >> quirk our way out if this. > >> > >> I believe the old group to be small because: > >> > >> 1. Generally speaking the "native" control method is usually not > >> present on the really old (pre ACPI video spec) mobile GPUs. > >> > >> 2. On most old laptops I would still expect there to be a vendor > >> interface too, and if both get registered standard desktop environments > >> will prefer the vendor one, so then we need a native DMI quirk to > >> disable the vendor interface anyways and we already have a bunch of > >> those, so some laptops in this group are already covered by DMI quirks. > >> > >> And a fix for the Chromebook case is already in Linus' tree, which > >> just leaves the weird case, of which there will hopefully be only > >> a few. > >> > >> I do share your worry that this might break some machines, but > >> the only way to really find out is to get this code out there > >> I'm afraid. > >> > >> I have just written a blog post asking for people to check if > >> their laptop might be affected; and to report various details > >> to me of their laptop is affected: > >> > >> https://hansdegoede.dreamwidth.org/26548.html > >> > >> Lets wait and see how this goes. If I get (too) many reports then > >> I will send a revert of the addition of the: > >> > >> if (acpi_video_get_backlight_type() != acpi_backlight_native) > >> return; > >> > >> check to the i915 / radeon / amd / nouveau drivers. > >> > >> (And if I only get a couple of reports I will probably just submit > >> DMI quirks for the affected models). > > > > Sounds reasonable to me, FWIW. > > > > And IIUC the check above can be overridden by passing > > acpi_backlight=native in the kernel command line, right? > > Right, that can be used as a quick workaround, but we really do > want this to work OOTB everywhere. Sure. My point is that if it doesn't work OOTB for someone, and say it used to, they can use the above workaround and report back. 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 0C7C4FA3742 for ; Thu, 27 Oct 2022 12:19:59 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 94CED10E3F0; Thu, 27 Oct 2022 12:19:51 +0000 (UTC) Received: from mail-qt1-f176.google.com (mail-qt1-f176.google.com [209.85.160.176]) by gabe.freedesktop.org (Postfix) with ESMTPS id E1AF510E3F0; Thu, 27 Oct 2022 12:19:44 +0000 (UTC) Received: by mail-qt1-f176.google.com with SMTP id l28so930352qtv.4; Thu, 27 Oct 2022 05:19:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=3e9j5Qwiqs/f1XbIA4ZFfx647JqImc8PuBMqMLRI+CY=; b=nZs3hLafqLMV6OIkI1vFHA4+DfehZtA4SzMfNMQ0HMk0WhGBl5kc+fklGyUYZuf7hs k0BmOg3rfqQmdLktcfLulLjtP7lCqA3pp8Gl7w/YTkhvOiSu0vUcfPYm6t2TV8d0MdGO B/r3qT1YpCm/gOWtqZkA46oDdBVKhI429GnAfjZwmjnlXe25TMNyI9qHJrc3PwJvdKYb AOPN/1tVL0XH3RrIfzPmEmrOm8KwGf2rPs6T0Uc5BdCABZeRv2sQySYbN7LngD2IGZDy Y3BfbvCI0a/i1WoxYsJpIhIMjYPe+TqML9A+9rmiq1vBHRqURly5TY2DTgW//TcaLiOD kSCQ== X-Gm-Message-State: ACrzQf0HFekXoxMC5y22s24SQAuVFrs+9pAX9sfAWclFz8a6Wt7e3N4h ul0VvztpHKTsM8jUdg6QtFn31CMnPUJOy8tg3Fg= X-Google-Smtp-Source: AMsMyM69RoU0FyynhwyvAcltO78mN8wnrxDaU0H42sOUgzVaxEwEWEEjpPn5ALxiGMgXKKWihZ8uqwTw9rMyl80ilzY= X-Received: by 2002:a05:622a:13c6:b0:39c:c34f:29ec with SMTP id p6-20020a05622a13c600b0039cc34f29ecmr40973105qtk.153.1666873183985; Thu, 27 Oct 2022 05:19:43 -0700 (PDT) MIME-Version: 1.0 References: <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> <099dee98-8aeb-af36-828c-110f5ac6e9a3@redhat.com> <20221027091123.GA28089@srcf.ucam.org> <933be908-0bc2-56cc-8d6f-38f2d208ef20@redhat.com> <20221027095249.GA28666@srcf.ucam.org> <6df2016d-ed2d-57fa-dcad-48537732895f@redhat.com> <526db9ed-bc39-b6be-c977-d4509ce22152@redhat.com> In-Reply-To: <526db9ed-bc39-b6be-c977-d4509ce22152@redhat.com> From: "Rafael J. Wysocki" Date: Thu, 27 Oct 2022 14:19:32 +0200 Message-ID: To: Hans de Goede Content-Type: text/plain; charset="UTF-8" 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: Karol Herbst , "Rafael J. Wysocki" , nouveau@lists.freedesktop.org, dri-devel@lists.freedesktop.org, platform-driver-x86@vger.kernel.org, Daniel Dadap , Dmitry Osipenko , amd-gfx@lists.freedesktop.org, linux-acpi@vger.kernel.org, Ben Skeggs , David Airlie , Len Brown , 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" On Thu, Oct 27, 2022 at 2:17 PM Hans de Goede wrote: > > Hi, > > On 10/27/22 14:09, Rafael J. Wysocki wrote: > > On Thu, Oct 27, 2022 at 12:37 PM Hans de Goede wrote: > >> > >> Hi, > >> > >> On 10/27/22 11:52, Matthew Garrett wrote: > >>> On Thu, Oct 27, 2022 at 11:39:38AM +0200, Hans de Goede wrote: > >>> > >>>> The *only* behavior which actually is new in 6.1 is the native GPU > >>>> drivers now doing the equivalent of: > >>>> > >>>> if (acpi_video_get_backlight_type() != acpi_backlight_native) > >>>> return; > >>>> > >>>> In their backlight register paths (i), which is causing the native > >>>> backlight to disappear on your custom laptop setup and on Chromebooks > >>>> (with the Chromebooks case being already solved I hope.). > >>> > >>> It's causing the backlight control to vanish on any machine that isn't > >>> ((acpi_video || vendor interface) || !acpi). Most machines that fall > >>> into that are either weird or Chromebooks or old, but there are machines > >>> that fall into that. > >> > >> I acknowledge that their are machines that fall into this category, > >> but I expect / hope there to be so few of them that we can just DMI > >> quirk our way out if this. > >> > >> I believe the old group to be small because: > >> > >> 1. Generally speaking the "native" control method is usually not > >> present on the really old (pre ACPI video spec) mobile GPUs. > >> > >> 2. On most old laptops I would still expect there to be a vendor > >> interface too, and if both get registered standard desktop environments > >> will prefer the vendor one, so then we need a native DMI quirk to > >> disable the vendor interface anyways and we already have a bunch of > >> those, so some laptops in this group are already covered by DMI quirks. > >> > >> And a fix for the Chromebook case is already in Linus' tree, which > >> just leaves the weird case, of which there will hopefully be only > >> a few. > >> > >> I do share your worry that this might break some machines, but > >> the only way to really find out is to get this code out there > >> I'm afraid. > >> > >> I have just written a blog post asking for people to check if > >> their laptop might be affected; and to report various details > >> to me of their laptop is affected: > >> > >> https://hansdegoede.dreamwidth.org/26548.html > >> > >> Lets wait and see how this goes. If I get (too) many reports then > >> I will send a revert of the addition of the: > >> > >> if (acpi_video_get_backlight_type() != acpi_backlight_native) > >> return; > >> > >> check to the i915 / radeon / amd / nouveau drivers. > >> > >> (And if I only get a couple of reports I will probably just submit > >> DMI quirks for the affected models). > > > > Sounds reasonable to me, FWIW. > > > > And IIUC the check above can be overridden by passing > > acpi_backlight=native in the kernel command line, right? > > Right, that can be used as a quick workaround, but we really do > want this to work OOTB everywhere. Sure. My point is that if it doesn't work OOTB for someone, and say it used to, they can use the above workaround and report back. 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 EE54BFA3745 for ; Thu, 27 Oct 2022 12:20:00 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id B012410E270; Thu, 27 Oct 2022 12:19:54 +0000 (UTC) Received: from mail-qt1-f176.google.com (mail-qt1-f176.google.com [209.85.160.176]) by gabe.freedesktop.org (Postfix) with ESMTPS id E1AF510E3F0; Thu, 27 Oct 2022 12:19:44 +0000 (UTC) Received: by mail-qt1-f176.google.com with SMTP id l28so930352qtv.4; Thu, 27 Oct 2022 05:19:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=3e9j5Qwiqs/f1XbIA4ZFfx647JqImc8PuBMqMLRI+CY=; b=nZs3hLafqLMV6OIkI1vFHA4+DfehZtA4SzMfNMQ0HMk0WhGBl5kc+fklGyUYZuf7hs k0BmOg3rfqQmdLktcfLulLjtP7lCqA3pp8Gl7w/YTkhvOiSu0vUcfPYm6t2TV8d0MdGO B/r3qT1YpCm/gOWtqZkA46oDdBVKhI429GnAfjZwmjnlXe25TMNyI9qHJrc3PwJvdKYb AOPN/1tVL0XH3RrIfzPmEmrOm8KwGf2rPs6T0Uc5BdCABZeRv2sQySYbN7LngD2IGZDy Y3BfbvCI0a/i1WoxYsJpIhIMjYPe+TqML9A+9rmiq1vBHRqURly5TY2DTgW//TcaLiOD kSCQ== X-Gm-Message-State: ACrzQf0HFekXoxMC5y22s24SQAuVFrs+9pAX9sfAWclFz8a6Wt7e3N4h ul0VvztpHKTsM8jUdg6QtFn31CMnPUJOy8tg3Fg= X-Google-Smtp-Source: AMsMyM69RoU0FyynhwyvAcltO78mN8wnrxDaU0H42sOUgzVaxEwEWEEjpPn5ALxiGMgXKKWihZ8uqwTw9rMyl80ilzY= X-Received: by 2002:a05:622a:13c6:b0:39c:c34f:29ec with SMTP id p6-20020a05622a13c600b0039cc34f29ecmr40973105qtk.153.1666873183985; Thu, 27 Oct 2022 05:19:43 -0700 (PDT) MIME-Version: 1.0 References: <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> <099dee98-8aeb-af36-828c-110f5ac6e9a3@redhat.com> <20221027091123.GA28089@srcf.ucam.org> <933be908-0bc2-56cc-8d6f-38f2d208ef20@redhat.com> <20221027095249.GA28666@srcf.ucam.org> <6df2016d-ed2d-57fa-dcad-48537732895f@redhat.com> <526db9ed-bc39-b6be-c977-d4509ce22152@redhat.com> In-Reply-To: <526db9ed-bc39-b6be-c977-d4509ce22152@redhat.com> From: "Rafael J. Wysocki" Date: Thu, 27 Oct 2022 14:19:32 +0200 Message-ID: Subject: Re: [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2) To: Hans de Goede Content-Type: text/plain; charset="UTF-8" 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: Karol Herbst , "Rafael J. Wysocki" , nouveau@lists.freedesktop.org, Joonas Lahtinen , dri-devel@lists.freedesktop.org, platform-driver-x86@vger.kernel.org, Daniel Dadap , Dmitry Osipenko , amd-gfx@lists.freedesktop.org, linux-acpi@vger.kernel.org, Ben Skeggs , David Airlie , Len Brown , Matthew Garrett , 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" On Thu, Oct 27, 2022 at 2:17 PM Hans de Goede wrote: > > Hi, > > On 10/27/22 14:09, Rafael J. Wysocki wrote: > > On Thu, Oct 27, 2022 at 12:37 PM Hans de Goede wrote: > >> > >> Hi, > >> > >> On 10/27/22 11:52, Matthew Garrett wrote: > >>> On Thu, Oct 27, 2022 at 11:39:38AM +0200, Hans de Goede wrote: > >>> > >>>> The *only* behavior which actually is new in 6.1 is the native GPU > >>>> drivers now doing the equivalent of: > >>>> > >>>> if (acpi_video_get_backlight_type() != acpi_backlight_native) > >>>> return; > >>>> > >>>> In their backlight register paths (i), which is causing the native > >>>> backlight to disappear on your custom laptop setup and on Chromebooks > >>>> (with the Chromebooks case being already solved I hope.). > >>> > >>> It's causing the backlight control to vanish on any machine that isn't > >>> ((acpi_video || vendor interface) || !acpi). Most machines that fall > >>> into that are either weird or Chromebooks or old, but there are machines > >>> that fall into that. > >> > >> I acknowledge that their are machines that fall into this category, > >> but I expect / hope there to be so few of them that we can just DMI > >> quirk our way out if this. > >> > >> I believe the old group to be small because: > >> > >> 1. Generally speaking the "native" control method is usually not > >> present on the really old (pre ACPI video spec) mobile GPUs. > >> > >> 2. On most old laptops I would still expect there to be a vendor > >> interface too, and if both get registered standard desktop environments > >> will prefer the vendor one, so then we need a native DMI quirk to > >> disable the vendor interface anyways and we already have a bunch of > >> those, so some laptops in this group are already covered by DMI quirks. > >> > >> And a fix for the Chromebook case is already in Linus' tree, which > >> just leaves the weird case, of which there will hopefully be only > >> a few. > >> > >> I do share your worry that this might break some machines, but > >> the only way to really find out is to get this code out there > >> I'm afraid. > >> > >> I have just written a blog post asking for people to check if > >> their laptop might be affected; and to report various details > >> to me of their laptop is affected: > >> > >> https://hansdegoede.dreamwidth.org/26548.html > >> > >> Lets wait and see how this goes. If I get (too) many reports then > >> I will send a revert of the addition of the: > >> > >> if (acpi_video_get_backlight_type() != acpi_backlight_native) > >> return; > >> > >> check to the i915 / radeon / amd / nouveau drivers. > >> > >> (And if I only get a couple of reports I will probably just submit > >> DMI quirks for the affected models). > > > > Sounds reasonable to me, FWIW. > > > > And IIUC the check above can be overridden by passing > > acpi_backlight=native in the kernel command line, right? > > Right, that can be used as a quick workaround, but we really do > want this to work OOTB everywhere. Sure. My point is that if it doesn't work OOTB for someone, and say it used to, they can use the above workaround and report back.