<!-- Some styling for better description lists --><style type='text/css'>dt { font-weight: bold;float: left;display:inline;margin-right: 1em} dd { display:block; margin-left: 2em}</style>

   hverkuil: <u>nohous</u>: shoot!
   nohous: well, if i didn't miss anything, there is no pixfmt defined e.g. for 10b 4:2:2 YCbCr
   <br> namely, i think the v210 fourcc is the one we should go on with
   hverkuil: Correct. There is no such format. But pixelformats are easy to add: add the define and update the DocBook.
   nohous: ok, so generally no big deal with mainlining new pixelformats
   hverkuil: No. That happens all the time.
   <br> Update videodev2.h, media/v4l2-core/v4l2-ioctl.c (for the format description) and DocBook/media/v4l/pixfmt*.xml
   <br> For a standard YUV format it would be nice if you could add support for it to the vivid driver (vivid-tpg.c) so people can test their application with that format without requiring your hardware, but I can do that as well.
   nohous: https://developer.apple.com/library/mac/qa/qa1501/_index.html
   <br> i think all the v* formats there should be defined
   hverkuil: One limitation: new pixelformats are only accepted if there is a driver mainlined that uses them.
   nohous: <u>hverkuil</u>: ok, i can update the vivid, at  least i'd have some test source if there's some bug in the hw
   hverkuil: Right. Ideally qv4l2 in v4l-utils should also be updated to correctly display the pixelformat.
   nohous: limitation understood, but does the vivid as user count in? :-)
   hverkuil: Depends, but for this format it does IMHO since it is a pretty standard format.
   <br> Mauro might decide otherwise.
   nohous: ok, one other thing
   <br> there is the vbi interface defined for access on the vertical blanking data
   <br> i am thinking on how to go with ancillary data
   <br> as they are present also in horizontal blanking periods, would it make more sense to somehow expose them over the vbi, or to go with multiplanar video format as you've originally suggested?
   ***: dannas has left
   hverkuil: I suspect you'll have a hard time shoehorning this data into the vbi API. That API was designed for analog video (broadcast SDTV) and I don't think it will scale to SDI.
   <br> My problem is that I don't know anything about how the anc data is transported over SDI.
   <br> Or what data is stored there.
   <br> I see three options:
   <br> if the data and video must remain closely in sync, then the only option is to either keep blanking + video in one big plane (needs a custom pixelformat) and let userspace figure it out, or to split off the blanking into a separate plane and again transport both together.
   <br> The second option is to use VBI but define a new buffer type (e.g. V4L2_BUF_TYPE_SDI_BLANKING_CAPTURE/OUTPUT)
   <br> The third is to come up with a new sdi-anc device with similar functionality as a vbi device.
   <br> I think that's not a good idea.
   <br> It should be 1 or 2.
   <br> Can your hardware split off video and anc data into separate DMA streams?
   <br> And how is the horizontal blanking vs vertical blanking handled?
   <br> (Hmm, perhaps SDI_BLANKING is too specific, ANC_DATA might be better)
   nohous: i am back, sorry
   <br> i don't think i want the user space to parse an image out of raw frame data
   <br> (actually, we might define such format, but it would be of marginal use in some special user case)
   <br> and as for the splitting: i do not want to allocate two or more full dma channels for single sdi stream, as this is kind of costly
   awalls_: <u>hverkuil</u>: didn't the VBI slicer in cx25843 chips throw the sliced data in as ancillary data?
   nohous: however, i can split the active line data to one buffer and the horizontal blank into another
   awalls_: which then was emitted via /dev/vbiN?
   nohous: the issue here is that amount of anc data per horizontal line is unknown in advance so some user / kernel space copying is then necessary, but i don't think i can do anything about that
   <br> <u>hverkuil</u>: maybe something like SMPTE298_
   <br> *SMPTE298_ANC_DATA
   <br> <u>awalls_</u>: i'll have a look on this
   awalls_: with the VBI device nodes you set them to sliced (anc data) or raw (line pixels in grayscale) at any one time.
   <br> <u>nohous</u>: the ivtv &amp; cx25840 drivers did it together, but can be hard to follow the code.
   <br> the cx18 driver does the same thing, but the code is easier to follow.
   nohous: from the api docs: Sliced VBI devices use hardware to demodulate data transmitted in the VBI. V4L2 drivers shall not do this by software, see also the raw VBI interface.
   awalls_: yes.  there is a hardware VBI slicer that creates the anc data in the cx25843 and cx23418 chips.
   nohous: i think i'd need to find some compromise here, as i can unpack the data from native 9b width, but i can not prevent "holes" in the target buffer if anc data doesn't fill the entire horiz blank interval
   <br> by unpack i mean unpacking in hardware
   awalls_: for ntsc and pal VBI anc data was always very short.
   <br> the horizontal blank pixel data was 1440 (720 * 2) pixels per line
   nohous: well, in sdi you can't really presume such thing since audio is also anc data and it _can_ be totally asynchronous to the video fps
   awalls_: ah.  I see how the sliced cbi interface won't work with that.
   <br> *vbi
   nohous: in most cases, you have synchronous 48kHz / 16 channels, but you can't rely on that with respect on which lines this data lie on
   <br> take for one the stupid 1000/1001 US framerates
   <br> if you want to see the related SMPTE standard, i can upload it somewhere
   <br> it would be nice to find standard way to expose this
   awalls_: /dev/ancdata :)
   <br> Or you could create an ALSA interface for embedded audio.  But the you lose the nice AV sync you had.
   hverkuil: <u>nohous</u>: do you know the maximum size of the anc data for each frame? So software could preallocate the buffers based on that size and when the DMA engine writes to the anc data plane it will just concatenate all the anc data for that frame and return the total size? Or fill the whole buffer but with 0 values where there is no anc data?
   <br> I presume SDI has some sort of parsing mechanism to find where the anc data is? So software can parse the anc data buffer?
   awalls_: the 1000/1001 comes from the transition to color TV and backward compatibility with black and white tv.
   <br> still within the tolerance for black and white sets while avoid the color components from beating with the line refresh.
   nohous: <u>hverkuil</u>: maximum size is generally the blanking width, which is known... so my approach would be to have a small buffer for each line
   awalls_: the actual fraction is something weirder but common factors cancel out.
   nohous: there is a possibility in the dma for early termination, so if there's less than max (or none at all) data for given line, only the received amount is transmitted
   hverkuil: As long as the driver can read that out from a register, then that's fine.
   <br> Can there be holes between anc data packets in SDI or are all anc data packets supposed to be concatenated?
   nohous: <u>hverkuil</u>: in order to concat the data in hw, i'd need to have full fledged dma channel just for anc data, which is, as said, costly
   <br> so i'd concat the small blanking buffers in sw, which is i think reasonable (the entire blanking is about 12% of raw frame size)
   hverkuil: OK, so you just split off anc (horizontal + vertical) from the video and put them in two different buffers.
   <br> What about audio? That's part of the anc data?
   nohous: <u>hverkuil</u>: if you mean holes during single line? not sure, sorry
   hverkuil: yes, that's what I mean.
   nohous: <u>hverkuil</u>: have to check out, but i can remove the potential holes in hw (i'd buffer only buffer the horiz blanking valid (and unpacked) payload, not the holes)
   <br> yes, audio is a type of anc data
   <br> so with this approach it would have to be parsed in sw
   hverkuil: OK.
   nohous: <u>hverkul</u>: btw, there is a similar concept in HDMI
   <br> i think it's called data packets
   <br> but i guess no one really ever needed their raw payloads exposed
   hverkuil: HDMI hardware filters those out and processes them. Audio goes out using spdif and other data which is limited in size (InfoFrames) ends up in registers of the hardware.
   nohous: but it might be worthy to come up with some general interface for such out-of-band data
   hverkuil: Right, you never see them directly.
   nohous: so, shall i keep with the multiplanar approach? or should i write the options down and address the mailing list?
   hverkuil: mulitplanar makes the most sense for your hardware.
   <br> There is one bottleneck: today the pixelformat has to define the format for all planes. But that would mean a pixelformat code for each combination of video and anc.data format.
   <br> That won't scale.
   <br> We've thought about this before and one option is to specify per-plane formats or something like that.
   <br> lyakh has similar requirements, I think.
   mvdworp: hi
   hverkuil: I don't think it is that hard to implement.
   lyakh: <u>nohous</u>: hverkuil: haven't read the complete communication, but I'm working on a design, that will push different data streams via different video device nodes, synchronised, using sequence numbers
   mvdworp: I have a question, can the universal_dvb be implented in the build?
   <br> I have a question, can the universal_netup* be implented in the build?
   hverkuil: <u>mvdworp</u>: what's 'the build'?
   mvdworp: Sorry, I ment the v4l build of the media_build_experimental
   <br> for DVB
   nohous: <u>lyakh</u>: can you tell what is the application for this ?
   lyakh: <u>nohous</u>: simultaneous streams over a single CSI-2 bus, a typical use-case includes actual video data, sent with one data type and per-frame metadata, sent with a different data type
   hverkuil: <u>mvdworp</u>: you mean when building using these instructions? http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers
   nohous: <u>lyakh</u>: so it's kind of similar to what we need - stream of video frames bundled with "metadata" synchronous to the individual frames
   mvdworp: Yes, please.
   lyakh: <u>nohous</u>: yes. We're also going to discuss this at ELC in April in San Diego
   hverkuil: <u>mvdworp</u>: You likely need to use the 'Developer's Approach
   <br> and then run 'make menuconfig' to enable this driver for your kernel.
   <br> But I see that this kernel relies on CONFIG_SPI_MASTER, which may not be enabled in your kernel.
   mvdworp: Yes it is enabled.
   <br> Unfortunately I can not find the universal_netup driver, for rev02
   nohous: <u>lyakh</u>: hm, shame, that's a bit far for away me
   <br> *far away for me
   lyakh: <u>nohous</u>: you can also mail your thoughts, ideas, requests to the mailing list, then we can incorporate that in the discussion
   hverkuil: <u>mvdworp</u>: does this report the driver?
   <br> find /lib/modules/`uname -r`|grep netup-unidvb.ko
   mvdworp: Nope, but I am currently rebuilding the driver package.
   <br> Again
   <br> So give me a second, and I'll try again.
   mvdworp_: .
   <br> exit
   <br> oops, sorry. -,-
   MikeyvanderWorp: Nope, even after reinstalling it does not work.
   <br> I do have SPI support enabled.
   <br> Any other ideas which may cause this issue?
   hverkuil: do you see it being compiled at all?
   mszyprow: <u>hverkuil</u>: I'm sorry that I disappeared last time we discussed, did you manage to get cec running on your odroid?
   hverkuil: <u>mszyprow</u>: no. But I am using the drm video output driver, so does the cec driver Kamil made even work with that?
   <br> I don't see the /dev/cec0 device appearing.
   mszyprow: <u>hverkuil</u>: yes, he was using it with drm
   <br> <u>hverkuil</u>: I assume you have added all the dts patches?
   <br> <u>hverkuil</u>: I mean cec device in dts
   MikeyvanderWorp: hverkuil, no. It does not seem to be compiled. Including the fact that I do not even see the proper version for this.
   hverkuil: <u>mszyprow</u>: yes, I did.
   mszyprow: <u>mszyprow</u>: give me a minute, I will check it
   MikeyvanderWorp: <u>hverkuil</u>: When I try to install the http://linuxtv.org/hg/v4l-dvb/ package, it gives me an error for another product. So let me try excluding that installation from the package.
   hverkuil: <u>mszyprow</u>: I'm using this tree: http://git.linuxtv.org/hverkuil/media_tree.git/log/?h=odroid-cec
   <br> (media_tree master + cec patches)
   <br> <u>MikeyvanderWorp</u>: /hg/? That's ancient!
   mszyprow: <u>hverkuil</u>: okay, I will clone and check
   MikeyvanderWorp: @hverkuil I am wondering if it is possible, If I can give you the model numbers we use (4 different chips).  If it is possible you can build us a media_tree
   <br> Would that be possible?
   hverkuil: <u>MikeyvanderWorp</u>: did you follow the 'Developer's Approach' as described in the wiki? Please do that first.
   MikeyvanderWorp: Let me see, sec.
   <br> I only did the "Basic Approach".
   mszyprow: <u>hverkuil</u>: which odroid model do you have?
   MikeyvanderWorp: Is there any difference between the Developer/Basic approach?
   theBear: heh even i know the answer to that
   hverkuil: <u>mszyprow</u>: odroid U3
   MikeyvanderWorp: I understand the difference between building/modifying additional drivers.
   <br> Nevermind, I'll try the Developer Approach. Brb!
   hverkuil: <u>MikeyvanderWorp</u>: what is your kernel version? uname -a
   <br> Very important question.
   MikeyvanderWorp: Linux IPTV-H7 4.1.15-gentoo-r1_IPTV-Utelisys #1 SMP Wed Feb 24 11:35:48 2016 x86_64 Intel(R) Xeon(R) CPU X7350 @ 2.93GHz GenuineIntel GNU/Linux
   hverkuil: OK, that's new enough (this driver is disabled for kernels &lt; 3.7)
   MikeyvanderWorp: Yes I saw that message, but it seems the Developer Approach gives me much more drivers....
   <br> Its now compiling.. So let's see how this goes.
   <br> I now have 33 files containing the word "netup", I had only "12" in the previous package. So this might already fixed my issue.
   <br> containing the name*
   hverkuil: Strange. Running the "Basic" approach on my box does compile the driver.
   MikeyvanderWorp: There is a difference between the rev01 and rev02
   <br> Do you also have both?
   mszyprow: <u>hverkuil</u>: It looks that "dts: exynos4412-odroid*: enable the HDMI CEC device" got broken somehow. I've sent you a fixup by mail.
   MikeyvanderWorp: Hmm, seems that the universal driver is now installed.
   <br> Let me see if works.
   hverkuil: <u>mszyprow</u>: thanks! that would be great if I can get it to work.
   <br> <u>mszyprow</u>: one thing that is missing in the driver is that it needs to be told what the physical address is. The application now has to read the EDID to find that. But the drm hdmi driver has that info as well.
   <br> It would be nice if the drm driver would just pass that on to the CEC driver.
   MikeyvanderWorp: And again it does not work. :(!
   mszyprow: <u>hverkuil</u>: yes, that could be easily added, I will take a look into this, but I can't promise any deadline
   <br> <u>hverkuil</u>: probably this should be implemented on drm-core &amp; cec-core levels
   <br> <u>hverkuil</u>: with some phandle pointing which cec device is physically linked with which hdmi connector
   MikeyvanderWorp: &gt;
   <br> <u>modprobe</u>: ERROR: could not insert 'cx23885': Unknown symbol in module, or unknown parameter (see dmesg)
   mszyprow: <u>hverkuil</u>: as I assume that one might even try to implement gpio based bit-bang cec driver (no idea if it is really possible with typical gpio bit-bang delays) and it would good if it will be also supported by cec&amp;drm layers
   hverkuil: <u>MikeyvanderWorp</u>: cx23885 has nothing to do with the netup driver. Seems to be unrelated. But what does dmesg say?
   MikeyvanderWorp: We have an cx23885 card also
   <br> But for the netup_universal it says the same
   <br> <u>modprobe</u>: ERROR: could not insert 'netup_unidvb': Invalid argument
   hverkuil: <u>MikeyvanderWorp</u>: can you post the dmesg output somewhere? pastebin would work.
   MikeyvanderWorp: Sure give me a second.
   <br> I can also sent you an e-mail if you like?
   mszyprow: <u>hverkuil</u>: I need to go now, if you have any problems with odroid, please mail me
   hverkuil: <u>mszyprow</u>: sure, thanks for your help. I'll probably work more on this on Friday.
   MikeyvanderWorp: http://217.117.234.9/dmesg.txt
   <br> @ hverkuil
   hverkuil: run 'depmod -a' as root, then reboot. It looks like the module dependencies map is messed up.
   <br> <u>MikeyvanderWorp</u>: ^^^^
   MikeyvanderWorp: Alright, Rebooting for second time.
   hverkuil: <u>MikeyvanderWorp</u>: what did you do to install?
   <br> You have to run 'make install' in media_build, copying just the netup driver isn't enough/
   <br> .
   MikeyvanderWorp: i know that
   <br> i did already
   hverkuil: OK, good.
   MikeyvanderWorp: But I did "make reload"
   <br> After that as it did not work yet.
   hverkuil: you did the make reload, but not the depmod -a?
   <br> that would explain it.
   MikeyvanderWorp: Yes, I did that too.
   hverkuil: Huh, weird.
   MikeyvanderWorp: Again it does not work
   <br> <u>videobuf2_v4l2</u>: Unknown symbol vb2_buffer_in_use (err 0)
   <br> Do you want system access to try?
   hverkuil: do you have the videobuf2_core.ko module in /lib/modules?
   MikeyvanderWorp: yes
   hverkuil: is it loaded?
   MikeyvanderWorp: drivers/media/v4l2-core/videobuf2-core.ko
   <br> No, that says a bunch of "unknown symbols"
   <br> and disagrees about version
   <br> As posted to you in that dmesg.txt file
   hverkuil: check the dates. Perhaps it is an old version.
   MikeyvanderWorp: I doubt that, I just installed the kernel
   <br> But give me a second
   hverkuil: If I have access, then I could take a look myself. I would suck at a helpdesk job :-)
   MikeyvanderWorp: If you would do that, It would be much appreciated yes.
   <br> Let me arrange you access.
   <br> sec
   <br> How to do private message again in IRC.
   <br> ./w
   hverkuil: <u>MikeyvanderWorp</u>: I see your 'test's, do you see my replies?
   MikeyvanderWorp: Nope.
   <br> I don't.
   <br> Thats ok, I will just sent you the details then.
   <br> We can talk here.
   hverkuil: weird. never had that *not* work.
   MikeyvanderWorp: Its probably my IRC window
   <br> Do you have by chance also an e-mail address, so we can have an conversation via e-mail when in feature something goes wrong with our drivers.
   hverkuil: hverkuil@xs4all.nl
   MikeyvanderWorp: Alright
   hverkuil: And for the record: I don't maintain this driver, so I can't give help with that.
   MikeyvanderWorp: Ah I thought you where one of the developers.
   hverkuil: post to the linux-media mailinglist (see linuxtv.org for info) if you need driver help.
   MikeyvanderWorp: Of this projecg
   <br> Of this project
   <br> Oki sec.
   hverkuil: One of the, yes, but not for DVB stuff.
   MikeyvanderWorp: Ah alright
   <br> But you are for the V4L right?
   hverkuil: yes
   MikeyvanderWorp: It does not matter actually, if you can fix the issue and let me know what the issue was, i'm good with it
   <br> The package is in the directory: /usr/src/Netup_Software/
   <br> One of our PCI cards in there is: cx23885 - so: modprobe cx23885
   hverkuil: <u>MikeyvanderWorp</u>: still waiting for an email, not sent yet?
   MikeyvanderWorp: No
   <br> I sent you a private message
   <br> xD
   <br> But I can sent you an e-mail yes.
   hverkuil: didn't see the private message this time :-)
   <br> so email it is.
   MikeyvanderWorp: Done. Sent you the information via e-mail.
   hverkuil: <u>MikeyvanderWorp</u>: did you move old drivers to updates/media in lib/modules/`uname -r`?
   <br> That's the cause: you have two videobuf2-core.ko modules in lib/modules/`uname -r`.
   <br> And modprobe picks the old one.
   <br> Move the updates directory up one level and run depmod -a again.
   sailus: <u>hverkuil</u>: Could you reply to Laurent on "media-ctl: List supported media bus formats"?
   MikeyvanderWorp: Oh really?
   <br> <u>modprobe</u>: ERROR: could not insert 'videobuf2_core': Unknown symbol in module, or unknown parameter (see dmesg)
   <br> Rebooting the system again.
   sailus: <u>hverkuil</u>: Thanks!
   MikeyvanderWorp: @hverkuil - I am now getting this issue:  netup_unidvb 0000:14:00.0: netup_unidvb_initdev(): failed to initizalize devic
   hverkuil: <u>MikeyvanderWorp</u>: that's where my support ends :-) At least your module dependencies are now correct.
   MikeyvanderWorp: Any suggestions?
   ***: benjiG has left
   <br> awalls has left
   <br> dannas has left