[04:40] *** Guest20298 has left "Leaving" [08:39] <javier__> sailus_: hi [08:40] <javier__> sailus_: sorry, yesterday I spent most of the day travelling so I didn't see your message before [14:57] <ritualmaster> Hi, anybody here that has ever used libmediactl? [15:20] <larsc> I bet pinchartl has [15:39] <ritualmaster> Thx [15:42] <jmleo> ritualmaster: but if you have a question, you should ask it ;) [15:58] <ritualmaster> Well, the thing is I am currently using libmediactl to enumerate a media bus and find all (sub-)device names/paths. I also need sometimes access to the fd inside the media_entity type to perform non standard io-ctls for some of the video (sub-)devices. I could also open them manually for separate fds, but since they are already contained (and op [15:58] <ritualmaster> ened) inside the entity, I would like to uses those. If I compile my program I can not access the entity internals (incomplete type)., since the type is only fully defined in the private header. Speaks anything against just including this header in my application? [16:02] <ritualmaster> For demo purposes I currently use the media-ctl command v4l2-ctl in a script: reset all links -> configure new resolution (format) on links -> set format on the video device node being the media chain endpoint -> perform ioctls on a subdevice for enabling certain camera features or configuring sensor resolutions [16:03] <ritualmaster> That is what I am trying to implement now. [16:08] <jmleo> ritualmaster: I can't find the question in all this... :p [16:12] <jmleo> you are using a script now, based on media-ctl + v4l2-ctl but would like to control it through a library with libmediactl ? [16:12] <jmleo> but libmediactl is private now [16:12] <jmleo> right ? [16:12] <ritualmaster> Well the type definition of media_entity is private. Yes want to use it as part of a c++ implementation of another framework. [16:13] <jmleo> https://gitlab.com/veo-labs/v4l-utils/commit/75f18c80eba3c890c235bfc99adf8f1164e3dbed [16:13] <jmleo> maybe useful ? [16:14] <jmleo> note however that media-ctl is going to change, so this is for the actual one, but pinchartl could tell you a lot more about it maybe mchehab too [16:15] <mchehab> jmleo, ritualmaster: yes, media-ctl is going to change, due to the Media Controller Next Gen patches (meant to be merged on Kernel 4.5) [16:16] <mchehab> the library will very likely need to be re-written due to it [16:17] <mchehab> It is up to pinchartl to define the new library API [16:17] <mchehab> but, IMHO, it is not the right moment to make the library non-private. It is pinchartl's call, though [16:18] <mchehab> he's likely not available ATM... we're in Korea today... it is 1am here ;) [16:19] <mchehab> so, I suggest you to ping here either via e-mail or wait for him to answer via IRC (but this can take a while) [16:21] <ritualmaster> Thanks jmleo and mchehab. Ah OK, so jmleo suggested version is not part official repo yet? Just found (http://git.linuxtv.org/cgit.cgi/v4l-utils.git/tree/utils/media-ctl?h=v4l-utils-1.8.1), were it is still private. For now I will just include the private header if this is going to change anyway. [16:22] <mchehab> it is part of the repo, but only as a private library used by media-ctl ;) [16:22] <ritualmaster> FYI: We are in yocto/poky fido environment using 3.19.5. Using 1.6.2 of v4l2-utils according to poky. [16:24] <mchehab> yeah, I guess you could include the private header... just be warned that, when this become a library, its API may change competely (or not), depending on how the API will be addressing the new ioctls added to support MC next gen [16:24] <mchehab> s/a library/an official library/ [16:25] <mchehab> I don't think 1.6.2 and 1.8.1 has much differences at libmediactl [16:25] <mchehab> probably some bug fixes [16:28] <ritualmaster> Hm. OK. This good. Should I run into any problems, changing it to the new version should be easy enough in this case. [16:29] <mchehab> double-checked: not much difference... DVB/ALSA device nodes parsing fixed (probably not relevant for anyone using upstream drivers) and Decoder/Tuner entities properly detected. There's also one small addition at media-ctl to parse V4L2_DV_FL_IS_CE_VIDEO [16:30] <ritualmaster> Great [16:30] <ritualmaster> ! [16:31] <ritualmaster> We won't get a new kernel version soon I think. So we will have to remain at one of these version throughout the project. [16:31] <ritualmaster> So the new api will not affect us in the near future of the project. [16:32] <ritualmaster> Thanks again guys for your help and feedback. Have good night in Korea! [16:32] <mchehab> ok. If your project doesn't have ALSA or DVB, then the current version should be safe for you [16:33] <mchehab> please notice, however, that when submitting your Kernel drivers upstream, you'll need to do a few adjustments due to the MC next gen [16:35] <mchehab> hmm... if you would need to change the number or entities/pads/links at runtime, you'll also need to upgrade to MC next gen. The current version doesn't allow that [16:35] <ritualmaster> Nope, don't use that via the API. The only driver that is from us, is the output of master thesis's from a colleague. Should we want to commit that upstream I think it will have to be adjusted anyway for it to be accepted. The other parts of the chain or partly official i.MX6 parts and from phytec. So not in our hand. [16:36] <ritualmaster> No don't need to do that. The chain is fixed. Just formats and device specific ioctls [16:36] <mchehab> ok. so you should be safe with v4l-utils 1.6.2 [16:37] <mchehab> ok, let me try to sleep ;) [16:37] <mchehab> cu [16:37] <ritualmaster> cu [17:10] *** benjiG has left [17:19] *** prabhakarlad has left [18:51] *** awalls has left [21:14] *** starsun has left "Leaving." [21:16] *** FlowRidda has left "Leaving."