[08:11] <prabhakarlad> sailus pinchartl: ping
[08:32] <hverkuil> prabhakarlad: ping
[08:32] <prabhakarlad> hverkuil: pong
[08:33] <hverkuil> prabhakarlad: does the rcar-vin have a scaler?
[08:34] <prabhakarlad> Yes it does support scaling.
[08:37] <hverkuil> So it will scale from the crop rectangle to the compose rectangle?
[08:37] <hverkuil> (just checking)
[08:42] <sailus> prabhakarlad: Pong.
[08:43] <prabhakarlad> hverkuil: let me dig through it, im not completely sure.
[08:46] <prabhakarlad> sailus: with the current fwnode parsing if an invalid bus-type (say 9) is passed in DT v4l2_fwnode_endpoint_alloc_parse(.bus_type = V4L2_MBUS_PARALLEL) returns success with bus-type set to V4L2_MBUS_PARALLEL. is this the expected behavior ?
[08:48] <sailus> prabhakarlad: Does it?
[08:49] <prabhakarlad> Yes :)
[08:49] <sailus> -ENXIO should be returned.
[08:50] <sailus> Looking at the code, that's what it seems to do.
[08:50] <sailus> But I haven't tested it for quite a while. :-)
[08:51] <sailus> The problem seems to be in v4l2_fwnode_bus_type_to_mbus().
[08:53] <sailus> We should add an invalid MBUS type and v4l2_fwnode_bus_type_to_mbus() should return that if there's no valid bus type.
[08:53] <sailus> Would you like to write a patch? :-)
[08:54] <prabhakarlad> Sure will do that :)
[08:55] <prabhakarlad> V4L2_MBUS_INVALID sounds good ?
[08:55] <sailus> Yeah.
[09:04] <prabhakarlad> hverkuil: Yes it does https://git.linuxtv.org/media_tree.git/tree/drivers/media/platform/rcar-vin/rcar-dma.c#n532
[09:05] <hverkuil> prabhakarlad: ok, good to know.
[09:10] <hverkuil> arnd: I looked at your proposed patch, and I really don't like how the compat code now pollutes the main v4l2-ioctl.c source.
[09:13] <hverkuil> This should remain as much as possible in v4l2-compat-ioctl32.c. The 32 bit structs can be added in a v4l2-compat-ioctl32.h header so v4l2-ioctl.c can include it, and helper functions can be placed in v4l2-compat-ioctl32.c.
[09:14] <hverkuil> So v4l2-ioctl.c can have the 'case's for the compat ioctls, but those should call helper functions from v4l2-compat-ioctl32.c instead of keeping it all in v4l2-ioctl.c.
[09:15] <arnd> hverkuil: ok, I'll try that then
[09:17] <hverkuil> arnd: I so wish I could step in a time machine and go back in time to tell the V4L2 designers about future 64 bit architectures :-)
[09:20] <arnd> hverkuil: the one part I can't figure out how to do yet is the v4l2_format32 conversion for V4L2_BUF_TYPE_VIDEO_OVERLAY, is there a reason why this one doesn't already get copied using check_array_args() ?
[09:20] <arnd> (the v4l2_clip array)
[09:23] <hverkuil> Probably because v4l2_clip has a different size for 32 vs 64 bit architectures, so you can't just copy it as an array.
[09:24] <hverkuil> The sad thing is that the 'next' 'pointer' is just discarded and never actually used.
[09:28] <arnd> hverkuil: I don't think the reason is compat mode, as that would be the same for the arrays in v4l2_buffer and v4l2_ext_controls
[09:40] <hverkuil> arnd: ah yes. Then I think it is simply that this already worked and nobody bothered to switch it over to check_array_args(). The check_array_args() function was created much, much later than the overlay support.
[09:40] <hverkuil> I have no objection to switch over to check_array_args() for overlays.
[09:41] <arnd> ok, thanks for confirming, now I just need to figure out which drivers actually access the v4l2_clip array
[09:43] <arnd> I suppose anything that implements either vidioc_g_fmt_vid_out_overlay or vidioc_g_fmt_vid_overlay
[09:48] <hverkuil> Yup. I count 7 drivers.
[09:51] <hverkuil> arnd: actually 8 drivers: drivers/staging/vc04_services/bcm2835-camera uses it as well.
[09:54] <arnd> hverkuil: what about users of vidioc_create_bufs? I see that the compat code does the conversion for those as well, but they all end up in vb2_ioctl_create_bufs, which does not support the overlay version
[09:54] <arnd> is that a coincidence or by design?
[09:56] <hverkuil> by design: overlays do not use buffers. Capture overlays write directly into a framebuffer, output overlays can be used to mix in a framebuffer (containing an OSD) into the output video signal.
[09:58] <arnd> ok, good, then VIDIOC_CREATE_BUFS32 compat support can be much simpler than it is today
[09:58] <hverkuil> For modern drivers this is never used, it's for old hardware only. I wish we could drop it altogether, but some of this HW is still in use, I'm pretty certain of that.
[13:54] *** kbingham has quit IRC (Ping timeout: 272 seconds)
[21:17] <arnd> hverkuil-: I've completed a first pass, with 9 files changed, 720 insertions(+), 1242 deletions(-)
[21:17] <arnd> have not tried compiling yet...