[{"id":749,"web_url":"https://patchwork.libcamera.org/comment/749/","msgid":"<20190201224828.GI4359@pendragon.ideasonboard.com>","date":"2019-02-01T22:48:28","subject":"Re: [libcamera-devel] [PATCH 7/7] libcamera: v4l2_device: Improve\n\tdocumentation","submitter":{"id":2,"url":"https://patchwork.libcamera.org/api/people/2/","name":"Laurent Pinchart","email":"laurent.pinchart@ideasonboard.com"},"content":"Hi Jacopo,\n\nThank you for the patch.\n\nOn Fri, Feb 01, 2019 at 04:42:48PM +0100, Jacopo Mondi wrote:\n> Improve the V4L2DeviceFormat documentation as suggested during patches\n> review.\n> \n> Signed-off-by: Jacopo Mondi \n> ---\n> src/libcamera/v4l2_device.cpp | 42 +++++++++++++++++++----------------\n> 1 file changed, 23 insertions(+), 19 deletions(-)\n> \n> diff --git a/src/libcamera/v4l2_device.cpp b/src/libcamera/v4l2_device.cpp\n> index 4d1f76b..5ae208f 100644\n> --- a/src/libcamera/v4l2_device.cpp\n> +++ b/src/libcamera/v4l2_device.cpp\n> @@ -84,48 +84,52 @@ LOG_DEFINE_CATEGORY(V4L2)\n> * \\class V4L2DeviceFormat\n> * \\brief The V4L2 device image format and sizes\n> *\n> - * Describes the image format and image sizes to be programmed on a V4L2\n> - * video device. The image format is defined by fourcc code as defined by\n> - * the V4L2 APIs with the V4L2_PIX_FMT_ macros, a visible width and height\n> - * and a variable number of planes (1 to 3) with variable sizes and line\n> - * strides.\n> + * This class describes the image format and image sizes to be programmed\n> + * on a V4L2 video device. The image format is defined by a fourcc code\n> + * as defined by the V4L2 API with the V4L2_PIX_FMT_* macros, a visible\n> + * width and height and one to three planes with configurable line stride\n> + * and a total per-plane size in bytes.\n> *\n> - * Formats defined as 'single planar' by the V4L2 APIs are represented with\n> - * V4L2DeviceFormat instances with a single plane\n> - * (V4L2DeviceFormat::planesCount = 1). Semi-planar and multiplanar formats use\n> - * 2 and 3 planes respectively.\n> + * The V4L2 APIs defines packed, semi-planar and planar image formats.\n> + * Packed formats are stored as a single, contiguous memory area, while\n> + * semi-planar and multi-planar ones use two or three (possibly not contiguous)\n> + * memory regions to store the image components as separate planes.\n> *\n> - * V4L2DeviceFormat defines the exchange format between components that\n> - * receive image configuration requests from applications and a V4L2Device.\n> - * The V4L2Device validates and applies the requested size and format to\n> - * the device driver.\n> + * Packed formats are represented by V4L2DeviceFormat instances with a\n> + * single valid \\ref planes array entry (\\ref planesCount = 1).\n> + * Non-packed formats allows configuring per plane size and line stride length,\n\ns/allows/allow/\ns/stride length/stride/\n\n> + * but only when applied to devices that support the V4L2 multi-planar APIs.\n\nI don't think this is correct. bytesperline can be set for all formats\n(packed and planar), both using the MPLANE and non-MPLANE APIs.\n\n> + * When a non-packed image format gets applied to a device that only supports\n\nI'd write \"planar or semi-planar\" instead of \"non-packed\".\n\n> + * the V4L2 single-planar APIs, it is not possible to configure per-plane sizes\n\nDid you mean strides instead of sizes ?\n\n> + * as the only valid informations are contained in the first entry of the \\ref\n\ns/informations/information/\n\n> + * planes array, and apply to the image as a whole.\n\nI'd write \"[...] per-plane sizes. Only the first entry of the \\ref\nplanes array is taken into account in that case, and apply to all\nplanes, with appropriate subsampling.\"\n\n> */\n> \n> /**\n> * \\var V4L2DeviceFormat::width\n> - * \\brief The image width\n> + * \\brief The image width in pixels\n> */\n> \n> /**\n> * \\var V4L2DeviceFormat::height\n> - * \\brief The image height\n> + * \\brief The image height in pixels\n> */\n> \n> /**\n> * \\var V4L2DeviceFormat::fourcc\n> * \\brief The pixel encoding scheme\n> *\n> - * The fourcc code, as defined by the V4L2 APIs with the V4L2_PIX_FMT_ macros,\n> + * The fourcc code, as defined by the V4L2 API with the V4L2_PIX_FMT_* macros,\n> * that identifies the image format pixel encoding scheme.\n> */\n> \n> /**\n> * \\var V4L2DeviceFormat::planes\n> - * \\brief The per-plane size information\n> + * \\brief The per-plane memory size information\n> *\n> * Images are stored in memory in one or more data planes. Each data plane\n> - * has a specific size and line length, which could differ from the image\n> - * visible sizes to accommodate line or plane padding data.\n> + * has a specific memory size and line length, which could differ from the\n\ns/memory size and line length/line stride and memory size/\n\n> + * image visible sizes to accommodate line or plane padding data.\n\ns/line or plane padding data/padding at the end of lines and end of the\nplane/ ?\n\n> *\n> * Only the first \\ref planesCount entries are considered valid.\n> */","headers":{"Return-Path":"","Received":["from perceval.ideasonboard.com (perceval.ideasonboard.com\n\t[213.167.242.64])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 7A85B60B10\n\tfor ;\n\tFri, 1 Feb 2019 23:48:34 +0100 (CET)","from pendragon.ideasonboard.com (85-76-65-45-nat.elisa-mobile.fi\n\t[85.76.65.45])\n\tby perceval.ideasonboard.com (Postfix) with ESMTPSA id B1C0B4F7;\n\tFri, 1 Feb 2019 23:48:32 +0100 (CET)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;\n\ts=mail; t=1549061314;\n\tbh=O3EmvU6nejakGH+ceAA8bo5Z2y+9w8tI/1fsf2ePDVU=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=AXuHMBPsgCxrCU8yYLEecTqMO0HEpwSjHXMlpo9wRReXg5LV0ybFUMZF/DnI2nLTH\n\tp6C5JlaUZe9MKgQydtvkvkuEvgXKsXzPRQTR9EPdQb/qUMD0WGamxDCzordnI9C30Y\n\tKJafO3Z4t8QIvFCp79uYfh8YThS8DFTMw9yPm+sk=","Date":"Sat, 2 Feb 2019 00:48:28 +0200","From":"Laurent Pinchart ","To":"Jacopo Mondi ","Cc":"libcamera-devel@lists.libcamera.org","Message-ID":"<20190201224828.GI4359@pendragon.ideasonboard.com>","References":"<20190201154248.15006-1-jacopo@jmondi.org>\n\t<20190201154248.15006-8-jacopo@jmondi.org>","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","In-Reply-To":"<20190201154248.15006-8-jacopo@jmondi.org>","User-Agent":"Mutt/1.10.1 (2018-07-13)","Subject":"Re: [libcamera-devel] [PATCH 7/7] libcamera: v4l2_device: Improve\n\tdocumentation","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.23","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","X-List-Received-Date":"Fri, 01 Feb 2019 22:48:34 -0000"}},{"id":751,"web_url":"https://patchwork.libcamera.org/comment/751/","msgid":"<20190203112202.b5frnkrye22hbl2k@uno.localdomain>","date":"2019-02-03T11:22:02","subject":"Re: [libcamera-devel] [PATCH 7/7] libcamera: v4l2_device: Improve\n\tdocumentation","submitter":{"id":3,"url":"https://patchwork.libcamera.org/api/people/3/","name":"Jacopo Mondi","email":"jacopo@jmondi.org"},"content":"Hi Laurent,\n\nOn Sat, Feb 02, 2019 at 12:48:28AM +0200, Laurent Pinchart wrote:\n> Hi Jacopo,\n>\n> Thank you for the patch.\n>\n> On Fri, Feb 01, 2019 at 04:42:48PM +0100, Jacopo Mondi wrote:\n> > Improve the V4L2DeviceFormat documentation as suggested during patches\n> > review.\n> >\n> > Signed-off-by: Jacopo Mondi \n> > ---\n> > src/libcamera/v4l2_device.cpp | 42 +++++++++++++++++++----------------\n> > 1 file changed, 23 insertions(+), 19 deletions(-)\n> >\n> > diff --git a/src/libcamera/v4l2_device.cpp b/src/libcamera/v4l2_device.cpp\n> > index 4d1f76b..5ae208f 100644\n> > --- a/src/libcamera/v4l2_device.cpp\n> > +++ b/src/libcamera/v4l2_device.cpp\n> > @@ -84,48 +84,52 @@ LOG_DEFINE_CATEGORY(V4L2)\n> > * \\class V4L2DeviceFormat\n> > * \\brief The V4L2 device image format and sizes\n> > *\n> > - * Describes the image format and image sizes to be programmed on a V4L2\n> > - * video device. The image format is defined by fourcc code as defined by\n> > - * the V4L2 APIs with the V4L2_PIX_FMT_ macros, a visible width and height\n> > - * and a variable number of planes (1 to 3) with variable sizes and line\n> > - * strides.\n> > + * This class describes the image format and image sizes to be programmed\n> > + * on a V4L2 video device. The image format is defined by a fourcc code\n> > + * as defined by the V4L2 API with the V4L2_PIX_FMT_* macros, a visible\n> > + * width and height and one to three planes with configurable line stride\n> > + * and a total per-plane size in bytes.\n> > *\n> > - * Formats defined as 'single planar' by the V4L2 APIs are represented with\n> > - * V4L2DeviceFormat instances with a single plane\n> > - * (V4L2DeviceFormat::planesCount = 1). Semi-planar and multiplanar formats use\n> > - * 2 and 3 planes respectively.\n> > + * The V4L2 APIs defines packed, semi-planar and planar image formats.\n> > + * Packed formats are stored as a single, contiguous memory area, while\n> > + * semi-planar and multi-planar ones use two or three (possibly not contiguous)\n> > + * memory regions to store the image components as separate planes.\n> > *\n> > - * V4L2DeviceFormat defines the exchange format between components that\n> > - * receive image configuration requests from applications and a V4L2Device.\n> > - * The V4L2Device validates and applies the requested size and format to\n> > - * the device driver.\n> > + * Packed formats are represented by V4L2DeviceFormat instances with a\n> > + * single valid \\ref planes array entry (\\ref planesCount = 1).\n> > + * Non-packed formats allows configuring per plane size and line stride length,\n>\n> s/allows/allow/\n> s/stride length/stride/\n>\n> > + * but only when applied to devices that support the V4L2 multi-planar APIs.\n>\n> I don't think this is correct. bytesperline can be set for all formats\n> (packed and planar), both using the MPLANE and non-MPLANE APIs.\n>\n\nWhen using single plane APIs, the bytesperlane cannot be set -per\nplane- I think the following sentece clarifies that.\n\n> > + * When a non-packed image format gets applied to a device that only supports\n>\n> I'd write \"planar or semi-planar\" instead of \"non-packed\".\n>\n> > + * the V4L2 single-planar APIs, it is not possible to configure per-plane sizes\n>\n> Did you mean strides instead of sizes ?\n\nI meant \"sizes\" as both stride and global plane size. Is this\nconfusing?\n\n>\n> > + * as the only valid informations are contained in the first entry of the \\ref\n>\n> s/informations/information/\n>\n> > + * planes array, and apply to the image as a whole.\n>\n> I'd write \"[...] per-plane sizes. Only the first entry of the \\ref\n> planes array is taken into account in that case, and apply to all\n> planes, with appropriate subsampling.\"\n>\n> > */\n> >\n> > /**\n> > * \\var V4L2DeviceFormat::width\n> > - * \\brief The image width\n> > + * \\brief The image width in pixels\n> > */\n> >\n> > /**\n> > * \\var V4L2DeviceFormat::height\n> > - * \\brief The image height\n> > + * \\brief The image height in pixels\n> > */\n> >\n> > /**\n> > * \\var V4L2DeviceFormat::fourcc\n> > * \\brief The pixel encoding scheme\n> > *\n> > - * The fourcc code, as defined by the V4L2 APIs with the V4L2_PIX_FMT_ macros,\n> > + * The fourcc code, as defined by the V4L2 API with the V4L2_PIX_FMT_* macros,\n> > * that identifies the image format pixel encoding scheme.\n> > */\n> >\n> > /**\n> > * \\var V4L2DeviceFormat::planes\n> > - * \\brief The per-plane size information\n> > + * \\brief The per-plane memory size information\n> > *\n> > * Images are stored in memory in one or more data planes. Each data plane\n> > - * has a specific size and line length, which could differ from the image\n> > - * visible sizes to accommodate line or plane padding data.\n> > + * has a specific memory size and line length, which could differ from the\n>\n> s/memory size and line length/line stride and memory size/\n>\n> > + * image visible sizes to accommodate line or plane padding data.\n>\n> s/line or plane padding data/padding at the end of lines and end of the\n> plane/ ?\n>\n\nThanks, I'll push the other 6 patches, and re-post this one for\nanother review cycle.\n\nThanks\n j\n\n> > *\n> > * Only the first \\ref planesCount entries are considered valid.\n> > */\n>\n> --\n> Regards,\n>\n> Laurent Pinchart","headers":{"Return-Path":"","Received":["from relay8-d.mail.gandi.net (relay8-d.mail.gandi.net\n\t[217.70.183.201])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id ADE5360B1B\n\tfor ;\n\tSun, 3 Feb 2019 12:21:44 +0100 (CET)","from uno.localdomain (unknown [151.216.143.124])\n\t(Authenticated sender: jacopo@jmondi.org)\n\tby relay8-d.mail.gandi.net (Postfix) with ESMTPSA id 3ADAC1BF207;\n\tSun, 3 Feb 2019 11:21:43 +0000 (UTC)"],"X-Originating-IP":"151.216.143.124","Date":"Sun, 3 Feb 2019 12:22:02 +0100","From":"Jacopo Mondi ","To":"Laurent Pinchart ","Cc":"libcamera-devel@lists.libcamera.org","Message-ID":"<20190203112202.b5frnkrye22hbl2k@uno.localdomain>","References":"<20190201154248.15006-1-jacopo@jmondi.org>\n\t<20190201154248.15006-8-jacopo@jmondi.org>\n\t<20190201224828.GI4359@pendragon.ideasonboard.com>","MIME-Version":"1.0","Content-Type":"multipart/signed; micalg=pgp-sha256;\n\tprotocol=\"application/pgp-signature\"; boundary=\"xnujl6ujf3qlq4dk\"","Content-Disposition":"inline","In-Reply-To":"<20190201224828.GI4359@pendragon.ideasonboard.com>","User-Agent":"NeoMutt/20180716","Subject":"Re: [libcamera-devel] [PATCH 7/7] libcamera: v4l2_device: Improve\n\tdocumentation","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.23","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","X-List-Received-Date":"Sun, 03 Feb 2019 11:21:44 -0000"}},{"id":755,"web_url":"https://patchwork.libcamera.org/comment/755/","msgid":"<20190204183910.GB4561@pendragon.ideasonboard.com>","date":"2019-02-04T18:39:10","subject":"Re: [libcamera-devel] [PATCH 7/7] libcamera: v4l2_device: Improve\n\tdocumentation","submitter":{"id":2,"url":"https://patchwork.libcamera.org/api/people/2/","name":"Laurent Pinchart","email":"laurent.pinchart@ideasonboard.com"},"content":"Hi Jacopo,\n\nOn Sun, Feb 03, 2019 at 12:22:02PM +0100, Jacopo Mondi wrote:\n> On Sat, Feb 02, 2019 at 12:48:28AM +0200, Laurent Pinchart wrote:\n> > On Fri, Feb 01, 2019 at 04:42:48PM +0100, Jacopo Mondi wrote:\n> >> Improve the V4L2DeviceFormat documentation as suggested during patches\n> >> review.\n> >>\n> >> Signed-off-by: Jacopo Mondi \n> >> ---\n> >> src/libcamera/v4l2_device.cpp | 42 +++++++++++++++++++----------------\n> >> 1 file changed, 23 insertions(+), 19 deletions(-)\n> >>\n> >> diff --git a/src/libcamera/v4l2_device.cpp b/src/libcamera/v4l2_device.cpp\n> >> index 4d1f76b..5ae208f 100644\n> >> --- a/src/libcamera/v4l2_device.cpp\n> >> +++ b/src/libcamera/v4l2_device.cpp\n> >> @@ -84,48 +84,52 @@ LOG_DEFINE_CATEGORY(V4L2)\n> >> * \\class V4L2DeviceFormat\n> >> * \\brief The V4L2 device image format and sizes\n> >> *\n> >> - * Describes the image format and image sizes to be programmed on a V4L2\n> >> - * video device. The image format is defined by fourcc code as defined by\n> >> - * the V4L2 APIs with the V4L2_PIX_FMT_ macros, a visible width and height\n> >> - * and a variable number of planes (1 to 3) with variable sizes and line\n> >> - * strides.\n> >> + * This class describes the image format and image sizes to be programmed\n> >> + * on a V4L2 video device. The image format is defined by a fourcc code\n> >> + * as defined by the V4L2 API with the V4L2_PIX_FMT_* macros, a visible\n> >> + * width and height and one to three planes with configurable line stride\n> >> + * and a total per-plane size in bytes.\n> >> *\n> >> - * Formats defined as 'single planar' by the V4L2 APIs are represented with\n> >> - * V4L2DeviceFormat instances with a single plane\n> >> - * (V4L2DeviceFormat::planesCount = 1). Semi-planar and multiplanar formats use\n> >> - * 2 and 3 planes respectively.\n> >> + * The V4L2 APIs defines packed, semi-planar and planar image formats.\n> >> + * Packed formats are stored as a single, contiguous memory area, while\n> >> + * semi-planar and multi-planar ones use two or three (possibly not contiguous)\n> >> + * memory regions to store the image components as separate planes.\n> >> *\n> >> - * V4L2DeviceFormat defines the exchange format between components that\n> >> - * receive image configuration requests from applications and a V4L2Device.\n> >> - * The V4L2Device validates and applies the requested size and format to\n> >> - * the device driver.\n> >> + * Packed formats are represented by V4L2DeviceFormat instances with a\n> >> + * single valid \\ref planes array entry (\\ref planesCount = 1).\n> >> + * Non-packed formats allows configuring per plane size and line stride length,\n> >\n> > s/allows/allow/\n> > s/stride length/stride/\n> >\n> >> + * but only when applied to devices that support the V4L2 multi-planar APIs.\n> >\n> > I don't think this is correct. bytesperline can be set for all formats\n> > (packed and planar), both using the MPLANE and non-MPLANE APIs.\n> \n> When using single plane APIs, the bytesperlane cannot be set -per\n> plane- I think the following sentece clarifies that.\n\nRe-reading the text I now understand what you meant. I think it's a bit\nconfusing.\n\n> >> + * When a non-packed image format gets applied to a device that only supports\n> >\n> > I'd write \"planar or semi-planar\" instead of \"non-packed\".\n> >\n> >> + * the V4L2 single-planar APIs, it is not possible to configure per-plane sizes\n> >\n> > Did you mean strides instead of sizes ?\n> \n> I meant \"sizes\" as both stride and global plane size. Is this\n> confusing?\n\nWith the single-planar API is used, sizeimage is set by the driver, not\nthe application, so it can't be configured, isn't it ?\n\n> >> + * as the only valid informations are contained in the first entry of the \\ref\n> >\n> > s/informations/information/\n> >\n> >> + * planes array, and apply to the image as a whole.\n> >\n> > I'd write \"[...] per-plane sizes. Only the first entry of the \\ref\n> > planes array is taken into account in that case, and apply to all\n> > planes, with appropriate subsampling.\"\n> >\n> >> */\n> >>\n> >> /**\n> >> * \\var V4L2DeviceFormat::width\n> >> - * \\brief The image width\n> >> + * \\brief The image width in pixels\n> >> */\n> >>\n> >> /**\n> >> * \\var V4L2DeviceFormat::height\n> >> - * \\brief The image height\n> >> + * \\brief The image height in pixels\n> >> */\n> >>\n> >> /**\n> >> * \\var V4L2DeviceFormat::fourcc\n> >> * \\brief The pixel encoding scheme\n> >> *\n> >> - * The fourcc code, as defined by the V4L2 APIs with the V4L2_PIX_FMT_ macros,\n> >> + * The fourcc code, as defined by the V4L2 API with the V4L2_PIX_FMT_* macros,\n> >> * that identifies the image format pixel encoding scheme.\n> >> */\n> >>\n> >> /**\n> >> * \\var V4L2DeviceFormat::planes\n> >> - * \\brief The per-plane size information\n> >> + * \\brief The per-plane memory size information\n> >> *\n> >> * Images are stored in memory in one or more data planes. Each data plane\n> >> - * has a specific size and line length, which could differ from the image\n> >> - * visible sizes to accommodate line or plane padding data.\n> >> + * has a specific memory size and line length, which could differ from the\n> >\n> > s/memory size and line length/line stride and memory size/\n> >\n> >> + * image visible sizes to accommodate line or plane padding data.\n> >\n> > s/line or plane padding data/padding at the end of lines and end of the\n> > plane/ ?\n> \n> Thanks, I'll push the other 6 patches, and re-post this one for\n> another review cycle.\n\nThank you.\n\n> >> *\n> >> * Only the first \\ref planesCount entries are considered valid.\n> >> */","headers":{"Return-Path":"","Received":["from perceval.ideasonboard.com (perceval.ideasonboard.com\n\t[213.167.242.64])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 0871160B2D\n\tfor ;\n\tMon, 4 Feb 2019 19:39:15 +0100 (CET)","from pendragon.ideasonboard.com (85-76-64-229-nat.elisa-mobile.fi\n\t[85.76.64.229])\n\tby perceval.ideasonboard.com (Postfix) with ESMTPSA id EF63F41;\n\tMon, 4 Feb 2019 19:39:13 +0100 (CET)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;\n\ts=mail; t=1549305554;\n\tbh=P2A9jOpEag/iqNwJRyd9Yj9ceRrgnPofFMwlp/2I68E=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=fDj8CfDcrSJS8JmoHUk7eBjCy//rDDnH6wjH4zmiIxmDKIxukgE3UffU06F2JfuTD\n\t5VEoOlaBCmFA/m/Uv9AUZr2/f69S0vjXL4DdA/oV0PZyCZhFHX8NCf0wlQBa0nA6rV\n\toB/ZOmrSMgTwajjsinA5tjveZgHNFejXqL9dWF78=","Date":"Mon, 4 Feb 2019 20:39:10 +0200","From":"Laurent Pinchart ","To":"Jacopo Mondi ","Cc":"libcamera-devel@lists.libcamera.org","Message-ID":"<20190204183910.GB4561@pendragon.ideasonboard.com>","References":"<20190201154248.15006-1-jacopo@jmondi.org>\n\t<20190201154248.15006-8-jacopo@jmondi.org>\n\t<20190201224828.GI4359@pendragon.ideasonboard.com>\n\t<20190203112202.b5frnkrye22hbl2k@uno.localdomain>","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","In-Reply-To":"<20190203112202.b5frnkrye22hbl2k@uno.localdomain>","User-Agent":"Mutt/1.10.1 (2018-07-13)","Subject":"Re: [libcamera-devel] [PATCH 7/7] libcamera: v4l2_device: Improve\n\tdocumentation","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.23","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","X-List-Received-Date":"Mon, 04 Feb 2019 18:39:15 -0000"}}]