From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mout-p-103.mailbox.org (mout-p-103.mailbox.org [80.241.56.161]) (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 CB7AF398906 for ; Mon, 23 Mar 2026 11:44:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=80.241.56.161 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774266274; cv=none; b=ickJ4P7da6DS2d0FF72tPpneu1BvxB3DdxDvFeDFWW2SK8uWBoG+F9UwBnBuAtHfwaOo6GPX2vGUJN++3sqQ+o5icLjRhVIhqy7iVV0cK7MV8WrgxD/8T6IuzCWh4ECGvjVV2xozXL6m1v1gOVCdVmJ1Z3QeeTYnfFY1Ty9XRf4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774266274; c=relaxed/simple; bh=HVf6D7gyVc3Uq0FJ9DJrNqEF1yIo+e3c6nQli8m+iDY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=g7ndKrJH4TLEyRTzP4zmmtg8AaKgJhV7eQXMz+Gvw4JzYXytrnF0afuQwALxo7uc4fVxseUneWC2HDObArqlMdE/AzVb/DwCpW0ANnqrJ09DHkPrGmokNCY2hanniUxL8nuME2TLcUy5HLmtjPsOpkxmmGUsSS1ZeV15RkrKoeY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=mailbox.org; spf=pass smtp.mailfrom=mailbox.org; dkim=pass (2048-bit key) header.d=mailbox.org header.i=@mailbox.org header.b=uGEXp/xn; arc=none smtp.client-ip=80.241.56.161 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=mailbox.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=mailbox.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=mailbox.org header.i=@mailbox.org header.b="uGEXp/xn" Received: from smtp1.mailbox.org (smtp1.mailbox.org [IPv6:2001:67c:2050:b231:465::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-103.mailbox.org (Postfix) with ESMTPS id 4ffWY70c1Gz9tsq; Mon, 23 Mar 2026 12:44:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailbox.org; s=mail20150812; t=1774266267; 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=2TUve5txxvSf6BWYHb2Px5K2r5y5MDg/b/HumxZnWkE=; b=uGEXp/xn5tV+VwS6LhUJ7M9iCLjV5UDwaXzOfQDQ6Ff8L7eUDctUa2gtoLDrNS8TLbO8zF FUL9i3vCrJSd1WHx4ko9JDnwbzTHmL7r1FVo7Lh9H0ZFjPdFHva2F8/mch4PFkaST/0Te8 xFaV6IW5VPcUBerYbM2Ji4VVzPSx7i4ABqx9mJmctvDddeARAHZHet8OijueQbmBX8UHxk 12j2fy71s3y386LlT9/VV62dRkGeNW4cm28TOcsyUNbsjXPdcN2ck0usD7WWtEptXtiA1E PI/qM1NxU2fO9LMJHSiQrmewtWvaZNi2xiIp1uQiYbhW9H1hUH7fn2gn+bdt1w== Message-ID: <1378c83e-6271-4d47-9b45-9bbed131f37e@mailbox.org> Date: Mon, 23 Mar 2026 12:44:19 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH v5 0/3] Add "link bpc" DRM property To: Mario Kleiner , Nicolas Frattaroli Cc: Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Harry Wentland , Leo Li , Rodrigo Siqueira , Alex Deucher , =?UTF-8?Q?Christian_K=C3=B6nig?= , =?UTF-8?B?VmlsbGUgU3lyasOkbMOk?= , 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 References: <20260319-link-bpc-v5-0-5306cd04a708@collabora.com> <8ba60a99-f69e-482e-bd68-f6bc36291c54@mailbox.org> <5797606.kQq0lBPeGt@workhorse> From: =?UTF-8?Q?Michel_D=C3=A4nzer?= Content-Language: en-CA In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-MBO-RS-META: ndkjuit9tox47ypefe8tyapcb5uwi87x X-MBO-RS-ID: c4a909e62259ec18369 On 3/21/26 03:33, Mario Kleiner wrote: > As somebody who writes software for neuroscience research, I would find this new property very useful. > > Even if the 'link bpc' is not the perfectly accurate answer in presence of dithering or display stream compression, I think it could provide an idea about the minimum precision available, so a DRM client can at least make sure its minimum requirements are met. E.g., a 'link bpc' of 10 would at least guarantee 10 bpc, and effectively a bit more if spatial dithering is applied in addition. There's a problem in the opposite direction: With dithering, the "link bpc" property implies that the display link can transmit less information than it actually can. > That said, I don't have practical experience with the effects of DSC, I don't have any > suitable hardware. Afaik it is not truly lossless, but only (supposed to be, usually) > perceptually lossless. It would be great to have some property that informs clients if DSC > is active or not, or allow some control over that. FWIW, I mentioned DSC not because it's potentially lossy, but because it allows transmitting a larger "real" (albeit potentially lossy) bpc over a smaller physical bpc. If the "link bpc" property reported the latter, it would again imply the link can transfer less information than it actually can. > Also as somebody who has spent many hours of his life hunting down some sysfs or debugfs files for reporting such numbers, the files usually being differently named, at different paths, with different formats, or not existing at all, depending on kernel version and gpu configuration. I'd like to do less of that in the future. No doubt that generic KMS properties would be better than that, I'm just skeptical that this specific property (alone) as currently defined is really useful. > In the scenarios used by my app, the app often knows what an optimal setting for 'max bpc' or reported value from such a 'link bpc' would be, How can it know that vs dithering? > But I could imagine regular desktop use cases, where a Wayland compositor can somewhat know what good minimum values for 'link bpc' would be, and maybe adapt, or give the user a hint about potentially degraded quality, and what to do about it ("Check your cables", "Reduce video resolution or refresh rate", "Run with less displays",...). I see potential for false positives resulting in spurious issue reports. > - A HDR-10 display mode on a true HDR sink implies one really wants a 'link bpc' of at least 10 bpc, especially given the large nonlinearity of EOTF's like Perceptual Quantizer, or things will look poor. Even with dithering? (Same question about the other scenarios you mentioned) -- Earthling Michel Dänzer \ GNOME / Xwayland / Mesa developer https://redhat.com \ Libre software enthusiast