Current Server Time: 22:53 (Central Europe)

#apertus IRC Channel Logs

2023/02/26

Timezone: UTC


00:34
anuejn
the edid of the hdmi input is https://paste.niemo.de/amadoligin.sh
00:39
anuejn
Bertl: what is the pixelclock of the default camera bitstream?
01:49
Bertl
anuejn: ah, I remember tuning the firmware for LAM/INT ... we might be quite off from the typical HDMI clock
01:50
Bertl
I'll build a new gateware with more default settings ...
10:24
se6astian
anuejn: also try switching between 1080p25/30/50/60 modes as I already witnessed several times that one was able to display on a device but the otherr wasnt
10:24
se6astian
if those still exist in the new userspace firmware
15:20
Bertl
anuejn: please use http://vserver.13thfloor.at/Stuff/AXIOM/BETA/LAM/cmv_hdmi4.{bin,bit} which has a fixed 148.5MHz
15:23
Bertl
and of course, yes, going for 1080pXX would be a good idea for a start and testing with a monitor would be nice as well ;)
20:15
anuejn
okay I got a bit further with the 2048x1536p and 1536x1536ps video timings
20:15
anuejn
though now it complains that it is not seeing AVI Info Frames
20:15
anuejn
which is probably... right?
20:16
anuejn
Bertl: do we have a mechanism of generating these currently?
20:17
anuejn
maybe we could patch the driver to ignore that but idk if that or generating them is easier
20:17
anuejn
(https://github.com/radxa/kernel/blob/linux-5.10-gen-rkr3.4/drivers/media/platform/rockchip/hdmirx/rk_hdmirx.c#L1535 is the relevant driver piece)
20:24
anuejn
(log for reference: https://paste.niemo.de/ebuliqepin.log)
22:03
se6astian
left the channel
22:04
se6astian
joined the channel
22:10
Bertl
anuejn: yeah, in theory we can generate arbitrary data frames
22:11
Bertl
including AVI Info Frames but nobody bothered to do/test this yet
22:12
Bertl
back then it was hard to test/get it right, but nowadays, with the magewell capture devices, it should be way easier to get the info frames right
23:01
anuejn
can you elaborate a bit on how to do that?
23:01
anuejn
do I just have to craft them as binary and put them somewhere?
23:06
anuejn
Bertl: and do we already have a tool somewhere for generating these or do I have to write one?
23:15
Bertl
there is a BRAM which can be used to generate data for data islands
23:17
Bertl
reg_mem_inst which basically is used by the rgb_hdmi instance to fill in data for the data islands
23:18
Bertl
the data islands need to be configured in the scan setup and the proper data needs to be loaded into the bram
23:18
Bertl
and no, there is no tool or script yet to do that
23:21
anuejn
but I don't have to change the gateware?
23:22
Bertl
the islands were never really tested, but if all is working as expected, then no, no need to change the gateware :)
23:22
anuejn
ah okay, that does sound experimental :)
23:24
anuejn
Bertl: hm... the only occurence of reg_mem i can find is https://github.com/apertus-open-source-cinema/axiom-firmware/blob/main/peripherals/soc_main/top.vhd#L2571
23:25
anuejn
can you point me to the gateware where everything is wired?
23:29
Bertl
http://vserver.13thfloor.at/Stuff/AXIOM/BETA/cmv_hdmi4/
23:29
Bertl
top.vhd, search for reg_mem_inst and follow the data
23:30
Bertl
dil_data is the signal for the rgb_hdmi instance
23:34
Bertl
the data islands are terc4 encoded and the hdmi scan isntance generates the terc event range which basically triggers the data output and address increment
23:35
Bertl
so the best option at the moment is to reserve a small area outside the display area of just the right size to generate the island(s) and fill them with meaningfull data from the bram
23:35
Bertl
e.g. in the vertical blanking back porch or so
23:37
Bertl
and they best start horizontally at the same position as the display area, so you can use the same guard markers for the island
23:45
anuejn
I see