pinchartl: Hi
ttomov: hi
I have received the long-awaited ack for ov5645 device tree binding
could you please include this in a pull request the next time you do it?
I'm not sure I will send more pull request for v4l2
s/request/requests/
ok
hverkuil: can I ask you the same? :)
I need to make a decision in the next couple of days at the latest, I'll let you know
ok
one more question pinchartl :) could you confirm that my understanding is correct:
(or reject :))
on a subdev which supports resizing (no crop) the resize ratio is defined by the ratio of the sink pad format size and sink pad actual compose selection. Source pad format size must always match the sink pad actual compose selection size.
ttomov: going to work, will be back here in 30-40 minutes.
ok, np
ttomov: that's would work, but if your subdev doesn't support composition, I wonder whether this isn't a bit overcomplicated
it would be simpler in that case to not support any selection rectangle
and configure scaling using the sink and source formats only
but that option is not explicitly described in the API documentation
the omap3isp driver implements scaling that way
yes, I agree it would be simpler with sink and source formats only, I just didn't find this in the documentation
ok, so I'll try to make it simpler then
thank you
ttomov: feel free to propose a documentation patch to clarify that
ok
We have drivers implementing a little bit different behaviour there.
And sometimes we need more sub-devices because the current model isn't flexible enough.
I guess it's ok to use the formats for that only. It's perhaps not really neat but quite practical and I don't see any harm in doing so.
ttomov: I can take the ov5645. Just to prevent any confusion: your resizing question has nothing to do with the ov5645 patch series, right?
It would be strange if that's the case, but I dropped in the middle of this discussion, so I'd better make sure.
hverkuil: yes, the resizer question concerns another driver
thank you hverkuil
ttomov: did a quick scan of the ov5645 driver and I saw that ov5645_subdev_internal_ops is empty. Why add it then? Am I missing something?
hverkuil: hm, I also cannot find a reason to keep it. It is left from a previous version. We have to remove it. Should I resend?
ttomov: please do! I'll take it today/tomorrow. Not sure if it is in time for 4.12, it's borderline.
ok, in this case do I have to remove reviewed-by and acked-by tags because of the change
it's trivial but technically...
No need for that. Keep the tags, we're not talking a redesign after all, just removing dead code.
ok, this is good
hverkuil, I see some regression in qv4l2, version 1.10, on scaled down window, the shaders suffer some lost of precision that looks like: http://imgur.com/a/Su4Tr
unscaled, it looks fine though
(unless this is a mesa/intel regression)
pinchartl: quick vsp1 question: the two HGO controls will modify the layout of the metadata, correct? But did it also modify the size? If I remember correctly it was possible to change these controls while streaming, so I presume the size of the metadata buffers was chosen such that it can handle up to the maximum size.
ndufresne: scaled down by how much?
I can't remember seeing something like that before.
hverkuil, no idea, compositor doing, but it does that a various scaled down factors
it's 1080p input
what gpu is used?
I mean the capture interface is setup at 1080p, pixel format is NV12
GPU is an Intel Ivybridge
this laptop is a x230
so well known, nothing special, also works in gst
hverkuil, another info, it's clean with YUYV
how well tested is NV12 ?
hverkuil: they modify the layout and the size, but the driver allocates buffers for the largest size anyway, as they all fit in one page
hverkuil, YV12 is clean too
ndufresne:  Do you see the same with vivid as the source? NV12 should work.
looks specific to a pixel format
I don't have vivid installed atm
pinchartl: good, then my memory was actually correct for once :-)
hverkuil, at the same time, same scale down with gst shaders is clean, + the console text on the left looks better
hverkuil, how do you configure you sampler ?
(weston shader are clean too apparently)
It's qv4l2 that is scaling down, right? Just making sure of that.
hverkuil, shaders are effected by the scaling of the window
specially if you have a coordinate precision error
Ah, reproduced trivially with vivid.
hverkuil: thanks :)
ndufresne: I'm not sure what I can do. I'm no opengl hero. The code is in utils/qv4l2/capture-win-gl.cpp, if you are interested. Just search for NV12.
I'm just reporting right now, I'm not a GL hero either
Interesting: I was looking at setting V4L2_CTRL_FLAG_GRABBED for controls that cannot be set when buffers are allocated. While it is easy to do this in queue_setup, it turns out there is no equivalent queue_exit op where you can 'ungrab'. Since the only control that needs this is the rotate control, and no one ever used the GRABBED flag there, this will take a bit more effort to implement.
I can't use stop_streaming, since you can allocate buffers, then free them without ever calling STREAMON.