<!-- Some styling for better description lists --><style type='text/css'>dt { font-weight: bold;float: left;display:inline;margin-right: 1em} dd { display:block; margin-left: 2em}</style>

   hverkuil: <u>ribalda</u>: pong
   ribalda: I have a question regarding https://linuxtv.org/downloads/v4l-dvb-apis/uapi/v4l/v4l2-selection-targets.html
   <br> why subdev are not allowed to have default areas?
   <br> I have a sensor with a blanking area and i want to be able to select as default the active pixels, and the bound all the pixels including the blanking area
   hverkuil: <u>ribalda</u>: I'm not really sure. sailus, pinchartl: any idea? This sounds like a reasonable use-case to me.
   sailus: <u>ribalda</u>: What do you mena by a "blanking area"?
   <br> Some sensors have black pixels and whatever (which we don't support right now).
   ribalda: optical banking. Pixels that are painted in bback
   sailus: Right.
   ribalda: the only thing that we need to do is allow default_area on the selection target
   <br> I use the black pixels for calibration. it helps you setting the optimal analog offset.
   sailus: I think we'd need to be able to define an API to access the order of the selection rectangles.
   <br> A reasonable default may not help much apart from the initial state of the sensor.
   ribalda: as I understand it, default = active pixels, bound= active pixels + black pixels
   sailus: You may not be able to crop the black pixels in a single crop operations, for instance, or you need to crop in a particular place in a sensor.
   ribalda: usually you read the whole image(active+balck), do you calibration magic and then configure the sensor to only output active
   sailus: This default approach might work if you have a simplistic sensor driver based on register lists, and never need more than that.
   <br> Most drivers are like that; the sensor datasheet often doesn't provide enough information to do more.
   ribalda: any idea why the selection targets is different for v4l2 and v4l2_subdev? as in https://linuxtv.org/downloads/v4l-dvb-apis/uapi/v4l/v4l2-selection-targets.html
   <br> because if they where the same I would not have any issues.
   <br> :)
   sailus: The default existed for some particular devices where the usual size for a given device not necessarily the maximum resolution.
   ribalda: and why we dont support it for subdevs?
   sailus: That was usually device specific, but for sub-device drivers this configuration either comes from the user space (pipeline) or the bridge.
   <br> Because a sensor can be mounted pretty much anywhere.
   <br> I'd propose to add a new selection target if you want to support this properly.
   <br> Even better would be to add an API to convey the order of these rectangles in hardware, and allow multiple with same ID for a given pad.
   <br> But I guess that could be left for later, too.
   ribalda: and the target would be active + blank? blank?
   <br> because for me active + blank = bound, or at least this is how I have always understood it
   sailus: The API does not cover black pixels at the moment.
   <br> Few would ever want to capture them.
   <br> I wonder if we could change the definition of the CROP_BOUNDS target in such a way that it only covers visible pixels.
   <br> Or add a new one for this.
   <br> But the applications generally are interested in visible pixels, very seldom in black pixels.
   <br> And, there's NATIVE_SIZE, too.
   <br> Hmm.
   ribalda: and the crop_bounds_no_black that you propose, how will it differ the _DEFAULT ?
   sailus: There's no device specific default for sub-devices at the moment.
   <br> The default is really a suggested configuration for a given device (say, a USB camera).
   <br> Whereas other resolutions are still expected to produce fine images.
   <br> In your case you have black pixels on the sensor.
   <br> That's clearly a different case.
   <br> Are you interested in capturing those black pixels btw.? :-)
   ribalda: so prehaps adding something like V4L2_SEL_TGT_COMPOSE_ACTIVE_ONLY ?
   <br> for v4l2 and subdevs?
   sailus: How about adding a target called CROP_VISIBLE?
   <br> That doesn't help changing existing users though, to push them only using visible pixels.
   <br> Hmm.
   <br> I guess we'd need to re-purpose the BOUNDS target.
   ribalda: I could prepare a mail for linux-media, with all the different options.
   <br> also Daniel, a colleage of mine will come to Lyon
   <br> maybe is better to discuss it in person
   <br> (I have to take care of the new baby during ELCE :( )
   sailus: I won't be in Lyon either.
   <br> Looking at the selection target documentation, the default traget is documented as q{Suggested cropping rectangle that covers the “whole picture”.}.
   <br> The word "picture" here is crucial indeed.
   <br> Oh well, considering this, I think we could just change that "No" to "Yes".
   hverkuil: The DEFAULT crop is typically used by SDTV receivers where the video receiver can receive more than the actual active video area. E.g. it can receive 768x488, but the default crop is 720x480@24x8.
   sailus: What's outside the croped area?
   hverkuil: Usually blanking (vertical/horizontal)
   sailus: I think that fits, too.
   hverkuil: but in some cases video might actually be shifted so you can move the crop around to hit the full video area.
   sailus: :-)
   <br> That won't happen on sensors.
   hverkuil: No, this is specific for analog SDTV video receivers.
   <br> which is where v4l2 originates.
   sailus: <u>ribalda</u>: So I agree with your original proposal after all.
   <br> On cameras someone might want to capture that data after all, so allowing capturing it makes sense.
   ribalda: <u>hverkuil</u>: sailus: can I send a patch to fix the documentation then? and also to fix v4l2-compliance?
   hverkuil: <u>ribalda</u>: what was the result of the discussion between you and Sakari? Sorry, I was busy with other things and didn't follow it.
   ribalda: I think we agreed on the original proposal: allow default on subdev
   <br> <u>sailus</u>: am I right? or I missunderstood you?
   sailus: <u>ribalda</u>: Please send a patch.