23:34 | anuejn | the edid of the hdmi input is https://paste.niemo.de/amadoligin.sh
| |
23:39 | anuejn | Bertl: what is the pixelclock of the default camera bitstream?
| |
00:49 | Bertl | anuejn: ah, I remember tuning the firmware for LAM/INT ... we might be quite off from the typical HDMI clock
| |
00:50 | Bertl | I'll build a new gateware with more default settings ...
| |
09: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
| |
09:24 | se6astian | if those still exist in the new userspace firmware
| |
14:20 | Bertl | anuejn: please use http://vserver.13thfloor.at/Stuff/AXIOM/BETA/LAM/cmv_hdmi4.{bin,bit} which has a fixed 148.5MHz
| |
14: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 ;)
| |
19:15 | anuejn | okay I got a bit further with the 2048x1536p and 1536x1536ps video timings
| |
19:15 | anuejn | though now it complains that it is not seeing AVI Info Frames
| |
19:15 | anuejn | which is probably... right?
| |
19:16 | anuejn | Bertl: do we have a mechanism of generating these currently?
| |
19:17 | anuejn | maybe we could patch the driver to ignore that but idk if that or generating them is easier
| |
19: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)
| |
19:24 | anuejn | (log for reference: https://paste.niemo.de/ebuliqepin.log)
| |
21:03 | se6astian | left the channel | |
21:04 | se6astian | joined the channel | |
21:10 | Bertl | anuejn: yeah, in theory we can generate arbitrary data frames
| |
21:11 | Bertl | including AVI Info Frames but nobody bothered to do/test this yet
| |
21: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
| |
22:01 | anuejn | can you elaborate a bit on how to do that?
| |
22:01 | anuejn | do I just have to craft them as binary and put them somewhere?
| |
22:06 | anuejn | Bertl: and do we already have a tool somewhere for generating these or do I have to write one?
| |
22:15 | Bertl | there is a BRAM which can be used to generate data for data islands
| |
22:17 | Bertl | reg_mem_inst which basically is used by the rgb_hdmi instance to fill in data for the data islands
| |
22:18 | Bertl | the data islands need to be configured in the scan setup and the proper data needs to be loaded into the bram
| |
22:18 | Bertl | and no, there is no tool or script yet to do that
| |
22:21 | anuejn | but I don't have to change the gateware?
| |
22:22 | Bertl | the islands were never really tested, but if all is working as expected, then no, no need to change the gateware :)
| |
22:22 | anuejn | ah okay, that does sound experimental :)
| |
22: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
| |
22:25 | anuejn | can you point me to the gateware where everything is wired?
| |
22:29 | Bertl | http://vserver.13thfloor.at/Stuff/AXIOM/BETA/cmv_hdmi4/
| |
22:29 | Bertl | top.vhd, search for reg_mem_inst and follow the data
| |
22:30 | Bertl | dil_data is the signal for the rgb_hdmi instance
| |
22: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
| |
22: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
| |
22:35 | Bertl | e.g. in the vertical blanking back porch or so
| |
22: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
| |
22:45 | anuejn | I see
|