HDMI2USB/Opsis not working with Decimator MD-CROSS v2

[xfxf]

HDMI2USB/Opsis devices do not appear to work at all with Decimator MD-CROSS v2 devices, which are commonly used as HDMI to HD-SDI converters in convention centres.

These devices typically exist at the podium, and is the 'bridge' between the HDMI cable at the lecturn, and a HD-SDI cable which goes back to the rooms video infrastructure (typically a long cable to the back of the room into a rack, which contains video switching equipment, and eventually the projectors).

They're often used in convention centres too for confidence monitors - it's how they will 'split' a signal from a laptop into two outputs (one HDMI to a confidence monitor, one HD-SDI back to their long cable to the video infrastructure rack).

This is both with input AND output with the HDMI2USB/Opsis.

The HDMI2USB output into the Decimator directly shows no video signal. I have taken a EDID dump of the Decimator which I will attach.

The Decimator outputting to the HDMI2USB - with its output set to 720p/50 or 720p/60 with the HDMI2USB would just show up garbage on the screen with WER errors on the first channel.

Tried multiple HDMI2USB's, tried multiple Redmere cables, no joy,.

DECIMATOR-edid.txt

[xfxf]

Picture of unit, and picture of a laptop input into Decimator MD-CROSS v2, with output into HDMI2USB, all set to the same resolution (720p50).

[mithro]

Please get the following;

• Add a display to the MD-CROSS v1 HDMI output and see what the display shows.
• Test both outputs.
• Include which HDMI2USB firmware build you are using.
• Dump the edid with xrandr --props
• Include the output of the HDMI2USB console
• Connect a laptop to the MD-CROSS and force the output to 720p60
• Connect a laptop to the MD-CROSS and force the output to 720p50

[mithro]

The 720p timing is said to be;

Detailed Timing Blocks - 0 is native
	Detailed Timing Block #1 - Timing definition:
	Mode = 1280 × 720 @ 60.000Hz
		Pixel Clock............. 74.25 MHz		Non-Interlaced

		                        Horizontal		Vertical
		Active.................. 1280 pixels		 720 lines
		Front Porch.............  110 pixels		   5 lines
		Sync Width..............   40 pixels		   5 lines
		Back Porch..............  220 pixels		  20 lines
		Blanking................  370 pixels		  30 lines
		Total................... 1650 pixels		 750 lines
		Scan Rate...............  45.000 kHz		 60.000 Hz

		Image Size..............  800 mm		 450 mm
		Border..................    0 pixels		   0 lines

			Sync: Digital separate with
				* Positive vertical polarity
				* Positive horizontal polarity

	Detailed Timing Block #2 - Timing definition:
	Mode = 1280 × 720 @ 50.000Hz
		Pixel Clock............. 74.25 MHz		Non-Interlaced

		                        Horizontal		Vertical
		Active.................. 1280 pixels		 720 lines
		Front Porch.............  440 pixels		   5 lines
		Sync Width..............   40 pixels		   5 lines
		Back Porch..............  220 pixels		  20 lines
		Blanking................  700 pixels		  30 lines
		Total................... 1980 pixels		 750 lines
		Scan Rate...............  37.500 kHz		 50.000 Hz

		Image Size..............  800 mm		 450 mm
		Border..................    0 pixels		   0 lines

			Sync: Digital separate with
				* Positive vertical polarity
				* Positive horizontal polarity

Try modifying the timing values in https://github.com/timvideos/litex-buildenv/blob/793f8c3f2807f68ec6ffe8003d56e3cb0abd69be/firmware/processor.c#L259-L274 to match those values exactly.

Information on converting between formats is found in the comment here -> https://github.com/timvideos/litex-buildenv/blob/793f8c3f2807f68ec6ffe8003d56e3cb0abd69be/firmware/processor.c#L37-L80

GitHub

timvideos/litex-buildenv

An environment for building LiteX based FPGA designs. Makes it easy to get everything you need! - timvideos/litex-buildenv

GitHub

timvideos/litex-buildenv

An environment for building LiteX based FPGA designs. Makes it easy to get everything you need! - timvideos/litex-buildenv

[mithro]

Most likely cause is that the DECIMATOR doesn't support RGB pixels (despite the HDMI specification requiring them to).

[ewenmcneill]

FTR, Decimator manual -- http://decimator.com/specs/MD-HX_HARDWARE_MANUAL_FV1.3.pdf -- reports (on page 5) that it supports DVI RGB 4:4:4, and HDMI RGB 4:4:4, as well as two HDMI YCbCr modes (4:4:4, 4:2:2), supposedly with two different audio formats. It only seems to be documented for output, but it's a reasonable guess that it also supports the same formats for input...

