From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.0la.ch (mail.0la.ch [78.47.82.197]) (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 0CC5B296BC0 for ; Fri, 17 Oct 2025 16:28:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=78.47.82.197 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1760718514; cv=none; b=adETnVOin713bTkbf3oKXa9yk18Rb/AEVxdZWXmGpKOvV+QjxBPCEB6HuAl6KBe1kI72CVfGyqYBWy/iW5sgfWXPsojSygNdJkthMqya/1/jxARrRAxJRJ+M/6v1xQocix+aRolK6zZt8MVpFe46yWXtwsouYOGmTd+LxWH5lCg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1760718514; c=relaxed/simple; bh=0O28JTWdc9NgXEwyajabq//FDFzSVup4D1anMceWfJw=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=VuqBkOTasYz6zym6ZD3498O4vcyYyDjfgD/LZsyYxtC9ZEzPFFVYlq3RkPG0mjaFFv59Jf07Tzj/E6ypdjlHeWvju8quUoaTEjuQglTzpEVU5j1WChF+SDbSblzeKYMTSn9ys90kDLvHCqJS5g+URoaZ/OveMTiNMQjzmJosPRo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=lach.pw; spf=pass smtp.mailfrom=lach.pw; dkim=pass (2048-bit key) header.d=lach.pw header.i=@lach.pw header.b=Gfk5dmlR; dkim=permerror (0-bit key) header.d=lach.pw header.i=@lach.pw header.b=5M09VXGp; arc=none smtp.client-ip=78.47.82.197 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=lach.pw Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=lach.pw Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=lach.pw header.i=@lach.pw header.b="Gfk5dmlR"; dkim=permerror (0-bit key) header.d=lach.pw header.i=@lach.pw header.b="5M09VXGp" DKIM-Signature: v=1; a=rsa-sha256; s=202502r; d=lach.pw; c=relaxed/relaxed; h=Message-ID:Date:Subject:To:From; t=1760718477; bh=TISoBNwEXTy+2dwSC0N2Ya5 Q1DPGHIdmijcD806QkPc=; b=Gfk5dmlR2UvzChTy9lgkesT5yQfzvJf/nYFNUMdE3M5DVMr1cT 0y0JAdLq4H46eQN0UfO8SYBsrY3XvUDef+hAHWpoAv13jPMQmkdgxrn/nzUYH870+GRNMzcnmXD H42s2SfexpchXRA8Fpnx7OpLJWrwFd84GHDxx8RxWAOi6qOuqo1XZoJe6fqgU+pefkFwOM/T6oT 6oFWFzN+GrOJXEyQRcEAmeswDqMjpHIjyAb4wkKpDCTgkBHLpjuXO1sg6ukJ87hoy2wnIfwdqhM Ucd4kBq+jsZtwmu0kX7cwaKHF6iliPX06hPP2qyF4asPaOhEQza+H9L1h8v/IOX14PQ==; DKIM-Signature: v=1; a=ed25519-sha256; s=202502e; d=lach.pw; c=relaxed/relaxed; h=Message-ID:Date:Subject:To:From; t=1760718477; bh=TISoBNwEXTy+2dwSC0N2Ya5 Q1DPGHIdmijcD806QkPc=; b=5M09VXGp4u3s0GzWxgdA1v4amtDjSXrUBgBNoieyfkVTD6WP4U 8XYLPECocfu/xHk9NuauGXloB6iOiGCMZRDw==; From: Yaroslav Bolyukin To: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter Cc: Harry Wentland , Leo Li , Rodrigo Siqueira , Alex Deucher , =?UTF-8?q?Christian=20K=C3=B6nig?= , Wayne Lin , amd-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Lach Subject: [PATCH v5 0/7] DisplayID DSC passthrough timing support Date: Fri, 17 Oct 2025 18:27:29 +0200 Message-ID: <20251017162736.45368-1-iam@lach.pw> X-Mailer: git-send-email 2.51.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Lach VESA DisplayID spec allows the device to force its DSC bits per pixel value. For example, the HTC Vive Pro 2 VR headset uses this value in high-resolution modes (3680x1836@90-120, 4896x2448@90-120), and when the kernel doesn't respect this parameter, garbage is displayed on the HMD instead. Me and other users have successfully tested the old (v3) version of this patch (which was applying DSC BPP value unconditionally, thus incorrect: https://lkml.org/lkml/2023/2/26/116) on Vive Pro 2 and Bigscreen Beyond VR headsets, and have been using it daily, it is known to work and doesn't seem to break anything else since 2022. Previously, I didn't have enough dedication to get it merged, I hope this time I will manage to get it to v6.19 :D Regarding driver support - I have looked at amdgpu and Nvidia's open-gpu-kernel-modules, and both seem to have some indication for this value; however, in Linux, it is unused in both. First patch implements parsing of DSC BPP values and display mode VII timings flag which mandates that the DSC BPP value should actually be used for this display mode. The second patch implements handling of this value for AMDGPU driver. The only thing that I don't like in the current implementation, is how the value of `dsc_passthrough_timings_support` flag is propagated from the connector display modes to the mode created in `DRM_IOCTL_MODE_SETCRTC` handler (which is used for VR display initialization in Monado and StreamVR), it feels like this flag should be initialized by the kernel itself, but as far as I can see there is no correct way to do this, as the timing constraints calculation belongs to the individual drivers. Another problem with how this flag is set, is that there is no hard connection between modes creaded in `SETCRTC` and the modes actually defined by connector, so I implement an assumption that this flag should be the same between choosen mode and the preferred display mode. Given that previously due to the missing support for this flag displays were only showing garbage, I believe this assumption won't break anything. Both of those downsides are due to the fact my understanding of DRM subsystem is not that high. If another implementation would be proposed by AMDGPU maintainers - I will gladly implement it here. v4->v5: * The patch was split into multiple * Disabled MSO parsing for eDP displays * Disabled MSO logs if not used * Passing of type VII timings block data * Minor codestyle changes: lines moved around, naming v3->v4: * This patch now parses timings support flag on type VII block, instead of applying it unconditionally. Previously I didn't understand the spec properly. * Now it also is not being applied for non-supported and/or non-VII blocks in amdgpu driver. Regards, Lach Yaroslav Bolyukin (7): drm/edid: rename VESA block parsing functions to more generic name drm/edid: prepare for VESA vendor-specific data block extension drm/edid: MSO should only be used for non-eDP displays drm/edid: parse DSC DPP passthru support flag for mode VII timings drm/edid: for consistency, use mask everywhere for block rev parsing drm/edid: parse DRM VESA dsc bpp target drm/amd: use fixed dsc bits-per-pixel from edid .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 12 +++ drivers/gpu/drm/drm_displayid_internal.h | 11 ++ drivers/gpu/drm/drm_edid.c | 101 +++++++++++------- include/drm/drm_connector.h | 6 ++ include/drm/drm_modes.h | 10 ++ 5 files changed, 103 insertions(+), 37 deletions(-) -- 2.51.0