EDID: v_sync offset/width are 6-bit values

[ewenmcneill]

Fix assumption that both h_sync and v_sync offset/width are 10-bit values, which resulted in the v_sync offset being sent as if it were 0; h_sync offset/width are 10-bit values, but v_sync offset/width
are 6-bit values.

t->v_sync_offset_width_l part of the change tested with read-edid in #478; t->hv_sync_offset_width_h part of the change only compiled. (HackFest building logistics mean I can't test it with read-edid now, but by inspection the 4-bit/2-bit split seems more correct than the 8-bit shifts that were there before.)

v_sync_offset of 720p set back to recommended 5 lines value (from #478) now that it's actually being sent properly rather than as zero.

For a summary of the packing of the timing section of EDID bit see:

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

Note that this did not make the Decimator accept the HDMI2USB output yet; so it's clearly not the only thing the Decimator didn't like :-(

[mithro]

Just FYI - this change will have no effect on the signals that board generates. This will only effect the information seen by the laptops connected to the board.

[ewenmcneill]

Just FYI - this change will have no effect on the signals that board generates. This will only effect the information seen by the laptops connected to the board.

Thanks for the confirmation. That was my guess too, but we weren't sure if the HDMI out on the Opsis was regenerated sync, or if it was passing through bit-for-bit the received signal when, eg, input0 was connected to output0, and thus potentially the (speaker) laptop signal was being sent with marginally correct v_sync that was passed through and thus confusing the Decimator. It sounds like maybe the Opsis generates its own h_sync/v_sync for the output (rescanning from a frame buffer?).

Ewen

[mithro]

There is no connection between the input and outputs. Inputs write to memory, outputs read from memory. To get an input on an output you use the correct memory address. Also why the output continues when there is no input.

[mithro]

FYI - This is the reason the Opsis can accept either 720p60 and 720p50 when the output is set to 720p60 or 720p50.

[ewenmcneill]

There is no connection between the input and outputs. Inputs write to memory, outputs read from memory.

Thanks, that's useful to know -- ie, that there's a frame buffer and sync-(re)generation on output in between. (CC @futaris FYI)

Ewen

[mithro]

FYI - The output is always going when configured.

[mithro]

The output mode is configured here ->

HDMI2USB-litex-firmware/firmware/processor.c

Line 526 in 5f50647

static void fb_set_mode(const struct video_timing *mode)

[mithro]

It /could/ be worth connecting an oscilloscope to the sync pin and looking at the stability. It should be rock solid.

[ewenmcneill]

The output mode is configured here ->

HDMI2USB-litex-firmware/firmware/processor.c

Line 526 in 5f50647

static void fb_set_mode(const struct video_timing *mode)

Based on that, it looks like the modeline timing change in processor.c would then apply to the configured output (see https://github.com/timvideos/HDMI2USB-litex-firmware/pull/482/files#diff-66a6e00147360f6e8cdf86606bc53602), which IIRC affects the 720p@60Hz output (the 720p@50Hz output appeared to have exactly the recommended values you'd mentioned in #478, so I didn't change that). It looks to me like the same tables in processor.c are used both to feed the EDID generation and to feed the configuration of the output scan out / sync generation.

(Definitely agree that scoping the output to look at the sync would be useful; unfortunately no one at the "Hackfest" had a scope with them, so arranging to do that would take some more organisation....)

Ewen

GitHub

EDID: v_sync offset/width are 6-bit values by ewenmcneill · Pull Request #482 · timvideos/HDMI2USB-litex-firmware

Fix assumption that both h_sync and v_sync offset/width are 10-bit values, which resulted in the v_sync offset being sent as if it were 0; h_sync offset/width are 10-bit values, but v_sync offset/w...

[ewenmcneill]

FTR, Opsis flashed with firmware built with this patch returns EDID:

ewen@parthenon:/sys/class/drm/card0-DP-1$ cat edid | parse-edid
Checksum Correct

Section "Monitor"
	Identifier "HDMI2USB-2"
	ModelName "HDMI2USB-2"
	VendorName "OHW"
	# Monitor Manufactured week 0 of 2015
	# EDID version 1.3
	# Digital Display
	DisplaySize 200 110
	Gamma 1.80
	Option "DPMS" "false"
	Horizsync 31-68
	VertRefresh 50-60
	# Maximum pixel clock is 80MHz
	Modeline 	"Mode 0" 74.25 1280 1720 1760 1980 720 725 730 750 +hsync +vsync 
	Modeline 	"Mode 1" 74.25 1280 1500 1540 1650 720 725 730 750 +hsync +vsync 
EndSection
ewen@parthenon:/sys/class/drm/card0-DP-1$ 

which seems correct to me: 720/725/730/750 vertical sync values seem like what we were aiming for in #478 (comment).

So I think this patch helps the EDID sent to the presenter laptop.

Ewen

PS: I've also verified I'm getting output to a 720p display from the Opsis with this build, so I don't think it's broken the output side changing the output sync timing either.

[ewenmcneill]

FTR, Carl reports that the JPEG encoder happens to work in my build with this fix (see #465 for background), and obviously this newer build has a bunch of the features he's been trying to add this year, so he's suggested running the Opsis (which are only doing camera capture this year, because reasons) on this bleeding edge build including this fix (from my laptop, given Travis is failing for what looks like unrelated issues).

Being tested today at the TechSpace staging area, and if it works it'll probably be in production on Monday. (It'd be good to get Travis's git checkout issues so that there's a pre-built version as a result, which we can actually use in future.)

Anyway this is further evidence that the JPEG encoder issue is, eg, gateware synthesis layout randomisation related, as I didn't change anything related to that.

Ewen

[ewenmcneill]

FWIW, the builds seem to be failing for an unrelated reason (git submodule version issue), eg,

https://travis-ci.com/timvideos/HDMI2USB-litex-firmware/jobs/274128704#L1034-L1051

which seems to be minvera-verilog:

fetching submodule litex/soc/cores/cpu/minerva/verilog
warning: redirecting to https://github.com/enjoy-digital/minerva-verilog/
warning: redirecting to https://github.com/enjoy-digital/minerva-verilog/
fatal: remote error: upload-pack: not our ref 0518621134dd7a551cac5758d9171a24d0c1578fs/master
The command "$PWD/.travis/setup.sh" failed and exited with 1 during .

And IIRC i had similar problems at one point when trying to update/fetch either litex-buildenv or HDMI2USB for my laptop. So possibly that submodule needs fixing up first, before Travis can build anything?

(All the ones I looked at in Travis failed for that same reason.)

Ewen

Travis CI - Test and Deploy with Confidence

Travis CI enables your team to test and ship your apps with confidence. Easily sync your projects with Travis CI and you'll be testing your code in minutes.

[ewenmcneill]

FWIW, the builds seem to be failing for an unrelated reason (git submodule version issue), eg,

https://travis-ci.com/timvideos/HDMI2USB-litex-firmware/jobs/274128704#L1034-L1051

which seems to be minvera-verilog:

Ah, there's a trailing s on the end of the git commit hash for the minerva-verilog submodule, which is causing it to fail to check out. I'm not sure where that's coming from:

(LX P=arty T=base F=micropython) ewen@parthenon:/src/fpga/litex-buildenv/third_party/litex$ git submodule | grep minerva
 0518621134dd7a551cac5758d9171a24d0c1578f litex/soc/cores/cpu/minerva/verilog (0518621)
(LX P=arty T=base F=micropython) ewen@parthenon:/src/fpga/litex-buildenv/third_party/litex$ git submodule | grep minerva | grep 0518621134dd7a551cac5758d9171a24d0c1578fs
(LX P=arty T=base F=micropython) ewen@parthenon:/src/fpga/litex-buildenv/third_party/litex$ git submodule | grep minerva | grep 0518621134dd7a551cac5758d9171a24d0c1578f
 0518621134dd7a551cac5758d9171a24d0c1578f litex/soc/cores/cpu/minerva/verilog (0518621)
(LX P=arty T=base F=micropython) ewen@parthenon:/src/fpga/litex-buildenv/third_party/litex$ 

Ewen

Travis CI - Test and Deploy with Confidence

Travis CI enables your team to test and ship your apps with confidence. Easily sync your projects with Travis CI and you'll be testing your code in minutes.

[ewenmcneill]

Ah, there's a trailing s on the end of the git commit hash for the minerva-verilog submodule, which is causing it to fail to check out. I'm not sure where that's coming from:

Digging further the root cause seems to be that Travis noticed I have a fork of litex, so it's trying to use that:

https://travis-ci.com/timvideos/HDMI2USB-litex-firmware/jobs/274128652#L583-L620

but unfortunately that's an ancient fork of litex, which doesn't have the right commits in it (and it's not what I'm using).

I'm going to try updating my fork of litex to the upstream master and see if that makes things happier :-)

Ewen

Travis CI - Test and Deploy with Confidence

Travis CI enables your team to test and ship your apps with confidence. Easily sync your projects with Travis CI and you'll be testing your code in minutes.

[ewenmcneill]

@mithro Could you force Travis to retry that build? I don't want to change that commit, as the commit hash is in the LCA2020 AV Team notes. And creating a trivial second commit to force a rebuilt seems likely just to create extra noise....

Apparently there's an option if you're signed in to Travis:

https://stackoverflow.com/questions/17606874/trigger-a-travis-ci-rebuild-without-pushing-a-commit

Ewen

Stack Overflow

Trigger a Travis-CI rebuild without pushing a commit?

Using Travis-CI, is it possible to trigger a rebuild without pushing a new commit to GitHub?

Use case: A build fails due to an externality. The source is actually correct. It would build OK and pa...

[mithro]

Forced travis to rerun.