xfxf
commented
5 years ago 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).
Open xfxf opened 5 years ago
xfxf
commented
5 years ago 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
commented
5 years ago Please get the following;
xrandr --props mithro
commented
5 years ago 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 polarityTry 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
An environment for building LiteX based FPGA designs. Makes it easy to get everything you need! - timvideos/litex-buildenv
An environment for building LiteX based FPGA designs. Makes it easy to get everything you need! - timvideos/litex-buildenv
mithro
commented
5 years ago Most likely cause is that the DECIMATOR doesn't support RGB pixels (despite the HDMI specification requiring them to).
ewenmcneill
commented
4 years ago 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
commented
4 years ago 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
ewenmcneill
commented
4 years ago 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
commented
4 years ago hdmi2usb.txt hdmi2usb-20200109_2011.txt
hdmi2usb.zip hdmi2usb-20200109_2011.zip
@ewenmcneill has a patch to fix the EDID.
ewenmcneill
commented
4 years ago @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
commented
4 years ago @ewenmcneill - I also had the same theory back @ https://github.com/timvideos/HDMI2USB-litex-firmware/issues/478#issuecomment-513837314
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
commented
4 years ago
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