--- Day changed Mon May 14 2012 14:09 -!- pinchartl [~pinchartl@perceval.ideasonboard.com] has joined #v4l-meeting 14:09 < pinchartl> hi 14:09 <@sailus> Bonjour! 14:09 < pinchartl> sorry for being late 14:10 <@sailus> C'est ne pas une problème. 14:10 <@sailus> Tu es le deuxième participant. :-) 14:11 < pinchartl> I don't know why my computer failed to warn me 14:11 <@sailus> I wonder if we should start. 14:12 <@sailus> Albeit I'm expecting Sylwester at least, and preferrably Tomasz. 14:12 <@sailus> I'll ping them. 14:12 < pinchartl> ok 14:16 -!- snawrocki [~snawrocki@217-67-201-162.itsa.net.pl] has joined #v4l-meeting 14:16 <@sailus> snawrocki: Dzien dobry! 14:17 < snawrocki> Hi Sakari, Laurent 14:17 < snawrocki> sorry, I'm a bit disorganized today.. 14:18 <@sailus> snawrocki: That's all right. 14:18 <@sailus> snawrocki: No sign of Tomasz? 14:18 <@sailus> It'd be good to have him here, too. 14:19 < snawrocki> just a minute, I'll try to contact him 14:24 < snawrocki> ok, his is going to join soon 14:25 <@sailus> Let's still wait for Tomasz to join. 14:26 <@sailus> Without pointing anyone, this must be a record time we've taken from the start of the meeting to do actually something useful. ;-) 14:27 < pinchartl> should we try to do even better next time ? :-D 14:27 <@sailus> I'm not sure if we should. 14:28 <@sailus> New records are cool but then again we wouldn't get anything done in the end. :-P 14:28 < pinchartl> :-) 14:32 -!- tstanisl_ [d98c6016@gateway/web/freenode/ip.217.140.96.22] has joined #v4l-meeting 14:32 <@sailus> tstanisl_: Dzien dobry! 14:32 <@sailus> I believe we're all here now. 14:32 <@sailus> So we can start. 14:32 <@sailus> I called up this meeting to discuss two things. 14:33 <@sailus> - To remove _ACTUAL / _ACTIVE, or not to remove it? If we do, this would be a wonderful time to do so. 14:33 <@sailus> - Unification of the target definitions between V4L2 and V4L2 subdev interface, and document only differences. Yes or no? 14:34 <@sailus> Let's proceed to the first one first. 14:34 < tstanisl_> hello. Are we going to solve this problem in democartic way, I mean voting? 14:34 <@sailus> I guess usually rough concensus is what we're looking for. :-) 14:35 <@sailus> That sounds a bit like democracy. :-) 14:36 <@sailus> There was a long, long discussion on what to call the target that actually takes effect on the hardware on V4L2 subdev interface. At the time we concluded with ACTUAL, as ACTIVE wasn't seen really good at all. 14:36 <@sailus> Now I have a feeling that even ACTUAL is purely artificial, and we might do better without such name. 14:36 <@sailus> So, e.g. the crop target that takes effect on hardware would be called simply V4L2_SUBDEV_SEL_TGT_CROP. 14:37 < snawrocki> Then what would be the reasons not to remove _ACTUAL/_ACTIVE ? Is anyone anyone strongly opposed to that ? 14:37 <@sailus> If additional specifications are needed, they are postfixed to this, such as BOUNDS and PADDING. 14:37 < pinchartl> I have nothing against removing them 14:38 <@sailus> tstanisl_: What's your opinion? 14:42 <@sailus> tstanisl_: Ping? 14:42 < pinchartl> a new record, I'm telling you :-D 14:43 < tstanisl_> pong 14:43 < tstanisl_> sorry 14:44 < tstanisl_> I am ok with removing _ACTUAL/_ACTIVE suffix. But we should introduce that last 4 bits of enum should be zero for default targets 14:44 < tstanisl_> or even last 8 bits 14:45 < tstanisl_> sorry, I'll back in circa 15 minutes 14:45 <@sailus> Ok. 14:45 <@sailus> I guess the matter is then settled. We'll proceed to remove the _ACTUAL/_ACTIVE postfix. 14:45 <@sailus> Who wants to write the patch? :-) 14:46 < pinchartl> do you ? :-) 14:46 <@sailus> We don't have many users of these values yet, so it won't be a big one. 14:46 < snawrocki> I could do that :) But I was wondering whether 14:47 < snawrocki> we could have same #defines for V4L2 and subdev API 14:47 < snawrocki> ? 14:47 <@sailus> That's the second topic. 14:47 <@sailus> To me they look largely the same. 14:47 <@sailus> There are somewhat subtle differences in meaning that depend on pixel format / media bus format. 14:48 <@sailus> But in principle the two are very similar. 14:48 < snawrocki> Let's imagine a situation where subdev is coupled with host driver, internally in the kernel 14:48 < snawrocki> I think we allow that ? Host driver using the pad ops 14:48 < snawrocki> in the kernel ? 14:48 <@sailus> We're looking to use the selections in configuring statistics windows (or metering, as it's called somewhere) and probably also to provide face detection information to user space. 14:49 <@sailus> snawrocki: We almost do that already. 14:49 <@sailus> I need to get some controls on the sensor from the OMAP 3 ISP CSI-2 receiver. 14:49 <@sailus> They're related to the frequency of the CSI-2 bus. 14:51 < snawrocki> alright, I mean if we use the selection API and pads ops to replace VIDIOC_S_CROP/ subdev video.s_crop pair 14:52 <@sailus> If? 14:52 <@sailus> The patches are in Mauro's tree already. 14:53 <@sailus> New drivers should no longer implement s/g_crop. 14:55 < snawrocki> doesn't it look strange that the selection targets are translated implicitly in the kernel, e.g. V4L2_SEL_TGT_CROP_ACTIVE <-> V4L2_SUBDEV_SEL_TGT_CROP_ACUAL ? 14:56 <@sailus> We currently don't guarantee they're the same, albeit in practice care has been taken they are. 14:56 < snawrocki> sailus: yes, that's right, but when the user uses selection (e.g. CROP) on /dev/video 14:56 < snawrocki> what targets should they use ? 14:56 < snawrocki> that's inconsistency.. 14:57 <@sailus> Right, yes, unifying the two would fix that. 14:57 <@sailus> It's a slight nuisance that the conversion has to be made, at least in principle. 14:58 <@sailus> On video nodes it's V4L2_SEL_* and on subdev nodes it's V4L2_SUBDEV_SEL_*. 14:59 < snawrocki> ok, it might be better to keep different target names.. 14:59 <@sailus> Why so? 15:00 <@sailus> I haven't seen a single reason why we really should do that. 15:00 < snawrocki> I just don't have strong opinion on that :) 15:00 <@sailus> They were separate to begin with because we didn't know too much about the two. 15:01 <@sailus> I mean, selection on V4L2 and on subdevs. 15:01 < snawrocki> alright, I was going to ask why they were different in first place 15:01 <@sailus> If you look at your exposure metering target patches, it looks like you essentially have the same documentation there twice. 15:02 < snawrocki> yes, exactly, that also bother me 15:02 < snawrocki> +s 15:02 < pinchartl> having a single definition thus sounds good 15:02 <@sailus> The reason why I made them different was that it's easier to unify them than to separate them. 15:02 <@sailus> And at the time I didn't know what would make sense in the long run. 15:02 <@sailus> Also no-one commented that. 15:03 <@sailus> So here we are. :-) 15:04 < pinchartl> what's the proposal ? to use the V4L2 definitions for subdevs ? 15:04 <@sailus> Yeah. 15:04 < snawrocki> IIRC, I asked whether we could unify selection targets, but I was just when I started working on the focus controls and realized there were issues. 15:04 <@sailus> And if there are differences between the two, then they are to be documented. 15:05 <@sailus> But I feel the delta is much, much less than twice the amount of documentation. 15:05 < snawrocki> Yes, I also thought we could just do that. 15:05 <@sailus> We should also specify which targets are valid on V4L2 and which ones on subdevs. 15:06 <@sailus> Or rather may. 15:06 <@sailus> Being not used currently is different from not applicable. 15:07 <@sailus> It's an interface spec, and does no take a stance what drivers implement. 15:11 < snawrocki> so the IOCTL description chapters would remain not significantly changed, I guess 15:11 <@sailus> That's right. 15:12 <@sailus> I think we could document the targets in V4L2 selection documentation, and if there are differences, document those in V4L2 subdev selection documentation. 15:12 <@sailus> How does that sound like? 15:13 <@sailus> Alternatively the targets could be documented outside IOCTL documentation. 15:14 < pinchartl> sailus: I'm fine with that 15:15 < snawrocki> yeah, perhaps the targets should be documented outside IOCTL documentation 15:15 < pinchartl> snawrocki: agreed 15:16 < snawrocki> otherwise we would have add references in subdev ioctl description to the v4l2 ioctls, or repeat those 15:16 <@sailus> Agreed. 15:16 <@sailus> Who wants to write the patch on this? :-) 15:16 <@sailus> There's a dependency to the first patch, and it'd be nice to get this all to 3.5 15:16 < tstanisl_> I am back 15:17 < snawrocki> alright, I was afraid of that question :-D 15:17 <@sailus> tstanisl_: Good. We just decided we'll unify the targets. 15:17 <@sailus> :-) 15:17 <@sailus> I can handle it for media-ctl and SMIA++ and omap3isp drivers. 15:18 <@sailus> I guess most of the work will be in documentation, though. 15:19 < pinchartl> sailus: the 3.5 merge window is just around the corner. we'll need to hurry up 15:19 <@sailus> Indeed. 15:20 <@sailus> I can also handle the renaming elsewhere in V4L2. 15:21 <@sailus> Anyone interested in writing (or rather mostly removing) documentation? :-) 15:22 < pinchartl> I'm afraid I won't have time for that before v3.5 15:22 <@sailus> Btw. one question: do you think we could make a single patch from the two changes, or would you think two are required? 15:23 <@sailus> The intermediate state does not make much sense except a tiny bit for review purposes. 15:23 < pinchartl> two separate patches are more logical from a review point of view but I won't nack a single patch 15:23 < snawrocki> I think we need one patch removing _ACTIVE from the target names 15:23 <@sailus> Ok. 15:24 <@sailus> Two patches then. 15:24 <@sailus> And perhaps a third one for documentation. 15:24 < snawrocki> and the other unifying the targets. 15:24 <@sailus> Yeah. 15:24 <@sailus> 1. Remove _ACTIVE / _ACTUAL. 15:25 <@sailus> 2. Unify selection targets i.e. no more separate subdev targets. 15:25 < tstanisl_> Do you think that we should add requirements for aligment for the selection tagets? 15:25 <@sailus> 3. Take the changes into account in documentation, i.e. we have selection target documentation that is separate from IOCTL documentation. 15:25 < snawrocki> sailus: Agreed. 15:26 < snawrocki> tstanisl_: what kind of requirements ? 15:26 <@sailus> No need for a separate documentation patch which removes _ACTIVE/_ACTUAL in docs, right? 15:27 <@sailus> What really matters after all is the code. :-) 15:27 < tstanisl_> that the base target like V4L2_SEL_TGT_CROP_ACTIVE (aka V4L2_SEL_TGT_CROP) should be aligned to 16 or256 15:27 <@sailus> We currently have no such information available in the interface. 15:28 < snawrocki> sailus: One patch seems fine for me.. 15:28 <@sailus> It could be possible to add that, but it's out of scope of these changes. 15:28 < tstanisl_> right.. it can be added at any time 15:28 < tstanisl_> later 15:28 <@sailus> tstanisl_: We're in hurry to get even these for 3.5. 15:29 <@sailus> It's important that we won't change the naming once people have started using it, even if it's experimental. 15:30 < tstanisl_> ok 15:30 < snawrocki> the original selection API is already in the kernel for 2 releases, IIRC, I feel it's a bit late for renaming already 15:30 <@sailus> We can also leave the old _ACTUAL name in the header file. 15:31 <@sailus> Thus existing software won't fail to compile, even if they're using the old name. 15:31 <@sailus> Or, rather, _ACTIVE in this case. 15:32 < snawrocki> fortunately there is no other drivers than Samsung's using the API, AFAICS, so we can handle it, but it's an unnecessary complication. 15:32 < pinchartl> and mark it as deprecated and scheduled for removal 15:32 < tstanisl_> I did not know that keeping backward compatibility is applied for experimental features :) 15:32 < pinchartl> tstanisl_: I don't think it's mandatory, but it's a nice bonus 15:32 < snawrocki> yeah, sounds good to me 15:32 < snawrocki> :-) 15:32 <@sailus> If you think we won't need it I'm happy not to leave the old definitions there. :-) 15:34 < snawrocki> I would just not leave compatibilty defines, there sooner they disappear, the better.. 15:34 < snawrocki> and let's don't do more changes like that... :-) 15:34 <@sailus> :-) 15:34 < snawrocki> s/there/the 15:35 <@sailus> That's my point, too. This kind of changes are best done sooner than later. 15:35 <@sailus> So now it's the time. :-) 15:35 <@sailus> Good. 15:36 <@sailus> Sounds like to me we're good. 15:36 <@sailus> Any other comments or questions? 15:36 <@sailus> Except who's going to write the patches. 15:36 < snawrocki> I could rework my previous patch, doing _ACTIVE -> _ACTUAL rename 15:37 <@sailus> I can write the documentation patch as well, but I need the first patch from Sylwester. 15:37 <@sailus> So the first patch is written by Sylwester, and the two latter by myself. 15:38 <@sailus> Comments, questions? 15:38 < snawrocki> I'll try to get it done today. 15:38 <@sailus> snawrocki: Excellent! 15:39 <@sailus> If there are no more questions or comments, I think we're done now. 15:40 <@sailus> Thanks to everyone for participation! 15:40 <@sailus> I'll post the link to meeting log to linux-media. 15:40 < snawrocki> Yeah, I think we can continue on the ML. 15:40 < snawrocki> ok, thanks 15:41 < pinchartl> tahnk you 15:41 < pinchartl> s/tahnk/thank/ 15:41 < tstanisl_> thanx