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 30BEA44CF40 for ; Wed, 1 Apr 2026 13:58:21 +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=1775051904; cv=none; b=ZajBWieITWImID4LSO8+aX1h+GZJ3F8iFd/8IHcHfaqGfrs7KXQUNdw8NjBerFaOpobKDl4PlXHglfZWFBzHmSkoHJqEYolo6NoEJWEhs99IMYxn6Med64oVfz8/cgJVU+xbvw3nr/YlhqL+YA+3i/F+kqz4CmnGY42UNXMKUok= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775051904; c=relaxed/simple; bh=s3yvmYWTk3Znd4vEvVUg8aHhDmWCu9lQIx5d8GRKL4Y=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Ovm/QcVXO05kkdC0+Kk6WG+Hhz1pOzhJ0h0du7fEYb8jdIKAln2Y8RR2R+a6m7ZexAjJCqoIdh73rqF+ow8T2FzlPyfIBAYvz14GoFD7vJ6YlpO8Zq9qrPvljcbGdO/GQVBk6IpwDlgPKb4jOqO9Op6+qB6ryCezsch6FGRtfVE= 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=Akr+iGoh; 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="Akr+iGoh" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1775051902; x=1806587902; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=s3yvmYWTk3Znd4vEvVUg8aHhDmWCu9lQIx5d8GRKL4Y=; b=Akr+iGohnkIl/3JWDYODpxAQKX8sTPHW9WTVGYH6oSs5TkSxNAZuy2Q6 xE/tTR4smWPk95xKVQY1QX2WzpYqNlDO+RKArBBY0WV11Xl0DrESHyTDY Q4Bq7JdSQ7XYA3UbH2iYtOmoqxEe4jIpQTVuzr87RwACmUU7FIXAxex4L 4/ehD9YICItTwZKTUCmoNvhi9LlRXq82sE5oY7EMx5bDG2ovfA5Te/X6d GXkdchKXOLQy3QMBZD4NHga0u4hEUouO3cKhozO+bAtEPyagd3KfwyT4B LC+oS1Fx8wCixxkHdDj3CnL1v/ZpADqKHC240ybJJIp40zrK4Ep82w+81 Q==; X-CSE-ConnectionGUID: +fLt4XHgRbW0xKOeWqo/0g== X-CSE-MsgGUID: P52AdIiWQhWyOGd33tlzEw== X-IronPort-AV: E=McAfee;i="6800,10657,11745"; a="75262796" X-IronPort-AV: E=Sophos;i="6.23,153,1770624000"; d="scan'208";a="75262796" Received: from fmviesa002.fm.intel.com ([10.60.135.142]) by fmvoesa112.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Apr 2026 06:57:28 -0700 X-CSE-ConnectionGUID: S80wAtacRF2cUgUJFBkWeA== X-CSE-MsgGUID: c7nLL/8MRneEYJkCbhYPVw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,153,1770624000"; d="scan'208";a="249714045" Received: from pgcooper-mobl3.ger.corp.intel.com (HELO localhost) ([10.245.244.199]) by fmviesa002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Apr 2026 06:57:22 -0700 Date: Wed, 1 Apr 2026 16:57:19 +0300 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Daniel Stone Cc: Harry Wentland , Pekka Paalanen , Michel =?iso-8859-1?Q?D=E4nzer?= , Nicolas Frattaroli , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Leo Li , Rodrigo Siqueira , Alex Deucher , Christian =?iso-8859-1?Q?K=F6nig?= , Daniel Stone , Dmitry Baryshkov , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, amd-gfx@lists.freedesktop.org, kernel@collabora.com, Derek Foreman , Marius Vlad Subject: Re: [PATCH v5 0/3] Add "link bpc" DRM property Message-ID: References: <20260319-link-bpc-v5-0-5306cd04a708@collabora.com> <4265353.aeNJFYEL58@workhorse> <254c20a4-cce3-4c8e-9902-514586f3e694@mailbox.org> <5416161.aeNJFYEL58@workhorse> <792c4540-d690-4453-a32e-62e23e78d628@mailbox.org> <9d525fe4-b091-4cd9-b977-de19ffe4b957@amd.com> <20260331155028.71246d7a@fluorite> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Patchwork-Hint: comment Organization: Intel Finland Oy - BIC 0357606-4 - c/o Alberga Business Park, 6 krs Bertel Jungin Aukio 5, 02600 Espoo, Finland On Wed, Apr 01, 2026 at 09:40:15AM +0100, Daniel Stone wrote: > Hi Harry, > > On Tue, 31 Mar 2026 at 18:47, Harry Wentland wrote: > > On 2026-03-31 08:50, Pekka Paalanen wrote: > > > People who care about the picture quality down to these levels will > > > likely want to know and learn about these techniques. They may also > > > want to explicitly control them. > > > > > > In time, when these have been used enough in the wild, compositor > > > developers will learn what makes a difference and what does not, so > > > they will adjust their reporting to end users. The most important thing > > > for the kernel is it offer an unambiguous and stable UAPI for these. > > > > > > Policy belongs in userspace. > > > > I don't like this as a blanket statement. There is a lot of policy that > > intersects with HW nuances, whether it comes to power or otherwise. > > Taking away driver vendor's abilities to optimize will hurt the Linux > > ecosystem in the long run. > > > > IMO this needs to be evaluated on a case by case basis. There are > > many places where it does make sense to give userspace a greater > > say on policy, but we don't want to push driver (HW specific) logic > > up into userspace. > > It's not something that's _just_ specific to a particular > display-controller manufacturer or a particular IP generation though. > It very much depends on the usecase. > > If you have a laptop and you're trying to give a presentation, > applying dithering and/or DSC makes a lot of sense: you don't want > your battery to die, and the projector's probably going to obliterate > half the colour anyway, so might as well as go for the most efficient > thing. BTW DSC is not free. The compressor does actual work, which takes energy. DSC may be a win power wise if you can then reduce the link frequency (+ some internal voltages/etc.). But if you can't reduce anything then all you really end up doing is burning more power compressing things needlessly. But it's all very hardware specific of course. So having explicit userspace control for this stuff doesn't seem like the best idea, apart from maybe a "no DSC at all" knob for the people who can't tolerate any kind of compression artifacts. I've been musing about userspace being able to provide some kind of relative quality weights for each output. The driver could then use those to figure out how to balance the final bpc and compression between the outputs. Something like this would let userspace express its preference while still allowing the driver to decide how to actually get there. Simple 'desired bpc' seem somewhat insufficient because I would imagine userspace just sets that to max for everything at the start, so the driver might not be able to tell which outputs can be degraded harder than others. I suppose a desired+min bpc might work, but would potentially force userspace to tweak the parameters in some semi random fashion and try again if the end result isn't appealing. And exactly what to tweak is really hard for userspace to figure out since it has no idea of the possibly complex internal/tbt/mst topologies, power costs, etc. > If your laptop is plugged into your big display at home to write code, > applying DSC to cram the highest possible resolution + refresh in > would make sense. But if dithering only results in a marginal power > saving, and your laptop is charging anyway - why bother degrading > visual acuity? > > If you're a media player, then you're in a good position to know what > would be good to go over the wire, because you know (& are possibly in > control of) the format over what comes in in the first place. > > But everyone's tradeoffs are different, which is why sometimes the > best choice is to ultimately leave it up to the user. If you dig into > any media playback device (STBs running Android TV, Apple TV, Fire TV, > et al), you'll see that all of them ultimately allow overrides for bpc > / colour model / subsampling / etc. Those aren't just there for fun, > but because they are usable to real people, and it's not possible for > Amlogic or MediaTek or Rockchip or whoever to statically decide that a > certain configuration is going to be best everywhere. > > Right now we have drivers making magic per-vendor/SKU decisions, > without even so much as a feedback mechanism to userspace (unless you > count debugfs, maybe) so it can even figure out what's going on, let > alone control it. To properly support some of those usecases, > userspace needs to be able to control what goes out on the wire, but > as a first step, it just wants to be informed of what the driver even > did with the properties we gave it. > > The end game of this isn't Weston logging something to stdout, it's to > surface things to userspace so it can guide the kernel into making a > good decision for usecases that may not be ones the silicon vendor > decided was 'probably the best thing' however many years ago. > > Cheers, > Daniel -- Ville Syrjälä Intel