headless: ah, that's docbook... it was already removed upstream (for Kernel 4.12)
you can instruct the building system to not build the docbook PDFs with:
make DOCBOOKS="" pdfdocs
this way, it will build just the ReST books
What I actually use here is:
$ make DOCBOOKS="" SPHINXDIRS=media SPHINXOPTS="-j5" htmldocs
(or pdfdocs)
to build just the media book
mchehab: ah! thanx
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) ?
koike: Is that on sub-devices?
sailus: both I think
https://linuxtv.org/downloads/v4l-dvb-apis/uapi/v4l/dev-subdev.html
Your driver probably should use either or.
But not both.
That wouldn't make much sense.
sailus: I am not implementing it, I am just trying to understand
Ah.
for a capture device, is I use the selection api, what setting the size of the image with S_FMT means?
The selection API was added to replace the CROP API on V4L2 devices.
For use without Media controller, where the device has a simple data path and can be meaningfully controlled through a single video node.
But it could still support e.g. scaling.
A similar interface is used on sub-devices to access the same selection rectangles, while allowing a more complex data path.
Or, device specific data paths.
Please see "4.15.3.4. Order of configuration and format propagation" in that link.
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?
I think we could have hidden that less well. :-)
S_FMT only affects them if you have an OUTPUT device.
Or, a sink pad.
For source pads the size is propagated to the previous selection rectangle supported by the device.
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 ?
s/I/driver
There's no direct dependency between the configured format on the video node and the sub-devices.
When the streaming is started, the formats need to match.
Otherwise they're essentially separate.
suppose we don't have any subd-device, I just want to know for a capture video device
For S_FMT, the width and height come from the selection on CAPTURE devices.
I have to admit I have never used the selection API on video devices.
This should be documented. Maybe it is. Or maybe it isn't.
https://linuxtv.org/downloads/v4l-dvb-apis/uapi/v4l/selection-api-004.html
I already read this and it doesn't answer my question :(
Hmm.
I think S_FMT afects the _BOUNDS rectangle, but it is not clear
koike: S_FMT defines the format of the memory buffer you capture the video into.
Changing that format will reset the selection compose rectangles to that of the new format.
Actually, it's a bit more complicated than that.
vivid_s_fmt_vid_cap implements all possible combinations.
My statement above is true is the hardware cannot scale and cannot compose (i.e. DMA to a rectangle within a larger memory buffer)
is the -> if the
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 ?
If the hardware can scale/compose, then the existing compose rectangle is constrained within the new format.
right.
hverkuil: I think I understand now, thanks
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.
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.
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)
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
maybe I could use the selection api in the vimc scaler subdevice node
instead of scaling only for a hardcoded factor
pad_ops: get/set_selection
Yes, I find it also annoying that sometimes ops are written as g_/s_, and sometimes as get_/set_. I prefer the first.
hverkuil: oh, sorry, I was looking at the wrong place, thanks
hverkuil: do you think this can merged in 4.13 https://patchwork.kernel.org/patch/9716289/
svarbanov: I need to follow-up on those. Haven't had time.
Feel free to add your Ack, though!
it would be welcome
hverkuil: ok, I will test it first
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/?
hverkuil: Sure. A little bit later today.
hverkuil: Replied.
thanks!