14:28 -!- snawrocki [~snawrocki@217-67-201-162.itsa.net.pl] has joined #v4l-meeting
14:29 -!- snawrocki [~snawrocki@217-67-201-162.itsa.net.pl] has left #v4l-meeting ["Leaving"]
14:59 -!- pinchartl [~pinchartl@perceval.ideasonboard.com] has joined #v4l-meeting
15:01 -!- snawrocki [~snawrocki@217-67-201-162.itsa.net.pl] has joined #v4l-meeting
15:02 < pinchartl> hi
15:03 < snawrocki> pinchartl: hi
15:04 < snawrocki> I wondering whether anyone alse is going to join, maybe Tukka or David ?
15:04 < snawrocki> unfortunately I'd forgotten to Cc them on the invitation
15:05 < snawrocki> Sakari seems to be not there yet..
15:08 < pinchartl> sailus: ping ?
15:11 < pinchartl> I've pinged him on jabber
15:15 < snawrocki> I think 3 persons is a minimum to carry on todays meeting, let's wait a moment and see if he shows up.
15:16 < pinchartl> ok
15:16 < pinchartl> you don't use jabber, do you ?
15:17 < snawrocki> I do, but at home only.
15:25 < pinchartl> I think he forgot about it :-/
15:31 < snawrocki> it's a pitty :/ we have already reserved some time, maybe we could discuss the topic at least briefly ?
15:32 < pinchartl> sure
15:33 < snawrocki> do you want me to send you the compiled DocBook chapter ?
15:33 < pinchartl> if it's available, yes, please
15:33 < snawrocki> ok, I've sent it
15:34 < snawrocki> I'm wondering whether we need a new class for the proposed controls 
15:35 < pinchartl> let me check my mails
15:35 < snawrocki> ok, there would be dependencies between the new and exisiting controls in the camera class
15:36 < snawrocki> for instance V4L2_CID_EXPOSURE_AUTO and V4L2_CID_EXPOSURE_BIAS
15:36 < snawrocki> V4L2_CID_EXPOSURE_BIAS would just be changing behaviour of V4L2_CID_EXPOSURE_AUTO
15:37 < pinchartl> ok
15:37 < pinchartl> the issue, as I see it, is quite simple
15:37 < pinchartl> we have different levels of controls, that interact with each other
15:37 < snawrocki> uhm ?
15:38 < pinchartl> on the lower levels we have controls that are directly mapped to dedicated hardware blocks
15:38 < pinchartl> analog gains for instance
15:38 < pinchartl> that's the lowest level
15:39 < snawrocki> yes, I talked with Sakari yesterday, and the conclusion was to create two new classes for the lovest level controls:
15:39 < pinchartl> on the higher levels we have controls that influence complex algorithms, usually implemented in software in a firmware
15:40 < pinchartl> white balance preset is somewhere there
15:40 < pinchartl> and of course we have controls in-between
15:41 < snawrocki> [s/lovest/lowest]
15:42 < snawrocki> yes, I guess auto exposure is an example of a "middle" level control ?
15:42 < pinchartl> yes
15:42 < pinchartl> another issue is that some hardware features can be controlled by several different V4L2 controls
15:42 < pinchartl> white balance for instance
15:42 < pinchartl> we have white balance temperature, white balance component and white balance preset controls
15:43 < pinchartl> a device and/or driver that supports white balance control can expose one or several of those controls
15:44 < snawrocki> yeah, there is nothing preventing driver to expose multiple controls, the interactions even now are underspecified as I can see
15:45 < snawrocki> for instance white balance temperature and white balance component controls
15:46 < snawrocki> I'm wondering how much separate control class is helpful for applications
15:46 <@sailus> Pong!
15:47 < snawrocki> :-)
15:47 < snawrocki> hi Sakari! :)
15:47 <@sailus> Sorry; for some reason my alarm didn't work. :-P
15:47 < pinchartl> I don't care much about the control classes to be honest
15:47 < pinchartl> I think it makes sense to group controls that are directly usable by end-users in tv or webcam applications in a class
15:48 < pinchartl> and have them displayed as-is by applications
15:48 < pinchartl> but other than that, I don't think classes are very useful
15:48 <@sailus> Hi, Sylwester and Laurent!
15:48 < pinchartl> dependencies and interactions between controls, however, need to be very well documented
15:52 < snawrocki> yes, I totally agree with that
15:52 <@sailus> Control classes are useful IMO also for documentation purposes.
15:52 <@sailus> When you're thinking of adding new controls, you can easily find out what else is there when looking a different classes.
15:53 < pinchartl> sailus: it's quite hard to decide on which class to put a control in in many cases. that's a sign that classes are ill-designed
15:53 <@sailus> E.g. you can ignore radio class when thinking of new camera controls.
15:53 <@sailus> pinchartl: I fully agree with that.
15:53 <@sailus> I think it would be good to be able to move controls across classes.
15:53 <@sailus> Not something we can do now, however, that's fixed in design.
15:54 <@sailus> If we even really, really needed to make classes visible to the user.
15:54 <@sailus> They don't help much, except for test programs which can show nice panels to users.
15:54 <@sailus> Should controls have tags instead?
15:55 <@sailus> You could associate multiple tags to a control; e.g. low level and camera tags.
15:55 <@sailus> Would that make any sense?
15:56 <@sailus> That would solve one of the issues in classes that you can have a control associated with just one at a time.
15:56 < snawrocki> it probably would make sense only for the controls that are directly shown to the user
15:56 < pinchartl> I think it would be overly complex compared to the benefits
15:57 <@sailus> I think some kind of classification is still useful to have in documentation.
15:57 <@sailus> That's what classes do somehow currently.
15:58 < snawrocki> maybe something like device profiles would be more useful
15:59 < snawrocki> but then we would have same controls repeated in different profiles
16:00 < snawrocki> I mean in the documentation of course
16:00 < snawrocki> but it seems to late for such change anyway
16:00 < snawrocki> s/to/too
16:01 < pinchartl> yes, it's probably too late
16:04 < snawrocki> then could I assume that the conclusion is to have the proposed controls in V4L2_CID_CAMERA_CLASS class and properly document interactions between new and existing controls ?
16:04 < snawrocki> or did I speak too fast ? :)
16:05 <@sailus> snawrocki: I think so.
16:05 <@sailus> That's how I'd do it.
16:05 < pinchartl> I'm fine with that, yes, but I wonder whether the documentation shouldn't also talk about some kind of profile
16:05 < pinchartl> for instance
16:05 < pinchartl> we'll have lots of different controls for white balance
16:06 <@sailus> I also have documented interactions between controls in the new control classes (image source and image processing).
16:06 < pinchartl> even if you document the relationships between them
16:06 < snawrocki> hmm, sounds like a good idea
16:06 < pinchartl> the important question that the documentation won't answer is which controls to expose for what kind of device
16:08 < snawrocki> yes, I think that's what is missing from application writer POV, it's hard to figure out which controls must, should or may be used for each task
16:09 < pinchartl> it's missing from both points of view (application and driver)
16:09 < snawrocki> or you program application for a specific driver or just expose all controls to a user on the panel, and let tehm decide
16:10 <@sailus> pinchartl: I agree this kind of information is missing currently.
16:11 < pinchartl> displaying all controls in a panel is asking for trouble
16:12 < snawrocki> Sure, the above two cases are both rather something than we wanted to avoid.
16:13 < pinchartl> is it something we want to support ?
16:13 < pinchartl> do we want to let drivers decide which controls an application should display ?
16:16 < snawrocki> That would be some sort of tag, sounds reasonable to me, I suppose that a driver writer will have better knowledge
16:17 < snawrocki> which controls are to be exposed to applications
16:17 < pinchartl> it will likely depend on what kind of application
16:18 < pinchartl> such behaviour is useful for consumer webcam or tv devices
16:18 < pinchartl> but probably not for the rest
16:18 <@sailus> Could we have tags?
16:19 < snawrocki> then we may need something more than just a binary flag
16:19 < snawrocki> I guess this is because we're trying to use controls
16:20 < snawrocki> for something more than they were originally designed :)
16:20 < snawrocki> i.e. to allow the user tweaking some parameters
16:21 < snawrocki> anyway extended controls seem to go further than that
16:21 < pinchartl> extended controls are no different than normal controls
16:22 < pinchartl> the extended control API just offers a way to set several controls at once
16:22 < pinchartl> that's it
16:28 < snawrocki> sailus: then what the tags might look like ?
16:28 < snawrocki> I'm wondering whether we should discuss this topic further
16:29 <@sailus> Hum, for example, low level or TV set.
16:29 < snawrocki> or just note that we may needs controls tags
16:29 <@sailus> A control could have several tags.
16:29 < snawrocki> and think about it again. 
16:29 <@sailus> I'm not sure whether we should pursue this even if it was decided that this is what we want, for current extended controls.
16:30 <@sailus> Well, something could be added to queryctrl, and we'll likely get ext_queryctrl soon anyway.
16:30 <@sailus> We'd need a bit field or two.
16:32 < snawrocki> the tags would indicate device profile to some extent ?
16:33 < snawrocki> I guess it's safe to assume that.
16:34 <@sailus> Profiles would tell what to expect in high level from the device.
16:36 < snawrocki> Ok.
16:37 < snawrocki> One of the topics on the agenda I have is specifying coordinates (rectangle, point) for auto focus, exposure and white balance.
16:38 < snawrocki> Shall we move to that ? Or are there any more comments on the controls classifications ?
16:38 < pinchartl> we can move to that
16:38 <@sailus> But tags as I thought them would be associated to controls.
16:39 <@sailus> Should profiles be limited to controls, or whole V4L2 API?
16:40 <@sailus> I remember we agreed on creating device profiles.
16:40 < snawrocki> IMO, whole V4L2 API.
16:41 <@sailus> I agree.
16:41 <@sailus> But what we discussed there was more on the level of proper V4L2 capture device / something you'll need to use MC first on / radio etc.
16:42 <@sailus> It's not at the level of TV / camera, for example.
16:44 <@sailus> But what could be done, is to have several items on the profile.
16:44 < snawrocki> I think what Mauro suggested as profiles in V4L2
16:44 <@sailus> For example, it could be a "V4L2 capture device" and "camera".
16:44 < snawrocki> was to refer to devices like TV/ camera, even various types of cameras
16:44 < snawrocki> not "capture device" or "output device"
16:49 < snawrocki> sailus: ok, for tags it makes sense, maybe even something more specific, like "embedded camera" etc.
16:53 < snawrocki> Ok, then moving to the pixel coordinates specification..
16:53 <@sailus> I actually have some ideas for that.
16:54 <@sailus> But I don't fully like them even myself but haven't been able to come up with anything better either.
16:54 < snawrocki> I guess we all know what the problem is ?
16:54 <@sailus> Selections and bitmask controls.
16:54 < pinchartl> yes
16:54 <@sailus> I think so.
16:54 <@sailus> Selections are used to specify the areas of interest for AEWB, histogram and AF.
16:55 < snawrocki> sailus: ok, it looks like we ned more complex types with the control API, to specify (set of) points and/or rectangles
16:55 <@sailus> A bitmask control or a few tell which of these selections are actually being used.
16:55 <@sailus> If it's a point, then width and height are just zero.
16:55 <@sailus> What do you think of that?
16:56 <@sailus> Then there would be no need to tell the type separately.
16:56 <@sailus> In hardware these are practically always rectangles.
16:56 < pinchartl> it's an interesting idea
16:57 <@sailus> The same could be applied to face detection, perhaps, but I haven't really thought about the details.
16:57 < snawrocki> sailus: yes, internally we even had 4 controls, (left, top, width, height), and (left, top) only have been used to specify point
16:58 < snawrocki> for facet detection we need to specify rectangles that contain a face, i.e. face size
16:59 < snawrocki> but it's mostly size only
17:00 < snawrocki> however there might be IPs that needs full rectangle coordinates, so it's basically same issue
17:01 < snawrocki> sailus: what about the selection target ?
17:02 < snawrocki> Do you mean specifying it with a bitmask ? Not sure I understood your point.
17:03 < snawrocki> Or would the bitmask be used to determine which selection targets are valid ?
17:03 <@sailus> For face detection or for statistics window-of-interest?
17:04 < snawrocki> Let's focus on the statistics windows.
17:05 <@sailus> There would be a set of rectangles used for a type of windows-of-interest.
17:05 <@sailus> Say, autofocus.
17:05 <@sailus> Each of the window would correspond to one bit in the bitmask.
17:06 <@sailus> If the bit is set, the window would be active.
17:06 < snawrocki> ok, I think I know what you mean..
17:06 < snawrocki> yeah
17:06 < snawrocki> that's interesting
17:06 <@sailus> I don't like that particularly much since there's nothing in the control that tells actually what is the target number of the selection.
17:06 <@sailus> But there is currently no generic way to do the association anyway.
17:07 < pinchartl> sailus: maybe one of the queryctrl field could be used for that ?
17:07 <@sailus> Good point.
17:08 <@sailus> It could tell the start address, and from the number of bits you'd know how many selections there are starting from that target number.
17:16 < pinchartl> is there anything else ?
17:17 < snawrocki> Yes, only the naming of the controls.
17:18 < snawrocki> Would you have any comments on that ?
17:19 < snawrocki> Here is a link to the patches: http://git.infradead.org/users/kmpark/linux-samsung/shortlog/refs/heads/camera-controls
17:20 <@sailus> A moment.
17:20 <@sailus> I have prefixed the controls with the class name.
17:20 <@sailus> Do you think it makes sense?
17:21 <@sailus> I actually prefer it since it gives hints where the control belongs to.
17:21 < pinchartl> I think it would just make the control names too long, without much added benefit
17:22 <@sailus> They wouldn't be *that* long
17:22 < snawrocki> Hmm, it could be better to add prefix, but existing controls don't have it
17:22 <@sailus> Some existing controls do not have it, especially the older ones.
17:22 <@sailus> The flash class does, for example.
17:22 < snawrocki> Lest consider this: V4L2_WHITE_BALANCE_PRESET_INCANDESCENT vs.
17:23 < snawrocki> V4L2_CAMERA_WHITE_BALANCE_PRESET_INCANDESCENT
17:23 < snawrocki> I don't see much benefit in adding the prefix
17:23 <@sailus> Ok.
17:24 <@sailus> It also gives more information on the class.
17:24 <@sailus> As we concluded, the classes don't serve that purpose really well due to difficulties in deciding which classes controls belong to.
17:24 < snawrocki> yes, but some control are getting really long
17:25 < snawrocki> even now I have been considering replacing AUTO_FOCUS with AF, etc.
17:25 < snawrocki> :-)
17:26 < snawrocki> Also it's not expected to abbreviate control name in menu items ?
17:27 < snawrocki> No, it's not a good idea, let's forget about it.
17:28 <@sailus> So, no class prefix in control names then?
17:28 < pinchartl> I'd avoid them
17:28 <@sailus> I'll remove them from my patches --- I sent them to the list last night; the changes will be small anyway.
17:28 < pinchartl> classes server little purpose, so a class prefix wouldn't be much more useful
17:28 <@sailus> I agree.
17:29 < snawrocki> Me to, given sometimes it might be difficult to associate a control with single class.
17:30 <@sailus> I guess that's the conclusion then?
17:30 <@sailus> I'd like to ask your opinion on my two additional classes, image source and image processing.
17:30 <@sailus> Do they still make sense to you?
17:31 < snawrocki> Yes, let's not prefix control names with a class name.
17:32 < snawrocki> I didn't change my mind, yet. :-)
17:32 <@sailus> I think classes mostly serve the purpose of documenting the controls in a structured way currently.
17:32 <@sailus> So I agree the two classes is the right way forward.
17:33 <@sailus> pinchartl: What do you think?
17:34 < pinchartl> let me check them
17:35 < snawrocki> sailus: there is a typo in patch 09/31: s/preriod/period
17:38 <@sailus> Oh.
17:38 <@sailus> I thought I fixed it already. :-P
17:38 <@sailus> Thanks for letting me know!
17:39 < pinchartl> as I said, I think that most classes are pointless, so I don't particularly like the creation of two new classes. this being said, I won't nack the patches. you should run this through Hans
17:41 <@sailus> pinchartl: Do you have an alternative proposal?
17:41 <@sailus> I don't want the documentation of controls to become an unreadable mess. Currently control classes give it a structure.
17:42 <@sailus> I'd sure like Hans' opinion but he's been a lot offline recently. :-I
17:43 < pinchartl> sailus: no I have no alternative proposal, that's why I won't nack the patches
17:44 < pinchartl> controls are already a mess in my opinion
17:44 < pinchartl> it's too late
17:45 <@sailus> I agree with that.
17:46 <@sailus> At least we have experience that should help us in designing something better that will some day replace them.
17:46 <@sailus> The property API. :-)
17:46 < snawrocki> I think it might make sense to create a new class for object (face) detection devices for instance, but even in this case there are some relationships with the camera controls
17:47 < snawrocki> how would the property API look like, a control framework with more complex data types ?
17:48 < pinchartl> the properties API will likely be a control-like API on /dev/media*
17:49 < pinchartl> with more complex data types possibly
17:50 <@sailus> What we primarily need is more flexibility.
17:50 <@sailus> So we can change these things later on.
17:50 <@sailus> We don't want to make any strict decisions on the API functionality in such a fundamental level as controls do, for example.
17:51 <@sailus> Say, you can only extend them in ways that have been previously thought.
17:51 <@sailus> And once you're out of reserved fields you're out of luck.
17:51 <@sailus> And then you create a new IOCTL which everyone has to start using.
17:55 < snawrocki> I think there was not much attention during design of these API towards extensions, and this causes  
17:55 < snawrocki> out of tree reimplementation of everything from scratch
17:58 < snawrocki> It looks like it's all I had for today.. :)
18:01 <@sailus> Thanks for the meeting!
18:01 <@sailus> I think this was quite useful.
18:02 <@sailus> Have a nice week-end!
18:02 <@sailus> Bye!
18:03 < snawrocki> thank you for joining! 
18:03 < pinchartl> you're welcome
18:03 < snawrocki> sailus: could you put the notes on you serwer ? And send me a link please ? :-)
18:04 < snawrocki> So I would include it in the summary, I guess it's good to send a sumary to linux-media ?
18:05 < snawrocki> sorry, I mean the IRC log :-/
18:07 < snawrocki> ok, nvm :-)
18:07 < snawrocki> have a nice weekend Laurent!
18:07 < snawrocki> bye
18:11 <@sailus> I can put them there.
18:11 <@sailus> A moment.