[11:01] <sailus> hverkuil: Would you use four controls or a single array control to pass four analogue gain factors to user space?
[11:07] <hverkuil> sailus: I'd use four controls. Simple integer controls are easier to handle than array/compound controls.
[11:11] <sailus> hverkuil: That's true indeed.
[11:11] <hverkuil> sailus: I looked up the formula used for analogue gain, and I'd definitely use four controls for this.
[11:11] <sailus> Ack.
[11:12] <sailus> hverkuil: Thanks!
[13:01] <ezequielg> hverkuil: good morning! how do you feel about having a VIDEO_V4L2_UNSTABLE_STATELESS config, and then destage all the drivers, supporting h264 only? The rest of the codecs would be protected by that VIDEO_V4L2_UNSTABLE_STATELESS config.
[13:11] <hverkuil> ezequielg: I feel a bit uncomfortable about this. What is the status w.r.t. the uAPI work for other codecs? MPEG is in progress, is anything in the pipeline for VP8?
[13:11] <hverkuil> and HEVC?
[13:11] <ezequielg> HEVC and VP9 are the problems.
[13:11] <ezequielg> mostly HEVC.
[13:12] <hverkuil> So VP8 and MPEG are close?
[13:12] <ezequielg> So, MPEG-2 and VP8 should be done.
[13:12] <ezequielg> VP8 is done and MPEG-2 cleanup patches are ready.
[13:13] <hverkuil> VP8 is done? Were patches posted for that?
[13:13] <ezequielg> No, it was already good.
[13:14] <ezequielg> Cedrus and MTK IIRC have confirmed they don't need uAPI changes, and I reviewed the uAPI.
[13:14] <ezequielg> It looks good as it is.
[13:14] <ezequielg> (except header comments, and stuff like that, but nothing that breaks the API)
[13:15] <hverkuil> OK, but it's still only defined in vp8-ctrls.h, so it should all be moved to the include/uapi.
[13:15] <ezequielg> Oh, yes.
[13:15] <ezequielg> But it's not blocked, that's my point.
[13:15] <hverkuil> Right.
[13:15] <ezequielg> As opposed to VP9 and HEVC, mostly HEVC, which need more work.
[13:16] <hverkuil> In any case, I prefer to postpone adding a new config for this until mpeg-2 and VP8 are finalized.
[13:17] <hverkuil> But I'd like to have mchehab's opinion as well.
[13:17] <ezequielg> My motivation for getting the drivers out, is that developers are impressed by staging  drivers. Over and over I've heard reluctancy from using these codecs on the basis of "staging quality".
[13:19] <mchehab> VIDEO_V4L2_UNSTABLE_STATELESS config seems really ugly
[13:20] <mchehab> what are the problems with those codecs?
[13:21] <ezequielg> The uAPI controls are not stable, so not part of the public uAPI.
[13:21] <mchehab> ezequielg if you want to move them out of staging, can't the codec part for the "unstable" ones remain on staging?
[13:21] <ezequielg> but people would be selecting a non staged driver, and would they expect backwards compatibility?
[13:22] <mchehab> ezequielg, once they got moved to be out of staging, the uAPI will be set into a stone, no matter if they're behind a Kconfig option or ont
[13:22] <ezequielg> once we fix the uAPIs, the legacy uAPI are simply droped. As they are explicitly "staging".
[13:23] <mchehab> in summary, only stuff under drivers/staging are allowed to have API changes (and even those might generate some noise if the API gets broken)
[13:24] <mchehab> everything else should remain backward compatible if API ever changes
[13:24] <ezequielg> OK, then.
[13:24] <ezequielg> No moving :-)
[13:24] <hverkuil> Hmm, how about putting a Kconfig in staging/media that has: VIDEO_V4L2_UNSTABLE_VP9 and _HEVC? Then the mainline drivers would use that to enable/disable the VP9 and HEVC bits if unset.
[13:24] <mchehab> ls
[13:25] <mchehab> hverkuil: I don't think this would be acceptable, but this is something that has to be disucussed with Linus
[13:25] <mchehab> c/c LKML
[13:26] <mchehab> and with Greg
[13:26] <hverkuil> An alternative is to clearly state in the staging Kconfigs that H264, MPEG-2 and VP8 are stable uAPIs, but not VP9 and HEVC, and also mention that in the TODOs.
[13:27] <ezequielg> FWIW, the only thing that has impact is moving things out
[13:27] <mchehab> I don't have any objection to that
[13:27] <mchehab> anything can be added at staging/*/TODO ;-)
[13:28] <ezequielg> So, I don't want to add more staging uAPIs, unless we really don't have enough information, and we are forced to.
[13:29] <ezequielg> Which means, I really don't want VP9 to go to staging. We have enough information for that one, so we are in a position to aim to regular uAPI.
[13:29] <mchehab> ezequielg, the entire concept of "staging uAPI" is something that doesn't have any official support
[13:29] <ezequielg> yeah.
[13:29] <ezequielg> then better not raise lkml eyebrows!
[13:29] <mchehab> agreed
[13:30] <ezequielg> with VP8, MPEG-2 and H.264 in very good shape, I'd say we can avoid staging uAPIs now.
[13:30] <ezequielg> I'll see if I can revisit HEVC this summer.
[13:30] <ezequielg> (my summe :)
[13:30] <ezequielg> *summer
[13:30] * mchehab is envy of your summer :-p
[13:31] <ezequielg> oh, thought we shared summers... you escaped this southern region?
[13:31] <mchehab> I miss a lot the sunlight during winter days
[13:32] <mchehab> ezequielg, yeah, I'm working abroad those days
[13:32] <ezequielg> well, I'm eny of your abroadness.
[13:34] <mchehab> well, in 2020 it doesn't matter much where you are... people need to avoid going to public spaces whenever you are
[13:35] <mchehab> well, in 2020 it doesn't matter much where you are... people need to avoid going to public spaces, *no matter where* you are
[13:35] <mchehab> (I guess whenever is not the proper word here ;-) )
[13:37] <mchehab> (the right word would likely be "wherever" - I guess)
[13:40] <hverkuil> pinchartl: finished reviewing the "media: Add new pixel formats for Xilinx v-frmbuf" series.
[13:52] <robertfoss> sailus:  I have some issues with the ov8856 sensor driver, and the modes it lists. all of them are invalid according to the datasheet (which I now have access to)
[13:53] <robertfoss> sailus: only the latest mode I submittedd a patch for seems to be correct (the register configuration for this mode may still be incorrect)
[13:54] <robertfoss> sailus: I tried to get a hold of Ben Kao to ask about these seemingly bad modes, since he wrote most of the drivers
[13:55] <robertfoss> sailus: Anyway, I just wanted to ask if you know anything more about this. Like what it tested using.
[13:56] <sailus> robertfoss: What makes you believe these modes are bad?
[13:57] <robertfoss> sailus: they're not listed in the datasheet, and at least one of them seems to configure the sensor to ouput using a different resolution than the stated one
[13:57] <pinchartl> hverkuil: thank you !
[13:58] <sailus> robertfoss: In general sensors aren't limited to specific configurations listed in datasheets, they're usually only examples.
[13:59] <robertfoss> sailus: I see
[13:59] <robertfoss> sailus: the listed mode resulting in a different resolution output still sounds bad to me
[14:00] <sailus> Why?
[14:02] <robertfoss> sailus: if i configure a v4l pipeline to use a specific mode, and the sensor disregards the resolution that has been picked, I end up with a distorted output
[14:02] <sailus> Ah.
[14:02] <sailus> Is the advertised size different from what the device actually outputs?
[14:02] <robertfoss> yeah, exactly
[14:02] <sailus> Ouch.
[14:04] <robertfoss> seeing that made have a look at the datasheet. the highest resolution listed in the driver is higher than the maximum resolution listed in the datasheet
[14:05] <robertfoss> As for the other modes, I haven't tested them, but since I didnt find them in the DS I figured I better ask someone about this
[14:07] <sailus> If you think there's a bug there and you have a fix, please cc Dongchun (in MAINTAINERS) as well.
[14:07] <sailus> And me naturally. :-)
[14:08] <robertfoss> Maybe I'll submit a quick patch disabling the impossibly high res mode now, and try to test the lower resolution modes
[14:11] <sailus> I think it'd be better to fix it than disable it.
[14:12] <andrey-konovalov> sailus, robertfoss: the datasheet says 3264x2448 active pixels, and the highest resolution in the driver robertfoss mentioned is 3280x2464. Like 16 dummy pixels (out of 32 total) and 16 dummy lines (out of 32 total) were added (?)
[14:12] <andrey-konovalov> (Could it have any sense?)
[14:14] <robertfoss> I don't know, I'm not super familiar with sensor behavior
[14:19] <pinchartl> andrey-konovalov: it's common to have a few (2-4-8-16) additional pixels on all sides that can be read out, in addition to the "nominal" resolution
[14:20] <pinchartl> "active pixels" is a bad term for the nominal resolution, as those extra pixels are active too
[14:20] <pinchartl> they're "just" not guaranteed to have the same quality as the other ones, they can suffer from edge-related effects
[14:21] <pinchartl> but it can be useful to read them out, as ISPs also often consume a few lines and columns on all sides for different image processing steps
[14:21] <pinchartl> for instance color interpolation (a.k.a. debayering) will often consume 2, 4 or 8 pixels on all sides
[14:23] <andrey-konovalov> pinchartl: "active pixels" is just how the datasheet calls them. From it I can't see the difference between active and dummy pixels like you've said.
[14:23] <pinchartl> different vendors use different terms, and a single vendor can use different terms in different datasheets too. it's messy
[14:23] <andrey-konovalov> Right, having some extra pixels at the boundaries would really help on debayering