All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicolas Dufresne <nicolas.dufresne@collabora.com>
To: Andrzej Hajda <a.hajda@samsung.com>,
	Thibault Saunier <thibault.saunier@osg.samsung.com>,
	linux-kernel@vger.kernel.org
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Kukjin Kim <kgene@kernel.org>,
	Mauro Carvalho Chehab <mchehab@s-opensource.com>,
	Andi Shyti <andi.shyti@samsung.com>,
	linux-media@vger.kernel.org, Shuah Khan <shuahkh@osg.samsung.com>,
	Javier Martinez Canillas <javier@osg.samsung.com>,
	linux-samsung-soc@vger.kernel.org,
	Krzysztof Kozlowski <krzk@kernel.org>,
	Inki Dae <inki.dae@samsung.com>,
	Sylwester Nawrocki <s.nawrocki@samsung.com>,
	linux-arm-kernel@lists.infradead.org,
	Ulf Hansson <ulf.hansson@linaro.org>,
	Jeongtae Park <jtp.park@samsung.com>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	Kamil Debski <kamil@wypas.org>
Subject: Re: [PATCH v6 2/2] [media] s5p-mfc: Handle 'v4l2_pix_format:field' in try_fmt and g_fmt
Date: Wed, 01 Mar 2017 09:35:36 -0500	[thread overview]
Message-ID: <1488378936.14858.1.camel@collabora.com> (raw)
In-Reply-To: <33dbd3fa-04b2-3d94-5163-0a10589ff1c7@samsung.com>

