[RFC] drm/i915: HDMI 3D frame packing on LSPCON (DP-to-HDMI) ports

[RFC] drm/i915: HDMI 3D frame packing on LSPCON (DP-to-HDMI) ports

[Adrien ASESIO]

Hi,

I would like to ask whether stereo 3D output on i915 ports that drive
an HDMI sink
through an LSPCON (DP branch device in PCON mode, MegaChips MCDP28x0
or Parade PS175)
is something that could be supported, and what you would want a patch
to look like.

Background: the HDMI 2.0 port of many Intel boards from Skylake to
Coffee Lake (Intel
NUC7/NUC8 among them) is an LSPCON, so i915 registers it as a
DisplayPort connector.
stereo_allowed is only set in intel_hdmi_init_connector(), never for DP, so
drm_helper_probe_single_connector_modes() prunes every 3D mode the
EDID advertises,
and lspcon_set_infoframes() only writes the AVI infoframe (and the
DRM/HDR packet),
so there is no path for the HDMI Vendor-Specific InfoFrame that
carries 3D_Structure.
Intel's support article 000030190 documented S3D as unsupported on
LSPCON designs.

Observation: on a NUC8i7BEH (i7-8559U, Coffee Lake; i915_display_info
reports the
branch device as "Type: HDMI, ID: MC2800, HW 2.2, SW 1.73") with
kernel 6.1.74, whose
code paths are unchanged in this respect on current master, I programmed the
frame-packing raster of CTA VIC 32 as a plain progressive mode from userspace:

    1920x2205 @ 24 Hz, clock 148500, htotal 2750, vtotal 2250, +hsync +vsync

