lkml.org 
[lkml]   [2020]   [Aug]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH] media: rcar-vin: Update crop and compose settings for every s_fmt call
    From
    Date
    On 03/08/2020 21:21, Niklas wrote:
    > Hi Lad, Hans,
    >
    > On 2020-08-03 19:11:32 +0100, Lad, Prabhakar wrote:
    >> Hi Hans,
    >>
    >> On Sat, Aug 1, 2020 at 10:04 AM Niklas <niklas.soderlund@ragnatech.se> wrote:
    >>>
    >>> Hi Lad,
    >>>
    >>> Thanks for your work.
    >>>
    >>> On 2020-07-31 10:29:05 +0100, Lad Prabhakar wrote:
    >>>> The crop and compose settings for VIN in non mc mode werent updated
    >>>> in s_fmt call this resulted in captured images being clipped.
    >>>>
    >>>> With the below sequence on the third capture where size is set to
    >>>> 640x480 resulted in clipped image of size 320x240.
    >>>>
    >>>> high(640x480) -> low (320x240) -> high (640x480)
    >>>>
    >>>> This patch makes sure the VIN crop and compose settings are updated.
    >>>
    >>> This is clearly an inconsistency in the VIN driver that should be fixed.
    >>> But I think the none-mc mode implements the correct behavior. That is
    >>> that S_FMT should not modify the crop/compose rectangles other then make
    >>> sure they don't go out of bounds. This is an area we tried to clarify in
    >>> the past but I'm still not sure what the correct answer to.
    >>>
    >> What should be the exact behaviour of the bridge driver for s_fmt
    >> call. Should the crop/compose settings be updated for every s_fmt
    >> callback or should they be only updated on s_selection callback.
    >> Currently the non-mc rcar-vin doesnt update the crop/compose setting
    >> in s_fmt callback due to which I see the above issue as mentioned.
    >
    > This is not entirely correct. It does update the crop and compose
    > rectangles on s_fmt, it makes sure they are not out-of-bounds for the
    > new format if it's accepted by s_fmt. See v4l2_rect_map_inside() calls
    > in the snippet bellow.

    For non-mc mode s_fmt must update any crop/compose rectangles to ensure that
    they are not out-of-bounds. But for mc mode the validation is done when you
    start streaming, so I think s_fmt won't make any changes in that mode.

    Double-check that with Laurent, though...

    Regards,

    Hans

    >
    > That being said there is a difference how this is handled in the VIN
    > driver between it's MC and non-MC modes and I would love to learn the
    > correct mode of operation and seeing VIN being updated to doing it
    > correct in both cases. Thanks Lad for dealing with this!
    >
    >>
    >> Cheers,
    >> Prabhakar
    >>
    >>>>
    >>>> Fixes: 104464f573d ("media: rcar-vin: Do not reset the crop and compose rectangles in s_fmt")
    >>>> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
    >>>> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com>
    >>>> ---
    >>>> drivers/media/platform/rcar-vin/rcar-v4l2.c | 6 ++++++
    >>>> 1 file changed, 6 insertions(+)
    >>>>
    >>>> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c b/drivers/media/platform/rcar-vin/rcar-v4l2.c
    >>>> index f421e25..a9b13d9 100644
    >>>> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
    >>>> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
    >>>> @@ -319,6 +319,12 @@ static int rvin_s_fmt_vid_cap(struct file *file, void *priv,
    >>>> fmt_rect.width = vin->format.width;
    >>>> fmt_rect.height = vin->format.height;
    >>>>
    >>>> + vin->crop.top = 0;
    >>>> + vin->crop.left = 0;
    >>>> + vin->crop.width = vin->format.width;
    >>>> + vin->crop.height = vin->format.height;
    >>>> + vin->compose = vin->crop;
    >>>> +
    >>>> v4l2_rect_map_inside(&vin->crop, &src_rect);
    >>>> v4l2_rect_map_inside(&vin->compose, &fmt_rect);
    >>>> vin->src_rect = src_rect;
    >>>> --
    >>>> 2.7.4
    >>>>
    >>>
    >>> --
    >>> Regards,
    >>> Niklas Söderlund
    >

    \
     
     \ /
      Last update: 2020-08-19 16:09    [W:4.953 / U:1.804 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site