* Re: [PATCH v3 0/3] drm/amd/display: HDMI 1.4 3D output (frame packing, top-and-bottom, side-by-side)
[not found] <20260921034104.1021664-1-capitain_jack@yahoo.com>
@ 2026-09-21 8:01 ` Adrian Betschart
2026-09-21 15:34 ` Daniel Ramos
0 siblings, 1 reply; 3+ messages in thread
From: Adrian Betschart @ 2026-09-21 8:01 UTC (permalink / raw)
To: Daniel Ramos
Cc: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter, amd-gfx,
dri-devel, linux-kernel
On Mon, 21 Sep 2026 00:41:04 -0300, Daniel Ramos wrote:
> Independent confirmation of this approach on older DCN hardware and a
> consumer-TV sink, plus a boundary record that matches your patch 3's
> diagnosis.
Thank you, Daniel. A second DCN generation and a TV as the sink is
exactly the coverage the series lacked, and the black frame-packing
picture without the doubled timing is a good independent check of
patch 3. (Adding the maintainers back to Cc.)
> Happy to run anything specific on this APU and television combination
> if it helps the review.
One request, if you have the time: your runs used your own port on
7.0, so a run of v3 itself would make your Tested-by cover the patches
as posted. It applies cleanly to 7.3-rc1. Top-and-bottom is the most
useful check, since patch 2 only affects that layout and your report
covers side-by-side and frame packing.
For the record, as with my later amdgpu patches: the series and this
reply were prepared with AI assistance (Claude Code); I reviewed and
tested the series as described in the cover letter. A respin will
carry the Assisted-by tag.
Harry, Leo: any comments on the series?
Thanks,
Adrian
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH v3 0/3] drm/amd/display: HDMI 1.4 3D output (frame packing, top-and-bottom, side-by-side)
2026-09-21 8:01 ` [PATCH v3 0/3] drm/amd/display: HDMI 1.4 3D output (frame packing, top-and-bottom, side-by-side) Adrian Betschart
@ 2026-09-21 15:34 ` Daniel Ramos
0 siblings, 0 replies; 3+ messages in thread
From: Daniel Ramos @ 2026-09-21 15:34 UTC (permalink / raw)
To: Adrian Betschart
Cc: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter, amd-gfx,
dri-devel, linux-kernel, Daniel Ramos
Hi Adrian, Harry, Leo, others,
Following your request, the testing is done, and it is a pass across the board: v3 as posted built into a 7.3-rc4 kernel and run today on the Renoir APU (DCN 2.1, Display Core 3.2.369) driving the Sony KDL-46HX855, all three layouts were tested in sequence (no restart) in one desktop-down window of about five minutes, so this Tested-by now covers the series exactly as it sits on the list.
Top-and-bottom first, as you suggested: the TV switched itself into 3D on 1920x1080@60 TaB and the disparity picture read in depth through its glasses, so the sink is happy with the 3D_Ext_Data byte patch 2 sends for that layout. Side-by-side half at 1920x1080@60 followed with the same self-switch and picture. Frame packing closed the window at 1920x1080@24: the tool presented one 1920x2205 packed buffer, the expanded timing from patch 3 scanned it, and the full two-eye picture showed where my earlier unfinished 7.0 experiment without the expansion had signal and black picture (fixed as well now the same way).
The probe numbers on 7.3-rc4 + v3 are identical to what our 7.0 port produced here: 22 modes and 0 stereo without the client cap, 51 modes and 29 stereo with it, no regressions on the aspect-ratio pass.
The run record is in the repo at the run11-betschart-v3-7.3rc4-all-pass-2026-09-21.log (https://github.com/danielcamposramos/sony-bravia-linux/blob/main/tools/stereo-modeset/run11-betschart-v3-7.3rc4-all-pass-2026-09-21.log), probe output and per-layout modeset lines included.
One more thing I would like to put on the table while the series is in review.
Since our first exchange I have kept the equivalent two changes prepared as a backport for the 7.0-era tree, where the connector code still lives in amdgpu_dm.c: same stereo_allowed plus VSIF wiring, same CRTC_STEREO_DOUBLE expansion for frame packing, forward-verified to apply cleanly against the pristine v7.0 source, sitting as format-patch mboxes in docs/upstream of the same repository.
They are an offer, not a request, and there is no competing series coming: if this v3 lands and a stable backport or an older-generation follow-up ever becomes wanted, they are ready to go as-is, and I am equally happy to reshape them or to let them retire unused once v3 ships downstream on its own.
Happy to run anything further on this APU and television if the review wants it.
Tested-by: Daniel Ramos <capitain_jack@yahoo.com>
Disclosure per Documentation/process/coding-assistants.html (https://docs.kernel.org/process/coding-assistants.html): prepared with AI assistance, directed and hardware-verified by me end to end; the assisting models were LLM Kimi K3 (Codex CLI), LLM GPT 5.6 Sol (Codex CLI) and LLM Claude Opus 5 (Claude Code CLI).
^ permalink raw reply [flat|nested] 3+ messages in thread
* [PATCH v3 0/3] drm/amd/display: HDMI 1.4 3D output (frame packing, top-and-bottom, side-by-side)
@ 2026-09-07 12:50 Adrian Betschart
0 siblings, 0 replies; 3+ messages in thread
From: Adrian Betschart @ 2026-09-07 12:50 UTC (permalink / raw)
To: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher
Cc: Christian König, amd-gfx, dri-devel, linux-kernel
amdgpu has never exposed the HDMI 1.4 3D modes that drm_edid derives
from a sink's HDMI VSDB: stereo_allowed is false on every connector, so
a 3D-capable TV or projector connected to a Radeon card cannot be driven
in frame-packing, top-and-bottom or side-by-side mode, although i915
has supported exactly this for a decade and the media players that
produce 3D frames (Kodi, mpv with 3D filters) only need the mode to
exist.
These three patches add it for native HDMI connectors, in the simplest form
that works on the hardware: the source packs both views into the frame
and the display core scans that frame out as ordinary 2D; the only
3D-specific output is the HDMI vendor infoframe. The reason it has to
be done this way is in patch 1: any of DC's stereo timing formats,
including the SW_PACKED ones, makes the hardware treat the surface as
two views and paint the whole frame into each half. Patch 2 adds the
3D_Ext_Data byte to the top-and-bottom vendor infoframe, without which
at least JVC D-ILA projectors do not engage 3D (Amlogic sources send
it, which is why those work with the same projector). Patch 3 sizes
the stream and the plane viewport by the doubled frame-packing timing
so each eye receives its own view rather than a stretched copy of the
first.
Tested on a Radeon RX 7600 (Navi 33, DCN 3.2.1) driving a JVC
DLA-RS4100 through an HDFury VRROOM, with Kodi (LibreELEC, GBM) as the
source, on a 7.2.3 kernel carrying these patches; the series here is
rebased onto amd-staging-drm-next and compile-tested there, and the
amdgpu_dm connector (308) and plane (95) KUnit suites pass; the freesync suite
crashes the same way on the unpatched base. All three layouts
engage the projector's 3D mode at 1920x1080p24, RGB 12 bpc, with
correct per-eye geometry (row-coded test frames read back through each
eye of shutter glasses) and correct eye assignment; frame packing is
also the format the projector uses for Blu-ray 3D.
Known limitation, not addressed here: a framebuffer with DCC enabled
does not scan out in a frame-packed mode on this GPU (the first flip
after the modeset never completes and the pipe wedges); the source has
to allocate the 3D framebuffer without DCC. A separate report will
follow once it is better understood.
Two unrelated FRL/DSC issues found on the same setup are tracked as
drm/amd issues 5770 and 5771.
v3:
- 1/3: pass CRTC_STEREO_DOUBLE unconditionally where amdgpu_dm recomputes the
CRTC fields, as the DRM core does in mode_fixup(); the flag only doubles a
frame-packing mode, and the previous `flags & DRM_MODE_FLAG_3D_FRAME_PACKING`
test also matched other 3D layouts (multi-bit field). The saved_mode variant
is back to its original form, since a stereo mode is no longer a FreeSync
video mode. Both from the Sashiko review of v2.
v2 (all three findings came from the Sashiko review bot, and all held up):
- 1/3: a stereo mode keeps its own CRTC timing in
decide_crtc_timing_for_drm_display_mode() - with the native timing
copied over it, a frame-packed 1080p24 mode (which shares pixel clock
and totals with 1080p60) lost its doubled timing on a 1080p sink even
with scaling off; and amdgpu_dm_is_freesync_video_mode() rejects a
stereo-flagged mode, which otherwise could be replaced by the 2D
FreeSync base mode and lose its 3D flags. KUnit cases for both.
- 3/3: the plane KUnit mocks now set hdisplay/vdisplay as well as the
crtc_* size, which drm_mode_get_hv_timing() derives the size from;
dm_test_helper_check_state_scaling_caps failed otherwise.
- 2/3: unchanged.
Adrian Betschart (3):
drm/amd/display: support HDMI 1.4 3D modes on HDMI connectors
drm/amd/display: send the 3D_Ext_Data byte for top-and-bottom too
drm/amd/display: size frame-packed streams by the doubled timing
.../display/amdgpu_dm/amdgpu_dm_connector.c | 58 ++++++++++++--
.../amd/display/amdgpu_dm/amdgpu_dm_plane.c | 13 ++-
.../tests/amdgpu_dm_connector_test.c | 80 +++++++++++++++++++
.../amdgpu_dm/tests/amdgpu_dm_plane_test.c | 12 +++
drivers/gpu/drm/amd/display/dc/dc_stream.h | 7 ++
.../display/modules/info_packet/info_packet.c | 4 +
6 files changed, 165 insertions(+), 9 deletions(-)
--
2.43.0
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-09-21 15:34 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20260921034104.1021664-1-capitain_jack@yahoo.com>
2026-09-21 8:01 ` [PATCH v3 0/3] drm/amd/display: HDMI 1.4 3D output (frame packing, top-and-bottom, side-by-side) Adrian Betschart
2026-09-21 15:34 ` Daniel Ramos
2026-09-07 12:50 Adrian Betschart
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®