[07:50] <sailus> hverkuil1: Do you have an opinion on the SPI sensor naming patch?
[07:50] <sailus> mchehab: ^
[07:50] <sailus> https://patchwork.linuxtv.org/patch/51329/
[07:52] <hverkuil> sailus: looks good to me.
[07:53] <CarlFK> yay, tv is back.  now I can get back to yack shaving.
[07:58] <javier__> sailus: it will also make it more consistent with v4l2_i2c_subdev_init() I think that uses "%s %d-%04x", driver->name, i2c_adapter_id, addr
[08:07] <sailus> Yes.
[08:07] <sailus> hverkuil: Does that count as an ack? :-)
[08:08] <sailus> I'm still waiting an indication from Samsung what do they prefer.
[08:10] *** benjiG has quit IRC (Quit: Leaving.)
[08:13] <mszyprow> sailus: I'm fine with such change
[08:13] <mszyprow> sailus: it will make logs a bit more easier to read
[08:17] <sailus> mszyprow: Could you ack the patch?
[10:26] <hverkuil> pH5: ping
[10:32] <pH5> hverkuil: hi
[10:35] <hverkuil> pH5: Was looking at your PXP v2 series, and I noticed that you still assume that userspace can specify the quantization range and YCbCr encoding for the capture side.
[10:35] <hverkuil> But without my RFC you cannot do that in the API. Did you forget to remove it?
[10:35] <hverkuil> or will there be a v3 with the RFC added to the series?
[10:36] <hverkuil> (which I would love to see, by the way!)
[10:45] <pH5> hverkuil: I'm overwriting both ycbcr_enc and quantization with defaults in try_fmt_vid_cap. So there are some currently unused csc2_coef_* coefficient sets in pxp_setup_csc(). Do you mean I should remove those?
[10:46] <pH5> I intend to pick up the RFC and add CSC support to both the PXP and the imx-media mem2mem driver, but I'd like to do that in a separate step.
[10:59] <pH5> hverkuil: why does your RFC say capture colorspace is ignored for non-Y'CbCr pixelformats? couldn't primaries be selectable for RGB formats as well?
[11:08] <hverkuil> pH5: sorry, meeting, back later
[11:28] <hverkuil> ycbcr_enc is ignored for non-Y'CbCr pixelformats. Y'CbCr encoding makes no sense if you're not in Y'CbCr format after all.
[11:29] <hverkuil> It's just that single field that is ignored, all the others are still valid.
[11:29] <hverkuil> and another meeting... :-(
[11:48] <pH5> ok, that makes sense to me
[12:06] *** larsc has quit IRC (Ping timeout: 240 seconds)
[12:14] <hverkuil> pH5: back
[12:15] <hverkuil> pH5: anyway, without the RFC the capture queue should copy colorspace and xfer_func from the output queue (it's doing that already), and set ycbcr_enc and quantization as follows:
[12:15] <hverkuil> - for RGB capture set ycbcr_enc to DEFAULT (it's ignored anyway) and quantization to FULL.
[12:16] <hverkuil> - for YUV capture set quantization to LIMITED and ycbcr_enc to 601 for resolutions <= SDTV (720x576) and to 709 for larger resolutions.
[12:17] <hverkuil> Just hardcoded, since that's all you can do.
[12:35] <hverkuil> pH5: I think it looks good after all. I had to wrap my head around to the fact that you let the colorspace decide which quantization/ycbcr_enc to use.
[12:42] <pH5> hverkuil: ok, thanks.
[12:42] <pH5> hverkuil: regarding the RFC, do you still think a single flag HAS_CSC is the way to go?
[12:44] <hverkuil> Not sure. An alternative that I thought of while re-reading the RFC is to have four flags: CAN_CONVERT_COLORSPACE/XFER_FUNC/YCBCR_ENC/QUANTIZATION.
[12:45] <hverkuil> I.e., which properties can the hardware convert.
[12:45] <hverkuil> Most can only do YCBCR_ENC/QUANTIZATION.
[12:46] <hverkuil> With a gamma table you can add XFER_FUNC and I never have seen any HW do COLORSPACE (aka colorimetry) conversion.
[12:47] <hverkuil> In any case, I think this would be more useful for userspace to detect the capabilities of the hardware.
[12:51] *** paul3741 has quit IRC (Ping timeout: 244 seconds)
[12:57] <pH5> hverkuil: I'll try that with the behavior you described (drivers set supported flags, userspace may clear any of them, all but flagged colorimetry values are ignored)
[12:58] <pH5> although I don't have any hardware with reasonable mem2mem gamma support currently.
[13:07] <hverkuil> pH5: no, I looked closer at your driver and it looks OK. I don't think you need to change anything.
[13:08] <hverkuil> It makes sense that if you pass in BT2020 RGB that you get BT2020 YCbCr with the ycbcr encoding valid for BT2020.
[13:34] <pH5> hverkuil: should there be a separate flag for ycbcr_enc and hsv_enc ?
[13:47] <hverkuil> pH5: no, I don't think so. This applies to the current pixelformat anyway, and if the format is HSV then it is obvious that the flag applies to HSV encoding, not Y'CbCr encoding.
[13:48] <hverkuil> But I think we should have two defines for the same flag, just as ycbcr_enc and hsv_enc are in a union.
[13:49] <hverkuil> Mostly because it is really, really weird to check a YCBCR_ENC flag when dealing with HSV.
[13:49] <pH5> yeah :) reasoning about colorimetry is hard enough as it is.
[13:49] <hverkuil> exactly.
[13:49] <hverkuil> It took me a long time before I really got the hang of this.
[14:05] *** bparrot has quit IRC (Remote host closed the connection)
[15:23] *** dmt has quit IRC (Remote host closed the connection)
[17:02] *** ao2 has quit IRC (Remote host closed the connection)
[17:21] *** _abbenormal has quit IRC (Quit: Leaving)
[21:09] *** andrey_utkin has quit IRC (Excess Flood)
[21:10] *** lyakh has quit IRC (Quit: thanks, bye)
[22:52] *** CarlFK has quit IRC (Ping timeout: 252 seconds)