From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E56C9324B35 for ; Mon, 17 Nov 2025 09:05:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763370320; cv=none; b=Njwi728pPSxPGfyl5YYS5e3i53x5AeNicFX461/EQaJ3t45LIOt/XIihTsxZoq8sXprgF++x2ECUq5ci90nMIjlQacIkS2bix2zmzdQ0zmgV03JTRYvxLomvM/bBxNQQVQr5gPnL2CLb0WsLvbg7BDPykEjxwEjkw5om3dRsgUU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763370320; c=relaxed/simple; bh=peg6NBb3JX9ALfvMindANn44vJpbxeSf6FcxOLoqY3A=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=sgqCw48/8+EZ7/oXxAenWMVq5xWLZ9x9lBNU+5uqxlm9kodsp5XNWoQu94RWez7HsZ5qfv959YHQr7b+uu95WCd1IWTFh2WlSubSZBWG/QDyN0KGZLrBmu4qax31hUmVZLKbLD9TOYHb3tRZA384RLfTvKL+uN/dMP+e5yKeoZw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=nuTnjqF0; arc=none smtp.client-ip=192.198.163.18 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="nuTnjqF0" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1763370319; x=1794906319; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=peg6NBb3JX9ALfvMindANn44vJpbxeSf6FcxOLoqY3A=; b=nuTnjqF0XXJ1u/er47ps3on63H/3YhGdjcetoZkdMzDc/FZbWr4ehlEC t2x1loFcVcGDmjTiJJ57cyWFlvdYD2ugYTiWK05qfUtZ7tJKYwE9z7zpK 9guQzz9PAZzIU+y9DAGvQsjRioPfQsMoPn6ZxU1maGNAjqhq9YI25zZau q+W0VbSXwCAodbdEn1Qp3fEYPW5R8+Chu0iSDflZ0tPalGu0I6IIqacRN rsSpgA5VSy9ZMt8Pwu+DYDIJMb9NBpbtJHCfOQEHSW/YoBDiyY1rKlGSf fGmZnIcbYFyfm8uFV9s8PE4sFvJh1xws8I6NFQ8qM4W7EAQLTiE8BpFgA g==; X-CSE-ConnectionGUID: S0BufdS3TYqYoO1cFgaf4Q== X-CSE-MsgGUID: SDCB/U3jSMmpjqR74URX0Q== X-IronPort-AV: E=McAfee;i="6800,10657,11615"; a="64568021" X-IronPort-AV: E=Sophos;i="6.19,311,1754982000"; d="scan'208";a="64568021" Received: from orviesa009.jf.intel.com ([10.64.159.149]) by fmvoesa112.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Nov 2025 01:05:18 -0800 X-CSE-ConnectionGUID: wNZg7wdiS8+pVA1l+3Y15w== X-CSE-MsgGUID: lUAFnS43S66c12eFpGw2jw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.19,311,1754982000"; d="scan'208";a="190187827" Received: from fdefranc-mobl3.ger.corp.intel.com (HELO localhost) ([10.245.246.42]) by orviesa009-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Nov 2025 01:05:14 -0800 From: Jani Nikula To: Mario Limonciello , Simona Vetter , xaver.hugl@kde.org Cc: Alex Deucher , Christian =?utf-8?Q?K=C3=B6n?= =?utf-8?Q?ig?= , David Airlie , "open list:RADEON and AMDGPU DRM DRIVERS" , "open list:DRM DRIVERS" , open list , Simona Vetter , Harry Wentland , Dmitry Baryshkov , Thomas Zimmermann , Maxime Ripard Subject: Re: [PATCH] drm/amd: Move adaptive backlight modulation property to drm core In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: <20251112222646.495189-1-mario.limonciello@amd.com> <83aa8a816cf301085a3e3638238f8fba11053dc2@intel.com> <449ee5ba065e1ceee8f7a04038442cff24772df9@intel.com> Date: Mon, 17 Nov 2025 11:05:10 +0200 Message-ID: <81da4bd8bcf6110145964f0c314dae1ea3046d10@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On Fri, 14 Nov 2025, Mario Limonciello wrote: > +Xaver > > On 11/14/2025 2:39 AM, Jani Nikula wrote: > > >>> >>> So this is basically Content Adaptive Brightness Control, but with the >>> technology ("backlight" and "modulation") unnecessarily encoded in the >>> ABI. >>> >>> You could have the same knob for adjusting CABC implemented in an OLED >>> panel, controlled via DPCD. >>> >>>> + * >>>> + * sysfs >>>> + * The ABM property is exposed to userspace via sysfs interface >>>> + * located at 'amdgpu/panel_power_savings' under the DRM device. >>> >>> Err what? Seriously suggesting that to the common ABI? We shouldn't have >>> sysfs involved at all, let alone vendor specific sysfs. >>> >>>> + * off >>>> + * Adaptive backlight modulation is disabled. >>>> + * min >>>> + * Adaptive backlight modulation is enabled at minimum intensity. >>>> + * bias min >>>> + * Adaptive backlight modulation is enabled at a more intense >>>> + * level than 'min'. >>>> + * bias max >>>> + * Adaptive backlight modulation is enabled at a more intense >>>> + * level than 'bias min'. >>>> + * max >>>> + * Adaptive backlight modulation is enabled at maximum intensity. >>> >>> So values 0-4 but with names. I don't know what "bias" means here, and I >>> probably shouldn't even have to know. It's an implementation detail >>> leaking to the ABI. >>> >>> In the past I've encountered CABC with different modes based on the use >>> case, e.g. "video" or "game", but I don't know how those would map to >>> the intensities. >>> >>> I'm concerned the ABI serves AMD hardware, no one else, and everyone >>> else coming after this is forced to shoehorn their implementation into >>> this. >> >> Apparently Harry had the same concerns [1]. >> > So let me explain how we got here. At the display next hackfest last > year (2024) we talked about how to get compositors to indicate they want > technologies like this to get out the way. A patch series was made that > would allow compositor to say "Require color accuracy" or "Require low > latency" are required. > > https://lore.kernel.org/amd-gfx/20240703051722.328-1-mario.limonciello@amd.com/ > > This got reverted because userspace didn't have an implementation ready > to go at the time. One was created and so I rebased/resent the series > earlier this year. > > https://lore.kernel.org/amd-gfx/20250621152657.1048807-1-superm1@kernel.org/ > > Xaver had some change of heart and wanted to talk about it at the next > hackfest. > > https://lore.kernel.org/amd-gfx/CAFZQkGxUwodf5bW0qQkXoPoz0CFFA1asJfUxFftMGgs5-VK2Hw@mail.gmail.com/ > > So we talked about it again at the hackfest this year and the decision > was not everyone can an octagon into a peg hole, so we're better off > re-introducing vendor properties for this. So series was respun per > that discussion. > > https://lore.kernel.org/amd-gfx/20250718192045.2091650-1-superm1@kernel.org/ > > Userspace implementation was done and so we merged this for 6.19. > > https://lore.kernel.org/amd-gfx/CAFZQkGwLWcyS0SqCHoiGsJd5J_u4aBJ0HMV5Bx3NknLdLkr8Uw@mail.gmail.com/ > > Then Simona suggested we need to make some changes where the propertye > should be in generic documentation etc: > > https://lore.kernel.org/amd-gfx/aQUz-mbM_WlXn_uZ@phenom.ffwll.local/ > > So that's where we are now with this patch. I can clean it up per the > feedback so far - but I think we need to be in agreement that this > property is actually the way forward or we should revert the property in > amdgpu instead of this moving approach and keep discussing. IMO we should either - admit we can't do a generic property for this *and* keep the vendor specific property details hidden in drivers, or - figure out a generic property and add that in drm core But I'm pretty much against adding an AMD vendor specific property in drm core. BR, Jani. -- Jani Nikula, Intel