Ewen

[ewenmcneill]

Working theory is that the calculation of byte 10 of the EDID detailed data has the wrong formula, which is resulting in the vertical sync offset value being 0 all the time in the EDID.

https://en.wikipedia.org/wiki/Extended_Display_Identification_Data#Detailed_Timing_Descriptor

describes byte 10 as two nibbles, with the offset in the high 4 bits (and the width in the lower 4 bits). But firmware/edid.c was setting that byte to just the offset value (putting the offset value into the width bits, and 0 into the offset value...).

We've built an updated image, just fighting to get it flashed onto the device so we can test it. (JTAG flashing of the Opsis continues to be wildly unreliable, but works just often enough to believe it's sometimes possible....)

Ewen

Extended Display Identification Data - Wikipedia

[ewenmcneill]

Looks like this patch makes the EDID data sensible (as seen by read-edid:

(LX P=opsis T=hdmi2usb) ewen@parthenon:/src/fpga/hdmi2usb-firmware$ git log -1
commit 5f5064789c1a579eb8c2dee2657c73c9c41a3638 (HEAD -> master, origin/master, origin/HEAD)
Merge: fc388ff 5c9c67e
Author: Tim Ansell <me@mith.ro>
Date:   Thu Oct 24 22:28:26 2019 -0700

    Merge pull request #481 from CarlFK/fix479
    
    move #endif - fixes #479
(LX P=opsis T=hdmi2usb) ewen@parthenon:/src/fpga/hdmi2usb-firmware$ git diff
diff --git a/firmware/edid.c b/firmware/edid.c
index 6db7a59..e93d0ce 100644
--- a/firmware/edid.c
+++ b/firmware/edid.c
@@ -159,7 +159,7 @@ static void generate_edid_timing(uint8_t *data_block, const struct video_timing
 
        t->h_sync_offset_l = timing->h_sync_offset & 0xff;
        t->h_sync_width_l = timing->h_sync_width & 0xff;
-       t->v_sync_offset_width_l = timing->v_sync_offset & 0xff;
+       t->v_sync_offset_width_l = ((timing->v_sync_offset & 0x0f) << 4) | (timing->v_sync_width & 0x0f);
        t->hv_sync_offset_width_h = ((timing->h_sync_offset >> 8) << 6) | ((timing->h_sync_width >> 8) << 4)
         | ((timing->v_sync_offset >> 8) << 2) | (timing->v_sync_width >> 8);
 
diff --git a/firmware/processor.c b/firmware/processor.c
index 782f9d7..65073f9 100644
--- a/firmware/processor.c
+++ b/firmware/processor.c
@@ -267,7 +267,7 @@ static const struct video_timing video_modes[PROCESSOR_MODE_COUNT] = {
 
                .v_active = 720,
                .v_blanking = 30,
-               .v_sync_offset = 20,
+               .v_sync_offset = 5,
                .v_sync_width = 5,
 
                .flags = EDID_DIGITAL | EDID_HSYNC_POS | EDID_VSYNC_POS
(LX P=opsis T=hdmi2usb) ewen@parthenon:/src/fpga/hdmi2usb-firmware$ 

(I'll turn that into a pull request tomorrow; comment just to keep notes.)

Ewen

[futaris]

hdmi2usb.txt
hdmi2usb-20200109_2011.txt

hdmi2usb.zip
hdmi2usb-20200109_2011.zip

@ewenmcneill has a patch to fix the EDID.

[ewenmcneill]

@futaris and i have done some tests with the Decimator MD-HX:

• From an NeTV2, the Decimator is happy with the HDMI video (default NeTV2 firmware, which is genlocked pass through video sync; original video was HDMI from @futaris's laptop)

• From a desktop PC with DVI, and a DVI to HDMI cable, the Decimator was happy with the video

• But from a Desktop PC we didn't get video that the Decimator would accept via DVI and a passive adapter.

@futaris has a theory that the issue might be that the Decimator doesn't actually accept DVI RGB 4:4:4 as input over the HDMI input port (even though its documentation does report that it can output DVI RGB 4:4:4).

Ewen

[mithro]

@ewenmcneill - I also had the same theory back @ #478 (comment)

Adding output of HDMI video signals to the Opsis board isn't super hard work, but it is something which would take more than a day (mainly due to testing).

[mithro]

timvideos/HDMI2USB-numato-opsis-sample-code#20

[mithro]

https://web.archive.org/web/20190520020602/http://hamsterworks.co.nz/mediawiki/index.php/Minimal_HDMI

Minimal HDMI - Hamsterworks Wiki!