[08:22] <sailus> syoung: Could you send them to me by e-mail, in plain text?
[09:07] <hverkuil> mripard: paulk-leonov: question regarding cedrus driver:
[09:08] <hverkuil> I don't see any code to set the sequence number in struct vb2_buffer, nor are the timestamps copied AFAICS.
[09:08] <hverkuil> Is this indeed missing or am I blind?
[09:13] <mripard> hverkuil: you seem to be right :)
[09:14] <hverkuil> I'm preparing a patch that at least copies the timestamp. I'm also adding 'cookie' support to refer to frames (untested, that's for you to do).
[09:15] <hverkuil> BTW, what happens if a wrong forward or backward reference is given? cedrus_dst_buf_addr returns 0 in that case, but what will be the result of that?
[09:20] <mripard> I guess that's undefined at the moment
[09:31] <mripard> hverkuil: paulk-leonov will have some time allocated in the near future to tackle this thnigs
[09:31] <mripard> I didn't have the time to look into the cookie patch you sent, unfortunately :/
[09:57] <hverkuil> mripard: paulk-leonov: tfiga: posted series adding cookie support for the cedrus driver and v4l2 core.
[09:58] <mripard> hverkuil: awesome, thanks
[12:21] <syoung> sailus: sure. It'll have to be next week sometime, I'm afraid
[13:19] <sailus> syoung: Ack; thanks!
[14:51] <ribalda> hello! what is the recommended way of selecting the are for the 3A? A composed control or a magic selection target. V4L2_SEL_TGT_3A ?
[15:09] <pinchartl> ribalda: it depends :-)
[15:09] <pinchartl> if you have a 3A subdev, you could simply use the crop rectangle at the input of the subdev
[15:09] <pinchartl> otherwise, I'd go for controls
[15:09] <pinchartl> I don't think introducing 3A selection targets would scale
[15:10] <ribalda> unfortunately it is a single device
[15:10] <pinchartl> a sensor ?
[15:11] <ribalda> @pinchartl sensor_reciver/dma all in one in fpga
[15:11] <ribalda> a big monster. I might create a fake subdevice
[15:11] <pinchartl> even if it's a single chip, it can be represented using multiple subdevs
[15:12] <pinchartl> to expose the internal architecture
[15:12] <pinchartl> it doesn't mean the subdevs would be fake
[15:15] <ribalda> and it will look much more elegant
[15:15] <ribalda> @pinchartl  thanks :)
[15:17] <pinchartl> you're welcome
[15:19] <ezequielg> mchehab: i just send you the revert for the vpu bindings
[15:22] <ezequielg> let me know if you need anything else
[15:43] <pH5> ezequielg, mchehab: did I understand correctly, JPEG_RAW is off the table for now, jpeg codec drivers should be implemented with the stateful codec API?
[15:56] <ezequielg> pH5: I am preparing a submission for Rockchip VPU JPEG encoder, that produces actual JPEG format.
[15:57] <ezequielg> it has the advantage of not requiring any new userspace, nor uapi changes.
[15:57] <ezequielg> it has the disadvantage of not being able to choose the quantization and huffman tables
[15:58] <ezequielg> i guess it is still under discussion, but it seems a good idea (to produce out-of-box usable drivers for users) to provide JPEG.
[15:58] <ezequielg> if a driver(s) wants to also offer JPEG_RAW via the request api (or not), i think that's also something we can discss
[15:58] <ezequielg> makes sense?
[15:58] <pH5> ezequielg: ok, thanks.
[16:00] <pH5> ezequielg: I'll follow your lead and do the same for coda i.mx6 then.
[16:01] *** prabhakarlad has left 
[16:04] <hverkuil> ezequielg: sorry if I asked this before, but why can't you choose the quantization and huffman tables? What is preventing you from supporting that?
[16:04] <ezequielg> pH5: coda i.mx6 supports jpeg encoding? is there a wip driver? i'd like to have another test route.
[16:05] <ezequielg> hverkuil: well, you need controls for that, which means you need uapi changes.
[16:05] <hverkuil> so?
[16:05] <ezequielg> right
[16:05] <ezequielg> so you are suggesting to keep the controls, but drop the JPEG_RAW
[16:05] <hverkuil> yes
[16:05] <ezequielg> and i guess have some defaults
[16:05] <hverkuil> Mauro was opposed to JPEG_RAW, but not to the controls.
[16:06] <ezequielg> yes, that is true.
[16:06] <ezequielg> ok, so that's the only disadvantage to the approach I guess.
[16:06] <ezequielg> if we address that, it'd be cool.
[16:07] <hverkuil> You can also still support the request api to associate controls with specific frames. It would be optional (i.e. you don't need to use it).
[16:07] <ezequielg> we should be able to merge this, and discuss the extra controls as follow up patches.
[16:07] <hverkuil> vim2m is a good example of a driver with optional request support.
[16:08] <hverkuil> sure
[16:08] <ezequielg> and this makes me less concerned about the default tables.
[16:08] <ezequielg> thank you hverkuil, i got lost in translation :-)
[16:09] <hverkuil> no problem, glad to help!
[16:09] *** benjiG has left 
[16:11] <ezequielg> pH5: I have a wandboard sitting here. If we can have at least two platforms, it will make more sense to expose huffman and quantization controls.
[16:34] <pH5> ezequielg: sounds like a plan :)
[16:36] <pH5> I'll send a WIP driver next week.
[16:37] <pH5> default tables should come from JPEG ITU-T.81 (ISO/IEC 10918-1) Annex K.3, I suppose
[16:38] <pH5> although it is unclear to me how manually setting quantization tables should interact with the quality control
[16:41] <ezequielg> he, i was wondering _exactly_ the same.