<!-- 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>
tfiga: working on encoder now
<br> one question, though
hverkuil: <u>tfiga</u>: ok
tfiga: <u>hverkuil</u>: I feel like the EOS event at the end of the Drain sequence is at least redundant
<br> <u>hverkuil</u>: and in the worst case it actually prevents the client from disambiguating between "EOS coded in the stream" and "finish of the drain"
hverkuil: I'll have to get back to you on this later today.
tfiga: <u>hverkuil</u>: okay, thanks, comments appreciated :)
ribalda: @hverkuil Good morning
<br> regarding a video pipeline with multiple steps: white balance, crop, flash,
<br> every step has multiple fine tunnings with controls
<br> something like 16 cores and 10-30 controls per core
<br> is it a good idea to define a v4l2_class per core?
<br> I am having in mind the calibration gui.
hverkuil: <u>mchehab</u>: urgent cec fix for 4.20: https://patchwork.linuxtv.org/patch/52530/
<br> <u>pinchartl</u>: ping
pinchartl: <u>hverkuil</u>: ponog
<br> or rather pong
hverkuil: I didn't get a RFP on the 'dim' topic from you, so I just came up with this:
<br> 10:00-10:10: dri-devel and 'dim' (Laurent Pinchart)
<br> Experiences (good and bad) with the dri-devel 'dim' utility.
<br> (scheduled just before the 'Automated Testing' topic)
<br> Is this OK?
pinchartl: that's ok, thank you for handling this
hverkuil: Posted final agenda. Looks good to me.
kbingham: sailus, Heya - I posted a v3 of the max9286 to account for the merge conflicts on the latest linux-media/master last week. The changes v2->v3 are minimal but max9286 has been unloved on the lists for a very long time. Do you know if you are able to look at it pre-elce? Or will it be after now ?
<br> (No worries if it's got to wait until after ELCE now - :D)
hverkuil: <u>ribalda</u>: what do you mean with 'core' and with 'v4l2_class'? (there is no v4l2_class, so I'm confused)
sailus: Oh dear.
<br> So many patches to review. :-I
<br> <u>kbingham</u>: I'll try to check that tomorrow / the day after.
ribalda: @hverkuil I am horrible explaining thins, sorry. By core I mean fpga core.
<br> by v4l2_class V4L2_CTRL_TYPE_CTRL_CLASS;
<br> like V4L2_CID_CAMERA_CLASS, V4L2_CID_DV_CLASS....
hverkuil: <u>ribalda</u>: are all the fpga cores identical?
ribalda: @hverkuil we have families: white balance, perspective, colorspace, packer
<br> something like 15 cores and 10 families
<br> the person designing the gui was asking to create a class per family, so she would show it in different tabs
hverkuil: Ah, now I get it.
ribalda: it is a pretty bizarre amount of controls :), in the range of 100
hverkuil: It's not a bad idea. I think it would look pretty decent in a GUI.
ribalda: I do not see many users of control classes, just 7 drivers, so I did not know if it was deprecated
hverkuil: How did you grep that? It is used by many drivers, so '7' seems wrong.
ribalda: git grep V4L2_CTRL_CLASS | grep .c:
hverkuil: Ah, that's not right.
<br> the control class is part of the control ID, drivers do not typically need to know about it, it's handled transparently by the control framework.
<br> e.g. all MPEG controls are part of the MPEG control class.
<br> When a driver adds a control for a new class, the control framework will automatically create a control of type V4L2_CTRL_TYPE_CTRL_CLASS.
<br> Since you will be adding non-standard control classes (i.e. the control core doesn't know about them), you will need to add them manually.
<br> See the vivid driver, vivid-ctrls.c, search for vivid_ctrl_class.
ribalda: <u>hverkuil</u>: thanks!
hverkuil: Most developers never need to create 'control class controls' since it is done for them.
ribalda: it is mainly to show the controls nicely on the gui. This is why I was a bit skeptical. Seemed like a userpace job to me
<br> but we also have the slider flag
hverkuil: Basically it is a control of type V4L2_CTRL_TYPE_CTRL_CLASS, the ID is that of the base ID of the control class ORed with 1, and the name can be used as the name of the tab page.
<br> qv4l2 does all that.
<br> Remember that controls are typically shown in a GUI, and so you need to provide enough info so such a GUI can be constructed.
<br> pretty much all generic v4l2 applications do this.
<br> For embedded systems that use custom applications it generally is much less important since it is all hand-crafted code.
ribalda: that is our main problem. we are a generic embedded platform :) :).
<br> <u>hverkuil</u>: Thank you very much. I hope nobody was using our old control ids because they will change after we add the class
hverkuil: You're welcome!
mchehab: <u>hverkuil</u>: patch doesn't apply on fixes branch:
<br> +<<<<<<<
<br> res = wait_for_completion_killable_timeout(&data->c,
<br> msecs_to_jiffies(timeout));
<br> +=======
<br> + wait_for_completion_killable(&data->c);
<br> + if (!data->completed)
<br> + cancel_delayed_work_sync(&data->work);
<br> +>>>>>>>
hverkuil: <u>mchehab</u>: it's for 4.20 (master branch). Hmm, I shouldn't have said 'FIXES' in the subject.
<br> Apologies for the confusion.
mchehab: yes. also, you added a cc stable since 4.18
<br> it won't apply there without backports
<br> you should expect compliants from Greg about that too
<br> I applied it already for 4.20
hverkuil: The patch that it fixes also has a CC to stable for 4.18. So as long as they are applied in the right order this will be fine.
mchehab: ok
hverkuil: Our Cisco CI tests caught this corner case: I was rather impressed by that, to be honest.
mchehab: that's good
hverkuil: <u>tfiga</u>: do we need the EOS event at all? The EOS event was added for the old ivtv MPEG decoder driver: this driver uses write() to write the compressed MPEG program stream to the decoder.
<br> This isn't an m2m device, it outputs the decoded video directly to an S-Video output.
<br> Since it isn't using the Streaming I/O API, it also has no way of reporting V4L2_BUF_FLAG_LAST. Hence the introduction of the EOS event.
<br> But with the proposed codec API we'll never use the old read/write API and so can always signal the end-of-stream by setting BUF_FLAG_LAST.
<br> Is there any reason why we want this event at all for m2m codecs?
<br> <u>pinchartl</u>: reminder: patch "Depth confidence pixel-format for Intel RealSense cameras" needs your review/ack.
***: benjiG has left