The sink (Panasonic TX-P..VT65 plasma, HDMI 1.4a, behind an Onkyo AVR)
switched into
frame-packed 3D by itself and displayed both eyes correctly; page
flips were delivered
at 41.667 ms (sd 0.01 ms) for minutes. So the LSPCON passes the
doubled raster, and at
least this TV detects frame packing from the timing without the VSIF
(or the LSPCON
generates one; I cannot tell without an HDMI analyser). Kodi now does
exactly this on
that machine (patch under review on the maintainer's 3D branch, [1]),
decoding 3D
Blu-ray MVC with FFmpeg's pending H.264 MVC series [2].

Questions:

1. Would a patch that sets connector->stereo_allowed for DP connectors
with an HDMI
   branch device (intel_dp->has_hdmi_sink / lspcon.active) be
acceptable, knowing that
   the VSIF cannot be sent? The modes would only appear for sinks
whose EDID advertises
   3D, and only to clients that set DRM_CLIENT_CAP_STEREO_3D. The risk
I see is clients
   that set the cap but do not understand
DRM_MODE_FLAG_3D_FRAME_PACKING picking a
   2205-line mode by accident.

2. Is there any documentation of an infoframe interface on the
MegaChips or Parade
   LSPCONs beyond the AVI registers i915 knows
(LSPCON_MCA_AVI_IF_WRITE_OFFSET 0x5C0,
   LSPCON_PARADE_AVI_IF_WRITE_OFFSET 0x516)? MegaChips' product page claims
   "stereoscopic 3D forwarding" for the MCDP2800.

3. If neither is wanted in the kernel, is "userspace programs the
doubled raster as a
   2D mode" an approach you consider legitimate, so that compositors
and players can
   do what I did above?

The amdgpu side is getting HDMI 1.4 3D output through Adrian
Betschart's series on
amd-gfx (2026-09), which restricts stereo_allowed to native HDMI
connectors for the
same reason.

Test tool (libdrm; lists stereo modes with the client cap, sets a
frame-packing or
forced raster, measures flip pacing): https://github.com/SilverGhostBS/fp3d-test

[1] https://github.com/popcornmix/xbmc/pull/35
[2] https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/24303

Thanks,
Adrien Asesio

Re: [RFC] drm/i915: HDMI 3D frame packing on LSPCON (DP-to-HDMI) ports

[Ville Syrjälä]

On Fri, Oct 16, 2026 at 04:05:16PM -0400, Adrien ASESIO wrote:
> Hi,
> 
> I would like to ask whether stereo 3D output on i915 ports that drive
> an HDMI sink
> through an LSPCON (DP branch device in PCON mode, MegaChips MCDP28x0
> or Parade PS175)
> is something that could be supported, and what you would want a patch
> to look like.

TBH I was hoping we could just kill off the entire stereo 3d thing
because it makes dealing with modes annoying. But I guess we can't do
that if people are actually using it :/

> 
> Background: the HDMI 2.0 port of many Intel boards from Skylake to
> Coffee Lake (Intel
> NUC7/NUC8 among them) is an LSPCON, so i915 registers it as a
> DisplayPort connector.
> stereo_allowed is only set in intel_hdmi_init_connector(), never for DP, so
> drm_helper_probe_single_connector_modes() prunes every 3D mode the
> EDID advertises,
> and lspcon_set_infoframes() only writes the AVI infoframe (and the
> DRM/HDR packet),
> so there is no path for the HDMI Vendor-Specific InfoFrame that
> carries 3D_Structure.
> Intel's support article 000030190 documented S3D as unsupported on
> LSPCON designs.
> 
> Observation: on a NUC8i7BEH (i7-8559U, Coffee Lake; i915_display_info
> reports the
> branch device as "Type: HDMI, ID: MC2800, HW 2.2, SW 1.73") with
> kernel 6.1.74, whose
> code paths are unchanged in this respect on current master, I programmed the
> frame-packing raster of CTA VIC 32 as a plain progressive mode from userspace:
> 
>     1920x2205 @ 24 Hz, clock 148500, htotal 2750, vtotal 2250, +hsync +vsync
> 
> The sink (Panasonic TX-P..VT65 plasma, HDMI 1.4a, behind an Onkyo AVR)
> switched into
> frame-packed 3D by itself and displayed both eyes correctly; page
> flips were delivered
> at 41.667 ms (sd 0.01 ms) for minutes. So the LSPCON passes the
> doubled raster, and at
> least this TV detects frame packing from the timing without the VSIF
> (or the LSPCON
> generates one; I cannot tell without an HDMI analyser). Kodi now does
> exactly this on
> that machine (patch under review on the maintainer's 3D branch, [1]),
> decoding 3D
> Blu-ray MVC with FFmpeg's pending H.264 MVC series [2].
> 
> Questions:
> 
> 1. Would a patch that sets connector->stereo_allowed for DP connectors
> with an HDMI
>    branch device (intel_dp->has_hdmi_sink / lspcon.active) be
> acceptable, knowing that
>    the VSIF cannot be sent? The modes would only appear for sinks
> whose EDID advertises
>    3D, and only to clients that set DRM_CLIENT_CAP_STEREO_3D. The risk
> I see is clients
>    that set the cap but do not understand
> DRM_MODE_FLAG_3D_FRAME_PACKING picking a
>    2205-line mode by accident.
> 
> 2. Is there any documentation of an infoframe interface on the
> MegaChips or Parade
>    LSPCONs beyond the AVI registers i915 knows
> (LSPCON_MCA_AVI_IF_WRITE_OFFSET 0x5C0,
>    LSPCON_PARADE_AVI_IF_WRITE_OFFSET 0x516)? MegaChips' product page claims
>    "stereoscopic 3D forwarding" for the MCDP2800.

There are no docs :(


On DP the VSC SDP can signal various stereo 3D modes (including
"Stacked Frame" which I think is what you want) whereas the MSA
can only signal the frame/field sequential modes.

Technically all DPCD 1.2+ sinks should support the VSC SDP, but
I don't think that really guarantees that a PCON would then
convert the VSC SDP to its infoframe counterpart.

I guess one way to verify whether it's really working would be to
just send the VSC SDP with the stereo 3D knobs in various
positions and see if the TV will respond accordingly.

> 
> 3. If neither is wanted in the kernel, is "userspace programs the
> doubled raster as a
>    2D mode" an approach you consider legitimate, so that compositors
> and players can
>    do what I did above?
> 
> The amdgpu side is getting HDMI 1.4 3D output through Adrian
> Betschart's series on
> amd-gfx (2026-09), which restricts stereo_allowed to native HDMI
> connectors for the
> same reason.
> 
> Test tool (libdrm; lists stereo modes with the client cap, sets a
> frame-packing or
> forced raster, measures flip pacing): https://github.com/SilverGhostBS/fp3d-test
> 
> [1] https://github.com/popcornmix/xbmc/pull/35
> [2] https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/24303
> 
> Thanks,
> Adrien Asesio

-- 
Ville Syrjälä
Intel