| *** tpb has joined #timvideos | 00:00 | |
| *** CarlFK has joined #timvideos | 01:13 | |
| *** ChanServ sets mode: +v CarlFK | 01:13 | |
| *** nueces has joined #timvideos | 01:46 | |
| *** sb0 has joined #timvideos | 02:51 | |
| xfxf | thaytan: at LCA you established the dv/hdv gstreamer sources had old timing code or something, which was why they were getting out of sync. is this resolved, or still there? | 03:56 |
|---|---|---|
| xfxf | (i'm assuming nobody cares about dv/hdv anymore :) | 03:59 |
| *** rohitksingh_work has joined #timvideos | 04:00 | |
| thaytan | xfxf, nothing has changed, but I'm not sure about the diagnosis | 04:04 |
| thaytan | I think if you set the network clock on the capture pipeline, things should stay in sync | 04:05 |
| thaytan | raw1394src will use that clock to apply timestamps onto the received packets | 04:05 |
| xfxf | okay, cool - i might give that another go if you think it should work | 04:06 |
| xfxf | my interpretation of the comments were that dv/hdv were probably best not to use but if you believe they'll remain in sync with a network clock, i'll try again | 04:06 |
| thaytan | xfxf, bilboed did a lot of work with HDV a while back, so we could ask him about it | 04:08 |
| *** rohitksingh_wor1 has joined #timvideos | 04:30 | |
| *** rohitksingh_work has quit IRC | 04:31 | |
| *** nueces has quit IRC | 04:35 | |
| xfxf | thaytan: okay, how do i do that, ping him on IRC? | 05:13 |
| *** rohitksingh_wor1 has quit IRC | 05:16 | |
| *** ssk1328 has joined #timvideos | 05:59 | |
| ssk1328 | mithro: Did you see the link to block diagram, I had sent here yesterday? | 06:14 |
| mithro | ssk1328: Yes I did, but it wasn't clear to me how to read it | 06:14 |
| ssk1328 | mithro: That is how the blocks are connected in HDMIOut __init__.py file | 06:15 |
| mithro | ssk1328: Sure, but that doesn't really tell you all that much? | 06:15 |
| ssk1328 | mithro: I need to understand how DMA is connected, if I am trying to figure out how to add another DMA port | 06:16 |
| mithro | ssk1328: Yes, you do | 06:16 |
| mithro | ssk1328: So - what you want to figure out is the signals between each of the blocks and what they are doing | 06:17 |
| ssk1328 | mithro: Yes | 06:17 |
| mithro | ssk1328: I don't find that diagram all that helpful in that bit | 06:18 |
| ssk1328 | mithro: Okay, I did add something for FrameInitiator, but now thats what I need to know | 06:19 |
| mithro | ssk1328: If the system worked the way I would expect - there is something which generates an memory address on every pixel clock which somehow gets to the dram system | 06:19 |
| ssk1328 | mithro: I guess the FrameInititor block does that, send the address signal to dma_lasmi.Reader() | 06:21 |
| mithro | ssk1328: Possibly | 06:22 |
| mithro | ssk1328: I think the VTG handles generating the "pixel position" - IE the current x/y position of the pixel | 06:22 |
| mithro | ssk1328: However, I don't think it works in terms of x/y position | 06:22 |
| ssk1328 | mithro: So if I am to read data from two, DMA ports, layouts at each interface have to be changed | 06:24 |
| mithro | ssk1328: So, you are going to have to generate two memory addresses which correspond to the same pixel in two different buffers | 06:26 |
| ssk1328 | mithro: Yes, via the FrameInititator block I guess | 06:27 |
| ssk1328 | mithro: The intseq block takes lasmi.aw as input | 06:28 |
| mithro | aw is? | 06:28 |
| ssk1328 | adress width | 06:28 |
| *** rohitksingh_work has joined #timvideos | 06:30 | |
| mithro | ssk1328: Is that how big a region of memory it needs to address? | 06:31 |
| ssk1328 | mithro: Yeah, basically if we are the memory address will have this many bits | 06:33 |
| ssk1328 | mithro: Basically any memory adress will have this many bits | 06:33 |
| mithro | ssk1328: the #m-labs guys can probably explain lasmi a bit better - sb0 is the primary creator of that if I understand correctly. | 06:33 |
| ssk1328 | mithro: Okay | 06:34 |
| ssk1328 | mithro: I guess I need to completely understand the FrameInitiator and VTG blocks too | 06:35 |
| mithro | ssk1328: yeah definately | 06:35 |
| mithro | ssk1328: I seem to remeber some lasmi documentation floating around? | 06:36 |
| mithro | Ahh ha! | 06:37 |
| mithro | https://migen.readthedocs.io/en/latest/casestudies.html | 06:37 |
| tpb | Title: Case studies Migen X documentation (at migen.readthedocs.io) | 06:37 |
| mithro | The purpose of the VGA framebuffer core is to scan a buffer in system memory and generate an appropriately timed video signal in order to display the picture from said buffer on a regular VGA monitor. | 06:37 |
| ssk1328 | mithro: The rest of the stuff (VTG and FrameInititator) was developed by? _florent_ I suppose? | 06:37 |
| mithro | actually, I think it was probably sb0 too | 06:37 |
| ssk1328 | mithro: I guess the block diagram I made is very similar | 06:38 |
| ssk1328 | mithro: But this is gold! | 06:38 |
| mithro | ssk1328: Did you Google any of these terms at all? | 06:38 |
| mithro | ssk1328: I found that by Googling "lasmi memory" | 06:38 |
| ssk1328 | VTG i knew was video timing generator, but I was seeing some Xilinx IPs | 06:39 |
| ssk1328 | When I googled | 06:39 |
| mithro | ssk1328: for misoc/litex stuff it is good idea to add things like "m-labs" "enjoy-digital" "Sebastien" and "Florent" to the search can help | 06:40 |
| ssk1328 | mithro: Next time definitely! | 06:40 |
| mithro | ssk1328: Sorry I didn't recall that this existed before | 07:05 |
| mithro | hey rohitksingh_work | 07:07 |
| rohitksingh_work | mithro: hi! | 07:07 |
| mithro | rohitksingh_work: I send the display port aux interceptor off to be made | 07:07 |
| mithro | rohitksingh_work: I'll send you one when I get them back - but it won't be for at least 3ish weeks before that happens | 07:08 |
| rohitksingh_work | mithro: wow! it will be fantastic to have it...I can peek at the AUX channel finally | 07:09 |
| rohitksingh_work | from hackvana again I guess? | 07:09 |
| mithro | rohitksingh_work: yes | 07:13 |
| rohitksingh_work | mithro / _florent_ / cr1901_modern : can anyone give me brief intro to new simulation flow in migen. Last I heard, it had changed from icarus to verilator. Docs seem to be in-progress https://github.com/m-labs/migen/blob/master/doc/simulation.rst | 07:14 |
| tpb | Title: migen/simulation.rst at master · m-labs/migen · GitHub (at github.com) | 07:14 |
| mithro | rohitksingh_work: misoc only does in python testing I think? | 07:17 |
| mithro | rohitksingh_work: One of the reasons litex exists is to keep the non-Python simulation stuff I think.... | 07:18 |
| mithro | rohitksingh_work: The verilator is more for doing whole system simulation - IE running the whole soc | 07:21 |
| sb0 | I wrote the framebuffer cores, yes | 07:21 |
| sb0 | but maybe Florent modified those you are using, I don't know | 07:22 |
| mithro | sb0: I think he mainly modified the pixel output bit to enable non-RGB pixels | 07:26 |
| *** rohitksingh_work has quit IRC | 07:53 | |
| *** rohitksingh_work has joined #timvideos | 08:09 | |
| rohitksingh_work | mithro: I've never tried simulating misoc/whole-soc...only individual modules with migen & icarus | 08:12 |
| mithro | rohitksingh_work: It's more useful for doing things like software development I think | 08:13 |
| rohitksingh_work | mithro: oh okay. I think _florent_ might provide some info on that | 08:16 |
| mithro | _florent_ is on holidays for the next 2 weeks I blieve | 08:17 |
| rohitksingh_work | ohh | 08:17 |
| mithro | bblr | 08:30 |
| ssk1328 | mithro: What should be the correct way to proceed here, I am thinking of something like this https://docs.google.com/document/d/1g1c2IwCVxVzSHWdXbZ746HP-fnM4y1WqFuBZNkLi5mw/edit#, add support for handling two pixel streams in VTG and Driver modules. This needs some changes to be done in VTG and Driver modules for handling double the data. | 08:35 |
| tpb | Title: Mixer Block Design - Google Docs (at docs.google.com) | 08:35 |
| ssk1328 | mithro: Or the other option being except for FrameInitiator module (which sits at the top), define two of everything else and connect accordingly, which might be easy but not sure this is how it is meant to be done | 08:37 |
| mithro | ssk1328: I think the VTG should be agnostic towards the pixel data it is transmitting | 09:38 |
| mithro | ssk1328: well, there should only be one VTG | 09:38 |
| mithro | ssk1328: It's important that both data coming in is synchronised | 09:39 |
| ssk1328 | mithro: agnostic as in VTG doesn't know what the data is, it just transmits | 09:40 |
| mithro | ssk1328: yeah? | 09:40 |
| ssk1328 | mithro: Okay, I guess some layout changes in VTG and Driver will be needed | 09:41 |
| mithro | ssk1328: see the diagram I updated | 10:01 |
| mithro | ssk1328: So it might be good to look at the VTG in misoc to see a simpler version, looking at the code I think florent changed it to deal with the fact that we can have multiple pixels in each memory word? | 10:09 |
| ssk1328 | mithro: Okay | 10:10 |
| ssk1328 | mithro: There are two Driver in this HDMIOut, that means instead of defining two instances of HDMIOut, we will have just this one instance | 10:11 |
| mithro | ssk1328: | 10:12 |
| mithro | ssk1328: ? | 10:12 |
| ssk1328 | mithro: So why do we have two driver module then, the mixer is already mixing them right? | 10:13 |
| mithro | I guess the driver doesn't really make sense - they should be "HDMI Output" modules really.... | 10:14 |
| ssk1328 | mithro: So basically earlier we used to define two instance of HDMIOut (defined in gateware/hdmi_out/__init__.py) in opsis_video.py, as both the HDMI out were independent, but now this one module will control both the hdmi_out ports | 10:19 |
| mithro | ssk1328: No you have the mixer have two outputs, which at a higher level you connect to the HDMI Outs | 10:51 |
| *** sb0 has quit IRC | 11:12 | |
| *** springermac has quit IRC | 11:14 | |
| *** springermac has joined #timvideos | 11:16 | |
| *** danielki has joined #timvideos | 11:33 | |
| *** sb0 has joined #timvideos | 11:41 | |
| *** sb0 has quit IRC | 11:51 | |
| *** sb0 has joined #timvideos | 12:33 | |
| *** nueces has joined #timvideos | 12:34 | |
| *** rohitksingh_work has quit IRC | 13:13 | |
| *** rohitksingh has joined #timvideos | 13:45 | |
| *** rohitksingh has quit IRC | 14:00 | |
| *** rohitksingh has joined #timvideos | 14:00 | |
| *** ssk1328 has quit IRC | 15:05 | |
| *** danielki has quit IRC | 15:32 | |
| *** rohitksingh has quit IRC | 16:30 | |
| *** rohitksingh has joined #timvideos | 16:35 | |
| *** Bertl_zZ is now known as Bertl | 16:48 | |
| *** rohitksingh has quit IRC | 17:00 | |
| *** rohitksingh has joined #timvideos | 17:00 | |
| *** rohitksingh has quit IRC | 17:11 | |
| *** rohitksingh has joined #timvideos | 17:12 | |
| *** sb0 has quit IRC | 17:17 | |
| *** j-so has joined #timvideos | 17:24 | |
| j-so | hi folks - qq about HDMI2USB - has anyone used it for doing overlays? | 17:25 |
| j-so | specifically, HDMI2 video + alpha channel overlayed on top of HDMI2 video? | 17:26 |
| CarlFK | j-so: curious what you mean. | 17:31 |
| j-so | basically, I have two incoming HDMI video streams | 17:38 |
| j-so | HDMI1 is just regular video - say from a set-top box | 17:38 |
| j-so | HDMI2 is an overlay - a dashboard I'd like superimposed on HDMI1 | 17:38 |
| j-so | and the combined signal to come out through a HDMI out | 17:39 |
| CarlFK | ah... kinda. I am guessing the MilkyMyst thing would do that. | 17:40 |
| *** danielki has joined #timvideos | 17:44 | |
| j-so | hmm. that kinda feels like overkill. has anyone managed to run Milkymist SoC on the Opsis? | 17:47 |
| CarlFK | i don't think so. I think it was deamed "this should work" | 17:50 |
| *** j-so has quit IRC | 17:52 | |
| *** j-so has joined #timvideos | 18:02 | |
| j-so | okay thanks, would love to hear if folks have made it work | 18:03 |
| *** danielki has quit IRC | 18:05 | |
| *** j-so has quit IRC | 18:09 | |
| *** ssk1328 has joined #timvideos | 18:47 | |
| *** CarlFK has quit IRC | 19:43 | |
| *** ivodd has quit IRC | 19:44 | |
| *** rohitksingh has quit IRC | 19:47 | |
| *** CarlFK has joined #timvideos | 20:24 | |
| *** ChanServ sets mode: +v CarlFK | 20:24 | |
| *** CarlFK has quit IRC | 20:43 | |
| mithro | http://www.phoronix.com/scan.php?page=news_item&px=HDMI-CEC-Linux-4.8 | 22:59 |
| tpb | Title: HDMI CEC Framework Finally Queued For Linux 4.8 - Phoronix (at www.phoronix.com) | 22:59 |
| mithro | CarlFK: is j-so comes back, ssk1328's work will allow for what j-so was asking for. It's effectively real time chroma-keying. | 23:01 |
| mithro | shenki: Things like that CEC support are the reason I think we want the hdmi2usb firmware to be Linux based in the future. | 23:03 |
| mithro | Be back later | 23:04 |
| *** CarlFK has joined #timvideos | 23:15 | |
| *** ChanServ sets mode: +v CarlFK | 23:15 | |
| cr1901_modern | mithro: Are you going to run Linux with an MMU or not? | 23:20 |
| *** ssk1328 has quit IRC | 23:45 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!