lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 2 Jul 2020 14:52:38 +0300
From:   Stanimir Varbanov <stanimir.varbanov@...aro.org>
To:     Stanimir Varbanov <stanimir.varbanov@...aro.org>,
        linux-media@...r.kernel.org, linux-kernel@...r.kernel.org
Cc:     Tomasz Figa <tfiga@...omium.org>,
        Hans Verkuil <hverkuil-cisco@...all.nl>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Nicolas Dufresne <nicolas@...fresne.ca>
Subject: Re: [PATCH] v4l: Add source change event for colorimetry

Hi,

Once we have this event there is still open question how the client will
know the data buffer on which the new colorspace is valid/applied.

The options could be:
 * a new buffer flag and
 * some information in the v4l2_event structure.

Thoughts?

On 7/2/20 1:00 PM, Stanimir Varbanov wrote:
> This event indicate that the source colorspace is changed
> during run-time. The client has to retrieve the new colorspace
> identifiers by getting the format (G_FMT).
> 
> Signed-off-by: Stanimir Varbanov <stanimir.varbanov@...aro.org>
> ---
>  .../userspace-api/media/v4l/vidioc-dqevent.rst        | 11 ++++++++++-
>  .../userspace-api/media/videodev2.h.rst.exceptions    |  1 +
>  include/uapi/linux/videodev2.h                        |  1 +
>  3 files changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/userspace-api/media/v4l/vidioc-dqevent.rst b/Documentation/userspace-api/media/v4l/vidioc-dqevent.rst
> index a9a176d5256d..3f69c753db58 100644
> --- a/Documentation/userspace-api/media/v4l/vidioc-dqevent.rst
> +++ b/Documentation/userspace-api/media/v4l/vidioc-dqevent.rst
> @@ -381,7 +381,16 @@ call.
>  	that many Video Capture devices are not able to recover from a temporary
>  	loss of signal and so restarting streaming I/O is required in order for
>  	the hardware to synchronize to the video signal.
> -
> +    * - ``V4L2_EVENT_SRC_CH_COLORIMETRY``
> +      - 0x0002
> +      - This event gets triggered when a colorspace change is detected at
> +	an input. By colorspace change here we include also changes in the
> +	colorspace specifiers (transfer function, Y'CbCr encoding and
> +	quantization). This event can come from an input or from video decoder.
> +	Once the event has been send to the client the driver has to update
> +	the colorspace specifiers internally so that they could be retrieved by
> +	client. In that case queue re-negotiation is not needed as this change
> +	only reflects on the interpretation of the data.
>  
>  Return Value
>  ============
> diff --git a/Documentation/userspace-api/media/videodev2.h.rst.exceptions b/Documentation/userspace-api/media/videodev2.h.rst.exceptions
> index ca05e4e126b2..54fc21af852d 100644
> --- a/Documentation/userspace-api/media/videodev2.h.rst.exceptions
> +++ b/Documentation/userspace-api/media/videodev2.h.rst.exceptions
> @@ -492,6 +492,7 @@ replace define V4L2_EVENT_CTRL_CH_FLAGS ctrl-changes-flags
>  replace define V4L2_EVENT_CTRL_CH_RANGE ctrl-changes-flags
>  
>  replace define V4L2_EVENT_SRC_CH_RESOLUTION src-changes-flags
> +replace define V4L2_EVENT_SRC_CH_COLORIMETRY src-changes-flags
>  
>  replace define V4L2_EVENT_MD_FL_HAVE_FRAME_SEQ :c:type:`v4l2_event_motion_det`
>  
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 303805438814..b5838bc4e3a3 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -2351,6 +2351,7 @@ struct v4l2_event_frame_sync {
>  };
>  
>  #define V4L2_EVENT_SRC_CH_RESOLUTION		(1 << 0)
> +#define V4L2_EVENT_SRC_CH_COLORIMETRY		(1 << 1)
>  
>  struct v4l2_event_src_change {
>  	__u32 changes;
> 

-- 
regards,
Stan

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