Hi, any idea how to get lower bound crop rectangles ? As far as I can see, V4L2_SEL_TGT_CROP_BOUNDS only reports the maximum ?
uajain: set the rectangle to 1x1 and see what the device returns
ah..
pinchartl: I wonder if we could implement the crop bounds in V4L2 core by just trying to set the rectangle as large as possible. That would save driver code.
All drivers should implement CROP_BOUNDS after all if they do support CROP, right?
sailus: that could be a good idea. for sensor drivers, however, I think we need even better
I'd like the drivers to fill a structure with static data
and a core helper would handle most of the runtime behaviour
pinchartl: Depending on which crop rectangle is in question, its size may not be static.
I guess the driver could update the data given to the framework though.
I envision one helper for "sensor model"
Sounds reasonable.
sailus: hverkuil: pisp-be not over yet. I have a BIT() entry in the uAPI header. Should I send a patch on top or a v12 ?
jmondi: It's in media stage master so I'd say "yes, please".
sailus: on its way
I'm not really extremely concerned of individual patches as long as in the end the fix is applied on top.
can I reference the commit in media stage for a Fixes tag, or will it change when applied to Linus' tree ?
*the commit id
re-thinking about it, probably a Fixes is not even required if both patches land in the same kernel version
jmondi: the first ocmmit could be backported, in which case the fix should be backported too. adding Fixes: helps with that
can I reference the commit in media stage for a Fixes tag, or will it change when applied to Linus' tree ?
jmondi: I believe you can, as long as the staging tree isn't rebased, which is what we try to avoid.
ok then!
mchehab_, syoung: I've had a series ready (with Acks & Reviews) for about 7 weeks, patchwork says "Delegated to: Stanimir Varbanov". Do I need to see with him?
https://patchwork.linuxtv.org/project/linux-media/patch/eb15a48b-6185-42dd-92ca-8df33b0ea4b5@freebox.fr/