[08:49] <hverkuil> narmstrong: v2 of the cec driver looks good. Now it is just waiting for the bindings to be acked by Rob H.
[08:50] <narmstrong> hverkuil: cool, thanks :-)
[10:21] <hverkuil> ezequielg: koike: I'm combining Ezequiel's pixelformat helpers patch with Helen's vimc patch that depends on it. That way it is in use and I can make a pull request for it.
[10:22] <hverkuil> koike: I had to make a small modification to the vimc patch since v4l2_get_fourcc_name has been dropped from the pixelformat helpers patch since that needs more work.
[10:28] <pinchartl> hverkuil: did you see Maxime's patches for a 4CC library ?
[10:33] <bbrezillon> hverkuil, pinchartl: what's the strategy when TRY_FMT is passed incorrect params (like invalid num_planes)?
[10:35] <pinchartl> bbrezillon: in general, fix the parameters
[10:35] <pinchartl> but when they're clearly wrong
[10:35] <bbrezillon> so it's a driver decision
[10:35] <pinchartl> (such as an invalid buffer type or a num_planes value that doesn't match the 4CC)
[10:35] <pinchartl> you can return -EINVAL
[10:36] <bbrezillon> does work well with my v4l_ext_format_to_format() helper :-/
[10:36] <bbrezillon> *doesn't
[10:36] <hverkuil> pinchartl: yes, hope to review it this week.
[10:36] <pinchartl> an important point to note is that with the current API you may not return -EINVAL for invalid 4CCs or resolutions
[10:37] <pinchartl> (which raises the interesting question of how to handle a non-supported 4CC that, when fixed by the driver, would result in a different number of planes)
[10:38] <hverkuil> pinchartl: actually TRY_FMT can return -EINVAL for invalid 4CCs. It was never consistently implemented in drivers :-(
[10:39] <hverkuil> The spec says it shouldn't return EINVAL in that case, but historically many drivers didn't follow that rule, sadly.
[10:39] <pinchartl> hverkuil: *can* as in we have drivers that do so today, or as in it's a behaviour that should be encouraged ?
[10:39] <pinchartl> ok
[10:39] <pinchartl> so it's just that we have drivers departing from the spec
[10:40] <hverkuil> It seems mostly webcam drivers that return EINVAL, if memory serves.
[10:41] <hverkuil> Changing it will break the ABI for those drivers. v4l2-compliance gives a warning if this is detected.
[10:41] <bbrezillon> right now I have problems with the new modifier field and with num_planes
[10:41] <bbrezillon> which can be invalid when passed by the userspace prog and fixed by the driver
[10:42] <pinchartl> hverkuil: do you think there are applications relying on the fact that the driver returns -EINVAL for unsupported formats ?
[10:42] <bbrezillon> but for the EXT -> !EXT ioctl wrappers, I do the EXT fmt -> fmt conversion before passing the fmt struct to the driver
[10:42] <bbrezillon> and the conversion helper complains when invalid params are passed
[10:43] <bbrezillon> I'll add a 'bool strict' argument and let some invalid field pass through when strict=false
[10:44] <bbrezillon> but that's hard to tell which ones should be correct and which ones shouldn't
[10:46] <hverkuil> pinchartl: it was the other way around: webcam drivers choose a default pixelformat, non-webcam drivers are more likely to return -EINVAL for an invalid pixelformat.
[10:47] <pinchartl> ok
[10:50] <bbrezillon> ok, and it seems the same rule applies to S_FMT
[10:51] <bbrezillon> if some params are inaccurate they can be adjuste by the driver, right?
[10:51] <bbrezillon> *adjusted
[10:53] <hverkuil> bbrezillon: yes
[10:55] <hverkuil> I'm going to make v4l2-compliance more strict: TRY/S_FMT are only allowed to return -EINVAL for an invalid pixelformat in the case of V4L2_BUF_TYPE_VIDEO_CAPTURE.
[10:56] <bbrezillon> so, other invalid fields must be fixed by drivers?
[10:56] <hverkuil> yes
[10:56] <hverkuil> the compliance test checks for that already.
[11:13] *** prabhakarlad has left 
[11:31] <hverkuil> tfiga: ping
[11:54] <narmstrong> hverkuil: the compatible fix went in /dev/null, i need to resend :-/
[11:55] <hverkuil> ok
[11:58] <narmstrong> hverkuil: do you mind if I wait for Rob's bindings review and I'll resend it fixed ?
[11:58] <hverkuil> no problem.
[12:00] <hverkuil> hmm, isn't there a chance that Rob will complain about the same thing? I think it might be better to resend it now so Rob reviews the right version.
[12:01] <narmstrong> last time I did that, he reviewed the old version
[12:01] <hverkuil> ah :-)
[12:03] <narmstrong> I suppose we can wait 1w, we are only at rc3
[12:03] <hverkuil> certainly
[13:10] <ezequielg> hverkuil: ping
[13:10] <hverkuil> ezequielg: pong
[13:11] <ezequielg> I can submit a new pixel format series, adding a user.
[13:11] <ezequielg> if that helps.
[13:11] <hverkuil> not needed, I can use the vimc patch as a user.
[13:12] <ezequielg> ok, cool.
[14:14] <bbrezillon> pinchartl, hverkuil: hm, I'm not sure I understand how one can set the ->ycbcr_enc prop
[14:15] <bbrezillon> it seems that v4l_s_fmt() resets the field
[14:16] <bbrezillon> looks like testSetExtFormats() fails when placed after testSetFormats() when testM2MFormats() is run
[14:16] <bbrezillon> S_EXT(G_EXT) != G_EXT
[14:18] <bbrezillon> and the problem comes from the ->ycbcr_env fields which is set to 1 by testM2MFormats, and suddenly becomes 0 when I do S_EXT_FMT(G_EXT_FMT)
[14:52] <bbrezillon> hverkuil, pinchartl: nevermind, it was just a missing priv = V4L2_PIX_FMT_PRIV_MAGIC in the ext_format_to_fomat() helper
[15:25] *** benjiG has left 
[18:27] <lifeofguenter> hi all :) - I am having issues with my webcam (logitech c310) - the video is vertically flipped. Running "LIBV4LCONTROL_FLAGS=1 LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libv4l/v4l1compat.so cheese" fixes the issue but the webcam is performing poor and I am not sure how I can get this to work "globally"
[18:27] <lifeofguenter> is there any way I can "sponsor" a fix?
[18:40] <lifeofguenter> hmm actually seems to be an issue with cheese + firefox (webrtc) - works well with guvcview + zoom.us