From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mout-p-102.mailbox.org (mout-p-102.mailbox.org [80.241.56.152]) (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 6C7FE39479C for ; Wed, 10 Jun 2026 07:46:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=80.241.56.152 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781077579; cv=none; b=VhfxUD+uP5FK0ZpSoyqERn/J2ZZexKjxAa4uTbI1K69MuWakbvJD8ZE+Sz5fE7YUBJYX4vgXW0vKsbLhW2mZAp2vC+uBR0BB4eap7kJ6WRc7yvzowCQ85SI2BQsnN3BPdAORRH6jbSly3fjDLH3MjPPwOgRAr7ZzlANUEtwuom4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781077579; c=relaxed/simple; bh=IPm+iGnPLfB+xnNpv4k1q96nbAoCc1sF2htBHzB8M8c=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=HGT1dmrdMGWNDMnvINvHlYPo0VluMM0A5XARueg1ZeZHud6RIc+TkRCoRgK1ijZaG59Drq+xjGuNMF9NqcySwjZnSvsHGaEYL95lGy9ZLBiR9BeWi/Hi1OahT3ZV/QS0AiTZqp29v3W8lZgDWfamgwuCZOgW7u8t95ByG/+jgRU= 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=yX65371M; arc=none smtp.client-ip=80.241.56.152 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="yX65371M" Received: from smtp202.mailbox.org (smtp202.mailbox.org [IPv6:2001:67c:2050:b231:465::202]) (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-102.mailbox.org (Postfix) with ESMTPS id 4gZyWb2s7jz9vDG; Wed, 10 Jun 2026 09:46:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailbox.org; s=mail20150812; t=1781077563; 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=wVSGFjS6rCtlRmsAFb7HqeiaT5Fx+/RP29GF/T5/5sY=; b=yX65371Mu5JXV+S5LBBQpDuemnSTuuAfYaKvNh8vg+mOrwgvJZHckCkz2SI/0Rr5Z+zlvx XWsLNw/Z6xpPqo27OCtuNQDAIdi0w4iLQs0FxSutS3PI/VHcBJDI2ghC9lzDUDumDm4BD/ qnZInxl5Q7fbDCGKPfsCbVorT8y77kwkHxcmVsJOC8b78oxNfQv1yhP7T6eP8rL0aTgR5v bn5N5kjk3UKqzTWvWmx0C03YvPWxDlPEIP6/fxUvu8cZBli6UQHEh/CKTkDjGKo3UHKe7W /8oOOpytjNazUn1TnI+MiRnMzmREtuK26PDY19d/mLxzHtlYyVrRdbLUv/73mw== Authentication-Results: outgoing_mbo_mout; dkim=none; spf=pass (outgoing_mbo_mout: domain of michel.daenzer@mailbox.org designates 2001:67c:2050:b231:465::202 as permitted sender) smtp.mailfrom=michel.daenzer@mailbox.org Message-ID: <14be0bdb-982d-4cad-8624-944c69937de4@mailbox.org> Date: Wed, 10 Jun 2026 09:45:54 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH 0/2] Make HDMI state helpers handle odd max bpc requests To: Maxime Ripard , Nicolas Frattaroli Cc: Maarten Lankhorst , Thomas Zimmermann , David Airlie , Simona Vetter , Dmitry Baryshkov , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, kernel@collabora.com References: <20260608-hdmi-max-bpc-fix-v1-0-6e8dcebc7274@collabora.com> <20260609-orthodox-cocky-bull-5ddef8@houat> From: =?UTF-8?Q?Michel_D=C3=A4nzer?= Content-Language: en-CA In-Reply-To: <20260609-orthodox-cocky-bull-5ddef8@houat> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-MBO-RS-ID: fa422c70b70e16a4572 X-MBO-RS-META: nnk6ehztgo6ksnne7e4fp9wmostf937q X-Rspamd-Queue-Id: 4gZyWb2s7jz9vDG On 6/9/26 14:51, Maxime Ripard wrote: > On Mon, Jun 08, 2026 at 01:19:06PM +0200, Nicolas Frattaroli wrote: >> With the "max bpc" KMS connector property, userspace can arbitrarily >> restrict the upper end of the bits-per-component range. This is fine and >> good, except the HDMI state helpers never considered that max_bpc could >> be influenced by a userspace setting, so assumed it'll always be an even >> value from the HDMI standards. >> >> This, unfortunately, is not the world we live in anymore. Patch 1 >> corrects sink_supports_format_bpc to return false on BPCs outside of >> what HDMI allows. Patch 2 then corrects handling of odd-numbered max >> bpcs by rounding the loop start value down to an even number instead. It >> also adds a KUnit test to make sure nobody breaks this again in the >> future. >> >> Signed-off-by: Nicolas Frattaroli > > Do you have a bit more details on the world you live in? :) > > In particular, why would erroring out on setting an odd value in > atomic_set_property not work? That doesn't make sense, since the "max bpc" property purely defines an upper limit. Setting an odd value for it doesn't mean the kernel has to use an odd effective bpc value, it can use any valid bpc <= the "max bpc" property value. -- Earthling Michel Dänzer \ GNOME / Xwayland / Mesa developer https://redhat.com \ Libre software enthusiast