[22:39] <shuah> ok
[00:17] <myself> Any recommended 4-input (quad) USB capture dongles that don't totally suck?
[00:17] <myself> (I know, those last few words kinda contradict each other...)
[00:19] <myself> I'd just rather route two USB cables through the wall, and do the capture over there, than try to shove 8 siamese coax+power cables through to reach a PCIe capture card.
[02:14] *** _jmleo changes his alias to jmleo
[02:32] *** _jmleo changes his alias to jmleo
[12:12] <pinchartl> hverkuil: ping
[12:12] <hverkuil> pinchartl: pong
[12:12] <pinchartl> regarding "[RFCv2 PATCH 0/8] Add VIDIOC_SUBDEV_QUERYCAP and use MEDIA_IOC_DEVICE_INFO"
[12:13] <pinchartl> I liked the previous version better where the entity ID was reported through VIDIOC_SUBDEV_QUERYCAP :-/
[12:14] <sailus> Hello!
[12:14] <pinchartl> what are the expected use cases for those two ioctls in userspace ?
[12:16] <hverkuil> SUBDEV_QUERYCAP: have a single ioctl that is always present in order to be certain a device node is a v4l-subdevX node. Basically QUERYCAP for v4l-subdev.
[12:16] <hverkuil> MEDIA_IOC_DEVICE_INFO can be used to find the corresponding media device node based on a v4l2 (or whatever) device node.
[12:17] <pinchartl> I know what they do
[12:17] <pinchartl> what I'd like to know is the expected use cases
[12:17] <pinchartl> I understand that v4l2-compliance is one of them
[12:17] <hverkuil> My use case is for v4l2-compliance.
[12:17] <pinchartl> are there other expected use cases ?
[12:18] <hverkuil> Since SUBDEV_QUERYCAP returns a version just like QUERYCAP it can be used to detect when features were added based on the kernel version.
[12:19] <hverkuil> And capabilities can be set in the future.
[12:20] <pinchartl> but we don't know yet what will be needed
[12:20] <pinchartl> I'm a bit reluctant to add two new ioctls for v4l2-compliance
[12:20] <pinchartl> I'm fine with VIDIOC_SUBDEV_QUERYCAP
[12:20] <sailus> hverkuil: The kernel version can be obtained using uname as well.
[12:20] <pinchartl> but I'd skip MEDIA_IOC_DEVICE_INFO for now
[12:20] <pinchartl> and add the entity id back to VIDIOC_SUBDEV_QUERYCAP
[12:21] <hverkuil> sailus: won't work with the media_build, whereas that will work correctly with the version number as returned by QUERYCAP.
[12:21] <sailus> uname is SYS V r4, and POSIX-1.2001.
[12:22] <sailus> hverkuil: So it's there just for media_build?
[12:22] <hverkuil> media_build will copy the media tree from kernel e.g. 4.2 to an older kernel, but querycap will report 4.2. Which is correct since the media drivers have the functionality of that kernel.
[12:22] <sailus> Ok.
[12:23] <hverkuil> No, version is there to provide a unique version number of the driver. It used to be that each driver had its own version numbering scheme, which usually wasn't updated when it should.
[12:23] <hverkuil> So we switch to using the kernel version, and as an added bonus it works cleanly with the media_build as well.
[12:23] <sailus> I think e.g. capability flags are still easier for the user space to use. It's not always very well documented (nor the developers may even want to know) what was added and when.
[12:23] <hverkuil> s/switch/switched/
[12:24] <hverkuil> I'm trying to remember why I removed the entity ID...
[12:25] <pinchartl> can't help you there :-)
[12:25] <pinchartl> maybe because you moved it to MEDIA_IOC_DEVICE_INFO instead ?
[12:26] <pinchartl> I'd prefer adding VIDIOC_SUBDEV_QUERYCAP only
[12:30] <hverkuil> I think the reason for using MEDIA_IOC_DEVICE_INFO was to avoid having to add an entity_id field to VIDIOC_QUERYCAP, or having to do something similar to ALSA/DVB/etc. Using MEDIA_IOC_DEVICE_INFO to obtain the media controller information and the entity ID (or in the near future the media interface ID) is something that works almost everywhere.
[12:31] <pinchartl> what about entities that will not have a device node but will instead be accessed through, let's say, a network interface ?
[12:31] <pinchartl> I don't think we have enough visibility on use cases for now
[12:31] <hverkuil> that's why I said 'almost'.
[12:33] <hverkuil> I propose to take version 1 of the patch ('[RFC PATCH 1/3] v4l2-subdev: add VIDIOC_SUBDEV_QUERYCAP ioctl'), but drop the pads field.
[12:33] <pinchartl> let me recheck it
[12:33] <hverkuil> and don't touch VIDIOC_QUERYCAP.
[12:34] <pinchartl> so only 1/3 and 2/3, and drop the pads field ?
[12:35] <pinchartl> (and possibly address the other very small nitpicking comments)
[12:35] <pinchartl> that looks good to me !
[12:36] <hverkuil> yes, 1+2 only, no pads.
[12:37] <pinchartl> go for it :-)
[12:47] <sailus> Let me go through the patches.
[12:48] <sailus> I'll do that this evening.
[12:55] <hverkuil> pinchartl: I remember why I had the pads in the first version: so if I give v4l2-compliance a v4l-subdev node, then it either needs to know the media controller the entity belongs to so it can query the number of pads, or it needs the number of pads in the struct v4l2_subdev_capability.
[12:56] <hverkuil> so I either need to know entity_id + pads or entity_id + major/minor of the MC device node.
[12:56] <hverkuil> The last is probably better, since that really gives you all the info you need.
[12:57] <pinchartl> and my comment was whether we couldn't get that information from sysfs
[12:57] <pinchartl> I wouldn't propose that as a generic solution
[12:57] <pinchartl> but for v4l2-compliance I believe it could do for now, until we get more use cases to design a better API
[13:00] <hverkuil> And this was the reason for using MEDIA_IOC_DEVICE_INFO in the second patch series since I think it would be a more generic solution.
[13:00] <hverkuil> Whether it can be done from sysfs I don't actually know. I know I don't like it, though :-)
[13:01] <hverkuil> Argh!
[13:01] <pinchartl> it's more generic, but I believe we need more use cases to design a good API. that's why I'd like to start with sysfs in v4l2-compliance, and then design an API with a couple more use cases available
[13:02] <pinchartl> Argh ? have you been hit by sysfs ?
[13:02] <sailus> Just replied the 1st patch... what I didn't get was where would you use the entity_id field on the V4L2 sub-device interface.
[13:02] <pinchartl> sailus: the idea is to point v4l2-compliance to a subdev node
[13:02] <hverkuil> 'Argh!' as in: why is something seemingly easy so difficult?
[13:03] <pinchartl> v4l2-compliance will then need to retrieve the number of pads
[13:03] <pinchartl> and will thus need the entity ID for that
[13:04] <sailus> And then it proceeds to open the MC device?
[13:04] <mchehab> pinchartl: I'm not aware of any fix patches for v4.2
[13:04] <mchehab> the window for sending new stuff closed weeks ago
[13:04] <pinchartl> mchehab: not fixes, features
[13:04] <pinchartl> the pull requests didn't make it to v4.2
[13:04] <pinchartl> what will you do with them ? process them for v4.3 ?
[13:04] <mchehab> all pull requests sent in time got merged
[13:05] <mchehab> the remaining one(s) will go to 4.3
[13:06] <mchehab> except for MC related patches. Those will be added on a separate topic branch until we fix MC
[13:06] <pinchartl> ok, so no need to resubmit
[13:06] <mchehab> no
[13:08] <sailus> pinchartl: How about "omap3isp: Fix sub-device power management code"?
[13:08] <sailus> I don't see that in media-fixes.
[13:11] <pinchartl> it was part of "[GIT PULL FOR v4.2] OMAP3 ISP and OMAP4 ISS fixes"
[13:12] <pinchartl> the problem has been present since v3.10, so it didn't make it to the fixes branch
[13:14] <sailus> Ok.
[13:29] <sailus> hverkuil: So you intend to add Media device's major and minor as well?
[13:29] <hverkuil> sailus: not for v3 (just posted).
[13:30] <hverkuil> But I would like to have a way to obtain the MC from a v4l-subdev/video/dvb/alsa/etc. device node. My v2 of this patch series did just that.
[13:30] <hverkuil> But Laurent didn't like it, and for now I just want to have some minimal implementation that I can use in v4l2-compliance.
[13:32] <shuah> mchehab, hverkuil, pinchartl, sailus: Are the Finland MC meeting dates are fixed? Any wiggle room there?
[13:32] <sailus> The entity id isn't quite enough, well, unless there's a system wide media deviec some day.
[13:33] <pinchartl> sailus: we also need the media devnode, yes
[13:33] <pinchartl> I wonder whether we can get that from sysfs
[13:33] <sailus> shuah: It was already difficult to agree on these, and I think someone might have reserved flights already.
[13:34] <pinchartl> s/wonder whether/hope that/ :-)
[13:34] <pinchartl> hverkuil: do you plan to check ?
[13:34] <hverkuil> check what?
[13:34] <pinchartl> whether you can find the media devnode from sysfs
[13:35] <sailus> I'll be back after a bit.
[13:36] <hverkuil> shuah: I don't think any flight have been reserved yet (I won't until Mauro has). But it has to be that week. And if Mauro will come over, then it has to be those particular days as well.
[13:36] <hverkuil> pinchartl: no, I plan to just require that the v4l2-compliance caller has to provide the MC device as well.
[13:38] <hverkuil> I don't think you can use sysfs for this since the MC can cover entities in different subsystems and on different buses.
[13:39] <shuah> ok thanks - I have to be back in Denver by July 27th - I will have to see if I can make it for a day at least.
[13:43] <hverkuil> pinchartl: I actually know for certain that sysfs won't work, just looking at something I am working on at the moment makes it clear that there is no way you can discover that information via sysfs.
[13:45] <mchehab> hverkuil: IMHO, with regards to the MEDIA_IOC_DEVICE_INFO/VIDIOC_SUBDEV_QUERYCAP, the best is to wait until we do the MC discussions
[13:46] <mchehab> and have a clearer view about alsa requirements
[13:50] <mchehab> hverkuil: actually, there's another option of flight via Portugal
[13:50] <hverkuil> VIDIOC_SUBDEV_QUERYCAP has nothing to do with alsa, it's just for v4l-subdev nodes.
[13:50] <mchehab> I might be able to slide it along the week, although it took 2 days for me to get a quote from the travel agency
[13:50] <hverkuil> wasn't that flight much longer?
[13:51] <hverkuil> flight time I mean
[13:51] <mchehab> not bad
[13:51] <mchehab> well... going to HEL is not bad
[13:51] <mchehab> returning will require me to sleep in Lisbon
[13:54] <mchehab> shuah: if you have to be in Denver on July, 27, it would mean that, for you to participate, it has to be on Jul, 29-31
[13:54] <mchehab> would that work for everyone?
[13:54] <shuah> correct
[13:54] <mchehab> subdev querycap is MC stuff
[13:54] <hverkuil> that's works for me.
[13:55] <mchehab> the concept of a generic MEDIA_IOC_DEVICE_INFO for all dev types will affect ALSA
[13:55] <hverkuil> The v3 patch series drops that. Because that's MC stuff and, as you say, still under discussion.
[13:56] <mchehab> that's why I think it is wiser to wait for MC discussions, in order to prevent us to increase entropy to an already messy enough API
[13:56] <shuah> I should have my patches done today - I am working on media-ctl tool and kernel changes at the same time
[13:57] <mchehab> hverkuil: the thing is that you're moving some MC-specific fields from MEDIA_IOC_DEVICE_INFO to VIDIOC_SUBDEV_QUERYCAP
[13:58] <mchehab> in any case, subdev API is part of MC... any change there will be at the topic branch anyway
[14:00] <hverkuil> shuah: would you depart for Helsinki on July 27 or 28? If it is the latter, then you will likely arrive somewhere in the morning of July 29. And if you are like me and you can't sleep in a plane, then you'll be very tired.
[14:00] <mchehab> so, as this won't be merging upstream before the meeting, better to wait for a while to rebase it, in order to avoid possible merging conflicts that might happen due to the changes we'll do at MC side
[14:00] <shuah> I have to leave on July 28th
[14:01] <shuah> right I think I probably don't get there until July 29th morning
[14:02] <pinchartl> mchehab: works for me
[14:08] <shuah> Quick search for flights says - I can't make it there until past noon on July 29th - I forget the loosing time thing :)
[14:09] <hverkuil> I'm OK with July 30 - August 1 as well (actually, it would be a bit better for me)
[14:09] <sailus> August 1st is out of question for me.
[14:09] <sailus> Also 31st is quite bad.
[14:10] <sailus> The earlier week would work though.
[14:18] <shuah> earlier week July 20 - 24th? works for me as well
[14:18] <pinchartl> not for me I'm afraid
[14:20] <hverkuil> Got to go. Anything after July 7th is fine by me :-)
[14:20] <shuah> where are those transporters when we need them :)
[14:22] <shuah> I take it nobody is coming to LinuxCon and LPC?
[14:22] <shuah> I am going to be at LPC in Seattle
[14:28] <pinchartl> I'll be at LPC too
[17:49] <devinheitmueller> myself: My guess is that it cannot *really* capture all eight ports at once. It probably just cycles through them continuously.
[17:50] <devinheitmueller> The description says "CONEXANT 10bit Super HD ADC", but Conexant doesn't make an eight-way encoder, and without that you wouldn't have enough USB bandwidth to do eight channels in parallel.
[18:11] <awalls> The bits need to go to 11. :)
[18:13] <myself> devinheitmueller: oh of course, i don't expect it to do 8 at once, just in rapid succession. Main question is whether those type of devices are well-known around here, infamous, or totally unknown.
[18:13] <devinheitmueller> It's probably just a standard decoder chip where they wired up eight mux pins.
[18:14] <devinheitmueller> I've seen devices like that, but I don't think any are supported under Linux currently.
[18:15] <myself> that's the datapoint i needed, thanks. :)
[18:15] <devinheitmueller> I've never really cared about such devices though. It's likely I could make one work pretty easily under Linux if needed.
[18:15] <myself> can i paypal ya one? heh.
[18:15] <devinheitmueller> Sorry, I just don't have the time to work on such devices anymore unless I've got a commercial customer paying for my time.
[18:16] <devinheitmueller> If you want multi-channel capture though, check out the cx25821 based devices. They are PCIe based, but they actually can record all the channels at once.
[18:16] <myself> how are the bluecherry cards? they got a lot of slashdot love in ~2010 for open-sourcing their driver, which said it was "90% functional" at the time and I don't know if it's been updated since
[18:17] <devinheitmueller> They seem to have largely gone dark. I think they're more focusing on software solutions nowadays.
[18:18] <devinheitmueller> (focusing on IP cameras which don't require drivers)
[18:19] <myself> yeah :/ I can get a 16-port bluecherry card for $99 but if it's totally abandoned, I don't know if I want to. But the more I look around in the dvr/capture market it looks like *nobody* supports anything or even offers connector pinouts. Am I missing something?
[18:19] <myself> (I'm a hardware guy and likely to build my own breakout cable for whatever card I get..)
[18:20] <devinheitmueller> There are lots of cards on amazon/ebay which are cx25821 based.
[18:20] <devinheitmueller> And they're dirt cheap too
[18:21] <myself> I'm trying to find device IDs that might hint at a brand name I should search for
[18:22] <devinheitmueller> Most of the cx25821 cards are no-name cards from China.
[18:22] <devinheitmueller> You won't find a "known vendor" who sells those sorts of boards at low prices.
[18:22] <myself> gotcha
[18:22] <myself> they're probably following the lovely Chinese-seller habit of putting their data as JPGs in the listing so it's not searchable, too :/
[18:24] <devinheitmueller> Probably the easiest thing would be to put "DVR card" into ebay and then just look at the PCB photos for the ones with a Conexant chip.
[18:24] <myself> thanks for all your help, by the way. Getting something that doesn't have super-buggy drivers is such a crapshoot without some guidance.
[18:24] <devinheitmueller> Oh wait, you don't want super buggy drivers? On Linux?
[18:24] <devinheitmueller> :-)
[18:25] <myself> haw. If I wanted super buggy drivers I'd have one of those amazon things I linked earlier :)
[18:29] <myself> Hmm. Geovision? Can't see the chips in any of the listings..
[18:30] <devinheitmueller> Worth noting that it's likely you'll have to do some driver work regardless of which one you buy. If the board has chips which are supported, then usually it's just a board profile that is required though.
[18:30] <devinheitmueller> (easier than having to write a driver from scratch)
[18:31] <devinheitmueller> I acutally did Linux support for this one a couple of weeks ago, but probably out of your price range. :-) http://www.bhphotovideo.com/c/product/844827-REG/ViewCast_95_00472_OSPREY_460E_4_CH_WITH.html
[18:33] <myself> Hmm. There's a beat-up one on eBay right now for $64, found in a recycling box with some components knocked off the board...
[18:35] <myself> 4ch natively, can switch 4 inputs per channel so 16 multiplexed... hmm!
[18:35] <devinheitmueller> Yeah, they are pretty nice. They're high end cards, hence the pricing.
[18:35] <devinheitmueller> Used in the broadcast industry.
[18:36] <myself> what makes 'em nice, just clean signal paths?
[18:36] <devinheitmueller> That's one item. They also support both balanced and unbalanced audio, SD component video, and have a bunch of good features in their Windows driver for stuff like overlays.
[18:36] <devinheitmueller> (i.e. balanced == XLR connectors)
[18:37] <devinheitmueller> You don't see it on that link I provided, but they have a bunch of rack-mountable breakout panels which you can attach to the card.
[18:38] <myself> Ahh, features that matter in studio but not surveillance :) interesting to know, though... same digitizers work for component and then you do something with the digized streams to interpret it as a single signal?
[18:38] <devinheitmueller> Most of the chips themselves could do SD component video, but the companies that make the boards typically won't break out the appropriate pins.
[18:39] <devinheitmueller> SD component is a pretty rare use case nowadays.
[18:39] <devinheitmueller> (pretty much anybody doing component would be doing HD)
[18:40] <devinheitmueller> One other good feature - most of the surveillence multi-channel cards either support no audio at all or just a single channel. The Viewcast boards support stereo audio.
[18:40] <devinheitmueller> I.e. stereo audio for every video channel.
[18:42] <myself> I'm trying to think of how that would even be used. I mean surveillance here has strict laws that you can't record audio; that's eavesdropping. And a 4-channel.. umm.. video-conferencing or something perhaps?
[18:42] <myself> cool feature regardless, though
[18:42] <devinheitmueller> It wouldn't be used for surveillance. Again, we're talking about stuff targeted at broadcast studios.
[18:42] <devinheitmueller> Or video streaming headends.
[18:42] <myself> aha, that makes sense. sure.
[18:43] <devinheitmueller> I own a hotel and want to rebroadcast four TV channels from cable boxes over an IP network.
[18:43] <devinheitmueller> Should have been more clear - that was just an example. I don't actually own a hotel.
[18:43] <myself> Hah. No I got it.
[18:45] <myself> hmm. One I can read the chip on is an intersil tw6869, which a quick google reveals to have a pretty thorough linux driver
[18:45] <devinheitmueller> Yeah, I actually don't know what state the techwell stuff is in right now.
[18:45] <devinheitmueller> Email the list and hverkuil will likely reply though.
[18:46] <myself> $45 for 8ch is pretty impressive, wonder if I can find a pair of those wedged onto one card and save a slot :) we only have 8 cameras right now but I'm feeling a need for more, and if I can reduce the slot-anxiety of going to 16 that's a bonus
[18:46] <myself> ohh that's a techwell chip, I guess intersil acquired them? I've seen techwell chips all over other cards I've been looking at too.
[18:46] <myself> https://github.com/igorizyumin/tw6869/tree/master/src
[18:46] <myself> ^^ very encouraging
[18:47] <devinheitmueller> Yeah, years ago.
[18:47] <myself> gotcha
[18:47] <devinheitmueller> I'm pretty sure hverkuil added support last August for a bunch of tw68 boards. Entirely possible you could just plug one in and it would work.
[18:50] <mchehab> pinchartl, sailus, hverkuil, shuah: as both pinchartl and shuah will be going to LPC, perhaps we can do our meeting there (either the week before or the 3 days after)
[19:20] <shuah> mchehab: that would work well. I haven't booked flight yet and can change hotel reservation as needed
[20:59] <tnt> The v4l_subdev_core_ops says that .init and .reset shouldn't be used anymore.
[20:59] <tnt> So where should that stuff go ?
[21:20] <awalls> the probe routine for the subdev, I would guess
[21:57] <tnt> I'm kind of suprised I'm not finding any start() / stop() for the sensor ...
[22:07] <awalls> What subdev driver?
[22:09] <tnt> well, all ? I'm writing one but I didn't really see anything like a start/stop in the ops
[22:10] <tnt> also looingin in the media/i2c folder, I couldn't really find a sensor with start/stop
[22:10] <awalls> s_stream
[22:10] <awalls> starts streaming
[22:10] <awalls> Random example: http://git.linuxtv.org/cgit.cgi/media_tree.git/tree/drivers/media/i2c/tvp514x.c#n821
[22:11] <awalls> not that I'm at all familiar with the TI subdevs
[22:11] <tnt> err ... so looks like I'm blind ...
[22:11] <tnt> how did I miss that ...
[22:11] <awalls> Too much indirection inside of v4l2 at times.
[22:12] <awalls> but meh.
[22:13] <awalls> s_stream is and audio op and a video op
[22:13] <awalls> *an
[22:14] <tnt> yup, saw that.
[22:17] *** awalls has quit IRC (Quit: awalls)
[22:41] <pinchartl> mchehab: before LPC could work, but I'll have to rebook my flight, that would be quite expensive
[22:41] <pinchartl> so I'd rather avoid that
[22:41] <pinchartl> and after LPC is not possible for me
[22:45] <headless> pinchartl: still not asleep? :-)
[22:46] * headless is prepping to go to bed
[22:51] <headless> night
[22:52] *** headless has quit IRC (Quit: headless)