[-- Attachment #1: Type: text/plain, Size: 4652 bytes --]

Le mercredi 01 mars 2017 à 14:12 +0100, Andrzej Hajda a écrit :
> On 01.03.2017 12:51, Thibault Saunier wrote:
> > It is required by the standard that the field order is set by the
> > driver, default to NONE in case any is provided, but we can
> > basically
> > accept any value provided by the userspace as we will anyway not
> > be able to do any deinterlacing.
> > 
> > In this patch we also make sure to pass the interlacing mode
> > provided
> > by userspace from the output to the capture side of the device so
> > that the information is given back to userspace. This way it can
> > handle it and potentially deinterlace afterward.
> 
> As I wrote previously:
> - on output side you have encoded bytestream - you cannot say about
> interlacing in such case, so the only valid value is NONE,

Userspace may know. It's important for the driver not to reset it back
to NONE, it would tell the userspace that this encoded format is not
supported when interlaced.

Obviously, when userspace don't know (ANY), it does not matter, it will
fail when we try to set the CAPTURE format. Though, it's quite late in
the process for the userspace, which makes implementing software
fallback difficult.

> - on capture side you have decoded frames, and in this case it
> depends
> on the device and driver capabilities, if the driver/device does not
> support (de-)interlacing (I suppose this is MFC case), interlace type
> field should be filled according to decoded bytestream header (on
> output
> side), but no direct copying from output side!!!

That is exact.

> 
> Regards
> Andrzej
> 
> > 
> > Signed-off-by: Thibault Saunier <thibault.saunier@osg.samsung.com>
> > 
> > ---
> > 
> > Changes in v6:
> > - Pass user output field value to the capture as the device is not
> >   doing any deinterlacing and thus decoded content will still be
> >   interlaced on the output.
> > 
> > Changes in v5:
> > - Just adapt the field and never error out.
> > 
> > Changes in v4: None
> > Changes in v3:
> > - Do not check values in the g_fmt functions as Andrzej explained
> > in previous review
> > 
> > Changes in v2:
> > - Fix a silly build error that slipped in while rebasing the
> > patches
> > 
> >  drivers/media/platform/s5p-mfc/s5p_mfc_common.h | 2 ++
> >  drivers/media/platform/s5p-mfc/s5p_mfc_dec.c    | 6 +++++-
> >  2 files changed, 7 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> > b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> > index ab23236aa942..3816a37de4bc 100644
> > --- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> > +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> > @@ -652,6 +652,8 @@ struct s5p_mfc_ctx {
> >  	size_t me_buffer_size;
> >  	size_t tmv_buffer_size;
> >  
> > +	enum v4l2_field field;
> > +
> >  	enum v4l2_mpeg_mfc51_video_force_frame_type
> > force_frame_type;
> >  
> >  	struct list_head ref_queue;
> > diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> > b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> > index 367ef8e8dbf0..6e5ca86fb331 100644
> > --- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> > +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> > @@ -345,7 +345,7 @@ static int vidioc_g_fmt(struct file *file, void
> > *priv, struct v4l2_format *f)
> >  		   rectangle. */
> >  		pix_mp->width = ctx->buf_width;
> >  		pix_mp->height = ctx->buf_height;
> > -		pix_mp->field = V4L2_FIELD_NONE;
> > +		pix_mp->field = ctx->field;
> >  		pix_mp->num_planes = 2;
> >  		/* Set pixelformat to the format in which MFC
> >  		   outputs the decoded frame */
> > @@ -380,6 +380,9 @@ static int vidioc_try_fmt(struct file *file,
> > void *priv, struct v4l2_format *f)
> >  	struct s5p_mfc_dev *dev = video_drvdata(file);
> >  	struct s5p_mfc_fmt *fmt;
> >  
> > +	if (f->fmt.pix.field == V4L2_FIELD_ANY)
> > +		f->fmt.pix.field = V4L2_FIELD_NONE;
> > +
> >  	mfc_debug(2, "Type is %d\n", f->type);
> >  	if (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
> >  		fmt = find_format(f, MFC_FMT_DEC);
> > @@ -436,6 +439,7 @@ static int vidioc_s_fmt(struct file *file, void
> > *priv, struct v4l2_format *f)
> >  		goto out;
> >  	} else if (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
> >  		/* src_fmt is validated by call to vidioc_try_fmt
> > */
> > +		ctx->field = f->fmt.pix.field;
> >  		ctx->src_fmt = find_format(f, MFC_FMT_DEC);
> >  		ctx->codec_mode = ctx->src_fmt->codec_mode;
> >  		mfc_debug(2, "The codec number is: %d\n", ctx-
> > >codec_mode);
> 
> 

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Nicolas Dufresne <nicolas.dufresne@collabora.com>
To: Andrzej Hajda <a.hajda@samsung.com>,
	Thibault Saunier <thibault.saunier@osg.samsung.com>,
	linux-kernel@vger.kernel.org
Cc: Inki Dae <inki.dae@samsung.com>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	linux-samsung-soc@vger.kernel.org,
	Jeongtae Park <jtp.park@samsung.com>,
	Shuah Khan <shuahkh@osg.samsung.com>,
	Andi Shyti <andi.shyti@samsung.com>,
	Kamil Debski <kamil@wypas.org>,
	Mauro Carvalho Chehab <mchehab@s-opensource.com>,
	Javier Martinez Canillas <javier@osg.samsung.com>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	Kukjin Kim <kgene@kernel.org>,
	Krzysztof Kozlowski <krzk@kernel.org>,
	Sylwester Nawrocki <s.nawrocki@samsung.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	linux-media@vger.kernel.org
Subject: Re: [PATCH v6 2/2] [media] s5p-mfc: Handle 'v4l2_pix_format:field' in try_fmt and g_fmt
Date: Wed, 01 Mar 2017 09:35:36 -0500	[thread overview]
Message-ID: <1488378936.14858.1.camel@collabora.com> (raw)
In-Reply-To: <33dbd3fa-04b2-3d94-5163-0a10589ff1c7@samsung.com>


[-- Attachment #1.1: Type: text/plain, Size: 4652 bytes --]

Le mercredi 01 mars 2017 à 14:12 +0100, Andrzej Hajda a écrit :
> On 01.03.2017 12:51, Thibault Saunier wrote:
> > It is required by the standard that the field order is set by the
> > driver, default to NONE in case any is provided, but we can
> > basically
> > accept any value provided by the userspace as we will anyway not
> > be able to do any deinterlacing.
> > 
> > In this patch we also make sure to pass the interlacing mode
> > provided
> > by userspace from the output to the capture side of the device so
> > that the information is given back to userspace. This way it can
> > handle it and potentially deinterlace afterward.
> 
> As I wrote previously:
> - on output side you have encoded bytestream - you cannot say about
> interlacing in such case, so the only valid value is NONE,

Userspace may know. It's important for the driver not to reset it back
to NONE, it would tell the userspace that this encoded format is not
supported when interlaced.

Obviously, when userspace don't know (ANY), it does not matter, it will
fail when we try to set the CAPTURE format. Though, it's quite late in
the process for the userspace, which makes implementing software
fallback difficult.

> - on capture side you have decoded frames, and in this case it
> depends
> on the device and driver capabilities, if the driver/device does not
> support (de-)interlacing (I suppose this is MFC case), interlace type
> field should be filled according to decoded bytestream header (on
> output
> side), but no direct copying from output side!!!

That is exact.

> 
> Regards
> Andrzej
> 
> > 
> > Signed-off-by: Thibault Saunier <thibault.saunier@osg.samsung.com>
> > 
> > ---
> > 
> > Changes in v6:
> > - Pass user output field value to the capture as the device is not
> >   doing any deinterlacing and thus decoded content will still be
> >   interlaced on the output.
> > 
> > Changes in v5:
> > - Just adapt the field and never error out.
> > 
> > Changes in v4: None
> > Changes in v3:
> > - Do not check values in the g_fmt functions as Andrzej explained
> > in previous review
> > 
> > Changes in v2:
> > - Fix a silly build error that slipped in while rebasing the
> > patches
> > 
> >  drivers/media/platform/s5p-mfc/s5p_mfc_common.h | 2 ++
> >  drivers/media/platform/s5p-mfc/s5p_mfc_dec.c    | 6 +++++-
> >  2 files changed, 7 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> > b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> > index ab23236aa942..3816a37de4bc 100644
> > --- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> > +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> > @@ -652,6 +652,8 @@ struct s5p_mfc_ctx {
> >  	size_t me_buffer_size;
> >  	size_t tmv_buffer_size;
> >  
> > +	enum v4l2_field field;
> > +
> >  	enum v4l2_mpeg_mfc51_video_force_frame_type
> > force_frame_type;
> >  
> >  	struct list_head ref_queue;
> > diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> > b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> > index 367ef8e8dbf0..6e5ca86fb331 100644
> > --- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> > +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> > @@ -345,7 +345,7 @@ static int vidioc_g_fmt(struct file *file, void
> > *priv, struct v4l2_format *f)
> >  		   rectangle. */
> >  		pix_mp->width = ctx->buf_width;
> >  		pix_mp->height = ctx->buf_height;
> > -		pix_mp->field = V4L2_FIELD_NONE;
> > +		pix_mp->field = ctx->field;
> >  		pix_mp->num_planes = 2;
> >  		/* Set pixelformat to the format in which MFC
> >  		   outputs the decoded frame */
> > @@ -380,6 +380,9 @@ static int vidioc_try_fmt(struct file *file,
> > void *priv, struct v4l2_format *f)
> >  	struct s5p_mfc_dev *dev = video_drvdata(file);
> >  	struct s5p_mfc_fmt *fmt;
> >  
> > +	if (f->fmt.pix.field == V4L2_FIELD_ANY)
> > +		f->fmt.pix.field = V4L2_FIELD_NONE;
> > +
> >  	mfc_debug(2, "Type is %d\n", f->type);
> >  	if (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
> >  		fmt = find_format(f, MFC_FMT_DEC);
> > @@ -436,6 +439,7 @@ static int vidioc_s_fmt(struct file *file, void
> > *priv, struct v4l2_format *f)
> >  		goto out;
> >  	} else if (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
> >  		/* src_fmt is validated by call to vidioc_try_fmt
> > */
> > +		ctx->field = f->fmt.pix.field;
> >  		ctx->src_fmt = find_format(f, MFC_FMT_DEC);
> >  		ctx->codec_mode = ctx->src_fmt->codec_mode;
> >  		mfc_debug(2, "The codec number is: %d\n", ctx-
> > >codec_mode);
> 
> 

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: nicolas.dufresne@collabora.com (Nicolas Dufresne)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v6 2/2] [media] s5p-mfc: Handle 'v4l2_pix_format:field' in try_fmt and g_fmt
Date: Wed, 01 Mar 2017 09:35:36 -0500	[thread overview]
Message-ID: <1488378936.14858.1.camel@collabora.com> (raw)
In-Reply-To: <33dbd3fa-04b2-3d94-5163-0a10589ff1c7@samsung.com>

Le mercredi 01 mars 2017 ? 14:12 +0100, Andrzej Hajda a ?crit?:
> On 01.03.2017 12:51, Thibault Saunier wrote:
> > It is required by the standard that the field order is set by the
> > driver, default to NONE in case any is provided, but we can
> > basically
> > accept any value provided by the userspace as we will anyway not
> > be able to do any deinterlacing.
> > 
> > In this patch we also make sure to pass the interlacing mode
> > provided
> > by userspace from the output to the capture side of the device so
> > that the information is given back to userspace. This way it can
> > handle it and potentially deinterlace afterward.
> 
> As I wrote previously:
> - on output side you have encoded bytestream - you cannot say about
> interlacing in such case, so the only valid value is NONE,

Userspace may know. It's important for the driver not to reset it back
to NONE, it would tell the userspace that this encoded format is not
supported when interlaced.

Obviously, when userspace don't know (ANY), it does not matter, it will
fail when we try to set the CAPTURE format. Though, it's quite late in
the process for the userspace, which makes implementing software
fallback difficult.

> - on capture side you have decoded frames, and in this case it
> depends
> on the device and driver capabilities, if the driver/device does not
> support (de-)interlacing (I suppose this is MFC case), interlace type
> field should be filled according to decoded bytestream header (on
> output
> side), but no direct copying from output side!!!

That is exact.

> 
> Regards
> Andrzej
> 
> > 
> > Signed-off-by: Thibault Saunier <thibault.saunier@osg.samsung.com>
> > 
> > ---
> > 
> > Changes in v6:
> > - Pass user output field value to the capture as the device is not
> > ? doing any deinterlacing and thus decoded content will still be
> > ? interlaced on the output.
> > 
> > Changes in v5:
> > - Just adapt the field and never error out.
> > 
> > Changes in v4: None
> > Changes in v3:
> > - Do not check values in the g_fmt functions as Andrzej explained
> > in previous review
> > 
> > Changes in v2:
> > - Fix a silly build error that slipped in while rebasing the
> > patches
> > 
> > ?drivers/media/platform/s5p-mfc/s5p_mfc_common.h | 2 ++
> > ?drivers/media/platform/s5p-mfc/s5p_mfc_dec.c????| 6 +++++-
> > ?2 files changed, 7 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> > b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> > index ab23236aa942..3816a37de4bc 100644
> > --- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> > +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> > @@ -652,6 +652,8 @@ struct s5p_mfc_ctx {
> > ?	size_t me_buffer_size;
> > ?	size_t tmv_buffer_size;
> > ?
> > +	enum v4l2_field field;
> > +
> > ?	enum v4l2_mpeg_mfc51_video_force_frame_type
> > force_frame_type;
> > ?
> > ?	struct list_head ref_queue;
> > diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> > b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> > index 367ef8e8dbf0..6e5ca86fb331 100644
> > --- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> > +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> > @@ -345,7 +345,7 @@ static int vidioc_g_fmt(struct file *file, void
> > *priv, struct v4l2_format *f)
> > ?		???rectangle. */
> > ?		pix_mp->width = ctx->buf_width;
> > ?		pix_mp->height = ctx->buf_height;
> > -		pix_mp->field = V4L2_FIELD_NONE;
> > +		pix_mp->field = ctx->field;
> > ?		pix_mp->num_planes = 2;
> > ?		/* Set pixelformat to the format in which MFC
> > ?		???outputs the decoded frame */
> > @@ -380,6 +380,9 @@ static int vidioc_try_fmt(struct file *file,
> > void *priv, struct v4l2_format *f)
> > ?	struct s5p_mfc_dev *dev = video_drvdata(file);
> > ?	struct s5p_mfc_fmt *fmt;
> > ?
> > +	if (f->fmt.pix.field == V4L2_FIELD_ANY)
> > +		f->fmt.pix.field = V4L2_FIELD_NONE;
> > +
> > ?	mfc_debug(2, "Type is %d\n", f->type);
> > ?	if (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
> > ?		fmt = find_format(f, MFC_FMT_DEC);
> > @@ -436,6 +439,7 @@ static int vidioc_s_fmt(struct file *file, void
> > *priv, struct v4l2_format *f)
> > ?		goto out;
> > ?	} else if (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
> > ?		/* src_fmt is validated by call to vidioc_try_fmt
> > */
> > +		ctx->field = f->fmt.pix.field;
> > ?		ctx->src_fmt = find_format(f, MFC_FMT_DEC);
> > ?		ctx->codec_mode = ctx->src_fmt->codec_mode;
> > ?		mfc_debug(2, "The codec number is: %d\n", ctx-
> > >codec_mode);
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170301/5b8317db/attachment-0001.sig>

  parent reply	other threads:[~2017-03-01 15:23 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-01 11:51 [PATCH v6 0/2] Fixes for colorspace logic in exynos-gsc and s5p-mfc drivers Thibault Saunier
2017-03-01 11:51 ` Thibault Saunier
2017-03-01 11:51 ` Thibault Saunier
2017-03-01 11:51 ` [PATCH v6 1/2] [media] exynos-gsc: Use user configured colorspace if provided Thibault Saunier
2017-03-01 11:51   ` Thibault Saunier
2017-03-10 10:31   ` Hans Verkuil
2017-03-10 10:31     ` Hans Verkuil
2017-03-01 11:51 ` [PATCH v6 2/2] [media] s5p-mfc: Handle 'v4l2_pix_format:field' in try_fmt and g_fmt Thibault Saunier
2017-03-01 11:51   ` Thibault Saunier
2017-03-01 11:51   ` Thibault Saunier
2017-03-01 13:12   ` Andrzej Hajda
2017-03-01 13:12     ` Andrzej Hajda
2017-03-01 13:12     ` Andrzej Hajda
2017-03-01 13:20     ` Thibault Saunier
2017-03-01 13:20       ` Thibault Saunier
2017-03-01 13:20       ` Thibault Saunier
2017-03-01 14:35     ` Nicolas Dufresne [this message]
2017-03-01 14:35       ` Nicolas Dufresne
2017-03-01 14:35       ` Nicolas Dufresne
2017-03-01 14:41       ` Thibault Saunier
2017-03-01 14:41         ` Thibault Saunier
2017-03-01 14:41         ` Thibault Saunier
2017-03-01 15:21     ` Nicolas Dufresne
2017-03-01 15:21       ` Nicolas Dufresne
2017-03-01 15:21       ` Nicolas Dufresne
2017-03-02  7:42       ` Andrzej Hajda
2017-03-02  7:42         ` Andrzej Hajda
2017-03-02  7:42         ` Andrzej Hajda
2017-03-10 10:45   ` Hans Verkuil
2017-03-10 10:45     ` Hans Verkuil

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1488378936.14858.1.camel@collabora.com \
    --to=nicolas.dufresne@collabora.com \
    --cc=a.hajda@samsung.com \
    --cc=andi.shyti@samsung.com \
    --cc=inki.dae@samsung.com \
    --cc=javier@osg.samsung.com \
    --cc=jtp.park@samsung.com \
    --cc=kamil@wypas.org \
    --cc=kgene@kernel.org \
    --cc=krzk@kernel.org \
    --cc=kyungmin.park@samsung.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=mchehab@kernel.org \
    --cc=mchehab@s-opensource.com \
    --cc=s.nawrocki@samsung.com \
    --cc=shuahkh@osg.samsung.com \
    --cc=thibault.saunier@osg.samsung.com \
    --cc=ulf.hansson@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.