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.