[11:21] <mchehab> headless: ah, that's docbook... it was already removed upstream (for Kernel 4.12)
[11:21] <mchehab> you can instruct the building system to not build the docbook PDFs with:
[11:22] <mchehab> make DOCBOOKS="" pdfdocs
[11:22] <mchehab> this way, it will build just the ReST books
[11:23] <mchehab> What I actually use here is:
[11:23] <mchehab> $ make DOCBOOKS="" SPHINXDIRS=media SPHINXOPTS="-j5" htmldocs
[11:23] <mchehab> (or pdfdocs)
[11:23] <mchehab> to build just the media book
[11:28] <headless> mchehab: ah! thanx
[11:37] <koike> Hi o/, question: I am checking about the targets of the Selection API (https://linuxtv.org/downloads/v4l-dvb-apis-new/uapi/v4l/v4l2-selection-targets.html) and I was wondering, which rectangle does the VIDIOC_S_FMT affects ? V4L2_SEL_TGT_COMPOSE_BOUNDS (for capture dev) ?
[11:52] <sailus> koike: Is that on sub-devices?
[11:52] <koike> sailus: both I think
[11:52] <sailus> https://linuxtv.org/downloads/v4l-dvb-apis/uapi/v4l/dev-subdev.html
[11:53] <sailus> Your driver probably should use either or.
[11:53] <sailus> But not both.
[11:53] <sailus> That wouldn't make much sense.
[11:53] <koike> sailus: I am not implementing it, I am just trying to understand
[11:53] <sailus> Ah.
[11:54] <koike> for a capture device, is I use the selection api, what setting the size of the image with S_FMT means?
[11:54] <sailus> The selection API was added to replace the CROP API on V4L2 devices.
[11:54] <sailus> For use without Media controller, where the device has a simple data path and can be meaningfully controlled through a single video node.
[11:54] <sailus> But it could still support e.g. scaling.
[11:55] <sailus> A similar interface is used on sub-devices to access the same selection rectangles, while allowing a more complex data path.
[11:55] <sailus> Or, device specific data paths.
[11:55] <sailus> Please see "4.15.3.4. Order of configuration and format propagation" in that link.
[11:56] <koike> yes, but in the selection API I can set the size of the rectangles right ({CROP,COMPOSE}_BOUND, ACTIVE, DEFAULT), but which rectangle S_FMT affects?
[11:56] <sailus> I think we could have hidden that less well. :-)
[11:56] <sailus> S_FMT only affects them if you have an OUTPUT device.
[11:56] <sailus> Or, a sink pad.
[11:57] <sailus> For source pads the size is propagated to the previous selection rectangle supported by the device.
[11:59] <koike> sailus: In a capture device for example, I can use VIDIOC_S_FMT to set colorimetry and other fields. You mean that I should ignore the width/height used in VIDIOC_S_FMT and only used the one from VIDIOC_S_SELECTION ?
[11:59] <koike> s/I/driver
[12:02] <sailus> There's no direct dependency between the configured format on the video node and the sub-devices.
[12:03] <sailus> When the streaming is started, the formats need to match.
[12:03] <sailus> Otherwise they're essentially separate.
[12:03] <koike> suppose we don't have any subd-device, I just want to know for a capture video device
[12:03] <sailus> For S_FMT, the width and height come from the selection on CAPTURE devices.
[12:04] <sailus> I have to admit I have never used the selection API on video devices.
[12:04] <sailus> This should be documented. Maybe it is. Or maybe it isn't.
[12:05] <sailus> https://linuxtv.org/downloads/v4l-dvb-apis/uapi/v4l/selection-api-004.html
[12:05] <koike> I already read this and it doesn't answer my question :(
[12:06] <sailus> Hmm.
[12:06] <koike> I think S_FMT afects the _BOUNDS rectangle, but it is not clear
[12:08] <hverkuil> koike: S_FMT defines the format of the memory buffer you capture the video into.
[12:09] <hverkuil> Changing that format will reset the selection compose rectangles to that of the new format.
[12:09] <hverkuil> Actually, it's a bit more complicated than that.
[12:10] <hverkuil> vivid_s_fmt_vid_cap implements all possible combinations.
[12:11] <hverkuil> My statement above is true is the hardware cannot scale and cannot compose (i.e. DMA to a rectangle within a larger memory buffer)
[12:11] <hverkuil> is the -> if the
[12:12] <koike> hverkuil: so changing the the width/height through S_FMT will make the driver to adjust the active sink (in case of capture device) rectangle to a size that fits in the memory buffer ?
[12:12] <hverkuil> If the hardware can scale/compose, then the existing compose rectangle is constrained within the new format.
[12:12] <hverkuil> right.
[12:13] <koike> hverkuil: I think I understand now, thanks
[12:14] <hverkuil> The rule of thumb is that the last called ioctl take precedence. It will try to keep the settings of previous ioctls if it can, or modify them otherwise.
[12:15] <hverkuil> In vimc the video node doesn't crop, scale or compose, so I don't think you need to implement the selection API at all in the video node.
[12:17] <koike> hverkuil: yes, I don't think I need. I am just reading the API to improve my understanding as a whole (and see if there is anything I could add in vimc of course)
[12:18] <koike> hverkuil: I see that I can use the selection api in a subdevice, but I didn't find the ops in struct v4l2_subdev_ops to implement those
[12:20] <koike> maybe I could use the selection api in the vimc scaler subdevice node
[12:20] <koike> instead of scaling only for a hardcoded factor
[12:21] <hverkuil> pad_ops: get/set_selection
[12:22] <hverkuil> Yes, I find it also annoying that sometimes ops are written as g_/s_, and sometimes as get_/set_. I prefer the first.
[12:22] <koike> hverkuil: oh, sorry, I was looking at the wrong place, thanks
[12:25] <svarbanov> hverkuil: do you think this can merged in 4.13 https://patchwork.kernel.org/patch/9716289/
[12:26] <hverkuil> svarbanov: I need to follow-up on those. Haven't had time.
[12:26] <hverkuil> Feel free to add your Ack, though!
[12:26] <hverkuil> it would be welcome
[12:26] <svarbanov> hverkuil: ok, I will test it first
[12:27] <hverkuil> sailus: no time like the present: can you take a look at https://patchwork.kernel.org/patch/9716289/ and https://patchwork.kernel.org/patch/9716291/?
[12:31] <sailus> hverkuil: Sure. A little bit later today.
[13:09] <sailus> hverkuil: Replied.
[13:09] <hverkuil> thanks!
[14:42] *** benjiG has left 
[17:01] *** prabhakarlad has left 
[20:45] * headless has successfully converted from .rst to .html
[23:38] *** gouchi has quit IRC (Remote host closed the connection)
[23:41] *** shuah has quit IRC (Read error: Connection reset by peer)
[23:58] *** DaRock has quit IRC (Read error: Connection reset by peer)