From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Subject: Re: [PATCH v2 1/1] Documentation: drm: describing drm properties exposed by various drivers Date: Thu, 6 Mar 2014 14:09:38 +0200 Message-ID: <20140306120938.GC3852@intel.com> References: <1394016990-5218-1-git-send-email-sagar.a.kamble@intel.com> <1394090125-30029-1-git-send-email-sagar.a.kamble@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Content-Disposition: inline In-Reply-To: <1394090125-30029-1-git-send-email-sagar.a.kamble@intel.com> Sender: linux-doc-owner@vger.kernel.org To: sagar.a.kamble@intel.com Cc: intel-gfx@lists.freedesktop.org, Rob Landley , Dave Airlie , Daniel Vetter , Laurent Pinchart , David Herrmann , Alex Deucher , "Purushothaman, Vijay A" , linux-doc@vger.kernel.org, dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org On Thu, Mar 06, 2014 at 12:45:25PM +0530, sagar.a.kamble@intel.com wrot= e: > From: Sagar Kamble >=20 > Started documenting drm properties for drm drivers. This patch provid= es > information about properties in drm, i915, psb and cdv/gma-500. Infor= mation > about other properties can be added on top of these. >=20 > v2: Added description of drm properties in armada, exynos, i2c/ch7006= , noveau, > omap, qxl, radeon, rcar-du Looks like dri-devel wasn't cc:d, so I'm adding that... Thanks for tackling this. I think one change I would do is drop the "Property Object" column. It's purely an implementation detail and thus has no bearing on any ABI/API issues, and there's a risk of it getting stale due to code changes. It should also make the table a bit less crowded. Another way to maybe make the table a bit less wide is to drop the DRM_MODE_PROP_ prefix from the type information. Just saying BLOB, ENUM, etc. should be enough. But if people prefer to see the whole type name there, I'm fine with leaving it as is. With this documentation I can immediately spot several more or less identical same properties but with slightly different names :( I really hope we can now start to avoid that mistake by making sure that people add all new properties to this document. And before adding a new property people should check the document to see if something similar might already exist. >=20 > Cc: Rob Landley > Cc: Dave Airlie > Cc: Daniel Vetter > Cc: Laurent Pinchart > Cc: David Herrmann > Cc: Alex Deucher > Cc: "Ville Syrj=C3=A4l=C3=A4" > Cc: Sagar Kamble > Cc: "Purushothaman, Vijay A" > Cc: linux-doc@vger.kernel.org >=20 > Signed-off-by: Sagar Kamble > --- > Documentation/DocBook/drm.tmpl | 1163 ++++++++++++++++++++++++++++++= ++++++++++ > 1 file changed, 1163 insertions(+) >=20 > diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/d= rm.tmpl > index ed1d6d2..477263e 100644 > --- a/Documentation/DocBook/drm.tmpl > +++ b/Documentation/DocBook/drm.tmpl > @@ -2317,6 +2317,1169 @@ void intel_crt_init(struct drm_device *dev) > pointer to the target object, a pointer to the previously crea= ted property > and an initial instance value. > > + > + Following table gives description of drm properties exposed by = various > + modules/drivers. > + > + > + > + > + > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > + > + > + > + > + > + > + > +=20 > + > +
Owner Module/DriversGroupProperty ObjectProperty NameTypeProperty ValuesObject attachedDescription/Restrictions
DRMGeneric Propertiesedid_property=E2=80=9CEDID=E2=80=9DDRM_MODE_PROP_BLOB | DRM_MODE_PROP_IMMUTABLE > +0ConnectorContains id of edid blob ptr object.
dpms_property=E2=80=9CDPMS=E2=80=9DDRM_MODE_PROP_ENUM{ DRM_MODE_DPMS_ON, =E2=80=9COn=E2=80=9D}, > +{ DRM_MODE_DPMS_STANDBY, =E2=80=9CStandby=E2=80=9D}, > +{ DRM_MODE_DPMS_SUSPEND, =E2=80=9CSuspend=E2=80=9D}, > +{ DRM_MODE_DPMS_OFF, =E2=80=9COff=E2=80=9D}ConnectorContains DPMS operation mode value.
DVI-I Propertiesdvi_i_subconnector_property=E2=80=9Csubconnector=E2=80=9DDRM_MODE_PROP_ENUM{ DRM_MODE_SUBCONNECTOR_Unknown, =E2=80=9CUnknow= n=E2=80=9D}, > +{ DRM_MODE_SUBCONNECTOR_DVID, =E2=80=9CDVI-D=E2=80=9D}, > +{ DRM_MODE_SUBCONNECTOR_DVIA, =E2=80=9CDVI-A=E2=80=9D}ConnectorTBD
dvi_i_select_subconnector_property=E2=80=9Cselect subconnector=E2=80=9DDRM_MODE_PROP_ENUM{ DRM_MODE_SUBCONNECTOR_Automatic, =E2=80=9CAuto= matic=E2=80=9D}, > +{ DRM_MODE_SUBCONNECTOR_DVID, =E2=80=9CDVI-D=E2=80=9D}, > +{ DRM_MODE_SUBCONNECTOR_DVIA, =E2=80=9CDVI-A=E2=80=9D}ConnectorTBD
TV Propertiestv_subconnector_property=E2=80=9Csubconnector=E2=80=9DDRM_MODE_PROP_ENUM{ DRM_MODE_SUBCONNECTOR_Unknown, "Unknown"}, > +{ DRM_MODE_SUBCONNECTOR_Composite, "Composite" }, > +{ DRM_MODE_SUBCONNECTOR_SVIDEO, "SVIDEO"}, > +{ DRM_MODE_SUBCONNECTOR_Component , "Component"}, > +{ DRM_MODE_SUBCONNECTOR_SCART, "SCART"}ConnectorTBD
tv_select_subconnector_property=E2=80=9Cselect subconnector=E2=80=9DDRM_MODE_PROP_ENUM{DRM_MODE_SUBCONNECTOR_Automatic, "Automatic"}, > +{DRM_MODE_SUBCONNECTOR_Composite, "Composite"}, > +{DRM_MODE_SUBCONNECTOR_SVIDEO, "SVIDEO"}, > +{DRM_MODE_SUBCONNECTOR_Component, "Component"}, > +{DRM_MODE_SUBCONNECTOR_SCART, "SCART"}ConnectorTBD
tv_mode_property=E2=80=9Cmode=E2=80=9DDRM_MODE_PROP_ENUM{0, "NTSC_M"} , {1, "NTSC_J"} , > +{2, "NTSC_443"}, {3, "PAL_B"} etc.ConnectorTBD
tv_left_margin_property=E2=80=9Cleft margin=E2=80=9DDRM_MODE_PROP_RANGEMin=3D0, Max=3D100ConnectorTBD
tv_right_margin_property=E2=80=9Cright margin=E2=80=9DDRM_MODE_PROP_RANGEMin=3D0, Max=3D100ConnectorTBD
tv_top_margin_property=E2=80=9Ctop margin=E2=80=9DDRM_MODE_PROP_RANGEMin=3D0, Max=3D100ConnectorTBD
tv_bottom_margin_property=E2=80=9Cbottom margin=E2=80=9DDRM_MODE_PROP_RANGEMin=3D0, Max=3D100ConnectorTBD
tv_brightness_property=E2=80=9Cbrightness=E2=80=9DDRM_MODE_PROP_RANGEMin=3D0, Max=3D100ConnectorTBD
tv_contrast_property=E2=80=9Ccontrast=E2=80=9DDRM_MODE_PROP_RANGEMin=3D0, Max=3D100ConnectorTBD
tv_flicker_reduction_property=E2=80=9Cflicker reduction=E2=80=9DDRM_MODE_PROP_RANGEMin=3D0, Max=3D100ConnectorTBD
tv_overscan_property=E2=80=9Coverscan=E2=80=9DDRM_MODE_PROP_RANGEMin=3D0, Max=3D100ConnectorTBD
tv_saturation_property=E2=80=9Csaturation=E2=80=9DDRM_MODE_PROP_RANGEMin=3D0, Max=3D100ConnectorTBD
tv_hue_property=E2=80=9Chue=E2=80=9DDRM_MODE_PROP_RANGEMin=3D0, Max=3D100ConnectorTBD
Optional Propertiesscaling_mode_property=E2=80=9Cscaling mode=E2=80=9DDRM_MODE_PROP_ENUM{ DRM_MODE_SCALE_NONE, "None" }, > +{ DRM_MODE_SCALE_FULLSCREEN, "Full" }, > +{ DRM_MODE_SCALE_CENTER, "Center" }, > +{ DRM_MODE_SCALE_ASPECT, "Full aspect" }ConnectorTBD
dirty_info_property=E2=80=9Cdirty=E2=80=9DDRM_MODE_PROP_ENUM | DRM_MODE_PROP_IMMUTABLE > +{ DRM_MODE_DIRTY_OFF, "Off" }, > +{ DRM_MODE_DIRTY_ON, "On" }, > +{ DRM_MODE_DIRTY_ANNOTATE, "Annotate" }ConnectorTBD
i915Genericbroadcast_rgb_property"Broadcast RGB"DRM_MODE_PROP_ENUM{ INTEL_BROADCAST_RGB_AUTO, "Automatic" }, > +{ INTEL_BROADCAST_RGB_FULL, "Full" }, > +{ INTEL_BROADCAST_RGB_LIMITED, "Limited 16:235" }ConnectorTBD
force_audio_property=E2=80=9Caudio=E2=80=9DDRM_MODE_PROP_ENUM{ HDMI_AUDIO_OFF_DVI, "force-dvi" }, > +{ HDMI_AUDIO_OFF, "off" }, > +{ HDMI_AUDIO_AUTO, "auto" }, > +{ HDMI_AUDIO_ON, "on" }ConnectorTBD
scaling_mode_property > +=20 > +Standard name as in DRMStandard type as in DRMStandard value as in DRMStandard Object as in DRMTBD
SDVO-TVtv_format=E2=80=9Cmode=E2=80=9DDRM_MODE_PROP_ENUM{0, "NTSC_M"} , {1, "NTSC_J"} , > +{2, "NTSC_443"}, {3, "PAL_B"} etc.ConnectorTBD
left"left_margin"DRM_MODE_PROP_RANGEMin=3D0, Max=3D SDVO dependentConnectorTBD
right"right_margin"DRM_MODE_PROP_RANGEMin=3D0, Max=3D SDVO dependentConnectorTBD
top"top_margin"DRM_MODE_PROP_RANGEMin=3D0, Max=3D SDVO dependentConnectorTBD
bottom"bottom_margin"DRM_MODE_PROP_RANGEMin=3D0, Max=3D SDVO dependentConnectorTBD
hpos=E2=80=9Chpos=E2=80=9DDRM_MODE_PROP_RANGEMin=3D0, Max=3D SDVO dependentConnectorTBD
vpos=E2=80=9Cvpos=E2=80=9DDRM_MODE_PROP_RANGEMin=3D0, Max=3D SDVO dependentConnectorTBD
contrast=E2=80=9Ccontrast=E2=80=9DDRM_MODE_PROP_RANGEMin=3D0, Max=3D SDVO dependentConnectorTBD
saturation=E2=80=9Csaturation=E2=80=9DDRM_MODE_PROP_RANGEMin=3D0, Max=3D SDVO dependentConnectorTBD
hue=E2=80=9Chue=E2=80=9DDRM_MODE_PROP_RANGEMin=3D0, Max=3D SDVO dependentConnectorTBD
sharpness=E2=80=9Csharpness=E2=80=9DDRM_MODE_PROP_RANGEMin=3D0, Max=3D SDVO dependentConnectorTBD
flicker_filter=E2=80=9Cflicker_filter=E2=80=9DDRM_MODE_PROP_RANGEMin=3D0, Max=3D SDVO dependentConnectorTBD
flicker_filter_adaptive=E2=80=9Cflicker_filter_adaptive=E2=80=9DDRM_MODE_PROP_RANGEMin=3D0, Max=3D SDVO dependentConnectorTBD
flicker_filter_2d=E2=80=9Cflicker_filter_2d=E2=80=9DDRM_MODE_PROP_RANGEMin=3D0, Max=3D SDVO dependentConnectorTBD
tv_chroma_filter=E2=80=9Ctv_chroma_filter=E2=80=9DDRM_MODE_PROP_RANGEMin=3D0, Max=3D SDVO dependentConnectorTBD
tv_luma_filter=E2=80=9Ctv_luma_filter=E2=80=9DDRM_MODE_PROP_RANGEMin=3D0, Max=3D SDVO dependentConnectorTBD
dot_crawl=E2=80=9Cdot_crawl=E2=80=9DDRM_MODE_PROP_RANGEMin=3D0, Max=3D1ConnectorTBD
SDVO-TV/LVDSbrightness=E2=80=9Cbrightness=E2=80=9DDRM_MODE_PROP_RANGEMin=3D0, Max=3D SDVO dependentConnectorTBD
CDV gma-500Genericbroadcast_rgb_property"Broadcast RGB"DRM_MODE_PROP_ENUM{ 0, =E2=80=9CFull=E2=80=9D}, > +{ 1, =E2=80=9CLimited 16:235=E2=80=9D}ConnectorTBD
force_audio_property"Broadcast RGB"DRM_MODE_PROP_ENUM{ -1, =E2=80=9Coff=E2=80=9D}, > +{ 0, =E2=80=9Cauto=E2=80=9D}, > +{ 1, =E2=80=9Con=E2=80=9D}ConnectorTBD
scaling_mode_property > +=20 > +Standard name as in DRMStandard type as in DRMStandard value as in DRMStandard Object as in DRMTBD
PoulsboGenericbacklight_property=E2=80=9Cbacklight=E2=80=9DDRM_MODE_PROP_RANGEMin=3D0, Max=3D100ConnectorTBD
scaling_mode_property > +=20 > +Standard name as in DRMStandard type as in DRMStandard value as in DRMStandard Object as in DRMTBD
SDVO-TVtv_format=E2=80=9Cmode=E2=80=9DDRM_MODE_PROP_ENUM{0, "NTSC_M"} , {1, "NTSC_J"} , > +=20 > +{2, "NTSC_443"}, {3, "PAL_B"} etc.ConnectorTBD
left"left_margin"DRM_MODE_PROP_RANGEMin=3D0, Max=3D SDVO dependentConnectorTBD
right"right_margin"DRM_MODE_PROP_RANGEMin=3D0, Max=3D SDVO dependentConnectorTBD
top"top_margin"DRM_MODE_PROP_RANGEMin=3D0, Max=3D SDVO dependentConnectorTBD
bottom"bottom_margin"DRM_MODE_PROP_RANGEMin=3D0, Max=3D SDVO dependentConnectorTBD
hpos=E2=80=9Chpos=E2=80=9DDRM_MODE_PROP_RANGEMin=3D0, Max=3D SDVO dependentConnectorTBD
vpos=E2=80=9Cvpos=E2=80=9DDRM_MODE_PROP_RANGEMin=3D0, Max=3D SDVO dependentConnectorTBD
contrast=E2=80=9Ccontrast=E2=80=9DDRM_MODE_PROP_RANGEMin=3D0, Max=3D SDVO dependentConnectorTBD
saturation=E2=80=9Csaturation=E2=80=9DDRM_MODE_PROP_RANGEMin=3D0, Max=3D SDVO dependentConnectorTBD
hue=E2=80=9Chue=E2=80=9DDRM_MODE_PROP_RANGEMin=3D0, Max=3D SDVO dependentConnectorTBD
sharpness=E2=80=9Csharpness=E2=80=9DDRM_MODE_PROP_RANGEMin=3D0, Max=3D SDVO dependentConnectorTBD
flicker_filter=E2=80=9Cflicker_filter=E2=80=9DDRM_MODE_PROP_RANGEMin=3D0, Max=3D SDVO dependentConnectorTBD
flicker_filter_adaptive=E2=80=9Cflicker_filter_adaptive=E2=80=9DDRM_MODE_PROP_RANGEMin=3D0, Max=3D SDVO dependentConnectorTBD
flicker_filter_2d=E2=80=9Cflicker_filter_2d=E2=80=9DDRM_MODE_PROP_RANGEMin=3D0, Max=3D SDVO dependentConnectorTBD
tv_chroma_filter=E2=80=9Ctv_chroma_filter=E2=80=9DDRM_MODE_PROP_RANGEMin=3D0, Max=3D SDVO dependentConnectorTBD
tv_luma_filter=E2=80=9Ctv_luma_filter=E2=80=9DDRM_MODE_PROP_RANGEMin=3D0, Max=3D SDVO dependentConnectorTBD
dot_crawl=E2=80=9Cdot_crawl=E2=80=9DDRM_MODE_PROP_RANGEMin=3D0, Max=3D1ConnectorTBD
SDVO-TV/LVDSbrightness=E2=80=9Cbrightness=E2=80=9DDRM_MODE_PROP_RANGEMin=3D0, Max=3D SDVO dependentConnectorTBD
armadaCRTCcsc_yuv_prop"CSC_YUV"DRM_MODE_PROP_ENUM{ CSC_AUTO, "Auto" }, > +{ CSC_YUV_CCIR601, "CCIR601" }, > +{ CSC_YUV_CCIR709, "CCIR709" }CRTCTBD
csc_rgb_prop"CSC_RGB"DRM_MODE_PROP_ENUM{ CSC_AUTO, "Auto" }, > +{ CSC_RGB_COMPUTER, "Computer system" }, > +{ CSC_RGB_STUDIO, "Studio" }CRTCTBD
Overlaycolorkey_prop"colorkey"DRM_MODE_PROP_RANGEMin=3D0, Max=3D0xffffffPlaneTBD
colorkey_min_prop"colorkey_min"DRM_MODE_PROP_RANGEMin=3D0, Max=3D0xffffffPlaneTBD
colorkey_max_prop"colorkey_max"DRM_MODE_PROP_RANGEMin=3D0, Max=3D0xffffffPlaneTBD
colorkey_val_prop"colorkey_val"DRM_MODE_PROP_RANGEMin=3D0, Max=3D0xffffffPlaneTBD
colorkey_alpha_prop"colorkey_alpha"DRM_MODE_PROP_RANGEMin=3D0, Max=3D0xffffffPlaneTBD
colorkey_mode_prop"colorkey_mode"DRM_MODE_PROP_ENUM{ CKMODE_DISABLE, "disabled" }, > +{ CKMODE_Y, "Y component" }, > +{ CKMODE_U, "U component" }, > +{ CKMODE_V, "V component" }, > +{ CKMODE_RGB, "RGB" }, > +{ CKMODE_R, =E2=80=9CR component" }, > +{ CKMODE_G, "G component" }, > +{ CKMODE_B, "B component" }PlaneTBD
brightness_prop"brightness"DRM_MODE_PROP_RANGEMin=3D0, Max=3D256 + 255PlaneTBD
contrast_prop"contrast"DRM_MODE_PROP_RANGEMin=3D0, Max=3D0x7fffPlaneTBD
saturation_prop"saturation"DRM_MODE_PROP_RANGEMin=3D0, Max=3D0x7fffPlaneTBD
exynosCRTCcrtc_mode_property=E2=80=9Cmode=E2=80=9DDRM_MODE_PROP_ENUM{ CRTC_MODE_NORMAL, "normal" }, > +{ CRTC_MODE_BLANK, "blank" }CRTCTBD
Overlayplane_zpos_property=E2=80=9Czpos=E2=80=9DDRM_MODE_PROP_RANGEMin=3D0, Max=3DMAX_PLANE-1PlaneTBD
i2c/ch7006_drvGenericscale_property=E2=80=9Cscale=E2=80=9DDRM_MODE_PROP_RANGEMin=3D0, Max=3D2ConnectorTBD
TV-Propertiesleft, > +right, > +top, > +bottom, > +hpos, > +vpos, > +contrast, > +saturation, > +hue, > +sharpness, > +flicker_filter, > +flicker_filter_adaptive, > +flicker_filter_2d, > +tv_chroma_filter, > +tv_luma_filter, > +dot_crawl,Standard names as in DRMStandard types as in DRMStandard Values as in DRMStandard object as in DRMTBD
tv_format=E2=80=9Cmode=E2=80=9DDRM_MODE_PROP_ENUM{0, "PAL"}, {1, "PAL-M"}, {2,"PAL-N"}, > +{2,=E2=80=9DPAL-Nc"}, {3, "PAL-60"}, {4, "NTSC-M"}, > +{5,"NTSC-J"}ConnectorTBD
noveauNV10 Overlaycolorkey"colorkey"DRM_MODE_PROP_RANGEMin=3D0, Max=3D0x01ffffffPlaneTBD
contrast=E2=80=9Ccontrast=E2=80=9DDRM_MODE_PROP_RANGEMin=3D0, Max=3D8192-1PlaneTBD
brightness=E2=80=9Cbrightness=E2=80=9DDRM_MODE_PROP_RANGEMin=3D0, Max=3D1024PlaneTBD
hue=E2=80=9Chue=E2=80=9DDRM_MODE_PROP_RANGEMin=3D0, Max=3D359PlaneTBD
saturation=E2=80=9Csaturation=E2=80=9DDRM_MODE_PROP_RANGEMin=3D0, Max=3D8192-1PlaneTBD
iturbt_709=E2=80=9Citurbt_709=E2=80=9DDRM_MODE_PROP_RANGEMin=3D0, Max=3D1PlaneTBD
Nv04 Overlaycolorkey=E2=80=9Ccolorkey=E2=80=9DDRM_MODE_PROP_RANGEMin=3D0, Max=3D0x01ffffffPlaneTBD
brightness=E2=80=9Cbrightness=E2=80=9DDRM_MODE_PROP_RANGEMin=3D0, Max=3D1024PlaneTBD
Displaydithering_mode=E2=80=9Cdithering mode=E2=80=9DDRM_MODE_PROP_ENUMCustom values which has gen info as well. > +{ 6, UNDERSCAN_AUTO, "auto" }, > +{ 6, UNDERSCAN_OFF, "off" }, > +{ 6, UNDERSCAN_ON, "on" }ConnectorTBD
dithering_depth=E2=80=9Cdithering depth=E2=80=9DDRM_MODE_PROP_ENUMCustom values which has gen info as well. > +{ 7, DITHERING_MODE_AUTO, "auto" }, > +{ 7, DITHERING_MODE_OFF, "off" }, > +{ 1, DITHERING_MODE_ON, "on" }, > +{ 6, DITHERING_MODE_STATIC2X2, "static 2x2" }, > +{ 6, DITHERING_MODE_DYNAMIC2X2, "dynamic 2x2" }, > +{ 4, DITHERING_MODE_TEMPORAL, "temporal" }ConnectorTBD
underscan_property=E2=80=9Cunderscan=E2=80=9DDRM_MODE_PROP_ENUMCustom values which has gen info as well. > +{ 6, DITHERING_DEPTH_AUTO, "auto" }, > +{ 6, DITHERING_DEPTH_6BPC, "6 bpc" }, > +{ 6, DITHERING_DEPTH_8BPC, "8 bpc" }ConnectorTBD
underscan_hborder_property=E2=80=9Cunderscan hborder=E2=80=9DDRM_MODE_PROP_RANGEMin=3D0, Max=3D128ConnectorTBD
underscan_vborder_property=E2=80=9Cunderscan vborder=E2=80=9DDRM_MODE_PROP_RANGEMin=3D0, Max=3D128ConnectorTBD
vibrant_hue_property=E2=80=9Cvibrant hue=E2=80=9DDRM_MODE_PROP_RANGEMin=3D0, Max=3D180ConnectorTBD
color_vibrance_property=E2=80=9Ccolor vibrance=E2=80=9DDRM_MODE_PROP_RANGEMin=3D0, Max=3D200ConnectorTBD
Genericscaling_mode_property > +=20 > +Standard name as in DRMStandard type as in DRMStandard value as in DRMStandard Object as in DRMTBD
omapGenericrotation_prop=E2=80=9Crotation=E2=80=9DDRM_MODE_PROP_BITMASK{ 0, "rotate-0" }, > +{ 1, "rotate-90" }, > +{ 2, "rotate-180" }, > +{ 3, "rotate-270" }, > +{ 4, "reflect-x" }, > +{ 5, "reflect-y" }CRTC, PlaneTBD
zorder_prop=E2=80=9Czorder=E2=80=9DDRM_MODE_PROP_RANGEMin=3D0, Max=3D3CRTC, PlaneTBD
qxlGenerichotplug_mode_update_property=E2=80=9Chotplug_mode_update"DRM_MODE_PROP_RANGEMin=3D0, Max=3D1ConnectorTBD
radeonDVI-Icoherent_mode_property=E2=80=9Ccoherent=E2=80=9DDRM_MODE_PROP_RANGEMin=3D0, Max=3D1ConnectorTBD
DAC enable load detectload_detect_property=E2=80=9Cload detection=E2=80=9DDRM_MODE_PROP_RANGEMin=3D0, Max=3D1ConnectorTBD
TV Standardtv_std_property"tv standard"DRM_MODE_PROP_ENUM{ TV_STD_NTSC, "ntsc" }, > +{ TV_STD_PAL, "pal" }, > +{ TV_STD_PAL_M, "pal-m" }, > +{ TV_STD_PAL_60, "pal-60" }, > +{ TV_STD_NTSC_J, "ntsc-j" }, > +{ TV_STD_SCART_PAL, "scart-pal" }, > +{ TV_STD_PAL_CN, "pal-cn" }, > +{ TV_STD_SECAM, "secam" }ConnectorTBD
legacy TMDS PLL detecttmds_pll_property"tmds_pll"DRM_MODE_PROP_ENUM{ 0, "driver" }, > +{ 1, "bios" }-TBD
Underscanunderscan_property"underscan"DRM_MODE_PROP_ENUM{ UNDERSCAN_OFF, "off" }, > +{ UNDERSCAN_ON, "on" }, > +{ UNDERSCAN_AUTO, "auto" }ConnectorTBD
underscan_hborder_property"underscan hborder"DRM_MODE_PROP_RANGEMin=3D0, Max=3D128ConnectorTBD
underscan_vborder_property"underscan vborder"DRM_MODE_PROP_RANGEMin=3D0, Max=3D128ConnectorTBD
Audioaudio_property=E2=80=9Caudio=E2=80=9DDRM_MODE_PROP_ENUM{ RADEON_AUDIO_DISABLE, "off" }, > +{ RADEON_AUDIO_ENABLE, "on" }, > +{ RADEON_AUDIO_AUTO, "auto" }ConnectorTBD
FMT Ditheringdither_property=E2=80=9Cdither=E2=80=9DDRM_MODE_PROP_ENUM{ RADEON_FMT_DITHER_DISABLE, "off" }, > +{ RADEON_FMT_DITHER_ENABLE, "on" }ConnectorTBD
Genericscaling_mode_property > +=20 > +Standard name as in DRMStandard type as in DRMStandard value as in DRMStandard Object as in DRMTBD
rcar-duGenericalpha"alpha"DRM_MODE_PROP_RANGEMin=3D0, Max=3D255PlaneTBD
colorkey"colorkey"DRM_MODE_PROP_RANGEMin=3D0, Max=3D0x01ffffffPlaneTBD
zpos"zpos"DRM_MODE_PROP_RANGEMin=3D1, Max=3D7PlaneTBD
> > =20 > > --=20 > 1.8.5 --=20 Ville Syrj=C3=A4l=C3=A4 Intel OTC From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sagar Arun Kamble Subject: Re: [PATCH v2 1/1] Documentation: drm: describing drm properties exposed by various drivers Date: Thu, 06 Mar 2014 19:31:24 +0530 Message-ID: <1394114484.31978.11.camel@sagar-desktop> References: <1394016990-5218-1-git-send-email-sagar.a.kamble@intel.com> <1394090125-30029-1-git-send-email-sagar.a.kamble@intel.com> <20140306120938.GC3852@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <20140306120938.GC3852@intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces@lists.freedesktop.org Errors-To: intel-gfx-bounces@lists.freedesktop.org To: Ville =?ISO-8859-1?Q?Syrj=E4l=E4?= Cc: Laurent Pinchart , linux-doc@vger.kernel.org, Daniel Vetter , intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, Rob Landley , David Herrmann , Alex Deucher , Dave Airlie List-Id: dri-devel@lists.freedesktop.org T24gVGh1LCAyMDE0LTAzLTA2IGF0IDE0OjA5ICswMjAwLCBWaWxsZSBTeXJqw6Rsw6Qgd3JvdGU6 Cj4gT24gVGh1LCBNYXIgMDYsIDIwMTQgYXQgMTI6NDU6MjVQTSArMDUzMCwgc2FnYXIuYS5rYW1i bGVAaW50ZWwuY29tIHdyb3RlOgo+ID4gRnJvbTogU2FnYXIgS2FtYmxlIDxzYWdhci5hLmthbWJs ZUBpbnRlbC5jb20+Cj4gPiAKPiA+IFN0YXJ0ZWQgZG9jdW1lbnRpbmcgZHJtIHByb3BlcnRpZXMg Zm9yIGRybSBkcml2ZXJzLiBUaGlzIHBhdGNoIHByb3ZpZGVzCj4gPiBpbmZvcm1hdGlvbiBhYm91 dCBwcm9wZXJ0aWVzIGluIGRybSwgaTkxNSwgcHNiIGFuZCBjZHYvZ21hLTUwMC4gSW5mb3JtYXRp b24KPiA+IGFib3V0IG90aGVyIHByb3BlcnRpZXMgY2FuIGJlIGFkZGVkIG9uIHRvcCBvZiB0aGVz ZS4KPiA+IAo+ID4gdjI6IEFkZGVkIGRlc2NyaXB0aW9uIG9mIGRybSBwcm9wZXJ0aWVzIGluIGFy bWFkYSwgZXh5bm9zLCBpMmMvY2g3MDA2LCBub3ZlYXUsCj4gPiBvbWFwLCBxeGwsIHJhZGVvbiwg cmNhci1kdQo+IAo+IExvb2tzIGxpa2UgZHJpLWRldmVsIHdhc24ndCBjYzpkLCBzbyBJJ20gYWRk aW5nIHRoYXQuLi4KPiAKPiBUaGFua3MgZm9yIHRhY2tsaW5nIHRoaXMuCj4gCj4gSSB0aGluayBv bmUgY2hhbmdlIEkgd291bGQgZG8gaXMgZHJvcCB0aGUgIlByb3BlcnR5IE9iamVjdCIgY29sdW1u Lgo+IEl0J3MgcHVyZWx5IGFuIGltcGxlbWVudGF0aW9uIGRldGFpbCBhbmQgdGh1cyBoYXMgbm8g YmVhcmluZyBvbiBhbnkKPiBBQkkvQVBJIGlzc3VlcywgYW5kIHRoZXJlJ3MgYSByaXNrIG9mIGl0 IGdldHRpbmcgc3RhbGUgZHVlIHRvIGNvZGUKPiBjaGFuZ2VzLiBJdCBzaG91bGQgYWxzbyBtYWtl IHRoZSB0YWJsZSBhIGJpdCBsZXNzIGNyb3dkZWQuCj4gCj4gQW5vdGhlciB3YXkgdG8gbWF5YmUg bWFrZSB0aGUgdGFibGUgYSBiaXQgbGVzcyB3aWRlIGlzIHRvIGRyb3AKPiB0aGUgRFJNX01PREVf UFJPUF8gcHJlZml4IGZyb20gdGhlIHR5cGUgaW5mb3JtYXRpb24uIEp1c3Qgc2F5aW5nCj4gQkxP QiwgRU5VTSwgZXRjLiBzaG91bGQgYmUgZW5vdWdoLiBCdXQgaWYgcGVvcGxlIHByZWZlciB0byBz ZWUgdGhlCj4gd2hvbGUgdHlwZSBuYW1lIHRoZXJlLCBJJ20gZmluZSB3aXRoIGxlYXZpbmcgaXQg YXMgaXMuCldpbGwgaW5jb3Jwb3JhdGUgdGhlc2UgY2hhbmdlcy4gRFJNX01PREVfUFJPUCBwcmVm aXggaXMga2luZCBvZgpyZWR1bmRhbnQgc28gd2lsbCByZW1vdmUgaXQuCj4gCj4gV2l0aCB0aGlz IGRvY3VtZW50YXRpb24gSSBjYW4gaW1tZWRpYXRlbHkgc3BvdCBzZXZlcmFsIG1vcmUgb3IgbGVz cwo+IGlkZW50aWNhbCBzYW1lIHByb3BlcnRpZXMgYnV0IHdpdGggc2xpZ2h0bHkgZGlmZmVyZW50 IG5hbWVzIDooIEkKPiByZWFsbHkgaG9wZSB3ZSBjYW4gbm93IHN0YXJ0IHRvIGF2b2lkIHRoYXQg bWlzdGFrZSBieSBtYWtpbmcgc3VyZQo+IHRoYXQgcGVvcGxlIGFkZCBhbGwgbmV3IHByb3BlcnRp ZXMgdG8gdGhpcyBkb2N1bWVudC4gQW5kIGJlZm9yZQo+IGFkZGluZyBhIG5ldyBwcm9wZXJ0eSBw ZW9wbGUgc2hvdWxkIGNoZWNrIHRoZSBkb2N1bWVudCB0byBzZWUgaWYKPiBzb21ldGhpbmcgc2lt aWxhciBtaWdodCBhbHJlYWR5IGV4aXN0LgoKQWdyZWUgd2l0aCB0aGlzLgo+IAo+ID4gCj4gPiBD YzogUm9iIExhbmRsZXkgPHJvYkBsYW5kbGV5Lm5ldD4KPiA+IENjOiBEYXZlIEFpcmxpZSA8YWly bGllZEByZWRoYXQuY29tPgo+ID4gQ2M6IERhbmllbCBWZXR0ZXIgPGRhbmllbC52ZXR0ZXJAZmZ3 bGwuY2g+Cj4gPiBDYzogTGF1cmVudCBQaW5jaGFydCA8bGF1cmVudC5waW5jaGFydCtyZW5lc2Fz QGlkZWFzb25ib2FyZC5jb20+Cj4gPiBDYzogRGF2aWQgSGVycm1hbm4gPGRoLmhlcnJtYW5uQGdt YWlsLmNvbT4KPiA+IENjOiBBbGV4IERldWNoZXIgPGFsZXhhbmRlci5kZXVjaGVyQGFtZC5jb20+ Cj4gPiBDYzogIlZpbGxlIFN5cmrDpGzDpCIgPHZpbGxlLnN5cmphbGFAbGludXguaW50ZWwuY29t Pgo+ID4gQ2M6IFNhZ2FyIEthbWJsZSA8c2FnYXIuYS5rYW1ibGVAaW50ZWwuY29tPgo+ID4gQ2M6 ICJQdXJ1c2hvdGhhbWFuLCBWaWpheSBBIiA8dmlqYXkuYS5wdXJ1c2hvdGhhbWFuQGludGVsLmNv bT4KPiA+IENjOiBsaW51eC1kb2NAdmdlci5rZXJuZWwub3JnCj4gPiAKPiA+IFNpZ25lZC1vZmYt Ynk6IFNhZ2FyIEthbWJsZSA8c2FnYXIuYS5rYW1ibGVAaW50ZWwuY29tPgo+ID4gLS0tCj4gPiAg RG9jdW1lbnRhdGlvbi9Eb2NCb29rL2RybS50bXBsIHwgMTE2MyArKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrCj4gPiAgMSBmaWxlIGNoYW5nZWQsIDExNjMgaW5zZXJ0aW9u cygrKQo+ID4gCj4gPiBkaWZmIC0tZ2l0IGEvRG9jdW1lbnRhdGlvbi9Eb2NCb29rL2RybS50bXBs IGIvRG9jdW1lbnRhdGlvbi9Eb2NCb29rL2RybS50bXBsCj4gPiBpbmRleCBlZDFkNmQyLi40Nzcy NjNlIDEwMDY0NAo+ID4gLS0tIGEvRG9jdW1lbnRhdGlvbi9Eb2NCb29rL2RybS50bXBsCj4gPiAr KysgYi9Eb2N1bWVudGF0aW9uL0RvY0Jvb2svZHJtLnRtcGwKPiA+IEBAIC0yMzE3LDYgKzIzMTcs MTE2OSBAQCB2b2lkIGludGVsX2NydF9pbml0KHN0cnVjdCBkcm1fZGV2aWNlICpkZXYpCj4gPiAg ICAgICAgcG9pbnRlciB0byB0aGUgdGFyZ2V0IG9iamVjdCwgYSBwb2ludGVyIHRvIHRoZSBwcmV2 aW91c2x5IGNyZWF0ZWQgcHJvcGVydHkKPiA+ICAgICAgICBhbmQgYW4gaW5pdGlhbCBpbnN0YW5j ZSB2YWx1ZS4KPiA+ICAgICAgPC9wYXJhPgo+ID4gKyAgICA8cGFyYT4KPiA+ICsgICAgIEZvbGxv d2luZyB0YWJsZSBnaXZlcyBkZXNjcmlwdGlvbiBvZiBkcm0gcHJvcGVydGllcyBleHBvc2VkIGJ5 IHZhcmlvdXMKPiA+ICsgICAgIG1vZHVsZXMvZHJpdmVycy4KPiA+ICsgICAgPC9wYXJhPgo+ID4g Kzx0YWJsZSBib3JkZXI9IjEiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMCIgPgo+ID4g Kzx0Ym9keT4KPiA+ICs8dHIgc3R5bGU9ImZvbnQtd2VpZ2h0OiBib2xkOyIgPgo+ID4gKzx0ZCB2 YWxpZ249InRvcCIgPk93bmVyIE1vZHVsZS9Ecml2ZXJzPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0 b3AiID5Hcm91cDwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+UHJvcGVydHkgT2JqZWN0PC90 ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5Qcm9wZXJ0eSBOYW1lPC90ZD4KPiA+ICs8dGQgdmFs aWduPSJ0b3AiID5UeXBlPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5Qcm9wZXJ0eSBWYWx1 ZXM8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPk9iamVjdCBhdHRhY2hlZDwvdGQ+Cj4gPiAr PHRkIHZhbGlnbj0idG9wIiA+RGVzY3JpcHRpb24vUmVzdHJpY3Rpb25zPC90ZD4KPiA+ICs8L3Ry Pgo+ID4gKyAKPiA+ICs8dHI+Cj4gPiArPHRkIHJvd3NwYW49IjE5IiB2YWxpZ249InRvcCIgPkRS TTwvdGQ+Cj4gPiArPHRkIHJvd3NwYW49IjIiIHZhbGlnbj0idG9wIiA+R2VuZXJpYyBQcm9wZXJ0 aWVzPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5lZGlkX3Byb3BlcnR5PC90ZD4KPiA+ICs8 dGQgdmFsaWduPSJ0b3AiID7igJxFRElE4oCdPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5E Uk1fTU9ERV9QUk9QX0JMT0IgfCBEUk1fTU9ERV9QUk9QX0lNTVVUQUJMRTwvdGQ+Cj4gPiArPHRk IHZhbGlnbj0idG9wIiA+MDwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+Q29ubmVjdG9yPC90 ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5Db250YWlucyBpZCBvZiBlZGlkIGJsb2IgcHRyIG9i amVjdC48L3RkPgo+ID4gKzwvdHI+Cj4gPiArIAo+ID4gKzx0cj4KPiA+ICs8dGQgdmFsaWduPSJ0 b3AiID5kcG1zX3Byb3BlcnR5PC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID7igJxEUE1T4oCd PC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5EUk1fTU9ERV9QUk9QX0VOVU08L3RkPgo+ID4g Kzx0ZCB2YWxpZ249InRvcCIgPnsgRFJNX01PREVfRFBNU19PTiwg4oCcT27igJ19LAo+ID4gK3sg RFJNX01PREVfRFBNU19TVEFOREJZLCDigJxTdGFuZGJ54oCdfSwKPiA+ICt7IERSTV9NT0RFX0RQ TVNfU1VTUEVORCwg4oCcU3VzcGVuZOKAnX0sCj4gPiAreyBEUk1fTU9ERV9EUE1TX09GRiwg4oCc T2Zm4oCdfTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+Q29ubmVjdG9yPC90ZD4KPiA+ICs8 dGQgdmFsaWduPSJ0b3AiID5Db250YWlucyBEUE1TIG9wZXJhdGlvbiBtb2RlIHZhbHVlLjwvdGQ+ Cj4gPiArPC90cj4KPiA+ICsgCj4gPiArPHRyPgo+ID4gKzx0ZCByb3dzcGFuPSIyIiB2YWxpZ249 InRvcCIgPkRWSS1JIFByb3BlcnRpZXM8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPmR2aV9p X3N1YmNvbm5lY3Rvcl9wcm9wZXJ0eTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+4oCcc3Vi Y29ubmVjdG9y4oCdPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5EUk1fTU9ERV9QUk9QX0VO VU08L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPnsgRFJNX01PREVfU1VCQ09OTkVDVE9SX1Vu a25vd24sIOKAnFVua25vd27igJ19LAo+ID4gK3sgRFJNX01PREVfU1VCQ09OTkVDVE9SX0RWSUQs IOKAnERWSS1E4oCdfSwKPiA+ICt7IERSTV9NT0RFX1NVQkNPTk5FQ1RPUl9EVklBLCDigJxEVkkt QeKAnX08L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPkNvbm5lY3RvcjwvdGQ+Cj4gPiArPHRk IHZhbGlnbj0idG9wIiA+VEJEPC90ZD4KPiA+ICs8L3RyPgo+ID4gKyAKPiA+ICs8dHI+Cj4gPiAr PHRkIHZhbGlnbj0idG9wIiA+ZHZpX2lfc2VsZWN0X3N1YmNvbm5lY3Rvcl9wcm9wZXJ0eTwvdGQ+ Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+4oCcc2VsZWN0IHN1YmNvbm5lY3RvcuKAnTwvdGQ+Cj4g PiArPHRkIHZhbGlnbj0idG9wIiA+RFJNX01PREVfUFJPUF9FTlVNPC90ZD4KPiA+ICs8dGQgdmFs aWduPSJ0b3AiID57IERSTV9NT0RFX1NVQkNPTk5FQ1RPUl9BdXRvbWF0aWMsIOKAnEF1dG9tYXRp Y+KAnX0sCj4gPiAreyBEUk1fTU9ERV9TVUJDT05ORUNUT1JfRFZJRCwg4oCcRFZJLUTigJ19LAo+ ID4gK3sgRFJNX01PREVfU1VCQ09OTkVDVE9SX0RWSUEsIOKAnERWSS1B4oCdfTwvdGQ+Cj4gPiAr PHRkIHZhbGlnbj0idG9wIiA+Q29ubmVjdG9yPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5U QkQ8L3RkPgo+ID4gKzwvdHI+Cj4gPiArIAo+ID4gKzx0cj4KPiA+ICs8dGQgcm93c3Bhbj0iMTMi IHZhbGlnbj0idG9wIiA+VFYgUHJvcGVydGllczwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+ dHZfc3ViY29ubmVjdG9yX3Byb3BlcnR5PC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID7igJxz dWJjb25uZWN0b3LigJ08L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPkRSTV9NT0RFX1BST1Bf RU5VTTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+eyBEUk1fTU9ERV9TVUJDT05ORUNUT1Jf VW5rbm93biwgIlVua25vd24ifSwKPiA+ICt7IERSTV9NT0RFX1NVQkNPTk5FQ1RPUl9Db21wb3Np dGUsICJDb21wb3NpdGUiIH0sCj4gPiAreyBEUk1fTU9ERV9TVUJDT05ORUNUT1JfU1ZJREVPLCAi U1ZJREVPIn0sCj4gPiAreyBEUk1fTU9ERV9TVUJDT05ORUNUT1JfQ29tcG9uZW50ICwgIkNvbXBv bmVudCJ9LAo+ID4gK3sgRFJNX01PREVfU1VCQ09OTkVDVE9SX1NDQVJULCAiU0NBUlQifTwvdGQ+ Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+Q29ubmVjdG9yPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0 b3AiID5UQkQ8L3RkPgo+ID4gKzwvdHI+Cj4gPiArIAo+ID4gKzx0cj4KPiA+ICs8dGQgdmFsaWdu PSJ0b3AiID50dl9zZWxlY3Rfc3ViY29ubmVjdG9yX3Byb3BlcnR5PC90ZD4KPiA+ICs8dGQgdmFs aWduPSJ0b3AiID7igJxzZWxlY3Qgc3ViY29ubmVjdG9y4oCdPC90ZD4KPiA+ICs8dGQgdmFsaWdu PSJ0b3AiID5EUk1fTU9ERV9QUk9QX0VOVU08L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPntE Uk1fTU9ERV9TVUJDT05ORUNUT1JfQXV0b21hdGljLCAiQXV0b21hdGljIn0sCj4gPiAre0RSTV9N T0RFX1NVQkNPTk5FQ1RPUl9Db21wb3NpdGUsICJDb21wb3NpdGUifSwKPiA+ICt7RFJNX01PREVf U1VCQ09OTkVDVE9SX1NWSURFTywgIlNWSURFTyJ9LAo+ID4gK3tEUk1fTU9ERV9TVUJDT05ORUNU T1JfQ29tcG9uZW50LCAiQ29tcG9uZW50In0sCj4gPiAre0RSTV9NT0RFX1NVQkNPTk5FQ1RPUl9T Q0FSVCwgIlNDQVJUIn08L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPkNvbm5lY3RvcjwvdGQ+ Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+VEJEPC90ZD4KPiA+ICs8L3RyPgo+ID4gKyAKPiA+ICs8 dHI+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+dHZfbW9kZV9wcm9wZXJ0eTwvdGQ+Cj4gPiArPHRk IHZhbGlnbj0idG9wIiA+4oCcbW9kZeKAnTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+RFJN X01PREVfUFJPUF9FTlVNPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID57MCwgIk5UU0NfTSJ9 ICwgezEsICJOVFNDX0oifSAsCj4gPiArezIsICJOVFNDXzQ0MyJ9LCB7MywgIlBBTF9CIn0gZXRj LjwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+Q29ubmVjdG9yPC90ZD4KPiA+ICs8dGQgdmFs aWduPSJ0b3AiID5UQkQ8L3RkPgo+ID4gKzwvdHI+Cj4gPiArIAo+ID4gKzx0cj4KPiA+ICs8dGQg dmFsaWduPSJ0b3AiID50dl9sZWZ0X21hcmdpbl9wcm9wZXJ0eTwvdGQ+Cj4gPiArPHRkIHZhbGln bj0idG9wIiA+4oCcbGVmdCBtYXJnaW7igJ08L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPkRS TV9NT0RFX1BST1BfUkFOR0U8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPk1pbj0wLCBNYXg9 MTAwPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5Db25uZWN0b3I8L3RkPgo+ID4gKzx0ZCB2 YWxpZ249InRvcCIgPlRCRDwvdGQ+Cj4gPiArPC90cj4KPiA+ICsgCj4gPiArPHRyPgo+ID4gKzx0 ZCB2YWxpZ249InRvcCIgPnR2X3JpZ2h0X21hcmdpbl9wcm9wZXJ0eTwvdGQ+Cj4gPiArPHRkIHZh bGlnbj0idG9wIiA+4oCccmlnaHQgbWFyZ2lu4oCdPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3Ai ID5EUk1fTU9ERV9QUk9QX1JBTkdFPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5NaW49MCwg TWF4PTEwMDwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+Q29ubmVjdG9yPC90ZD4KPiA+ICs8 dGQgdmFsaWduPSJ0b3AiID5UQkQ8L3RkPgo+ID4gKzwvdHI+Cj4gPiArIAo+ID4gKzx0cj4KPiA+ ICs8dGQgdmFsaWduPSJ0b3AiID50dl90b3BfbWFyZ2luX3Byb3BlcnR5PC90ZD4KPiA+ICs8dGQg dmFsaWduPSJ0b3AiID7igJx0b3AgbWFyZ2lu4oCdPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3Ai ID5EUk1fTU9ERV9QUk9QX1JBTkdFPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5NaW49MCwg TWF4PTEwMDwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+Q29ubmVjdG9yPC90ZD4KPiA+ICs8 dGQgdmFsaWduPSJ0b3AiID5UQkQ8L3RkPgo+ID4gKzwvdHI+Cj4gPiArIAo+ID4gKzx0cj4KPiA+ ICs8dGQgdmFsaWduPSJ0b3AiID50dl9ib3R0b21fbWFyZ2luX3Byb3BlcnR5PC90ZD4KPiA+ICs8 dGQgdmFsaWduPSJ0b3AiID7igJxib3R0b20gbWFyZ2lu4oCdPC90ZD4KPiA+ICs8dGQgdmFsaWdu PSJ0b3AiID5EUk1fTU9ERV9QUk9QX1JBTkdFPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5N aW49MCwgTWF4PTEwMDwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+Q29ubmVjdG9yPC90ZD4K PiA+ICs8dGQgdmFsaWduPSJ0b3AiID5UQkQ8L3RkPgo+ID4gKzwvdHI+Cj4gPiArIAo+ID4gKzx0 cj4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID50dl9icmlnaHRuZXNzX3Byb3BlcnR5PC90ZD4KPiA+ ICs8dGQgdmFsaWduPSJ0b3AiID7igJxicmlnaHRuZXNz4oCdPC90ZD4KPiA+ICs8dGQgdmFsaWdu PSJ0b3AiID5EUk1fTU9ERV9QUk9QX1JBTkdFPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5N aW49MCwgTWF4PTEwMDwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+Q29ubmVjdG9yPC90ZD4K PiA+ICs8dGQgdmFsaWduPSJ0b3AiID5UQkQ8L3RkPgo+ID4gKzwvdHI+Cj4gPiArIAo+ID4gKzx0 cj4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID50dl9jb250cmFzdF9wcm9wZXJ0eTwvdGQ+Cj4gPiAr PHRkIHZhbGlnbj0idG9wIiA+4oCcY29udHJhc3TigJ08L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRv cCIgPkRSTV9NT0RFX1BST1BfUkFOR0U8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPk1pbj0w LCBNYXg9MTAwPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5Db25uZWN0b3I8L3RkPgo+ID4g Kzx0ZCB2YWxpZ249InRvcCIgPlRCRDwvdGQ+Cj4gPiArPC90cj4KPiA+ICsgCj4gPiArPHRyPgo+ ID4gKzx0ZCB2YWxpZ249InRvcCIgPnR2X2ZsaWNrZXJfcmVkdWN0aW9uX3Byb3BlcnR5PC90ZD4K PiA+ICs8dGQgdmFsaWduPSJ0b3AiID7igJxmbGlja2VyIHJlZHVjdGlvbuKAnTwvdGQ+Cj4gPiAr PHRkIHZhbGlnbj0idG9wIiA+RFJNX01PREVfUFJPUF9SQU5HRTwvdGQ+Cj4gPiArPHRkIHZhbGln bj0idG9wIiA+TWluPTAsIE1heD0xMDA8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPkNvbm5l Y3RvcjwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+VEJEPC90ZD4KPiA+ICs8L3RyPgo+ID4g KyAKPiA+ICs8dHI+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+dHZfb3ZlcnNjYW5fcHJvcGVydHk8 L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPuKAnG92ZXJzY2Fu4oCdPC90ZD4KPiA+ICs8dGQg dmFsaWduPSJ0b3AiID5EUk1fTU9ERV9QUk9QX1JBTkdFPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0 b3AiID5NaW49MCwgTWF4PTEwMDwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+Q29ubmVjdG9y PC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5UQkQ8L3RkPgo+ID4gKzwvdHI+Cj4gPiArIAo+ ID4gKzx0cj4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID50dl9zYXR1cmF0aW9uX3Byb3BlcnR5PC90 ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID7igJxzYXR1cmF0aW9u4oCdPC90ZD4KPiA+ICs8dGQg dmFsaWduPSJ0b3AiID5EUk1fTU9ERV9QUk9QX1JBTkdFPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0 b3AiID5NaW49MCwgTWF4PTEwMDwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+Q29ubmVjdG9y PC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5UQkQ8L3RkPgo+ID4gKzwvdHI+Cj4gPiArIAo+ ID4gKzx0cj4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID50dl9odWVfcHJvcGVydHk8L3RkPgo+ID4g Kzx0ZCB2YWxpZ249InRvcCIgPuKAnGh1ZeKAnTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+ RFJNX01PREVfUFJPUF9SQU5HRTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+TWluPTAsIE1h eD0xMDA8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPkNvbm5lY3RvcjwvdGQ+Cj4gPiArPHRk IHZhbGlnbj0idG9wIiA+VEJEPC90ZD4KPiA+ICs8L3RyPgo+ID4gKyAKPiA+ICs8dHI+Cj4gPiAr PHRkIHJvd3NwYW49IjIiIHZhbGlnbj0idG9wIiA+T3B0aW9uYWwgUHJvcGVydGllczwvdGQ+Cj4g PiArPHRkIHZhbGlnbj0idG9wIiA+c2NhbGluZ19tb2RlX3Byb3BlcnR5PC90ZD4KPiA+ICs8dGQg dmFsaWduPSJ0b3AiID7igJxzY2FsaW5nIG1vZGXigJ08L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRv cCIgPkRSTV9NT0RFX1BST1BfRU5VTTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+eyBEUk1f TU9ERV9TQ0FMRV9OT05FLCAiTm9uZSIgfSwKPiA+ICt7IERSTV9NT0RFX1NDQUxFX0ZVTExTQ1JF RU4sICJGdWxsIiB9LAo+ID4gK3sgRFJNX01PREVfU0NBTEVfQ0VOVEVSLCAiQ2VudGVyIiB9LAo+ ID4gK3sgRFJNX01PREVfU0NBTEVfQVNQRUNULCAiRnVsbCBhc3BlY3QiIH08L3RkPgo+ID4gKzx0 ZCB2YWxpZ249InRvcCIgPkNvbm5lY3RvcjwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+VEJE PC90ZD4KPiA+ICs8L3RyPgo+ID4gKyAKPiA+ICs8dHI+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+ ZGlydHlfaW5mb19wcm9wZXJ0eTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+4oCcZGlydHni gJ08L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPkRSTV9NT0RFX1BST1BfRU5VTSB8IERSTV9N T0RFX1BST1BfSU1NVVRBQkxFPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID57IERSTV9NT0RF X0RJUlRZX09GRiwgIk9mZiIgfSwKPiA+ICt7IERSTV9NT0RFX0RJUlRZX09OLCAiT24iIH0sCj4g PiAreyBEUk1fTU9ERV9ESVJUWV9BTk5PVEFURSwgIkFubm90YXRlIiB9PC90ZD4KPiA+ICs8dGQg dmFsaWduPSJ0b3AiID5Db25uZWN0b3I8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPlRCRDwv dGQ+Cj4gPiArPC90cj4KPiA+ICsgCj4gPiArPHRyPgo+ID4gKzx0ZCByb3dzcGFuPSIyMSIgdmFs aWduPSJ0b3AiPmk5MTU8L3RkPgo+ID4gKzx0ZCByb3dzcGFuPSIzIiB2YWxpZ249InRvcCI+R2Vu ZXJpYzwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+YnJvYWRjYXN0X3JnYl9wcm9wZXJ0eTwv dGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+IkJyb2FkY2FzdCBSR0IiPC90ZD4KPiA+ICs8dGQg dmFsaWduPSJ0b3AiID5EUk1fTU9ERV9QUk9QX0VOVU08L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRv cCIgPnsgSU5URUxfQlJPQURDQVNUX1JHQl9BVVRPLCAiQXV0b21hdGljIiB9LAo+ID4gK3sgSU5U RUxfQlJPQURDQVNUX1JHQl9GVUxMLCAiRnVsbCIgfSwKPiA+ICt7IElOVEVMX0JST0FEQ0FTVF9S R0JfTElNSVRFRCwgIkxpbWl0ZWQgMTY6MjM1IiB9PC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3Ai ID5Db25uZWN0b3I8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPlRCRDwvdGQ+Cj4gPiArPC90 cj4KPiA+ICsgCj4gPiArPHRyPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPmZvcmNlX2F1ZGlvX3By b3BlcnR5PC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID7igJxhdWRpb+KAnTwvdGQ+Cj4gPiAr PHRkIHZhbGlnbj0idG9wIiA+RFJNX01PREVfUFJPUF9FTlVNPC90ZD4KPiA+ICs8dGQgdmFsaWdu PSJ0b3AiID57IEhETUlfQVVESU9fT0ZGX0RWSSwgImZvcmNlLWR2aSIgfSwKPiA+ICt7IEhETUlf QVVESU9fT0ZGLCAib2ZmIiB9LAo+ID4gK3sgSERNSV9BVURJT19BVVRPLCAiYXV0byIgfSwKPiA+ ICt7IEhETUlfQVVESU9fT04sICJvbiIgfTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+Q29u bmVjdG9yPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5UQkQ8L3RkPgo+ID4gKzwvdHI+Cj4g PiArIAo+ID4gKzx0cj4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5zY2FsaW5nX21vZGVfcHJvcGVy dHkKPiA+ICsgCj4gPiArPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5TdGFuZGFyZCBuYW1l IGFzIGluIERSTTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+U3RhbmRhcmQgdHlwZSBhcyBp biBEUk08L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPlN0YW5kYXJkIHZhbHVlIGFzIGluIERS TTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+U3RhbmRhcmQgT2JqZWN0IGFzIGluIERSTTwv dGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+VEJEPC90ZD4KPiA+ICs8L3RyPgo+ID4gKyAKPiA+ ICs8dHI+Cj4gPiArPHRkIHJvd3NwYW49IjE3IiB2YWxpZ249InRvcCI+U0RWTy1UVjwvdGQ+Cj4g PiArPHRkIHZhbGlnbj0idG9wIiA+dHZfZm9ybWF0PC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3Ai ID7igJxtb2Rl4oCdPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5EUk1fTU9ERV9QUk9QX0VO VU08L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPnswLCAiTlRTQ19NIn0gLCB7MSwgIk5UU0Nf SiJ9ICwKPiA+ICt7MiwgIk5UU0NfNDQzIn0sIHszLCAiUEFMX0IifSBldGMuPC90ZD4KPiA+ICs8 dGQgdmFsaWduPSJ0b3AiID5Db25uZWN0b3I8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPlRC RDwvdGQ+Cj4gPiArPC90cj4KPiA+ICsgCj4gPiArPHRyPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIg PmxlZnQ8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPiJsZWZ0X21hcmdpbiI8L3RkPgo+ID4g Kzx0ZCB2YWxpZ249InRvcCIgPkRSTV9NT0RFX1BST1BfUkFOR0U8L3RkPgo+ID4gKzx0ZCB2YWxp Z249InRvcCIgPk1pbj0wLCBNYXg9IFNEVk8gZGVwZW5kZW50PC90ZD4KPiA+ICs8dGQgdmFsaWdu PSJ0b3AiID5Db25uZWN0b3I8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPlRCRDwvdGQ+Cj4g PiArPC90cj4KPiA+ICsgCj4gPiArPHRyPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPnJpZ2h0PC90 ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID4icmlnaHRfbWFyZ2luIjwvdGQ+Cj4gPiArPHRkIHZh bGlnbj0idG9wIiA+RFJNX01PREVfUFJPUF9SQU5HRTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9w IiA+TWluPTAsIE1heD0gU0RWTyBkZXBlbmRlbnQ8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIg PkNvbm5lY3RvcjwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+VEJEPC90ZD4KPiA+ICs8L3Ry Pgo+ID4gKyAKPiA+ICs8dHI+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+dG9wPC90ZD4KPiA+ICs8 dGQgdmFsaWduPSJ0b3AiID4idG9wX21hcmdpbiI8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIg PkRSTV9NT0RFX1BST1BfUkFOR0U8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPk1pbj0wLCBN YXg9IFNEVk8gZGVwZW5kZW50PC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5Db25uZWN0b3I8 L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPlRCRDwvdGQ+Cj4gPiArPC90cj4KPiA+ICsgCj4g PiArPHRyPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPmJvdHRvbTwvdGQ+Cj4gPiArPHRkIHZhbGln bj0idG9wIiA+ImJvdHRvbV9tYXJnaW4iPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5EUk1f TU9ERV9QUk9QX1JBTkdFPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5NaW49MCwgTWF4PSBT RFZPIGRlcGVuZGVudDwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+Q29ubmVjdG9yPC90ZD4K PiA+ICs8dGQgdmFsaWduPSJ0b3AiID5UQkQ8L3RkPgo+ID4gKzwvdHI+Cj4gPiArIAo+ID4gKzx0 cj4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5ocG9zPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3Ai ID7igJxocG9z4oCdPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5EUk1fTU9ERV9QUk9QX1JB TkdFPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5NaW49MCwgTWF4PSBTRFZPIGRlcGVuZGVu dDwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+Q29ubmVjdG9yPC90ZD4KPiA+ICs8dGQgdmFs aWduPSJ0b3AiID5UQkQ8L3RkPgo+ID4gKzwvdHI+Cj4gPiArIAo+ID4gKzx0cj4KPiA+ICs8dGQg dmFsaWduPSJ0b3AiID52cG9zPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID7igJx2cG9z4oCd PC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5EUk1fTU9ERV9QUk9QX1JBTkdFPC90ZD4KPiA+ ICs8dGQgdmFsaWduPSJ0b3AiID5NaW49MCwgTWF4PSBTRFZPIGRlcGVuZGVudDwvdGQ+Cj4gPiAr PHRkIHZhbGlnbj0idG9wIiA+Q29ubmVjdG9yPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5U QkQ8L3RkPgo+ID4gKzwvdHI+Cj4gPiArIAo+ID4gKzx0cj4KPiA+ICs8dGQgdmFsaWduPSJ0b3Ai ID5jb250cmFzdDwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+4oCcY29udHJhc3TigJ08L3Rk Pgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPkRSTV9NT0RFX1BST1BfUkFOR0U8L3RkPgo+ID4gKzx0 ZCB2YWxpZ249InRvcCIgPk1pbj0wLCBNYXg9IFNEVk8gZGVwZW5kZW50PC90ZD4KPiA+ICs8dGQg dmFsaWduPSJ0b3AiID5Db25uZWN0b3I8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPlRCRDwv dGQ+Cj4gPiArPC90cj4KPiA+ICsgCj4gPiArPHRyPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPnNh dHVyYXRpb248L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPuKAnHNhdHVyYXRpb27igJ08L3Rk Pgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPkRSTV9NT0RFX1BST1BfUkFOR0U8L3RkPgo+ID4gKzx0 ZCB2YWxpZ249InRvcCIgPk1pbj0wLCBNYXg9IFNEVk8gZGVwZW5kZW50PC90ZD4KPiA+ICs8dGQg dmFsaWduPSJ0b3AiID5Db25uZWN0b3I8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPlRCRDwv dGQ+Cj4gPiArPC90cj4KPiA+ICsgCj4gPiArPHRyPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPmh1 ZTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+4oCcaHVl4oCdPC90ZD4KPiA+ICs8dGQgdmFs aWduPSJ0b3AiID5EUk1fTU9ERV9QUk9QX1JBTkdFPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3Ai ID5NaW49MCwgTWF4PSBTRFZPIGRlcGVuZGVudDwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+ Q29ubmVjdG9yPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5UQkQ8L3RkPgo+ID4gKzwvdHI+ Cj4gPiArIAo+ID4gKzx0cj4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5zaGFycG5lc3M8L3RkPgo+ ID4gKzx0ZCB2YWxpZ249InRvcCIgPuKAnHNoYXJwbmVzc+KAnTwvdGQ+Cj4gPiArPHRkIHZhbGln bj0idG9wIiA+RFJNX01PREVfUFJPUF9SQU5HRTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+ TWluPTAsIE1heD0gU0RWTyBkZXBlbmRlbnQ8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPkNv bm5lY3RvcjwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+VEJEPC90ZD4KPiA+ICs8L3RyPgo+ ID4gKyAKPiA+ICs8dHI+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+ZmxpY2tlcl9maWx0ZXI8L3Rk Pgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPuKAnGZsaWNrZXJfZmlsdGVy4oCdPC90ZD4KPiA+ICs8 dGQgdmFsaWduPSJ0b3AiID5EUk1fTU9ERV9QUk9QX1JBTkdFPC90ZD4KPiA+ICs8dGQgdmFsaWdu PSJ0b3AiID5NaW49MCwgTWF4PSBTRFZPIGRlcGVuZGVudDwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0i dG9wIiA+Q29ubmVjdG9yPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5UQkQ8L3RkPgo+ID4g KzwvdHI+Cj4gPiArIAo+ID4gKzx0cj4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5mbGlja2VyX2Zp bHRlcl9hZGFwdGl2ZTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+4oCcZmxpY2tlcl9maWx0 ZXJfYWRhcHRpdmXigJ08L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPkRSTV9NT0RFX1BST1Bf UkFOR0U8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPk1pbj0wLCBNYXg9IFNEVk8gZGVwZW5k ZW50PC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5Db25uZWN0b3I8L3RkPgo+ID4gKzx0ZCB2 YWxpZ249InRvcCIgPlRCRDwvdGQ+Cj4gPiArPC90cj4KPiA+ICsgCj4gPiArPHRyPgo+ID4gKzx0 ZCB2YWxpZ249InRvcCIgPmZsaWNrZXJfZmlsdGVyXzJkPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0 b3AiID7igJxmbGlja2VyX2ZpbHRlcl8yZOKAnTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+ RFJNX01PREVfUFJPUF9SQU5HRTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+TWluPTAsIE1h eD0gU0RWTyBkZXBlbmRlbnQ8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPkNvbm5lY3Rvcjwv dGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+VEJEPC90ZD4KPiA+ICs8L3RyPgo+ID4gKyAKPiA+ ICs8dHI+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+dHZfY2hyb21hX2ZpbHRlcjwvdGQ+Cj4gPiAr PHRkIHZhbGlnbj0idG9wIiA+4oCcdHZfY2hyb21hX2ZpbHRlcuKAnTwvdGQ+Cj4gPiArPHRkIHZh bGlnbj0idG9wIiA+RFJNX01PREVfUFJPUF9SQU5HRTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9w IiA+TWluPTAsIE1heD0gU0RWTyBkZXBlbmRlbnQ8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIg PkNvbm5lY3RvcjwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+VEJEPC90ZD4KPiA+ICs8L3Ry Pgo+ID4gKyAKPiA+ICs8dHI+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+dHZfbHVtYV9maWx0ZXI8 L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPuKAnHR2X2x1bWFfZmlsdGVy4oCdPC90ZD4KPiA+ ICs8dGQgdmFsaWduPSJ0b3AiID5EUk1fTU9ERV9QUk9QX1JBTkdFPC90ZD4KPiA+ICs8dGQgdmFs aWduPSJ0b3AiID5NaW49MCwgTWF4PSBTRFZPIGRlcGVuZGVudDwvdGQ+Cj4gPiArPHRkIHZhbGln bj0idG9wIiA+Q29ubmVjdG9yPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5UQkQ8L3RkPgo+ ID4gKzwvdHI+Cj4gPiArIAo+ID4gKzx0cj4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5kb3RfY3Jh d2w8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPuKAnGRvdF9jcmF3bOKAnTwvdGQ+Cj4gPiAr PHRkIHZhbGlnbj0idG9wIiA+RFJNX01PREVfUFJPUF9SQU5HRTwvdGQ+Cj4gPiArPHRkIHZhbGln bj0idG9wIiA+TWluPTAsIE1heD0xPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5Db25uZWN0 b3I8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPlRCRDwvdGQ+Cj4gPiArPC90cj4KPiA+ICsg Cj4gPiArPHRyPgo+ID4gKzx0ZCB2YWxpZ249InRvcCI+U0RWTy1UVi9MVkRTPC90ZD4KPiA+ICs8 dGQgdmFsaWduPSJ0b3AiID5icmlnaHRuZXNzPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID7i gJxicmlnaHRuZXNz4oCdPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5EUk1fTU9ERV9QUk9Q X1JBTkdFPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5NaW49MCwgTWF4PSBTRFZPIGRlcGVu ZGVudDwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+Q29ubmVjdG9yPC90ZD4KPiA+ICs8dGQg dmFsaWduPSJ0b3AiID5UQkQ8L3RkPgo+ID4gKzwvdHI+Cj4gPiArIAo+ID4gKzx0cj4KPiA+ICs8 dGQgcm93c3Bhbj0iMyIgdmFsaWduPSJ0b3AiPkNEViBnbWEtNTAwPC90ZD4KPiA+ICs8dGQgcm93 c3Bhbj0iMyIgdmFsaWduPSJ0b3AiPkdlbmVyaWM8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIg PmJyb2FkY2FzdF9yZ2JfcHJvcGVydHk8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPiJCcm9h ZGNhc3QgUkdCIjwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+RFJNX01PREVfUFJPUF9FTlVN PC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID57IDAsIOKAnEZ1bGzigJ19LAo+ID4gK3sgMSwg 4oCcTGltaXRlZCAxNjoyMzXigJ19PC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5Db25uZWN0 b3I8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPlRCRDwvdGQ+Cj4gPiArPC90cj4KPiA+ICsg Cj4gPiArPHRyPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPmZvcmNlX2F1ZGlvX3Byb3BlcnR5PC90 ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID4iQnJvYWRjYXN0IFJHQiI8L3RkPgo+ID4gKzx0ZCB2 YWxpZ249InRvcCIgPkRSTV9NT0RFX1BST1BfRU5VTTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9w IiA+eyAtMSwg4oCcb2Zm4oCdfSwKPiA+ICt7IDAsIOKAnGF1dG/igJ19LAo+ID4gK3sgMSwg4oCc b27igJ19PC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5Db25uZWN0b3I8L3RkPgo+ID4gKzx0 ZCB2YWxpZ249InRvcCIgPlRCRDwvdGQ+Cj4gPiArPC90cj4KPiA+ICsgCj4gPiArPHRyPgo+ID4g Kzx0ZCB2YWxpZ249InRvcCIgPnNjYWxpbmdfbW9kZV9wcm9wZXJ0eQo+ID4gKyAKPiA+ICs8L3Rk Pgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPlN0YW5kYXJkIG5hbWUgYXMgaW4gRFJNPC90ZD4KPiA+ ICs8dGQgdmFsaWduPSJ0b3AiID5TdGFuZGFyZCB0eXBlIGFzIGluIERSTTwvdGQ+Cj4gPiArPHRk IHZhbGlnbj0idG9wIiA+U3RhbmRhcmQgdmFsdWUgYXMgaW4gRFJNPC90ZD4KPiA+ICs8dGQgdmFs aWduPSJ0b3AiID5TdGFuZGFyZCBPYmplY3QgYXMgaW4gRFJNPC90ZD4KPiA+ICs8dGQgdmFsaWdu PSJ0b3AiID5UQkQ8L3RkPgo+ID4gKzwvdHI+Cj4gPiArIAo+ID4gKzx0cj4KPiA+ICs8dGQgcm93 c3Bhbj0iMjAiIHZhbGlnbj0idG9wIj5Qb3Vsc2JvPC90ZD4KPiA+ICs8dGQgcm93c3Bhbj0iMiIg dmFsaWduPSJ0b3AiPkdlbmVyaWM8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPmJhY2tsaWdo dF9wcm9wZXJ0eTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+4oCcYmFja2xpZ2h04oCdPC90 ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5EUk1fTU9ERV9QUk9QX1JBTkdFPC90ZD4KPiA+ICs8 dGQgdmFsaWduPSJ0b3AiID5NaW49MCwgTWF4PTEwMDwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9w IiA+Q29ubmVjdG9yPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5UQkQ8L3RkPgo+ID4gKzwv dHI+Cj4gPiArIAo+ID4gKzx0cj4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5zY2FsaW5nX21vZGVf cHJvcGVydHkKPiA+ICsgCj4gPiArPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5TdGFuZGFy ZCBuYW1lIGFzIGluIERSTTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+U3RhbmRhcmQgdHlw ZSBhcyBpbiBEUk08L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPlN0YW5kYXJkIHZhbHVlIGFz IGluIERSTTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+U3RhbmRhcmQgT2JqZWN0IGFzIGlu IERSTTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+VEJEPC90ZD4KPiA+ICs8L3RyPgo+ID4g KyAKPiA+ICs8dHI+Cj4gPiArPHRkIHJvd3NwYW49IjE3IiB2YWxpZ249InRvcCI+U0RWTy1UVjwv dGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+dHZfZm9ybWF0PC90ZD4KPiA+ICs8dGQgdmFsaWdu PSJ0b3AiID7igJxtb2Rl4oCdPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5EUk1fTU9ERV9Q Uk9QX0VOVU08L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPnswLCAiTlRTQ19NIn0gLCB7MSwg Ik5UU0NfSiJ9ICwKPiA+ICsgCj4gPiArezIsICJOVFNDXzQ0MyJ9LCB7MywgIlBBTF9CIn0gZXRj LjwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+Q29ubmVjdG9yPC90ZD4KPiA+ICs8dGQgdmFs aWduPSJ0b3AiID5UQkQ8L3RkPgo+ID4gKzwvdHI+Cj4gPiArIAo+ID4gKzx0cj4KPiA+ICs8dGQg dmFsaWduPSJ0b3AiID5sZWZ0PC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID4ibGVmdF9tYXJn aW4iPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5EUk1fTU9ERV9QUk9QX1JBTkdFPC90ZD4K PiA+ICs8dGQgdmFsaWduPSJ0b3AiID5NaW49MCwgTWF4PSBTRFZPIGRlcGVuZGVudDwvdGQ+Cj4g PiArPHRkIHZhbGlnbj0idG9wIiA+Q29ubmVjdG9yPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3Ai ID5UQkQ8L3RkPgo+ID4gKzwvdHI+Cj4gPiArIAo+ID4gKzx0cj4KPiA+ICs8dGQgdmFsaWduPSJ0 b3AiID5yaWdodDwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+InJpZ2h0X21hcmdpbiI8L3Rk Pgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPkRSTV9NT0RFX1BST1BfUkFOR0U8L3RkPgo+ID4gKzx0 ZCB2YWxpZ249InRvcCIgPk1pbj0wLCBNYXg9IFNEVk8gZGVwZW5kZW50PC90ZD4KPiA+ICs8dGQg dmFsaWduPSJ0b3AiID5Db25uZWN0b3I8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPlRCRDwv dGQ+Cj4gPiArPC90cj4KPiA+ICsgCj4gPiArPHRyPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPnRv cDwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+InRvcF9tYXJnaW4iPC90ZD4KPiA+ICs8dGQg dmFsaWduPSJ0b3AiID5EUk1fTU9ERV9QUk9QX1JBTkdFPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0 b3AiID5NaW49MCwgTWF4PSBTRFZPIGRlcGVuZGVudDwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9w IiA+Q29ubmVjdG9yPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5UQkQ8L3RkPgo+ID4gKzwv dHI+Cj4gPiArIAo+ID4gKzx0cj4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5ib3R0b208L3RkPgo+ ID4gKzx0ZCB2YWxpZ249InRvcCIgPiJib3R0b21fbWFyZ2luIjwvdGQ+Cj4gPiArPHRkIHZhbGln bj0idG9wIiA+RFJNX01PREVfUFJPUF9SQU5HRTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+ TWluPTAsIE1heD0gU0RWTyBkZXBlbmRlbnQ8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPkNv bm5lY3RvcjwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+VEJEPC90ZD4KPiA+ICs8L3RyPgo+ ID4gKyAKPiA+ICs8dHI+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+aHBvczwvdGQ+Cj4gPiArPHRk IHZhbGlnbj0idG9wIiA+4oCcaHBvc+KAnTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+RFJN X01PREVfUFJPUF9SQU5HRTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+TWluPTAsIE1heD0g U0RWTyBkZXBlbmRlbnQ8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPkNvbm5lY3RvcjwvdGQ+ Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+VEJEPC90ZD4KPiA+ICs8L3RyPgo+ID4gKyAKPiA+ICs8 dHI+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+dnBvczwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9w IiA+4oCcdnBvc+KAnTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+RFJNX01PREVfUFJPUF9S QU5HRTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+TWluPTAsIE1heD0gU0RWTyBkZXBlbmRl bnQ8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPkNvbm5lY3RvcjwvdGQ+Cj4gPiArPHRkIHZh bGlnbj0idG9wIiA+VEJEPC90ZD4KPiA+ICs8L3RyPgo+ID4gKyAKPiA+ICs8dHI+Cj4gPiArPHRk IHZhbGlnbj0idG9wIiA+Y29udHJhc3Q8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPuKAnGNv bnRyYXN04oCdPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5EUk1fTU9ERV9QUk9QX1JBTkdF PC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5NaW49MCwgTWF4PSBTRFZPIGRlcGVuZGVudDwv dGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+Q29ubmVjdG9yPC90ZD4KPiA+ICs8dGQgdmFsaWdu PSJ0b3AiID5UQkQ8L3RkPgo+ID4gKzwvdHI+Cj4gPiArIAo+ID4gKzx0cj4KPiA+ICs8dGQgdmFs aWduPSJ0b3AiID5zYXR1cmF0aW9uPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID7igJxzYXR1 cmF0aW9u4oCdPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5EUk1fTU9ERV9QUk9QX1JBTkdF PC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5NaW49MCwgTWF4PSBTRFZPIGRlcGVuZGVudDwv dGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+Q29ubmVjdG9yPC90ZD4KPiA+ICs8dGQgdmFsaWdu PSJ0b3AiID5UQkQ8L3RkPgo+ID4gKzwvdHI+Cj4gPiArIAo+ID4gKzx0cj4KPiA+ICs8dGQgdmFs aWduPSJ0b3AiID5odWU8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPuKAnGh1ZeKAnTwvdGQ+ Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+RFJNX01PREVfUFJPUF9SQU5HRTwvdGQ+Cj4gPiArPHRk IHZhbGlnbj0idG9wIiA+TWluPTAsIE1heD0gU0RWTyBkZXBlbmRlbnQ8L3RkPgo+ID4gKzx0ZCB2 YWxpZ249InRvcCIgPkNvbm5lY3RvcjwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+VEJEPC90 ZD4KPiA+ICs8L3RyPgo+ID4gKyAKPiA+ICs8dHI+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+c2hh cnBuZXNzPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID7igJxzaGFycG5lc3PigJ08L3RkPgo+ ID4gKzx0ZCB2YWxpZ249InRvcCIgPkRSTV9NT0RFX1BST1BfUkFOR0U8L3RkPgo+ID4gKzx0ZCB2 YWxpZ249InRvcCIgPk1pbj0wLCBNYXg9IFNEVk8gZGVwZW5kZW50PC90ZD4KPiA+ICs8dGQgdmFs aWduPSJ0b3AiID5Db25uZWN0b3I8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPlRCRDwvdGQ+ Cj4gPiArPC90cj4KPiA+ICsgCj4gPiArPHRyPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPmZsaWNr ZXJfZmlsdGVyPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID7igJxmbGlja2VyX2ZpbHRlcuKA nTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+RFJNX01PREVfUFJPUF9SQU5HRTwvdGQ+Cj4g PiArPHRkIHZhbGlnbj0idG9wIiA+TWluPTAsIE1heD0gU0RWTyBkZXBlbmRlbnQ8L3RkPgo+ID4g Kzx0ZCB2YWxpZ249InRvcCIgPkNvbm5lY3RvcjwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+ VEJEPC90ZD4KPiA+ICs8L3RyPgo+ID4gKyAKPiA+ICs8dHI+Cj4gPiArPHRkIHZhbGlnbj0idG9w IiA+ZmxpY2tlcl9maWx0ZXJfYWRhcHRpdmU8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPuKA nGZsaWNrZXJfZmlsdGVyX2FkYXB0aXZl4oCdPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5E Uk1fTU9ERV9QUk9QX1JBTkdFPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5NaW49MCwgTWF4 PSBTRFZPIGRlcGVuZGVudDwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+Q29ubmVjdG9yPC90 ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5UQkQ8L3RkPgo+ID4gKzwvdHI+Cj4gPiArIAo+ID4g Kzx0cj4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5mbGlja2VyX2ZpbHRlcl8yZDwvdGQ+Cj4gPiAr PHRkIHZhbGlnbj0idG9wIiA+4oCcZmxpY2tlcl9maWx0ZXJfMmTigJ08L3RkPgo+ID4gKzx0ZCB2 YWxpZ249InRvcCIgPkRSTV9NT0RFX1BST1BfUkFOR0U8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRv cCIgPk1pbj0wLCBNYXg9IFNEVk8gZGVwZW5kZW50PC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3Ai ID5Db25uZWN0b3I8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPlRCRDwvdGQ+Cj4gPiArPC90 cj4KPiA+ICsgCj4gPiArPHRyPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPnR2X2Nocm9tYV9maWx0 ZXI8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPuKAnHR2X2Nocm9tYV9maWx0ZXLigJ08L3Rk Pgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPkRSTV9NT0RFX1BST1BfUkFOR0U8L3RkPgo+ID4gKzx0 ZCB2YWxpZ249InRvcCIgPk1pbj0wLCBNYXg9IFNEVk8gZGVwZW5kZW50PC90ZD4KPiA+ICs8dGQg dmFsaWduPSJ0b3AiID5Db25uZWN0b3I8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPlRCRDwv dGQ+Cj4gPiArPC90cj4KPiA+ICsgCj4gPiArPHRyPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPnR2 X2x1bWFfZmlsdGVyPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID7igJx0dl9sdW1hX2ZpbHRl cuKAnTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+RFJNX01PREVfUFJPUF9SQU5HRTwvdGQ+ Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+TWluPTAsIE1heD0gU0RWTyBkZXBlbmRlbnQ8L3RkPgo+ ID4gKzx0ZCB2YWxpZ249InRvcCIgPkNvbm5lY3RvcjwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9w IiA+VEJEPC90ZD4KPiA+ICs8L3RyPgo+ID4gKyAKPiA+ICs8dHI+Cj4gPiArPHRkIHZhbGlnbj0i dG9wIiA+ZG90X2NyYXdsPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID7igJxkb3RfY3Jhd2zi gJ08L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPkRSTV9NT0RFX1BST1BfUkFOR0U8L3RkPgo+ ID4gKzx0ZCB2YWxpZ249InRvcCIgPk1pbj0wLCBNYXg9MTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0i dG9wIiA+Q29ubmVjdG9yPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5UQkQ8L3RkPgo+ID4g KzwvdHI+Cj4gPiArIAo+ID4gKzx0cj4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiPlNEVk8tVFYvTFZE UzwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+YnJpZ2h0bmVzczwvdGQ+Cj4gPiArPHRkIHZh bGlnbj0idG9wIiA+4oCcYnJpZ2h0bmVzc+KAnTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+ RFJNX01PREVfUFJPUF9SQU5HRTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+TWluPTAsIE1h eD0gU0RWTyBkZXBlbmRlbnQ8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPkNvbm5lY3Rvcjwv dGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+VEJEPC90ZD4KPiA+ICs8L3RyPgo+ID4gKyAKPiA+ ICs8dHI+Cj4gPiArPHRkIHJvd3NwYW49IjExIiB2YWxpZ249InRvcCI+YXJtYWRhPC90ZD4KPiA+ ICs8dGQgcm93c3Bhbj0iMiIgdmFsaWduPSJ0b3AiPkNSVEM8L3RkPgo+ID4gKzx0ZCB2YWxpZ249 InRvcCIgPmNzY195dXZfcHJvcDwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+IkNTQ19ZVVYi PC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5EUk1fTU9ERV9QUk9QX0VOVU08L3RkPgo+ID4g Kzx0ZCB2YWxpZ249InRvcCIgPnsgQ1NDX0FVVE8sICJBdXRvIiB9LAo+ID4gK3sgQ1NDX1lVVl9D Q0lSNjAxLCAiQ0NJUjYwMSIgfSwKPiA+ICt7IENTQ19ZVVZfQ0NJUjcwOSwgIkNDSVI3MDkiIH08 L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPkNSVEM8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRv cCIgPlRCRDwvdGQ+Cj4gPiArPC90cj4KPiA+ICsgCj4gPiArPHRyPgo+ID4gKzx0ZCB2YWxpZ249 InRvcCIgPmNzY19yZ2JfcHJvcDwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+IkNTQ19SR0Ii PC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5EUk1fTU9ERV9QUk9QX0VOVU08L3RkPgo+ID4g Kzx0ZCB2YWxpZ249InRvcCIgPnsgQ1NDX0FVVE8sICJBdXRvIiB9LAo+ID4gK3sgQ1NDX1JHQl9D T01QVVRFUiwgIkNvbXB1dGVyIHN5c3RlbSIgfSwKPiA+ICt7IENTQ19SR0JfU1RVRElPLCAiU3R1 ZGlvIiB9PC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5DUlRDPC90ZD4KPiA+ICs8dGQgdmFs aWduPSJ0b3AiID5UQkQ8L3RkPgo+ID4gKzwvdHI+Cj4gPiArIAo+ID4gKzx0cj4KPiA+ICs8dGQg cm93c3Bhbj0iOSIgdmFsaWduPSJ0b3AiPk92ZXJsYXk8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRv cCIgPmNvbG9ya2V5X3Byb3A8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPiJjb2xvcmtleSI8 L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPkRSTV9NT0RFX1BST1BfUkFOR0U8L3RkPgo+ID4g Kzx0ZCB2YWxpZ249InRvcCIgPk1pbj0wLCBNYXg9MHhmZmZmZmY8L3RkPgo+ID4gKzx0ZCB2YWxp Z249InRvcCIgPlBsYW5lPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5UQkQ8L3RkPgo+ID4g KzwvdHI+Cj4gPiArIAo+ID4gKzx0cj4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5jb2xvcmtleV9t aW5fcHJvcDwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+ImNvbG9ya2V5X21pbiI8L3RkPgo+ ID4gKzx0ZCB2YWxpZ249InRvcCIgPkRSTV9NT0RFX1BST1BfUkFOR0U8L3RkPgo+ID4gKzx0ZCB2 YWxpZ249InRvcCIgPk1pbj0wLCBNYXg9MHhmZmZmZmY8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRv cCIgPlBsYW5lPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5UQkQ8L3RkPgo+ID4gKzwvdHI+ Cj4gPiArIAo+ID4gKzx0cj4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5jb2xvcmtleV9tYXhfcHJv cDwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+ImNvbG9ya2V5X21heCI8L3RkPgo+ID4gKzx0 ZCB2YWxpZ249InRvcCIgPkRSTV9NT0RFX1BST1BfUkFOR0U8L3RkPgo+ID4gKzx0ZCB2YWxpZ249 InRvcCIgPk1pbj0wLCBNYXg9MHhmZmZmZmY8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPlBs YW5lPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5UQkQ8L3RkPgo+ID4gKzwvdHI+Cj4gPiAr IAo+ID4gKzx0cj4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5jb2xvcmtleV92YWxfcHJvcDwvdGQ+ Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+ImNvbG9ya2V5X3ZhbCI8L3RkPgo+ID4gKzx0ZCB2YWxp Z249InRvcCIgPkRSTV9NT0RFX1BST1BfUkFOR0U8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIg Pk1pbj0wLCBNYXg9MHhmZmZmZmY8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPlBsYW5lPC90 ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5UQkQ8L3RkPgo+ID4gKzwvdHI+Cj4gPiArIAo+ID4g Kzx0cj4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5jb2xvcmtleV9hbHBoYV9wcm9wPC90ZD4KPiA+ ICs8dGQgdmFsaWduPSJ0b3AiID4iY29sb3JrZXlfYWxwaGEiPC90ZD4KPiA+ICs8dGQgdmFsaWdu PSJ0b3AiID5EUk1fTU9ERV9QUk9QX1JBTkdFPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5N aW49MCwgTWF4PTB4ZmZmZmZmPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5QbGFuZTwvdGQ+ Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+VEJEPC90ZD4KPiA+ICs8L3RyPgo+ID4gKyAKPiA+ICs8 dHI+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+Y29sb3JrZXlfbW9kZV9wcm9wPC90ZD4KPiA+ICs8 dGQgdmFsaWduPSJ0b3AiID4iY29sb3JrZXlfbW9kZSI8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRv cCIgPkRSTV9NT0RFX1BST1BfRU5VTTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+eyBDS01P REVfRElTQUJMRSwgImRpc2FibGVkIiB9LAo+ID4gK3sgQ0tNT0RFX1ksICJZIGNvbXBvbmVudCIg fSwKPiA+ICt7IENLTU9ERV9VLCAiVSBjb21wb25lbnQiIH0sCj4gPiAreyBDS01PREVfViwgIlYg Y29tcG9uZW50IiB9LAo+ID4gK3sgQ0tNT0RFX1JHQiwgIlJHQiIgfSwKPiA+ICt7IENLTU9ERV9S LCDigJxSIGNvbXBvbmVudCIgfSwKPiA+ICt7IENLTU9ERV9HLCAiRyBjb21wb25lbnQiIH0sCj4g PiAreyBDS01PREVfQiwgIkIgY29tcG9uZW50IiB9PC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3Ai ID5QbGFuZTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+VEJEPC90ZD4KPiA+ICs8L3RyPgo+ ID4gKyAKPiA+ICs8dHI+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+YnJpZ2h0bmVzc19wcm9wPC90 ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID4iYnJpZ2h0bmVzcyI8L3RkPgo+ID4gKzx0ZCB2YWxp Z249InRvcCIgPkRSTV9NT0RFX1BST1BfUkFOR0U8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIg Pk1pbj0wLCBNYXg9MjU2ICsgMjU1PC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5QbGFuZTwv dGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+VEJEPC90ZD4KPiA+ICs8L3RyPgo+ID4gKyAKPiA+ ICs8dHI+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+Y29udHJhc3RfcHJvcDwvdGQ+Cj4gPiArPHRk IHZhbGlnbj0idG9wIiA+ImNvbnRyYXN0IjwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+RFJN X01PREVfUFJPUF9SQU5HRTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+TWluPTAsIE1heD0w eDdmZmY8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPlBsYW5lPC90ZD4KPiA+ICs8dGQgdmFs aWduPSJ0b3AiID5UQkQ8L3RkPgo+ID4gKzwvdHI+Cj4gPiArIAo+ID4gKzx0cj4KPiA+ICs8dGQg dmFsaWduPSJ0b3AiID5zYXR1cmF0aW9uX3Byb3A8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIg PiJzYXR1cmF0aW9uIjwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+RFJNX01PREVfUFJPUF9S QU5HRTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+TWluPTAsIE1heD0weDdmZmY8L3RkPgo+ ID4gKzx0ZCB2YWxpZ249InRvcCIgPlBsYW5lPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5U QkQ8L3RkPgo+ID4gKzwvdHI+Cj4gPiArIAo+ID4gKzx0cj4KPiA+ICs8dGQgcm93c3Bhbj0iMiIg dmFsaWduPSJ0b3AiPmV4eW5vczwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIj5DUlRDPC90ZD4K PiA+ICs8dGQgdmFsaWduPSJ0b3AiID5jcnRjX21vZGVfcHJvcGVydHk8L3RkPgo+ID4gKzx0ZCB2 YWxpZ249InRvcCIgPuKAnG1vZGXigJ08L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPkRSTV9N T0RFX1BST1BfRU5VTTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+eyBDUlRDX01PREVfTk9S TUFMLCAibm9ybWFsIiB9LAo+ID4gK3sgQ1JUQ19NT0RFX0JMQU5LLCAiYmxhbmsiIH08L3RkPgo+ ID4gKzx0ZCB2YWxpZ249InRvcCIgPkNSVEM8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPlRC RDwvdGQ+Cj4gPiArPC90cj4KPiA+ICsgCj4gPiArPHRyPgo+ID4gKzx0ZCB2YWxpZ249InRvcCI+ T3ZlcmxheTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+cGxhbmVfenBvc19wcm9wZXJ0eTwv dGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+4oCcenBvc+KAnTwvdGQ+Cj4gPiArPHRkIHZhbGln bj0idG9wIiA+RFJNX01PREVfUFJPUF9SQU5HRTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+ TWluPTAsIE1heD1NQVhfUExBTkUtMTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+UGxhbmU8 L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPlRCRDwvdGQ+Cj4gPiArPC90cj4KPiA+ICsgCj4g PiArPHRyPgo+ID4gKzx0ZCByb3dzcGFuPSIzIiB2YWxpZ249InRvcCI+aTJjL2NoNzAwNl9kcnY8 L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCI+R2VuZXJpYzwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0i dG9wIiA+c2NhbGVfcHJvcGVydHk8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPuKAnHNjYWxl 4oCdPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5EUk1fTU9ERV9QUk9QX1JBTkdFPC90ZD4K PiA+ICs8dGQgdmFsaWduPSJ0b3AiID5NaW49MCwgTWF4PTI8L3RkPgo+ID4gKzx0ZCB2YWxpZ249 InRvcCIgPkNvbm5lY3RvcjwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+VEJEPC90ZD4KPiA+ ICs8L3RyPgo+ID4gKyAKPiA+ICs8dHI+Cj4gPiArPHRkIHJvd3NwYW49IjIiIHZhbGlnbj0idG9w Ij5UVi1Qcm9wZXJ0aWVzPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5sZWZ0LAo+ID4gK3Jp Z2h0LAo+ID4gK3RvcCwKPiA+ICtib3R0b20sCj4gPiAraHBvcywKPiA+ICt2cG9zLAo+ID4gK2Nv bnRyYXN0LAo+ID4gK3NhdHVyYXRpb24sCj4gPiAraHVlLAo+ID4gK3NoYXJwbmVzcywKPiA+ICtm bGlja2VyX2ZpbHRlciwKPiA+ICtmbGlja2VyX2ZpbHRlcl9hZGFwdGl2ZSwKPiA+ICtmbGlja2Vy X2ZpbHRlcl8yZCwKPiA+ICt0dl9jaHJvbWFfZmlsdGVyLAo+ID4gK3R2X2x1bWFfZmlsdGVyLAo+ ID4gK2RvdF9jcmF3bCw8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPlN0YW5kYXJkIG5hbWVz IGFzIGluIERSTTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+U3RhbmRhcmQgdHlwZXMgYXMg aW4gRFJNPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5TdGFuZGFyZCBWYWx1ZXMgYXMgaW4g RFJNPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5TdGFuZGFyZCBvYmplY3QgYXMgaW4gRFJN PC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5UQkQ8L3RkPgo+ID4gKzwvdHI+Cj4gPiArIAo+ ID4gKzx0cj4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID50dl9mb3JtYXQ8L3RkPgo+ID4gKzx0ZCB2 YWxpZ249InRvcCIgPuKAnG1vZGXigJ08L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPkRSTV9N T0RFX1BST1BfRU5VTTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+ezAsICJQQUwifSwgezEs ICJQQUwtTSJ9LCB7MiwiUEFMLU4ifSwKPiA+ICt7MizigJ1QQUwtTmMifSwgezMsICJQQUwtNjAi fSwgezQsICJOVFNDLU0ifSwKPiA+ICt7NSwiTlRTQy1KIn08L3RkPgo+ID4gKzx0ZCB2YWxpZ249 InRvcCIgPkNvbm5lY3RvcjwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+VEJEPC90ZD4KPiA+ ICs8L3RyPgo+ID4gKyAKPiA+ICs8dHI+Cj4gPiArPHRkIHJvd3NwYW49IjE2IiB2YWxpZ249InRv cCI+bm92ZWF1PC90ZD4KPiA+ICs8dGQgcm93c3Bhbj0iNiIgdmFsaWduPSJ0b3AiPk5WMTAgT3Zl cmxheTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+Y29sb3JrZXk8L3RkPgo+ID4gKzx0ZCB2 YWxpZ249InRvcCIgPiJjb2xvcmtleSI8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPkRSTV9N T0RFX1BST1BfUkFOR0U8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPk1pbj0wLCBNYXg9MHgw MWZmZmZmZjwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+UGxhbmU8L3RkPgo+ID4gKzx0ZCB2 YWxpZ249InRvcCIgPlRCRDwvdGQ+Cj4gPiArPC90cj4KPiA+ICsgCj4gPiArPHRyPgo+ID4gKzx0 ZCB2YWxpZ249InRvcCIgPmNvbnRyYXN0PC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID7igJxj b250cmFzdOKAnTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+RFJNX01PREVfUFJPUF9SQU5H RTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+TWluPTAsIE1heD04MTkyLTE8L3RkPgo+ID4g Kzx0ZCB2YWxpZ249InRvcCIgPlBsYW5lPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5UQkQ8 L3RkPgo+ID4gKzwvdHI+Cj4gPiArIAo+ID4gKzx0cj4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5i cmlnaHRuZXNzPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID7igJxicmlnaHRuZXNz4oCdPC90 ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5EUk1fTU9ERV9QUk9QX1JBTkdFPC90ZD4KPiA+ICs8 dGQgdmFsaWduPSJ0b3AiID5NaW49MCwgTWF4PTEwMjQ8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRv cCIgPlBsYW5lPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5UQkQ8L3RkPgo+ID4gKzwvdHI+ Cj4gPiArIAo+ID4gKzx0cj4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5odWU8L3RkPgo+ID4gKzx0 ZCB2YWxpZ249InRvcCIgPuKAnGh1ZeKAnTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+RFJN X01PREVfUFJPUF9SQU5HRTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+TWluPTAsIE1heD0z NTk8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPlBsYW5lPC90ZD4KPiA+ICs8dGQgdmFsaWdu PSJ0b3AiID5UQkQ8L3RkPgo+ID4gKzwvdHI+Cj4gPiArIAo+ID4gKzx0cj4KPiA+ICs8dGQgdmFs aWduPSJ0b3AiID5zYXR1cmF0aW9uPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID7igJxzYXR1 cmF0aW9u4oCdPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5EUk1fTU9ERV9QUk9QX1JBTkdF PC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5NaW49MCwgTWF4PTgxOTItMTwvdGQ+Cj4gPiAr PHRkIHZhbGlnbj0idG9wIiA+UGxhbmU8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPlRCRDwv dGQ+Cj4gPiArPC90cj4KPiA+ICsgCj4gPiArPHRyPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPml0 dXJidF83MDk8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPuKAnGl0dXJidF83MDnigJ08L3Rk Pgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPkRSTV9NT0RFX1BST1BfUkFOR0U8L3RkPgo+ID4gKzx0 ZCB2YWxpZ249InRvcCIgPk1pbj0wLCBNYXg9MTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+ UGxhbmU8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPlRCRDwvdGQ+Cj4gPiArPC90cj4KPiA+ ICsgCj4gPiArPHRyPgo+ID4gKzx0ZCByb3dzcGFuPSIyIiB2YWxpZ249InRvcCI+TnYwNCBPdmVy bGF5PC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5jb2xvcmtleTwvdGQ+Cj4gPiArPHRkIHZh bGlnbj0idG9wIiA+4oCcY29sb3JrZXnigJ08L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPkRS TV9NT0RFX1BST1BfUkFOR0U8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPk1pbj0wLCBNYXg9 MHgwMWZmZmZmZjwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+UGxhbmU8L3RkPgo+ID4gKzx0 ZCB2YWxpZ249InRvcCIgPlRCRDwvdGQ+Cj4gPiArPC90cj4KPiA+ICsgCj4gPiArPHRyPgo+ID4g Kzx0ZCB2YWxpZ249InRvcCIgPmJyaWdodG5lc3M8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIg PuKAnGJyaWdodG5lc3PigJ08L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPkRSTV9NT0RFX1BS T1BfUkFOR0U8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPk1pbj0wLCBNYXg9MTAyNDwvdGQ+ Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+UGxhbmU8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIg PlRCRDwvdGQ+Cj4gPiArPC90cj4KPiA+ICsgCj4gPiArPHRyPgo+ID4gKzx0ZCByb3dzcGFuPSI3 IiB2YWxpZ249InRvcCI+RGlzcGxheTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+ZGl0aGVy aW5nX21vZGU8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPuKAnGRpdGhlcmluZyBtb2Rl4oCd PC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5EUk1fTU9ERV9QUk9QX0VOVU08L3RkPgo+ID4g Kzx0ZCB2YWxpZ249InRvcCIgPkN1c3RvbSB2YWx1ZXMgd2hpY2ggaGFzIGdlbiBpbmZvIGFzIHdl bGwuCj4gPiAreyA2LCBVTkRFUlNDQU5fQVVUTywgImF1dG8iIH0sCj4gPiAreyA2LCBVTkRFUlND QU5fT0ZGLCAib2ZmIiB9LAo+ID4gK3sgNiwgVU5ERVJTQ0FOX09OLCAib24iIH08L3RkPgo+ID4g Kzx0ZCB2YWxpZ249InRvcCIgPkNvbm5lY3RvcjwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+ VEJEPC90ZD4KPiA+ICs8L3RyPgo+ID4gKyAKPiA+ICs8dHI+Cj4gPiArPHRkIHZhbGlnbj0idG9w IiA+ZGl0aGVyaW5nX2RlcHRoPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID7igJxkaXRoZXJp bmcgZGVwdGjigJ08L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPkRSTV9NT0RFX1BST1BfRU5V TTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+Q3VzdG9tIHZhbHVlcyB3aGljaCBoYXMgZ2Vu IGluZm8gYXMgd2VsbC4KPiA+ICt7IDcsIERJVEhFUklOR19NT0RFX0FVVE8sICJhdXRvIiB9LAo+ ID4gK3sgNywgRElUSEVSSU5HX01PREVfT0ZGLCAib2ZmIiB9LAo+ID4gK3sgMSwgRElUSEVSSU5H X01PREVfT04sICJvbiIgfSwKPiA+ICt7IDYsIERJVEhFUklOR19NT0RFX1NUQVRJQzJYMiwgInN0 YXRpYyAyeDIiIH0sCj4gPiAreyA2LCBESVRIRVJJTkdfTU9ERV9EWU5BTUlDMlgyLCAiZHluYW1p YyAyeDIiIH0sCj4gPiAreyA0LCBESVRIRVJJTkdfTU9ERV9URU1QT1JBTCwgInRlbXBvcmFsIiB9 PC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5Db25uZWN0b3I8L3RkPgo+ID4gKzx0ZCB2YWxp Z249InRvcCIgPlRCRDwvdGQ+Cj4gPiArPC90cj4KPiA+ICsgCj4gPiArPHRyPgo+ID4gKzx0ZCB2 YWxpZ249InRvcCIgPnVuZGVyc2Nhbl9wcm9wZXJ0eTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9w IiA+4oCcdW5kZXJzY2Fu4oCdPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5EUk1fTU9ERV9Q Uk9QX0VOVU08L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPkN1c3RvbSB2YWx1ZXMgd2hpY2gg aGFzIGdlbiBpbmZvIGFzIHdlbGwuCj4gPiAreyA2LCBESVRIRVJJTkdfREVQVEhfQVVUTywgImF1 dG8iIH0sCj4gPiAreyA2LCBESVRIRVJJTkdfREVQVEhfNkJQQywgIjYgYnBjIiB9LAo+ID4gK3sg NiwgRElUSEVSSU5HX0RFUFRIXzhCUEMsICI4IGJwYyIgfTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0i dG9wIiA+Q29ubmVjdG9yPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5UQkQ8L3RkPgo+ID4g KzwvdHI+Cj4gPiArIAo+ID4gKzx0cj4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID51bmRlcnNjYW5f aGJvcmRlcl9wcm9wZXJ0eTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+4oCcdW5kZXJzY2Fu IGhib3JkZXLigJ08L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPkRSTV9NT0RFX1BST1BfUkFO R0U8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPk1pbj0wLCBNYXg9MTI4PC90ZD4KPiA+ICs8 dGQgdmFsaWduPSJ0b3AiID5Db25uZWN0b3I8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPlRC RDwvdGQ+Cj4gPiArPC90cj4KPiA+ICsgCj4gPiArPHRyPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIg PnVuZGVyc2Nhbl92Ym9yZGVyX3Byb3BlcnR5PC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID7i gJx1bmRlcnNjYW4gdmJvcmRlcuKAnTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+RFJNX01P REVfUFJPUF9SQU5HRTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+TWluPTAsIE1heD0xMjg8 L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPkNvbm5lY3RvcjwvdGQ+Cj4gPiArPHRkIHZhbGln bj0idG9wIiA+VEJEPC90ZD4KPiA+ICs8L3RyPgo+ID4gKyAKPiA+ICs8dHI+Cj4gPiArPHRkIHZh bGlnbj0idG9wIiA+dmlicmFudF9odWVfcHJvcGVydHk8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRv cCIgPuKAnHZpYnJhbnQgaHVl4oCdPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5EUk1fTU9E RV9QUk9QX1JBTkdFPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5NaW49MCwgTWF4PTE4MDwv dGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+Q29ubmVjdG9yPC90ZD4KPiA+ICs8dGQgdmFsaWdu PSJ0b3AiID5UQkQ8L3RkPgo+ID4gKzwvdHI+Cj4gPiArIAo+ID4gKzx0cj4KPiA+ICs8dGQgdmFs aWduPSJ0b3AiID5jb2xvcl92aWJyYW5jZV9wcm9wZXJ0eTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0i dG9wIiA+4oCcY29sb3IgdmlicmFuY2XigJ08L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPkRS TV9NT0RFX1BST1BfUkFOR0U8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPk1pbj0wLCBNYXg9 MjAwPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5Db25uZWN0b3I8L3RkPgo+ID4gKzx0ZCB2 YWxpZ249InRvcCIgPlRCRDwvdGQ+Cj4gPiArPC90cj4KPiA+ICsgCj4gPiArPHRyPgo+ID4gKzx0 ZCB2YWxpZ249InRvcCI+R2VuZXJpYzwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+c2NhbGlu Z19tb2RlX3Byb3BlcnR5Cj4gPiArIAo+ID4gKzwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+ U3RhbmRhcmQgbmFtZSBhcyBpbiBEUk08L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPlN0YW5k YXJkIHR5cGUgYXMgaW4gRFJNPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5TdGFuZGFyZCB2 YWx1ZSBhcyBpbiBEUk08L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPlN0YW5kYXJkIE9iamVj dCBhcyBpbiBEUk08L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPlRCRDwvdGQ+Cj4gPiArPC90 cj4KPiA+ICsgCj4gPiArPHRyPgo+ID4gKzx0ZCByb3dzcGFuPSIyIiB2YWxpZ249InRvcCI+b21h cDwvdGQ+Cj4gPiArPHRkIHJvd3NwYW49IjIiIHZhbGlnbj0idG9wIj5HZW5lcmljPC90ZD4KPiA+ ICs8dGQgdmFsaWduPSJ0b3AiID5yb3RhdGlvbl9wcm9wPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0 b3AiID7igJxyb3RhdGlvbuKAnTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+RFJNX01PREVf UFJPUF9CSVRNQVNLPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID57IDAsICJyb3RhdGUtMCIg fSwKPiA+ICt7IDEsICJyb3RhdGUtOTAiIH0sCj4gPiAreyAyLCAicm90YXRlLTE4MCIgfSwKPiA+ ICt7IDMsICJyb3RhdGUtMjcwIiB9LAo+ID4gK3sgNCwgInJlZmxlY3QteCIgfSwKPiA+ICt7IDUs ICJyZWZsZWN0LXkiIH08L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPkNSVEMsIFBsYW5lPC90 ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5UQkQ8L3RkPgo+ID4gKzwvdHI+Cj4gPiArIAo+ID4g Kzx0cj4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID56b3JkZXJfcHJvcDwvdGQ+Cj4gPiArPHRkIHZh bGlnbj0idG9wIiA+4oCcem9yZGVy4oCdPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5EUk1f TU9ERV9QUk9QX1JBTkdFPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5NaW49MCwgTWF4PTM8 L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPkNSVEMsIFBsYW5lPC90ZD4KPiA+ICs8dGQgdmFs aWduPSJ0b3AiID5UQkQ8L3RkPgo+ID4gKzwvdHI+Cj4gPiArIAo+ID4gKzx0cj4KPiA+ICs8dGQg dmFsaWduPSJ0b3AiPnF4bDwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIj5HZW5lcmljPC90ZD4K PiA+ICs8dGQgdmFsaWduPSJ0b3AiID5ob3RwbHVnX21vZGVfdXBkYXRlX3Byb3BlcnR5PC90ZD4K PiA+ICs8dGQgdmFsaWduPSJ0b3AiID7igJxob3RwbHVnX21vZGVfdXBkYXRlIjwvdGQ+Cj4gPiAr PHRkIHZhbGlnbj0idG9wIiA+RFJNX01PREVfUFJPUF9SQU5HRTwvdGQ+Cj4gPiArPHRkIHZhbGln bj0idG9wIiA+TWluPTAsIE1heD0xPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5Db25uZWN0 b3I8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPlRCRDwvdGQ+Cj4gPiArPC90cj4KPiA+ICsg Cj4gPiArPHRyPgo+ID4gKzx0ZCByb3dzcGFuPSIxMCIgdmFsaWduPSJ0b3AiPnJhZGVvbjwvdGQ+ Cj4gPiArPHRkIHZhbGlnbj0idG9wIj5EVkktSTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+ Y29oZXJlbnRfbW9kZV9wcm9wZXJ0eTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+4oCcY29o ZXJlbnTigJ08L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPkRSTV9NT0RFX1BST1BfUkFOR0U8 L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPk1pbj0wLCBNYXg9MTwvdGQ+Cj4gPiArPHRkIHZh bGlnbj0idG9wIiA+Q29ubmVjdG9yPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5UQkQ8L3Rk Pgo+ID4gKzwvdHI+Cj4gPiArIAo+ID4gKzx0cj4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiPkRBQyBl bmFibGUgbG9hZCBkZXRlY3Q8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPmxvYWRfZGV0ZWN0 X3Byb3BlcnR5PC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID7igJxsb2FkIGRldGVjdGlvbuKA nTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+RFJNX01PREVfUFJPUF9SQU5HRTwvdGQ+Cj4g PiArPHRkIHZhbGlnbj0idG9wIiA+TWluPTAsIE1heD0xPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0 b3AiID5Db25uZWN0b3I8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPlRCRDwvdGQ+Cj4gPiAr PC90cj4KPiA+ICsgCj4gPiArPHRyPgo+ID4gKzx0ZCB2YWxpZ249InRvcCI+VFYgU3RhbmRhcmQ8 L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPnR2X3N0ZF9wcm9wZXJ0eTwvdGQ+Cj4gPiArPHRk IHZhbGlnbj0idG9wIiA+InR2IHN0YW5kYXJkIjwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+ RFJNX01PREVfUFJPUF9FTlVNPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID57IFRWX1NURF9O VFNDLCAibnRzYyIgfSwKPiA+ICt7IFRWX1NURF9QQUwsICJwYWwiIH0sCj4gPiAreyBUVl9TVERf UEFMX00sICJwYWwtbSIgfSwKPiA+ICt7IFRWX1NURF9QQUxfNjAsICJwYWwtNjAiIH0sCj4gPiAr eyBUVl9TVERfTlRTQ19KLCAibnRzYy1qIiB9LAo+ID4gK3sgVFZfU1REX1NDQVJUX1BBTCwgInNj YXJ0LXBhbCIgfSwKPiA+ICt7IFRWX1NURF9QQUxfQ04sICJwYWwtY24iIH0sCj4gPiAreyBUVl9T VERfU0VDQU0sICJzZWNhbSIgfTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+Q29ubmVjdG9y PC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5UQkQ8L3RkPgo+ID4gKzwvdHI+Cj4gPiArIAo+ ID4gKzx0cj4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiPmxlZ2FjeSBUTURTIFBMTCBkZXRlY3Q8L3Rk Pgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPnRtZHNfcGxsX3Byb3BlcnR5PC90ZD4KPiA+ICs8dGQg dmFsaWduPSJ0b3AiID4idG1kc19wbGwiPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5EUk1f TU9ERV9QUk9QX0VOVU08L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPnsgMCwgImRyaXZlciIg fSwKPiA+ICt7IDEsICJiaW9zIiB9PC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID4tPC90ZD4K PiA+ICs8dGQgdmFsaWduPSJ0b3AiID5UQkQ8L3RkPgo+ID4gKzwvdHI+Cj4gPiArIAo+ID4gKzx0 cj4KPiA+ICs8dGQgcm93c3Bhbj0iMyIgdmFsaWduPSJ0b3AiPlVuZGVyc2NhbjwvdGQ+Cj4gPiAr PHRkIHZhbGlnbj0idG9wIiA+dW5kZXJzY2FuX3Byb3BlcnR5PC90ZD4KPiA+ICs8dGQgdmFsaWdu PSJ0b3AiID4idW5kZXJzY2FuIjwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+RFJNX01PREVf UFJPUF9FTlVNPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID57IFVOREVSU0NBTl9PRkYsICJv ZmYiIH0sCj4gPiAreyBVTkRFUlNDQU5fT04sICJvbiIgfSwKPiA+ICt7IFVOREVSU0NBTl9BVVRP LCAiYXV0byIgfTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+Q29ubmVjdG9yPC90ZD4KPiA+ ICs8dGQgdmFsaWduPSJ0b3AiID5UQkQ8L3RkPgo+ID4gKzwvdHI+Cj4gPiArIAo+ID4gKzx0cj4K PiA+ICs8dGQgdmFsaWduPSJ0b3AiID51bmRlcnNjYW5faGJvcmRlcl9wcm9wZXJ0eTwvdGQ+Cj4g PiArPHRkIHZhbGlnbj0idG9wIiA+InVuZGVyc2NhbiBoYm9yZGVyIjwvdGQ+Cj4gPiArPHRkIHZh bGlnbj0idG9wIiA+RFJNX01PREVfUFJPUF9SQU5HRTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9w IiA+TWluPTAsIE1heD0xMjg8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPkNvbm5lY3Rvcjwv dGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+VEJEPC90ZD4KPiA+ICs8L3RyPgo+ID4gKyAKPiA+ ICs8dHI+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+dW5kZXJzY2FuX3Zib3JkZXJfcHJvcGVydHk8 L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPiJ1bmRlcnNjYW4gdmJvcmRlciI8L3RkPgo+ID4g Kzx0ZCB2YWxpZ249InRvcCIgPkRSTV9NT0RFX1BST1BfUkFOR0U8L3RkPgo+ID4gKzx0ZCB2YWxp Z249InRvcCIgPk1pbj0wLCBNYXg9MTI4PC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5Db25u ZWN0b3I8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPlRCRDwvdGQ+Cj4gPiArPC90cj4KPiA+ ICsgCj4gPiArPHRyPgo+ID4gKzx0ZCB2YWxpZ249InRvcCI+QXVkaW88L3RkPgo+ID4gKzx0ZCB2 YWxpZ249InRvcCIgPmF1ZGlvX3Byb3BlcnR5PC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID7i gJxhdWRpb+KAnTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+RFJNX01PREVfUFJPUF9FTlVN PC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID57IFJBREVPTl9BVURJT19ESVNBQkxFLCAib2Zm IiB9LAo+ID4gK3sgUkFERU9OX0FVRElPX0VOQUJMRSwgIm9uIiB9LAo+ID4gK3sgUkFERU9OX0FV RElPX0FVVE8sICJhdXRvIiB9PC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5Db25uZWN0b3I8 L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPlRCRDwvdGQ+Cj4gPiArPC90cj4KPiA+ICsgCj4g PiArPHRyPgo+ID4gKzx0ZCB2YWxpZ249InRvcCI+Rk1UIERpdGhlcmluZzwvdGQ+Cj4gPiArPHRk IHZhbGlnbj0idG9wIiA+ZGl0aGVyX3Byb3BlcnR5PC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3Ai ID7igJxkaXRoZXLigJ08L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPkRSTV9NT0RFX1BST1Bf RU5VTTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+eyBSQURFT05fRk1UX0RJVEhFUl9ESVNB QkxFLCAib2ZmIiB9LAo+ID4gK3sgUkFERU9OX0ZNVF9ESVRIRVJfRU5BQkxFLCAib24iIH08L3Rk Pgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPkNvbm5lY3RvcjwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0i dG9wIiA+VEJEPC90ZD4KPiA+ICs8L3RyPgo+ID4gKyAKPiA+ICs8dHI+Cj4gPiArPHRkIHZhbGln bj0idG9wIj5HZW5lcmljPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5zY2FsaW5nX21vZGVf cHJvcGVydHkKPiA+ICsgCj4gPiArPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5TdGFuZGFy ZCBuYW1lIGFzIGluIERSTTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+U3RhbmRhcmQgdHlw ZSBhcyBpbiBEUk08L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPlN0YW5kYXJkIHZhbHVlIGFz IGluIERSTTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+U3RhbmRhcmQgT2JqZWN0IGFzIGlu IERSTTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0idG9wIiA+VEJEPC90ZD4KPiA+ICs8L3RyPgo+ID4g KyAKPiA+ICs8dHI+Cj4gPiArPHRkIHJvd3NwYW49IjMiIHZhbGlnbj0idG9wIj5yY2FyLWR1PC90 ZD4KPiA+ICs8dGQgcm93c3Bhbj0iMyIgdmFsaWduPSJ0b3AiPkdlbmVyaWM8L3RkPgo+ID4gKzx0 ZCB2YWxpZ249InRvcCIgPmFscGhhPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID4iYWxwaGEi PC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5EUk1fTU9ERV9QUk9QX1JBTkdFPC90ZD4KPiA+ ICs8dGQgdmFsaWduPSJ0b3AiID5NaW49MCwgTWF4PTI1NTwvdGQ+Cj4gPiArPHRkIHZhbGlnbj0i dG9wIiA+UGxhbmU8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPlRCRDwvdGQ+Cj4gPiArPC90 cj4KPiA+ICsgCj4gPiArPHRyPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPmNvbG9ya2V5PC90ZD4K PiA+ICs8dGQgdmFsaWduPSJ0b3AiID4iY29sb3JrZXkiPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0 b3AiID5EUk1fTU9ERV9QUk9QX1JBTkdFPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5NaW49 MCwgTWF4PTB4MDFmZmZmZmY8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPlBsYW5lPC90ZD4K PiA+ICs8dGQgdmFsaWduPSJ0b3AiID5UQkQ8L3RkPgo+ID4gKzwvdHI+Cj4gPiArIAo+ID4gKzx0 cj4KPiA+ICs8dGQgdmFsaWduPSJ0b3AiID56cG9zPC90ZD4KPiA+ICs8dGQgdmFsaWduPSJ0b3Ai ID4ienBvcyI8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPkRSTV9NT0RFX1BST1BfUkFOR0U8 L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPk1pbj0xLCBNYXg9NzwvdGQ+Cj4gPiArPHRkIHZh bGlnbj0idG9wIiA+UGxhbmU8L3RkPgo+ID4gKzx0ZCB2YWxpZ249InRvcCIgPlRCRDwvdGQ+Cj4g PiArPC90cj4KPiA+ICsgCj4gPiArPC90Ym9keT4KPiA+ICs8L3RhYmxlPgo+ID4gICAgPC9zZWN0 MT4KPiA+ICAKPiA+ICAgIDwhLS0gSW50ZXJuYWxzOiB2ZXJ0aWNhbCBibGFua2luZyAtLT4KPiA+ IC0tIAo+ID4gMS44LjUKPiAKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXwpJbnRlbC1nZnggbWFpbGluZyBsaXN0CkludGVsLWdmeEBsaXN0cy5mcmVlZGVz a3RvcC5vcmcKaHR0cDovL2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lu dGVsLWdmeAo= From mboxrd@z Thu Jan 1 00:00:00 1970 From: sagar.a.kamble@intel.com Subject: [PATCH v3 1/1] Documentation: drm: describing drm properties exposed by various drivers Date: Thu, 6 Mar 2014 20:11:28 +0530 Message-ID: <1394116888-19538-1-git-send-email-sagar.a.kamble@intel.com> References: <1394114484.31978.11.camel@sagar-desktop> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <1394114484.31978.11.camel@sagar-desktop> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces@lists.freedesktop.org Errors-To: intel-gfx-bounces@lists.freedesktop.org To: intel-gfx@lists.freedesktop.org Cc: Laurent Pinchart , linux-doc@vger.kernel.org, Daniel Vetter , dri-devel@lists.freedesktop.org, Rob Landley , David Herrmann , Alex Deucher , Dave Airlie , Sagar Kamble List-Id: dri-devel@lists.freedesktop.org RnJvbTogU2FnYXIgS2FtYmxlIDxzYWdhci5hLmthbWJsZUBpbnRlbC5jb20+CgpTdGFydGVkIGRv Y3VtZW50aW5nIGRybSBwcm9wZXJ0aWVzIGZvciBkcm0gZHJpdmVycy4gVGhpcyBwYXRjaCBwcm92 aWRlcwppbmZvcm1hdGlvbiBhYm91dCBwcm9wZXJ0aWVzIGluIGRybSwgaTkxNSwgcHNiIGFuZCBj ZHYvZ21hLTUwMC4gSW5mb3JtYXRpb24KYWJvdXQgb3RoZXIgcHJvcGVydGllcyBjYW4gYmUgYWRk ZWQgb24gdG9wIG9mIHRoZXNlLgoKdjI6IEFkZGVkIGRlc2NyaXB0aW9uIG9mIGRybSBwcm9wZXJ0 aWVzIGluIGFybWFkYSwgZXh5bm9zLCBpMmMvY2g3MDA2LCBub3ZlYXUsCm9tYXAsIHF4bCwgcmFk ZW9uLCByY2FyLWR1Cgp2MzogUmVtb3ZlZCAiUHJvcGVydHkgT2JqZWN0IiBjb2x1bW4gc2luY2Ug aXQgaXMgaW1wbGVtZW50YXRpb24gcmVsYXRlZC4gUHJvcGVydHkKdHlwZSBjb2x1bW4gcmVmaW5l ZC5bVmlsbGUncyByZXZpZXcgY29tbWVudHNdCgpDYzogUm9iIExhbmRsZXkgPHJvYkBsYW5kbGV5 Lm5ldD4KQ2M6IERhdmUgQWlybGllIDxhaXJsaWVkQHJlZGhhdC5jb20+CkNjOiBEYW5pZWwgVmV0 dGVyIDxkYW5pZWwudmV0dGVyQGZmd2xsLmNoPgpDYzogTGF1cmVudCBQaW5jaGFydCA8bGF1cmVu dC5waW5jaGFydCtyZW5lc2FzQGlkZWFzb25ib2FyZC5jb20+CkNjOiBEYXZpZCBIZXJybWFubiA8 ZGguaGVycm1hbm5AZ21haWwuY29tPgpDYzogQWxleCBEZXVjaGVyIDxhbGV4YW5kZXIuZGV1Y2hl ckBhbWQuY29tPgpDYzogIlZpbGxlIFN5cmrDpGzDpCIgPHZpbGxlLnN5cmphbGFAbGludXguaW50 ZWwuY29tPgpDYzogU2FnYXIgS2FtYmxlIDxzYWdhci5hLmthbWJsZUBpbnRlbC5jb20+CkNjOiAi UHVydXNob3RoYW1hbiwgVmlqYXkgQSIgPHZpamF5LmEucHVydXNob3RoYW1hbkBpbnRlbC5jb20+ CkNjOiBsaW51eC1kb2NAdmdlci5rZXJuZWwub3JnCkNjOiBkcmktZGV2ZWxAbGlzdHMuZnJlZWRl c2t0b3Aub3JnCgpTaWduZWQtb2ZmLWJ5OiBTYWdhciBLYW1ibGUgPHNhZ2FyLmEua2FtYmxlQGlu dGVsLmNvbT4KLS0tCiBEb2N1bWVudGF0aW9uL0RvY0Jvb2svZHJtLnRtcGwgfCAxMDI1ICsrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysKIDEgZmlsZSBjaGFuZ2VkLCAxMDI1 IGluc2VydGlvbnMoKykKCmRpZmYgLS1naXQgYS9Eb2N1bWVudGF0aW9uL0RvY0Jvb2svZHJtLnRt cGwgYi9Eb2N1bWVudGF0aW9uL0RvY0Jvb2svZHJtLnRtcGwKaW5kZXggZWQxZDZkMi4uZjM4YzUw NSAxMDA2NDQKLS0tIGEvRG9jdW1lbnRhdGlvbi9Eb2NCb29rL2RybS50bXBsCisrKyBiL0RvY3Vt ZW50YXRpb24vRG9jQm9vay9kcm0udG1wbApAQCAtMjMxNyw2ICsyMzE3LDEwMzEgQEAgdm9pZCBp bnRlbF9jcnRfaW5pdChzdHJ1Y3QgZHJtX2RldmljZSAqZGV2KQogICAgICAgcG9pbnRlciB0byB0 aGUgdGFyZ2V0IG9iamVjdCwgYSBwb2ludGVyIHRvIHRoZSBwcmV2aW91c2x5IGNyZWF0ZWQgcHJv cGVydHkKICAgICAgIGFuZCBhbiBpbml0aWFsIGluc3RhbmNlIHZhbHVlLgogICAgIDwvcGFyYT4K KyAgICA8cGFyYT4KKyAgICAgRm9sbG93aW5nIHRhYmxlIGdpdmVzIGRlc2NyaXB0aW9uIG9mIGRy bSBwcm9wZXJ0aWVzIGV4cG9zZWQgYnkgdmFyaW91cworICAgICBtb2R1bGVzL2RyaXZlcnMuCisg ICAgPC9wYXJhPgorPHRhYmxlIGJvcmRlcj0iMSIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5n PSIwIiA+Cis8dGJvZHk+Cis8dHIgc3R5bGU9ImZvbnQtd2VpZ2h0OiBib2xkOyI+Cis8dGQgdmFs aWduPSJ0b3AiID5Pd25lciBNb2R1bGUvRHJpdmVyczwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5H cm91cDwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5Qcm9wZXJ0eSBOYW1lPC90ZD4KKzx0ZCB2YWxp Z249InRvcCIgPlR5cGU8L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+UHJvcGVydHkgVmFsdWVzPC90 ZD4KKzx0ZCB2YWxpZ249InRvcCIgPk9iamVjdCBhdHRhY2hlZDwvdGQ+Cis8dGQgdmFsaWduPSJ0 b3AiID5EZXNjcmlwdGlvbi9SZXN0cmljdGlvbnM8L3RkPgorPC90cj4KKyAKKzx0cj4KKzx0ZCBy b3dzcGFuPSIxOSIgdmFsaWduPSJ0b3AiID5EUk08L3RkPgorPHRkIHJvd3NwYW49IjIiIHZhbGln bj0idG9wIiA+R2VuZXJpYzwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID7igJxFRElE4oCdPC90ZD4K Kzx0ZCB2YWxpZ249InRvcCIgPkJMT0IgfCBJTU1VVEFCTEU8L3RkPgorPHRkIHZhbGlnbj0idG9w IiA+MDwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5Db25uZWN0b3I8L3RkPgorPHRkIHZhbGlnbj0i dG9wIiA+Q29udGFpbnMgaWQgb2YgZWRpZCBibG9iIHB0ciBvYmplY3QuPC90ZD4KKzwvdHI+Cisg Cis8dHI+Cis8dGQgdmFsaWduPSJ0b3AiID7igJxEUE1T4oCdPC90ZD4KKzx0ZCB2YWxpZ249InRv cCIgPkVOVU08L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+eyBEUk1fTU9ERV9EUE1TX09OLCDigJxP buKAnX0sCit7IERSTV9NT0RFX0RQTVNfU1RBTkRCWSwg4oCcU3RhbmRieeKAnX0sCit7IERSTV9N T0RFX0RQTVNfU1VTUEVORCwg4oCcU3VzcGVuZOKAnX0sCit7IERSTV9NT0RFX0RQTVNfT0ZGLCDi gJxPZmbigJ19PC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPkNvbm5lY3RvcjwvdGQ+Cis8dGQgdmFs aWduPSJ0b3AiID5Db250YWlucyBEUE1TIG9wZXJhdGlvbiBtb2RlIHZhbHVlLjwvdGQ+Cis8L3Ry PgorIAorPHRyPgorPHRkIHJvd3NwYW49IjIiIHZhbGlnbj0idG9wIiA+RFZJLUk8L3RkPgorPHRk IHZhbGlnbj0idG9wIiA+4oCcc3ViY29ubmVjdG9y4oCdPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIg PkVOVU08L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+eyBEUk1fTU9ERV9TVUJDT05ORUNUT1JfVW5r bm93biwg4oCcVW5rbm93buKAnX0sCit7IERSTV9NT0RFX1NVQkNPTk5FQ1RPUl9EVklELCDigJxE VkktROKAnX0sCit7IERSTV9NT0RFX1NVQkNPTk5FQ1RPUl9EVklBLCDigJxEVkktQeKAnX08L3Rk PgorPHRkIHZhbGlnbj0idG9wIiA+Q29ubmVjdG9yPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPlRC RDwvdGQ+Cis8L3RyPgorIAorPHRyPgorPHRkIHZhbGlnbj0idG9wIiA+4oCcc2VsZWN0IHN1YmNv bm5lY3RvcuKAnTwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5FTlVNPC90ZD4KKzx0ZCB2YWxpZ249 InRvcCIgPnsgRFJNX01PREVfU1VCQ09OTkVDVE9SX0F1dG9tYXRpYywg4oCcQXV0b21hdGlj4oCd fSwKK3sgRFJNX01PREVfU1VCQ09OTkVDVE9SX0RWSUQsIOKAnERWSS1E4oCdfSwKK3sgRFJNX01P REVfU1VCQ09OTkVDVE9SX0RWSUEsIOKAnERWSS1B4oCdfTwvdGQ+Cis8dGQgdmFsaWduPSJ0b3Ai ID5Db25uZWN0b3I8L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+VEJEPC90ZD4KKzwvdHI+CisgCis8 dHI+Cis8dGQgcm93c3Bhbj0iMTMiIHZhbGlnbj0idG9wIiA+VFY8L3RkPgorPHRkIHZhbGlnbj0i dG9wIiA+4oCcc3ViY29ubmVjdG9y4oCdPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPkVOVU08L3Rk PgorPHRkIHZhbGlnbj0idG9wIiA+eyBEUk1fTU9ERV9TVUJDT05ORUNUT1JfVW5rbm93biwgIlVu a25vd24ifSwKK3sgRFJNX01PREVfU1VCQ09OTkVDVE9SX0NvbXBvc2l0ZSwgIkNvbXBvc2l0ZSIg fSwKK3sgRFJNX01PREVfU1VCQ09OTkVDVE9SX1NWSURFTywgIlNWSURFTyJ9LAoreyBEUk1fTU9E RV9TVUJDT05ORUNUT1JfQ29tcG9uZW50ICwgIkNvbXBvbmVudCJ9LAoreyBEUk1fTU9ERV9TVUJD T05ORUNUT1JfU0NBUlQsICJTQ0FSVCJ9PC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPkNvbm5lY3Rv cjwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5UQkQ8L3RkPgorPC90cj4KKyAKKzx0cj4KKzx0ZCB2 YWxpZ249InRvcCIgPuKAnHNlbGVjdCBzdWJjb25uZWN0b3LigJ08L3RkPgorPHRkIHZhbGlnbj0i dG9wIiA+RU5VTTwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID57RFJNX01PREVfU1VCQ09OTkVDVE9S X0F1dG9tYXRpYywgIkF1dG9tYXRpYyJ9LAore0RSTV9NT0RFX1NVQkNPTk5FQ1RPUl9Db21wb3Np dGUsICJDb21wb3NpdGUifSwKK3tEUk1fTU9ERV9TVUJDT05ORUNUT1JfU1ZJREVPLCAiU1ZJREVP In0sCit7RFJNX01PREVfU1VCQ09OTkVDVE9SX0NvbXBvbmVudCwgIkNvbXBvbmVudCJ9LAore0RS TV9NT0RFX1NVQkNPTk5FQ1RPUl9TQ0FSVCwgIlNDQVJUIn08L3RkPgorPHRkIHZhbGlnbj0idG9w IiA+Q29ubmVjdG9yPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPlRCRDwvdGQ+Cis8L3RyPgorIAor PHRyPgorPHRkIHZhbGlnbj0idG9wIiA+4oCcbW9kZeKAnTwvdGQ+Cis8dGQgdmFsaWduPSJ0b3Ai ID5FTlVNPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPnswLCAiTlRTQ19NIn0gLCB7MSwgIk5UU0Nf SiJ9ICwKK3syLCAiTlRTQ180NDMifSwgezMsICJQQUxfQiJ9IGV0Yy48L3RkPgorPHRkIHZhbGln bj0idG9wIiA+Q29ubmVjdG9yPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPlRCRDwvdGQ+Cis8L3Ry PgorIAorPHRyPgorPHRkIHZhbGlnbj0idG9wIiA+4oCcbGVmdCBtYXJnaW7igJ08L3RkPgorPHRk IHZhbGlnbj0idG9wIiA+UkFOR0U8L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+TWluPTAsIE1heD0x MDA8L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+Q29ubmVjdG9yPC90ZD4KKzx0ZCB2YWxpZ249InRv cCIgPlRCRDwvdGQ+Cis8L3RyPgorIAorPHRyPgorPHRkIHZhbGlnbj0idG9wIiA+4oCccmlnaHQg bWFyZ2lu4oCdPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPlJBTkdFPC90ZD4KKzx0ZCB2YWxpZ249 InRvcCIgPk1pbj0wLCBNYXg9MTAwPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPkNvbm5lY3Rvcjwv dGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5UQkQ8L3RkPgorPC90cj4KKyAKKzx0cj4KKzx0ZCB2YWxp Z249InRvcCIgPuKAnHRvcCBtYXJnaW7igJ08L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+UkFOR0U8 L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+TWluPTAsIE1heD0xMDA8L3RkPgorPHRkIHZhbGlnbj0i dG9wIiA+Q29ubmVjdG9yPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPlRCRDwvdGQ+Cis8L3RyPgor IAorPHRyPgorPHRkIHZhbGlnbj0idG9wIiA+4oCcYm90dG9tIG1hcmdpbuKAnTwvdGQ+Cis8dGQg dmFsaWduPSJ0b3AiID5SQU5HRTwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5NaW49MCwgTWF4PTEw MDwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5Db25uZWN0b3I8L3RkPgorPHRkIHZhbGlnbj0idG9w IiA+VEJEPC90ZD4KKzwvdHI+CisgCis8dHI+Cis8dGQgdmFsaWduPSJ0b3AiID7igJxicmlnaHRu ZXNz4oCdPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPlJBTkdFPC90ZD4KKzx0ZCB2YWxpZ249InRv cCIgPk1pbj0wLCBNYXg9MTAwPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPkNvbm5lY3RvcjwvdGQ+ Cis8dGQgdmFsaWduPSJ0b3AiID5UQkQ8L3RkPgorPC90cj4KKyAKKzx0cj4KKzx0ZCB2YWxpZ249 InRvcCIgPuKAnGNvbnRyYXN04oCdPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPlJBTkdFPC90ZD4K Kzx0ZCB2YWxpZ249InRvcCIgPk1pbj0wLCBNYXg9MTAwPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIg PkNvbm5lY3RvcjwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5UQkQ8L3RkPgorPC90cj4KKyAKKzx0 cj4KKzx0ZCB2YWxpZ249InRvcCIgPuKAnGZsaWNrZXIgcmVkdWN0aW9u4oCdPC90ZD4KKzx0ZCB2 YWxpZ249InRvcCIgPlJBTkdFPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPk1pbj0wLCBNYXg9MTAw PC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPkNvbm5lY3RvcjwvdGQ+Cis8dGQgdmFsaWduPSJ0b3Ai ID5UQkQ8L3RkPgorPC90cj4KKyAKKzx0cj4KKzx0ZCB2YWxpZ249InRvcCIgPuKAnG92ZXJzY2Fu 4oCdPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPlJBTkdFPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIg Pk1pbj0wLCBNYXg9MTAwPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPkNvbm5lY3RvcjwvdGQ+Cis8 dGQgdmFsaWduPSJ0b3AiID5UQkQ8L3RkPgorPC90cj4KKyAKKzx0cj4KKzx0ZCB2YWxpZ249InRv cCIgPuKAnHNhdHVyYXRpb27igJ08L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+UkFOR0U8L3RkPgor PHRkIHZhbGlnbj0idG9wIiA+TWluPTAsIE1heD0xMDA8L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+ Q29ubmVjdG9yPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPlRCRDwvdGQ+Cis8L3RyPgorIAorPHRy PgorPHRkIHZhbGlnbj0idG9wIiA+4oCcaHVl4oCdPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPlJB TkdFPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPk1pbj0wLCBNYXg9MTAwPC90ZD4KKzx0ZCB2YWxp Z249InRvcCIgPkNvbm5lY3RvcjwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5UQkQ8L3RkPgorPC90 cj4KKyAKKzx0cj4KKzx0ZCByb3dzcGFuPSIyIiB2YWxpZ249InRvcCIgPk9wdGlvbmFsPC90ZD4K Kzx0ZCB2YWxpZ249InRvcCIgPuKAnHNjYWxpbmcgbW9kZeKAnTwvdGQ+Cis8dGQgdmFsaWduPSJ0 b3AiID5FTlVNPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPnsgRFJNX01PREVfU0NBTEVfTk9ORSwg Ik5vbmUiIH0sCit7IERSTV9NT0RFX1NDQUxFX0ZVTExTQ1JFRU4sICJGdWxsIiB9LAoreyBEUk1f TU9ERV9TQ0FMRV9DRU5URVIsICJDZW50ZXIiIH0sCit7IERSTV9NT0RFX1NDQUxFX0FTUEVDVCwg IkZ1bGwgYXNwZWN0IiB9PC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPkNvbm5lY3RvcjwvdGQ+Cis8 dGQgdmFsaWduPSJ0b3AiID5UQkQ8L3RkPgorPC90cj4KKyAKKzx0cj4KKzx0ZCB2YWxpZ249InRv cCIgPuKAnGRpcnR54oCdPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPkVOVU0gfCBJTU1VVEFCTEU8 L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+eyBEUk1fTU9ERV9ESVJUWV9PRkYsICJPZmYiIH0sCit7 IERSTV9NT0RFX0RJUlRZX09OLCAiT24iIH0sCit7IERSTV9NT0RFX0RJUlRZX0FOTk9UQVRFLCAi QW5ub3RhdGUiIH08L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+Q29ubmVjdG9yPC90ZD4KKzx0ZCB2 YWxpZ249InRvcCIgPlRCRDwvdGQ+Cis8L3RyPgorIAorPHRyPgorPHRkIHJvd3NwYW49IjIxIiB2 YWxpZ249InRvcCIgPmk5MTU8L3RkPgorPHRkIHJvd3NwYW49IjMiIHZhbGlnbj0idG9wIiA+R2Vu ZXJpYzwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID4iQnJvYWRjYXN0IFJHQiI8L3RkPgorPHRkIHZh bGlnbj0idG9wIiA+RU5VTTwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID57IElOVEVMX0JST0FEQ0FT VF9SR0JfQVVUTywgIkF1dG9tYXRpYyIgfSwKK3sgSU5URUxfQlJPQURDQVNUX1JHQl9GVUxMLCAi RnVsbCIgfSwKK3sgSU5URUxfQlJPQURDQVNUX1JHQl9MSU1JVEVELCAiTGltaXRlZCAxNjoyMzUi IH08L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+Q29ubmVjdG9yPC90ZD4KKzx0ZCB2YWxpZ249InRv cCIgPlRCRDwvdGQ+Cis8L3RyPgorIAorPHRyPgorPHRkIHZhbGlnbj0idG9wIiA+4oCcYXVkaW/i gJ08L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+RU5VTTwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID57 IEhETUlfQVVESU9fT0ZGX0RWSSwgImZvcmNlLWR2aSIgfSwKK3sgSERNSV9BVURJT19PRkYsICJv ZmYiIH0sCit7IEhETUlfQVVESU9fQVVUTywgImF1dG8iIH0sCit7IEhETUlfQVVESU9fT04sICJv biIgfTwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5Db25uZWN0b3I8L3RkPgorPHRkIHZhbGlnbj0i dG9wIiA+VEJEPC90ZD4KKzwvdHI+CisgCis8dHI+Cis8dGQgdmFsaWduPSJ0b3AiID5TdGFuZGFy ZCBuYW1lIGFzIGluIERSTTwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5TdGFuZGFyZCB0eXBlIGFz IGluIERSTTwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5TdGFuZGFyZCB2YWx1ZSBhcyBpbiBEUk08 L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+U3RhbmRhcmQgT2JqZWN0IGFzIGluIERSTTwvdGQ+Cis8 dGQgdmFsaWduPSJ0b3AiID5UQkQ8L3RkPgorPC90cj4KKyAKKzx0cj4KKzx0ZCByb3dzcGFuPSIx NyIgdmFsaWduPSJ0b3AiID5TRFZPLVRWPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPuKAnG1vZGXi gJ08L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+RU5VTTwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID57 MCwgIk5UU0NfTSJ9ICwgezEsICJOVFNDX0oifSAsCit7MiwgIk5UU0NfNDQzIn0sIHszLCAiUEFM X0IifSBldGMuPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPkNvbm5lY3RvcjwvdGQ+Cis8dGQgdmFs aWduPSJ0b3AiID5UQkQ8L3RkPgorPC90cj4KKyAKKzx0cj4KKzx0ZCB2YWxpZ249InRvcCIgPiJs ZWZ0X21hcmdpbiI8L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+UkFOR0U8L3RkPgorPHRkIHZhbGln bj0idG9wIiA+TWluPTAsIE1heD0gU0RWTyBkZXBlbmRlbnQ8L3RkPgorPHRkIHZhbGlnbj0idG9w IiA+Q29ubmVjdG9yPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPlRCRDwvdGQ+Cis8L3RyPgorIAor PHRyPgorPHRkIHZhbGlnbj0idG9wIiA+InJpZ2h0X21hcmdpbiI8L3RkPgorPHRkIHZhbGlnbj0i dG9wIiA+UkFOR0U8L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+TWluPTAsIE1heD0gU0RWTyBkZXBl bmRlbnQ8L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+Q29ubmVjdG9yPC90ZD4KKzx0ZCB2YWxpZ249 InRvcCIgPlRCRDwvdGQ+Cis8L3RyPgorIAorPHRyPgorPHRkIHZhbGlnbj0idG9wIiA+InRvcF9t YXJnaW4iPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPlJBTkdFPC90ZD4KKzx0ZCB2YWxpZ249InRv cCIgPk1pbj0wLCBNYXg9IFNEVk8gZGVwZW5kZW50PC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPkNv bm5lY3RvcjwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5UQkQ8L3RkPgorPC90cj4KKyAKKzx0cj4K Kzx0ZCB2YWxpZ249InRvcCIgPiJib3R0b21fbWFyZ2luIjwvdGQ+Cis8dGQgdmFsaWduPSJ0b3Ai ID5SQU5HRTwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5NaW49MCwgTWF4PSBTRFZPIGRlcGVuZGVu dDwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5Db25uZWN0b3I8L3RkPgorPHRkIHZhbGlnbj0idG9w IiA+VEJEPC90ZD4KKzwvdHI+CisgCis8dHI+Cis8dGQgdmFsaWduPSJ0b3AiID7igJxocG9z4oCd PC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPlJBTkdFPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPk1p bj0wLCBNYXg9IFNEVk8gZGVwZW5kZW50PC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPkNvbm5lY3Rv cjwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5UQkQ8L3RkPgorPC90cj4KKyAKKzx0cj4KKzx0ZCB2 YWxpZ249InRvcCIgPuKAnHZwb3PigJ08L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+UkFOR0U8L3Rk PgorPHRkIHZhbGlnbj0idG9wIiA+TWluPTAsIE1heD0gU0RWTyBkZXBlbmRlbnQ8L3RkPgorPHRk IHZhbGlnbj0idG9wIiA+Q29ubmVjdG9yPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPlRCRDwvdGQ+ Cis8L3RyPgorIAorPHRyPgorPHRkIHZhbGlnbj0idG9wIiA+4oCcY29udHJhc3TigJ08L3RkPgor PHRkIHZhbGlnbj0idG9wIiA+UkFOR0U8L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+TWluPTAsIE1h eD0gU0RWTyBkZXBlbmRlbnQ8L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+Q29ubmVjdG9yPC90ZD4K Kzx0ZCB2YWxpZ249InRvcCIgPlRCRDwvdGQ+Cis8L3RyPgorIAorPHRyPgorPHRkIHZhbGlnbj0i dG9wIiA+4oCcc2F0dXJhdGlvbuKAnTwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5SQU5HRTwvdGQ+ Cis8dGQgdmFsaWduPSJ0b3AiID5NaW49MCwgTWF4PSBTRFZPIGRlcGVuZGVudDwvdGQ+Cis8dGQg dmFsaWduPSJ0b3AiID5Db25uZWN0b3I8L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+VEJEPC90ZD4K KzwvdHI+CisgCis8dHI+Cis8dGQgdmFsaWduPSJ0b3AiID7igJxodWXigJ08L3RkPgorPHRkIHZh bGlnbj0idG9wIiA+UkFOR0U8L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+TWluPTAsIE1heD0gU0RW TyBkZXBlbmRlbnQ8L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+Q29ubmVjdG9yPC90ZD4KKzx0ZCB2 YWxpZ249InRvcCIgPlRCRDwvdGQ+Cis8L3RyPgorIAorPHRyPgorPHRkIHZhbGlnbj0idG9wIiA+ 4oCcc2hhcnBuZXNz4oCdPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPlJBTkdFPC90ZD4KKzx0ZCB2 YWxpZ249InRvcCIgPk1pbj0wLCBNYXg9IFNEVk8gZGVwZW5kZW50PC90ZD4KKzx0ZCB2YWxpZ249 InRvcCIgPkNvbm5lY3RvcjwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5UQkQ8L3RkPgorPC90cj4K KyAKKzx0cj4KKzx0ZCB2YWxpZ249InRvcCIgPuKAnGZsaWNrZXJfZmlsdGVy4oCdPC90ZD4KKzx0 ZCB2YWxpZ249InRvcCIgPlJBTkdFPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPk1pbj0wLCBNYXg9 IFNEVk8gZGVwZW5kZW50PC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPkNvbm5lY3RvcjwvdGQ+Cis8 dGQgdmFsaWduPSJ0b3AiID5UQkQ8L3RkPgorPC90cj4KKyAKKzx0cj4KKzx0ZCB2YWxpZ249InRv cCIgPuKAnGZsaWNrZXJfZmlsdGVyX2FkYXB0aXZl4oCdPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIg PlJBTkdFPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPk1pbj0wLCBNYXg9IFNEVk8gZGVwZW5kZW50 PC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPkNvbm5lY3RvcjwvdGQ+Cis8dGQgdmFsaWduPSJ0b3Ai ID5UQkQ8L3RkPgorPC90cj4KKyAKKzx0cj4KKzx0ZCB2YWxpZ249InRvcCIgPuKAnGZsaWNrZXJf ZmlsdGVyXzJk4oCdPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPlJBTkdFPC90ZD4KKzx0ZCB2YWxp Z249InRvcCIgPk1pbj0wLCBNYXg9IFNEVk8gZGVwZW5kZW50PC90ZD4KKzx0ZCB2YWxpZ249InRv cCIgPkNvbm5lY3RvcjwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5UQkQ8L3RkPgorPC90cj4KKyAK Kzx0cj4KKzx0ZCB2YWxpZ249InRvcCIgPuKAnHR2X2Nocm9tYV9maWx0ZXLigJ08L3RkPgorPHRk IHZhbGlnbj0idG9wIiA+UkFOR0U8L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+TWluPTAsIE1heD0g U0RWTyBkZXBlbmRlbnQ8L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+Q29ubmVjdG9yPC90ZD4KKzx0 ZCB2YWxpZ249InRvcCIgPlRCRDwvdGQ+Cis8L3RyPgorIAorPHRyPgorPHRkIHZhbGlnbj0idG9w IiA+4oCcdHZfbHVtYV9maWx0ZXLigJ08L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+UkFOR0U8L3Rk PgorPHRkIHZhbGlnbj0idG9wIiA+TWluPTAsIE1heD0gU0RWTyBkZXBlbmRlbnQ8L3RkPgorPHRk IHZhbGlnbj0idG9wIiA+Q29ubmVjdG9yPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPlRCRDwvdGQ+ Cis8L3RyPgorIAorPHRyPgorPHRkIHZhbGlnbj0idG9wIiA+4oCcZG90X2NyYXds4oCdPC90ZD4K Kzx0ZCB2YWxpZ249InRvcCIgPlJBTkdFPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPk1pbj0wLCBN YXg9MTwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5Db25uZWN0b3I8L3RkPgorPHRkIHZhbGlnbj0i dG9wIiA+VEJEPC90ZD4KKzwvdHI+CisgCis8dHI+Cis8dGQgdmFsaWduPSJ0b3AiID5TRFZPLVRW L0xWRFM8L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+4oCcYnJpZ2h0bmVzc+KAnTwvdGQ+Cis8dGQg dmFsaWduPSJ0b3AiID5SQU5HRTwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5NaW49MCwgTWF4PSBT RFZPIGRlcGVuZGVudDwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5Db25uZWN0b3I8L3RkPgorPHRk IHZhbGlnbj0idG9wIiA+VEJEPC90ZD4KKzwvdHI+CisgCis8dHI+Cis8dGQgcm93c3Bhbj0iMyIg dmFsaWduPSJ0b3AiID5DRFYgZ21hLTUwMDwvdGQ+Cis8dGQgcm93c3Bhbj0iMyIgdmFsaWduPSJ0 b3AiID5HZW5lcmljPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPiJCcm9hZGNhc3QgUkdCIjwvdGQ+ Cis8dGQgdmFsaWduPSJ0b3AiID5FTlVNPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPnsgMCwg4oCc RnVsbOKAnX0sCit7IDEsIOKAnExpbWl0ZWQgMTY6MjM14oCdfTwvdGQ+Cis8dGQgdmFsaWduPSJ0 b3AiID5Db25uZWN0b3I8L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+VEJEPC90ZD4KKzwvdHI+Cisg Cis8dHI+Cis8dGQgdmFsaWduPSJ0b3AiID4iQnJvYWRjYXN0IFJHQiI8L3RkPgorPHRkIHZhbGln bj0idG9wIiA+RU5VTTwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID57IC0xLCDigJxvZmbigJ19LAor eyAwLCDigJxhdXRv4oCdfSwKK3sgMSwg4oCcb27igJ19PC90ZD4KKzx0ZCB2YWxpZ249InRvcCIg PkNvbm5lY3RvcjwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5UQkQ8L3RkPgorPC90cj4KKyAKKzx0 cj4KKzx0ZCB2YWxpZ249InRvcCIgPlN0YW5kYXJkIG5hbWUgYXMgaW4gRFJNPC90ZD4KKzx0ZCB2 YWxpZ249InRvcCIgPlN0YW5kYXJkIHR5cGUgYXMgaW4gRFJNPC90ZD4KKzx0ZCB2YWxpZ249InRv cCIgPlN0YW5kYXJkIHZhbHVlIGFzIGluIERSTTwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5TdGFu ZGFyZCBPYmplY3QgYXMgaW4gRFJNPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPlRCRDwvdGQ+Cis8 L3RyPgorIAorPHRyPgorPHRkIHJvd3NwYW49IjIwIiB2YWxpZ249InRvcCIgPlBvdWxzYm88L3Rk PgorPHRkIHJvd3NwYW49IjIiIHZhbGlnbj0idG9wIiA+R2VuZXJpYzwvdGQ+Cis8dGQgdmFsaWdu PSJ0b3AiID7igJxiYWNrbGlnaHTigJ08L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+UkFOR0U8L3Rk PgorPHRkIHZhbGlnbj0idG9wIiA+TWluPTAsIE1heD0xMDA8L3RkPgorPHRkIHZhbGlnbj0idG9w IiA+Q29ubmVjdG9yPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPlRCRDwvdGQ+Cis8L3RyPgorIAor PHRyPgorPHRkIHZhbGlnbj0idG9wIiA+U3RhbmRhcmQgbmFtZSBhcyBpbiBEUk08L3RkPgorPHRk IHZhbGlnbj0idG9wIiA+U3RhbmRhcmQgdHlwZSBhcyBpbiBEUk08L3RkPgorPHRkIHZhbGlnbj0i dG9wIiA+U3RhbmRhcmQgdmFsdWUgYXMgaW4gRFJNPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPlN0 YW5kYXJkIE9iamVjdCBhcyBpbiBEUk08L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+VEJEPC90ZD4K KzwvdHI+CisgCis8dHI+Cis8dGQgcm93c3Bhbj0iMTciIHZhbGlnbj0idG9wIiA+U0RWTy1UVjwv dGQ+Cis8dGQgdmFsaWduPSJ0b3AiID7igJxtb2Rl4oCdPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIg PkVOVU08L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+ezAsICJOVFNDX00ifSAsIHsxLCAiTlRTQ19K In0gLAorezIsICJOVFNDXzQ0MyJ9LCB7MywgIlBBTF9CIn0gZXRjLjwvdGQ+Cis8dGQgdmFsaWdu PSJ0b3AiID5Db25uZWN0b3I8L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+VEJEPC90ZD4KKzwvdHI+ CisgCis8dHI+Cis8dGQgdmFsaWduPSJ0b3AiID4ibGVmdF9tYXJnaW4iPC90ZD4KKzx0ZCB2YWxp Z249InRvcCIgPlJBTkdFPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPk1pbj0wLCBNYXg9IFNEVk8g ZGVwZW5kZW50PC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPkNvbm5lY3RvcjwvdGQ+Cis8dGQgdmFs aWduPSJ0b3AiID5UQkQ8L3RkPgorPC90cj4KKyAKKzx0cj4KKzx0ZCB2YWxpZ249InRvcCIgPiJy aWdodF9tYXJnaW4iPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPlJBTkdFPC90ZD4KKzx0ZCB2YWxp Z249InRvcCIgPk1pbj0wLCBNYXg9IFNEVk8gZGVwZW5kZW50PC90ZD4KKzx0ZCB2YWxpZ249InRv cCIgPkNvbm5lY3RvcjwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5UQkQ8L3RkPgorPC90cj4KKyAK Kzx0cj4KKzx0ZCB2YWxpZ249InRvcCIgPiJ0b3BfbWFyZ2luIjwvdGQ+Cis8dGQgdmFsaWduPSJ0 b3AiID5SQU5HRTwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5NaW49MCwgTWF4PSBTRFZPIGRlcGVu ZGVudDwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5Db25uZWN0b3I8L3RkPgorPHRkIHZhbGlnbj0i dG9wIiA+VEJEPC90ZD4KKzwvdHI+CisgCis8dHI+Cis8dGQgdmFsaWduPSJ0b3AiID4iYm90dG9t X21hcmdpbiI8L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+UkFOR0U8L3RkPgorPHRkIHZhbGlnbj0i dG9wIiA+TWluPTAsIE1heD0gU0RWTyBkZXBlbmRlbnQ8L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+ Q29ubmVjdG9yPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPlRCRDwvdGQ+Cis8L3RyPgorIAorPHRy PgorPHRkIHZhbGlnbj0idG9wIiA+4oCcaHBvc+KAnTwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5S QU5HRTwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5NaW49MCwgTWF4PSBTRFZPIGRlcGVuZGVudDwv dGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5Db25uZWN0b3I8L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+ VEJEPC90ZD4KKzwvdHI+CisgCis8dHI+Cis8dGQgdmFsaWduPSJ0b3AiID7igJx2cG9z4oCdPC90 ZD4KKzx0ZCB2YWxpZ249InRvcCIgPlJBTkdFPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPk1pbj0w LCBNYXg9IFNEVk8gZGVwZW5kZW50PC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPkNvbm5lY3Rvcjwv dGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5UQkQ8L3RkPgorPC90cj4KKyAKKzx0cj4KKzx0ZCB2YWxp Z249InRvcCIgPuKAnGNvbnRyYXN04oCdPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPlJBTkdFPC90 ZD4KKzx0ZCB2YWxpZ249InRvcCIgPk1pbj0wLCBNYXg9IFNEVk8gZGVwZW5kZW50PC90ZD4KKzx0 ZCB2YWxpZ249InRvcCIgPkNvbm5lY3RvcjwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5UQkQ8L3Rk PgorPC90cj4KKyAKKzx0cj4KKzx0ZCB2YWxpZ249InRvcCIgPuKAnHNhdHVyYXRpb27igJ08L3Rk PgorPHRkIHZhbGlnbj0idG9wIiA+UkFOR0U8L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+TWluPTAs IE1heD0gU0RWTyBkZXBlbmRlbnQ8L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+Q29ubmVjdG9yPC90 ZD4KKzx0ZCB2YWxpZ249InRvcCIgPlRCRDwvdGQ+Cis8L3RyPgorIAorPHRyPgorPHRkIHZhbGln bj0idG9wIiA+4oCcaHVl4oCdPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPlJBTkdFPC90ZD4KKzx0 ZCB2YWxpZ249InRvcCIgPk1pbj0wLCBNYXg9IFNEVk8gZGVwZW5kZW50PC90ZD4KKzx0ZCB2YWxp Z249InRvcCIgPkNvbm5lY3RvcjwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5UQkQ8L3RkPgorPC90 cj4KKyAKKzx0cj4KKzx0ZCB2YWxpZ249InRvcCIgPuKAnHNoYXJwbmVzc+KAnTwvdGQ+Cis8dGQg dmFsaWduPSJ0b3AiID5SQU5HRTwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5NaW49MCwgTWF4PSBT RFZPIGRlcGVuZGVudDwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5Db25uZWN0b3I8L3RkPgorPHRk IHZhbGlnbj0idG9wIiA+VEJEPC90ZD4KKzwvdHI+CisgCis8dHI+Cis8dGQgdmFsaWduPSJ0b3Ai ID7igJxmbGlja2VyX2ZpbHRlcuKAnTwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5SQU5HRTwvdGQ+ Cis8dGQgdmFsaWduPSJ0b3AiID5NaW49MCwgTWF4PSBTRFZPIGRlcGVuZGVudDwvdGQ+Cis8dGQg dmFsaWduPSJ0b3AiID5Db25uZWN0b3I8L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+VEJEPC90ZD4K KzwvdHI+CisgCis8dHI+Cis8dGQgdmFsaWduPSJ0b3AiID7igJxmbGlja2VyX2ZpbHRlcl9hZGFw dGl2ZeKAnTwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5SQU5HRTwvdGQ+Cis8dGQgdmFsaWduPSJ0 b3AiID5NaW49MCwgTWF4PSBTRFZPIGRlcGVuZGVudDwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5D b25uZWN0b3I8L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+VEJEPC90ZD4KKzwvdHI+CisgCis8dHI+ Cis8dGQgdmFsaWduPSJ0b3AiID7igJxmbGlja2VyX2ZpbHRlcl8yZOKAnTwvdGQ+Cis8dGQgdmFs aWduPSJ0b3AiID5SQU5HRTwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5NaW49MCwgTWF4PSBTRFZP IGRlcGVuZGVudDwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5Db25uZWN0b3I8L3RkPgorPHRkIHZh bGlnbj0idG9wIiA+VEJEPC90ZD4KKzwvdHI+CisgCis8dHI+Cis8dGQgdmFsaWduPSJ0b3AiID7i gJx0dl9jaHJvbWFfZmlsdGVy4oCdPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPlJBTkdFPC90ZD4K Kzx0ZCB2YWxpZ249InRvcCIgPk1pbj0wLCBNYXg9IFNEVk8gZGVwZW5kZW50PC90ZD4KKzx0ZCB2 YWxpZ249InRvcCIgPkNvbm5lY3RvcjwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5UQkQ8L3RkPgor PC90cj4KKyAKKzx0cj4KKzx0ZCB2YWxpZ249InRvcCIgPuKAnHR2X2x1bWFfZmlsdGVy4oCdPC90 ZD4KKzx0ZCB2YWxpZ249InRvcCIgPlJBTkdFPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPk1pbj0w LCBNYXg9IFNEVk8gZGVwZW5kZW50PC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPkNvbm5lY3Rvcjwv dGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5UQkQ8L3RkPgorPC90cj4KKyAKKzx0cj4KKzx0ZCB2YWxp Z249InRvcCIgPuKAnGRvdF9jcmF3bOKAnTwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5SQU5HRTwv dGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5NaW49MCwgTWF4PTE8L3RkPgorPHRkIHZhbGlnbj0idG9w IiA+Q29ubmVjdG9yPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPlRCRDwvdGQ+Cis8L3RyPgorIAor PHRyPgorPHRkIHZhbGlnbj0idG9wIiA+U0RWTy1UVi9MVkRTPC90ZD4KKzx0ZCB2YWxpZ249InRv cCIgPuKAnGJyaWdodG5lc3PigJ08L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+UkFOR0U8L3RkPgor PHRkIHZhbGlnbj0idG9wIiA+TWluPTAsIE1heD0gU0RWTyBkZXBlbmRlbnQ8L3RkPgorPHRkIHZh bGlnbj0idG9wIiA+Q29ubmVjdG9yPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPlRCRDwvdGQ+Cis8 L3RyPgorIAorPHRyPgorPHRkIHJvd3NwYW49IjExIiB2YWxpZ249InRvcCIgPmFybWFkYTwvdGQ+ Cis8dGQgcm93c3Bhbj0iMiIgdmFsaWduPSJ0b3AiID5DUlRDPC90ZD4KKzx0ZCB2YWxpZ249InRv cCIgPiJDU0NfWVVWIjwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5FTlVNPC90ZD4KKzx0ZCB2YWxp Z249InRvcCIgPnsgQ1NDX0FVVE8sICJBdXRvIiB9LAoreyBDU0NfWVVWX0NDSVI2MDEsICJDQ0lS NjAxIiB9LAoreyBDU0NfWVVWX0NDSVI3MDksICJDQ0lSNzA5IiB9PC90ZD4KKzx0ZCB2YWxpZ249 InRvcCIgPkNSVEM8L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+VEJEPC90ZD4KKzwvdHI+CisgCis8 dHI+Cis8dGQgdmFsaWduPSJ0b3AiID4iQ1NDX1JHQiI8L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+ RU5VTTwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID57IENTQ19BVVRPLCAiQXV0byIgfSwKK3sgQ1ND X1JHQl9DT01QVVRFUiwgIkNvbXB1dGVyIHN5c3RlbSIgfSwKK3sgQ1NDX1JHQl9TVFVESU8sICJT dHVkaW8iIH08L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+Q1JUQzwvdGQ+Cis8dGQgdmFsaWduPSJ0 b3AiID5UQkQ8L3RkPgorPC90cj4KKyAKKzx0cj4KKzx0ZCByb3dzcGFuPSI5IiB2YWxpZ249InRv cCIgPk92ZXJsYXk8L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+ImNvbG9ya2V5IjwvdGQ+Cis8dGQg dmFsaWduPSJ0b3AiID5SQU5HRTwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5NaW49MCwgTWF4PTB4 ZmZmZmZmPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPlBsYW5lPC90ZD4KKzx0ZCB2YWxpZ249InRv cCIgPlRCRDwvdGQ+Cis8L3RyPgorIAorPHRyPgorPHRkIHZhbGlnbj0idG9wIiA+ImNvbG9ya2V5 X21pbiI8L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+UkFOR0U8L3RkPgorPHRkIHZhbGlnbj0idG9w IiA+TWluPTAsIE1heD0weGZmZmZmZjwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5QbGFuZTwvdGQ+ Cis8dGQgdmFsaWduPSJ0b3AiID5UQkQ8L3RkPgorPC90cj4KKyAKKzx0cj4KKzx0ZCB2YWxpZ249 InRvcCIgPiJjb2xvcmtleV9tYXgiPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPlJBTkdFPC90ZD4K Kzx0ZCB2YWxpZ249InRvcCIgPk1pbj0wLCBNYXg9MHhmZmZmZmY8L3RkPgorPHRkIHZhbGlnbj0i dG9wIiA+UGxhbmU8L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+VEJEPC90ZD4KKzwvdHI+CisgCis8 dHI+Cis8dGQgdmFsaWduPSJ0b3AiID4iY29sb3JrZXlfdmFsIjwvdGQ+Cis8dGQgdmFsaWduPSJ0 b3AiID5SQU5HRTwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5NaW49MCwgTWF4PTB4ZmZmZmZmPC90 ZD4KKzx0ZCB2YWxpZ249InRvcCIgPlBsYW5lPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPlRCRDwv dGQ+Cis8L3RyPgorIAorPHRyPgorPHRkIHZhbGlnbj0idG9wIiA+ImNvbG9ya2V5X2FscGhhIjwv dGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5SQU5HRTwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5NaW49 MCwgTWF4PTB4ZmZmZmZmPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPlBsYW5lPC90ZD4KKzx0ZCB2 YWxpZ249InRvcCIgPlRCRDwvdGQ+Cis8L3RyPgorIAorPHRyPgorPHRkIHZhbGlnbj0idG9wIiA+ ImNvbG9ya2V5X21vZGUiPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPkVOVU08L3RkPgorPHRkIHZh bGlnbj0idG9wIiA+eyBDS01PREVfRElTQUJMRSwgImRpc2FibGVkIiB9LAoreyBDS01PREVfWSwg IlkgY29tcG9uZW50IiB9LAoreyBDS01PREVfVSwgIlUgY29tcG9uZW50IiB9LAoreyBDS01PREVf ViwgIlYgY29tcG9uZW50IiB9LAoreyBDS01PREVfUkdCLCAiUkdCIiB9LAoreyBDS01PREVfUiwg 4oCcUiBjb21wb25lbnQiIH0sCit7IENLTU9ERV9HLCAiRyBjb21wb25lbnQiIH0sCisgQ0tNT0RF X0IsICJCIGNvbXBvbmVudCIgfTwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5QbGFuZTwvdGQ+Cis8 dGQgdmFsaWduPSJ0b3AiID5UQkQ8L3RkPgorPC90cj4KKyAKKzx0cj4KKzx0ZCB2YWxpZ249InRv cCIgPiJicmlnaHRuZXNzIjwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5SQU5HRTwvdGQ+Cis8dGQg dmFsaWduPSJ0b3AiID5NaW49MCwgTWF4PTI1NiArIDI1NTwvdGQ+Cis8dGQgdmFsaWduPSJ0b3Ai ID5QbGFuZTwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5UQkQ8L3RkPgorPC90cj4KKyAKKzx0cj4K Kzx0ZCB2YWxpZ249InRvcCIgPiJjb250cmFzdCI8L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+UkFO R0U8L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+TWluPTAsIE1heD0weDdmZmY8L3RkPgorPHRkIHZh bGlnbj0idG9wIiA+UGxhbmU8L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+VEJEPC90ZD4KKzwvdHI+ CisgCis8dHI+Cis8dGQgdmFsaWduPSJ0b3AiID4ic2F0dXJhdGlvbiI8L3RkPgorPHRkIHZhbGln bj0idG9wIiA+UkFOR0U8L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+TWluPTAsIE1heD0weDdmZmY8 L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+UGxhbmU8L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+VEJE PC90ZD4KKzwvdHI+CisgCis8dHI+Cis8dGQgcm93c3Bhbj0iMiIgdmFsaWduPSJ0b3AiID5leHlu b3M8L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+Q1JUQzwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID7i gJxtb2Rl4oCdPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPkVOVU08L3RkPgorPHRkIHZhbGlnbj0i dG9wIiA+eyBDUlRDX01PREVfTk9STUFMLCAibm9ybWFsIiB9LAoreyBDUlRDX01PREVfQkxBTkss ICJibGFuayIgfTwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5DUlRDPC90ZD4KKzx0ZCB2YWxpZ249 InRvcCIgPlRCRDwvdGQ+Cis8L3RyPgorIAorPHRyPgorPHRkIHZhbGlnbj0idG9wIiA+T3Zlcmxh eTwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID7igJx6cG9z4oCdPC90ZD4KKzx0ZCB2YWxpZ249InRv cCIgPlJBTkdFPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPk1pbj0wLCBNYXg9TUFYX1BMQU5FLTE8 L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+UGxhbmU8L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+VEJE PC90ZD4KKzwvdHI+CisgCis8dHI+Cis8dGQgcm93c3Bhbj0iMyIgdmFsaWduPSJ0b3AiID5pMmMv Y2g3MDA2X2RydjwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5HZW5lcmljPC90ZD4KKzx0ZCB2YWxp Z249InRvcCIgPuKAnHNjYWxl4oCdPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPlJBTkdFPC90ZD4K Kzx0ZCB2YWxpZ249InRvcCIgPk1pbj0wLCBNYXg9MjwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5D b25uZWN0b3I8L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+VEJEPC90ZD4KKzwvdHI+CisgCis8dHI+ Cis8dGQgcm93c3Bhbj0iMiIgdmFsaWduPSJ0b3AiID5UVjwvdGQ+Cis8dGQgdmFsaWduPSJ0b3Ai ID5TdGFuZGFyZCBuYW1lcyBhcyBpbiBEUk08L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+U3RhbmRh cmQgdHlwZXMgYXMgaW4gRFJNPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPlN0YW5kYXJkIFZhbHVl cyBhcyBpbiBEUk08L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+U3RhbmRhcmQgb2JqZWN0IGFzIGlu IERSTTwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5UQkQ8L3RkPgorPC90cj4KKyAKKzx0cj4KKzx0 ZCB2YWxpZ249InRvcCIgPuKAnG1vZGXigJ08L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+RU5VTTwv dGQ+Cis8dGQgdmFsaWduPSJ0b3AiID57MCwgIlBBTCJ9LCB7MSwgIlBBTC1NIn0sIHsyLCJQQUwt TiJ9LAorezIs4oCdUEFMLU5jIn0sIHszLCAiUEFMLTYwIn0sIHs0LCAiTlRTQy1NIn0sCit7NSwi TlRTQy1KIn08L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+Q29ubmVjdG9yPC90ZD4KKzx0ZCB2YWxp Z249InRvcCIgPlRCRDwvdGQ+Cis8L3RyPgorIAorPHRyPgorPHRkIHJvd3NwYW49IjE2IiB2YWxp Z249InRvcCIgPm5vdmVhdTwvdGQ+Cis8dGQgcm93c3Bhbj0iNiIgdmFsaWduPSJ0b3AiID5OVjEw IE92ZXJsYXk8L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+ImNvbG9ya2V5IjwvdGQ+Cis8dGQgdmFs aWduPSJ0b3AiID5SQU5HRTwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5NaW49MCwgTWF4PTB4MDFm ZmZmZmY8L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+UGxhbmU8L3RkPgorPHRkIHZhbGlnbj0idG9w IiA+VEJEPC90ZD4KKzwvdHI+CisgCis8dHI+Cis8dGQgdmFsaWduPSJ0b3AiID7igJxjb250cmFz dOKAnTwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5SQU5HRTwvdGQ+Cis8dGQgdmFsaWduPSJ0b3Ai ID5NaW49MCwgTWF4PTgxOTItMTwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5QbGFuZTwvdGQ+Cis8 dGQgdmFsaWduPSJ0b3AiID5UQkQ8L3RkPgorPC90cj4KKyAKKzx0cj4KKzx0ZCB2YWxpZ249InRv cCIgPuKAnGJyaWdodG5lc3PigJ08L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+UkFOR0U8L3RkPgor PHRkIHZhbGlnbj0idG9wIiA+TWluPTAsIE1heD0xMDI0PC90ZD4KKzx0ZCB2YWxpZ249InRvcCIg PlBsYW5lPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPlRCRDwvdGQ+Cis8L3RyPgorIAorPHRyPgor PHRkIHZhbGlnbj0idG9wIiA+4oCcaHVl4oCdPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPlJBTkdF PC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPk1pbj0wLCBNYXg9MzU5PC90ZD4KKzx0ZCB2YWxpZ249 InRvcCIgPlBsYW5lPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPlRCRDwvdGQ+Cis8L3RyPgorIAor PHRyPgorPHRkIHZhbGlnbj0idG9wIiA+4oCcc2F0dXJhdGlvbuKAnTwvdGQ+Cis8dGQgdmFsaWdu PSJ0b3AiID5SQU5HRTwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5NaW49MCwgTWF4PTgxOTItMTwv dGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5QbGFuZTwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5UQkQ8 L3RkPgorPC90cj4KKyAKKzx0cj4KKzx0ZCB2YWxpZ249InRvcCIgPuKAnGl0dXJidF83MDnigJ08 L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+UkFOR0U8L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+TWlu PTAsIE1heD0xPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPlBsYW5lPC90ZD4KKzx0ZCB2YWxpZ249 InRvcCIgPlRCRDwvdGQ+Cis8L3RyPgorIAorPHRyPgorPHRkIHJvd3NwYW49IjIiIHZhbGlnbj0i dG9wIiA+TnYwNCBPdmVybGF5PC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPuKAnGNvbG9ya2V54oCd PC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPlJBTkdFPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPk1p bj0wLCBNYXg9MHgwMWZmZmZmZjwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5QbGFuZTwvdGQ+Cis8 dGQgdmFsaWduPSJ0b3AiID5UQkQ8L3RkPgorPC90cj4KKyAKKzx0cj4KKzx0ZCB2YWxpZ249InRv cCIgPuKAnGJyaWdodG5lc3PigJ08L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+UkFOR0U8L3RkPgor PHRkIHZhbGlnbj0idG9wIiA+TWluPTAsIE1heD0xMDI0PC90ZD4KKzx0ZCB2YWxpZ249InRvcCIg PlBsYW5lPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPlRCRDwvdGQ+Cis8L3RyPgorIAorPHRyPgor PHRkIHJvd3NwYW49IjciIHZhbGlnbj0idG9wIiA+RGlzcGxheTwvdGQ+Cis8dGQgdmFsaWduPSJ0 b3AiID7igJxkaXRoZXJpbmcgbW9kZeKAnTwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5FTlVNPC90 ZD4KKzx0ZCB2YWxpZ249InRvcCIgPkN1c3RvbSB2YWx1ZXMgd2hpY2ggaGFzIGdlbiBpbmZvIGFz IHdlbGwuCit7IDYsIFVOREVSU0NBTl9BVVRPLCAiYXV0byIgfSwKK3sgNiwgVU5ERVJTQ0FOX09G RiwgIm9mZiIgfSwKK3sgNiwgVU5ERVJTQ0FOX09OLCAib24iIH08L3RkPgorPHRkIHZhbGlnbj0i dG9wIiA+Q29ubmVjdG9yPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPlRCRDwvdGQ+Cis8L3RyPgor IAorPHRyPgorPHRkIHZhbGlnbj0idG9wIiA+4oCcZGl0aGVyaW5nIGRlcHRo4oCdPC90ZD4KKzx0 ZCB2YWxpZ249InRvcCIgPkVOVU08L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+Q3VzdG9tIHZhbHVl cyB3aGljaCBoYXMgZ2VuIGluZm8gYXMgd2VsbC4KK3sgNywgRElUSEVSSU5HX01PREVfQVVUTywg ImF1dG8iIH0sCit7IDcsIERJVEhFUklOR19NT0RFX09GRiwgIm9mZiIgfSwKK3sgMSwgRElUSEVS SU5HX01PREVfT04sICJvbiIgfSwKK3sgNiwgRElUSEVSSU5HX01PREVfU1RBVElDMlgyLCAic3Rh dGljIDJ4MiIgfSwKK3sgNiwgRElUSEVSSU5HX01PREVfRFlOQU1JQzJYMiwgImR5bmFtaWMgMngy IiB9LAoreyA0LCBESVRIRVJJTkdfTU9ERV9URU1QT1JBTCwgInRlbXBvcmFsIiB9PC90ZD4KKzx0 ZCB2YWxpZ249InRvcCIgPkNvbm5lY3RvcjwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5UQkQ8L3Rk PgorPC90cj4KKyAKKzx0cj4KKzx0ZCB2YWxpZ249InRvcCIgPuKAnHVuZGVyc2NhbuKAnTwvdGQ+ Cis8dGQgdmFsaWduPSJ0b3AiID5FTlVNPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPkN1c3RvbSB2 YWx1ZXMgd2hpY2ggaGFzIGdlbiBpbmZvIGFzIHdlbGwuCit7IDYsIERJVEhFUklOR19ERVBUSF9B VVRPLCAiYXV0byIgfSwKK3sgNiwgRElUSEVSSU5HX0RFUFRIXzZCUEMsICI2IGJwYyIgfSwKK3sg NiwgRElUSEVSSU5HX0RFUFRIXzhCUEMsICI4IGJwYyIgfTwvdGQ+Cis8dGQgdmFsaWduPSJ0b3Ai ID5Db25uZWN0b3I8L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+VEJEPC90ZD4KKzwvdHI+CisgCis8 dHI+Cis8dGQgdmFsaWduPSJ0b3AiID7igJx1bmRlcnNjYW4gaGJvcmRlcuKAnTwvdGQ+Cis8dGQg dmFsaWduPSJ0b3AiID5SQU5HRTwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5NaW49MCwgTWF4PTEy ODwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5Db25uZWN0b3I8L3RkPgorPHRkIHZhbGlnbj0idG9w IiA+VEJEPC90ZD4KKzwvdHI+CisgCis8dHI+Cis8dGQgdmFsaWduPSJ0b3AiID7igJx1bmRlcnNj YW4gdmJvcmRlcuKAnTwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5SQU5HRTwvdGQ+Cis8dGQgdmFs aWduPSJ0b3AiID5NaW49MCwgTWF4PTEyODwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5Db25uZWN0 b3I8L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+VEJEPC90ZD4KKzwvdHI+CisgCis8dHI+Cis8dGQg dmFsaWduPSJ0b3AiID7igJx2aWJyYW50IGh1ZeKAnTwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5S QU5HRTwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5NaW49MCwgTWF4PTE4MDwvdGQ+Cis8dGQgdmFs aWduPSJ0b3AiID5Db25uZWN0b3I8L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+VEJEPC90ZD4KKzwv dHI+CisgCis8dHI+Cis8dGQgdmFsaWduPSJ0b3AiID7igJxjb2xvciB2aWJyYW5jZeKAnTwvdGQ+ Cis8dGQgdmFsaWduPSJ0b3AiID5SQU5HRTwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5NaW49MCwg TWF4PTIwMDwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5Db25uZWN0b3I8L3RkPgorPHRkIHZhbGln bj0idG9wIiA+VEJEPC90ZD4KKzwvdHI+CisgCis8dHI+Cis8dGQgdmFsaWduPSJ0b3AiID5HZW5l cmljPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPlN0YW5kYXJkIG5hbWUgYXMgaW4gRFJNPC90ZD4K Kzx0ZCB2YWxpZ249InRvcCIgPlN0YW5kYXJkIHR5cGUgYXMgaW4gRFJNPC90ZD4KKzx0ZCB2YWxp Z249InRvcCIgPlN0YW5kYXJkIHZhbHVlIGFzIGluIERSTTwvdGQ+Cis8dGQgdmFsaWduPSJ0b3Ai ID5TdGFuZGFyZCBPYmplY3QgYXMgaW4gRFJNPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPlRCRDwv dGQ+Cis8L3RyPgorIAorPHRyPgorPHRkIHJvd3NwYW49IjIiIHZhbGlnbj0idG9wIiA+b21hcDwv dGQ+Cis8dGQgcm93c3Bhbj0iMiIgdmFsaWduPSJ0b3AiID5HZW5lcmljPC90ZD4KKzx0ZCB2YWxp Z249InRvcCIgPuKAnHJvdGF0aW9u4oCdPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPkJJVE1BU0s8 L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+eyAwLCAicm90YXRlLTAiIH0sCit7IDEsICJyb3RhdGUt OTAiIH0sCit7IDIsICJyb3RhdGUtMTgwIiB9LAoreyAzLCAicm90YXRlLTI3MCIgfSwKK3sgNCwg InJlZmxlY3QteCIgfSwKK3sgNSwgInJlZmxlY3QteSIgfTwvdGQ+Cis8dGQgdmFsaWduPSJ0b3Ai ID5DUlRDLCBQbGFuZTwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5UQkQ8L3RkPgorPC90cj4KKyAK Kzx0cj4KKzx0ZCB2YWxpZ249InRvcCIgPuKAnHpvcmRlcuKAnTwvdGQ+Cis8dGQgdmFsaWduPSJ0 b3AiID5SQU5HRTwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5NaW49MCwgTWF4PTM8L3RkPgorPHRk IHZhbGlnbj0idG9wIiA+Q1JUQywgUGxhbmU8L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+VEJEPC90 ZD4KKzwvdHI+CisgCis8dHI+Cis8dGQgdmFsaWduPSJ0b3AiID5xeGw8L3RkPgorPHRkIHZhbGln bj0idG9wIiA+R2VuZXJpYzwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID7igJxob3RwbHVnX21vZGVf dXBkYXRlIjwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5SQU5HRTwvdGQ+Cis8dGQgdmFsaWduPSJ0 b3AiID5NaW49MCwgTWF4PTE8L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+Q29ubmVjdG9yPC90ZD4K Kzx0ZCB2YWxpZ249InRvcCIgPlRCRDwvdGQ+Cis8L3RyPgorIAorPHRyPgorPHRkIHJvd3NwYW49 IjEwIiB2YWxpZ249InRvcCIgPnJhZGVvbjwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5EVkktSTwv dGQ+Cis8dGQgdmFsaWduPSJ0b3AiID7igJxjb2hlcmVudOKAnTwvdGQ+Cis8dGQgdmFsaWduPSJ0 b3AiID5SQU5HRTwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5NaW49MCwgTWF4PTE8L3RkPgorPHRk IHZhbGlnbj0idG9wIiA+Q29ubmVjdG9yPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPlRCRDwvdGQ+ Cis8L3RyPgorIAorPHRyPgorPHRkIHZhbGlnbj0idG9wIiA+REFDIGVuYWJsZSBsb2FkIGRldGVj dDwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID7igJxsb2FkIGRldGVjdGlvbuKAnTwvdGQ+Cis8dGQg dmFsaWduPSJ0b3AiID5SQU5HRTwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5NaW49MCwgTWF4PTE8 L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+Q29ubmVjdG9yPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIg PlRCRDwvdGQ+Cis8L3RyPgorIAorPHRyPgorPHRkIHZhbGlnbj0idG9wIiA+VFYgU3RhbmRhcmQ8 L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+InR2IHN0YW5kYXJkIjwvdGQ+Cis8dGQgdmFsaWduPSJ0 b3AiID5FTlVNPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPnsgVFZfU1REX05UU0MsICJudHNjIiB9 LAoreyBUVl9TVERfUEFMLCAicGFsIiB9LAoreyBUVl9TVERfUEFMX00sICJwYWwtbSIgfSwKK3sg VFZfU1REX1BBTF82MCwgInBhbC02MCIgfSwKK3sgVFZfU1REX05UU0NfSiwgIm50c2MtaiIgfSwK K3sgVFZfU1REX1NDQVJUX1BBTCwgInNjYXJ0LXBhbCIgfSwKK3sgVFZfU1REX1BBTF9DTiwgInBh bC1jbiIgfSwKK3sgVFZfU1REX1NFQ0FNLCAic2VjYW0iIH08L3RkPgorPHRkIHZhbGlnbj0idG9w IiA+Q29ubmVjdG9yPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPlRCRDwvdGQ+Cis8L3RyPgorIAor PHRyPgorPHRkIHZhbGlnbj0idG9wIiA+bGVnYWN5IFRNRFMgUExMIGRldGVjdDwvdGQ+Cis8dGQg dmFsaWduPSJ0b3AiID4idG1kc19wbGwiPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPkVOVU08L3Rk PgorPHRkIHZhbGlnbj0idG9wIiA+eyAwLCAiZHJpdmVyIiB9LAoreyAxLCAiYmlvcyIgfTwvdGQ+ Cis8dGQgdmFsaWduPSJ0b3AiID4tPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPlRCRDwvdGQ+Cis8 L3RyPgorIAorPHRyPgorPHRkIHJvd3NwYW49IjMiIHZhbGlnbj0idG9wIiA+VW5kZXJzY2FuPC90 ZD4KKzx0ZCB2YWxpZ249InRvcCIgPiJ1bmRlcnNjYW4iPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIg PkVOVU08L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+eyBVTkRFUlNDQU5fT0ZGLCAib2ZmIiB9LAor eyBVTkRFUlNDQU5fT04sICJvbiIgfSwKK3sgVU5ERVJTQ0FOX0FVVE8sICJhdXRvIiB9PC90ZD4K Kzx0ZCB2YWxpZ249InRvcCIgPkNvbm5lY3RvcjwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5UQkQ8 L3RkPgorPC90cj4KKyAKKzx0cj4KKzx0ZCB2YWxpZ249InRvcCIgPiJ1bmRlcnNjYW4gaGJvcmRl ciI8L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+UkFOR0U8L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+ TWluPTAsIE1heD0xMjg8L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+Q29ubmVjdG9yPC90ZD4KKzx0 ZCB2YWxpZ249InRvcCIgPlRCRDwvdGQ+Cis8L3RyPgorIAorPHRyPgorPHRkIHZhbGlnbj0idG9w IiA+InVuZGVyc2NhbiB2Ym9yZGVyIjwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5SQU5HRTwvdGQ+ Cis8dGQgdmFsaWduPSJ0b3AiID5NaW49MCwgTWF4PTEyODwvdGQ+Cis8dGQgdmFsaWduPSJ0b3Ai ID5Db25uZWN0b3I8L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+VEJEPC90ZD4KKzwvdHI+CisgCis8 dHI+Cis8dGQgdmFsaWduPSJ0b3AiID5BdWRpbzwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID7igJxh dWRpb+KAnTwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5FTlVNPC90ZD4KKzx0ZCB2YWxpZ249InRv cCIgPnsgUkFERU9OX0FVRElPX0RJU0FCTEUsICJvZmYiIH0sCit7IFJBREVPTl9BVURJT19FTkFC TEUsICJvbiIgfSwKK3sgUkFERU9OX0FVRElPX0FVVE8sICJhdXRvIiB9PC90ZD4KKzx0ZCB2YWxp Z249InRvcCIgPkNvbm5lY3RvcjwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5UQkQ8L3RkPgorPC90 cj4KKyAKKzx0cj4KKzx0ZCB2YWxpZ249InRvcCIgPkZNVCBEaXRoZXJpbmc8L3RkPgorPHRkIHZh bGlnbj0idG9wIiA+4oCcZGl0aGVy4oCdPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPkVOVU08L3Rk PgorPHRkIHZhbGlnbj0idG9wIiA+eyBSQURFT05fRk1UX0RJVEhFUl9ESVNBQkxFLCAib2ZmIiB9 LAoreyBSQURFT05fRk1UX0RJVEhFUl9FTkFCTEUsICJvbiIgfTwvdGQ+Cis8dGQgdmFsaWduPSJ0 b3AiID5Db25uZWN0b3I8L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+VEJEPC90ZD4KKzwvdHI+Cisg Cis8dHI+Cis8dGQgdmFsaWduPSJ0b3AiID5HZW5lcmljPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIg PlN0YW5kYXJkIG5hbWUgYXMgaW4gRFJNPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPlN0YW5kYXJk IHR5cGUgYXMgaW4gRFJNPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPlN0YW5kYXJkIHZhbHVlIGFz IGluIERSTTwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5TdGFuZGFyZCBPYmplY3QgYXMgaW4gRFJN PC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPlRCRDwvdGQ+Cis8L3RyPgorIAorPHRyPgorPHRkIHJv d3NwYW49IjMiIHZhbGlnbj0idG9wIiA+cmNhci1kdTwvdGQ+Cis8dGQgcm93c3Bhbj0iMyIgdmFs aWduPSJ0b3AiID5HZW5lcmljPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPiJhbHBoYSI8L3RkPgor PHRkIHZhbGlnbj0idG9wIiA+UkFOR0U8L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+TWluPTAsIE1h eD0yNTU8L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+UGxhbmU8L3RkPgorPHRkIHZhbGlnbj0idG9w IiA+VEJEPC90ZD4KKzwvdHI+CisgCis8dHI+Cis8dGQgdmFsaWduPSJ0b3AiID4iY29sb3JrZXki PC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPlJBTkdFPC90ZD4KKzx0ZCB2YWxpZ249InRvcCIgPk1p bj0wLCBNYXg9MHgwMWZmZmZmZjwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5QbGFuZTwvdGQ+Cis8 dGQgdmFsaWduPSJ0b3AiID5UQkQ8L3RkPgorPC90cj4KKyAKKzx0cj4KKzx0ZCB2YWxpZ249InRv cCIgPiJ6cG9zIjwvdGQ+Cis8dGQgdmFsaWduPSJ0b3AiID5SQU5HRTwvdGQ+Cis8dGQgdmFsaWdu PSJ0b3AiID5NaW49MSwgTWF4PTc8L3RkPgorPHRkIHZhbGlnbj0idG9wIiA+UGxhbmU8L3RkPgor PHRkIHZhbGlnbj0idG9wIiA+VEJEPC90ZD4KKzwvdHI+CisgCis8L3Rib2R5PgorPC90YWJsZT4K ICAgPC9zZWN0MT4KIAogICA8IS0tIEludGVybmFsczogdmVydGljYWwgYmxhbmtpbmcgLS0+Ci0t IAoxLjguNQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K SW50ZWwtZ2Z4IG1haWxpbmcgbGlzdApJbnRlbC1nZnhAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0 dHA6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9pbnRlbC1nZngK From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Subject: Re: [PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers Date: Sat, 10 May 2014 13:39:37 +0300 Message-ID: <20140510103937.GC18465@intel.com> References: <1394016990-5218-1-git-send-email-sagar.a.kamble@intel.com> <2919182.UBDg5nOr7Z@avalon> <1394622965.18918.12.camel@sagar-desktop> <3136468.2PAlK4Gq8k@avalon> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Content-Disposition: inline In-Reply-To: <3136468.2PAlK4Gq8k@avalon> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Laurent Pinchart Cc: Laurent Pinchart , linux-doc@vger.kernel.org, Daniel Vetter , intel-gfx , dri-devel@lists.freedesktop.org, "Purushothaman, Vijay A" , Rob Landley , Alex Deucher , Dave Airlie , Sagar Arun Kamble List-Id: dri-devel@lists.freedesktop.org On Wed, Mar 12, 2014 at 12:25:06PM +0100, Laurent Pinchart wrote: > Hi Sagar, > = > On Wednesday 12 March 2014 16:46:05 Sagar Arun Kamble wrote: > > On Mon, 2014-03-10 at 15:36 +0100, Laurent Pinchart wrote: > > > On Monday 10 March 2014 06:21:49 Daniel Vetter wrote: > > > > On Wed, Mar 5, 2014 at 11:56 AM, wrote: > > > > > + > > > > > + > > > > > + > > > > > + > > > > > + > > > > > + > > > > > + > > > > > + > > > > > + > > > > > + > > > > > + > > > > > + > > > > = > > > > In my opinion this is a horrible way to write property documentatio= ns > > > > - explicitly constructing html tables is error prone and really hard > > > > to read in the source. Imo docbook in general is rather horrible, > > > > which is way I write almost all my docs as kerneldoc ;-) > > > > = > > > > I think a simple asciidoc/markdown would be much simpler, with a bit > > > > of free-form structure to group properties into relevant groups. > > > > Long-term we might even need to split it up into different spec fil= es > > > > to keep a good overview. > > > = > > > Docbook is indeed hard to read and write when it comes to such tables. > > > However I like having the properties documented in the DRM core > > > documentation. Maybe we could come up with a simpler text format that > > > would be transformed into docbook when compiling the documentation ? > > = > > Does this mean we need to create comment block with "Doc: drm > > properties" style section in each driver where drm properties are > > instantiated. And then in drm.tmpl collect all these using !P escape > > sequence? > > How do create table out of these across all drivers? > = > I don't have a strong preference here. Documenting properties in source c= ode = > comments would be fine, so would an external central documentation file i= n a = > non Docbook format. For the record I'm personally fine with using Docbook= as = > in this patch :-) > = > If we decide to go for property documentation inside the source code then= I = > believe we'll have to create our own format, as creating a properties tab= le = > from kerneldoc information extracted from comments is probably not possib= le. Can comeone pick up the ball here and figure out what needs to be done? The reason why I want a central place for the documentation is to force people to collaborate outside their own sandbox when adding properties. Whether that's docbook or some text file I don't care so much at this point. The fact that it's a central place should mandate that the patches changing it will go through dri-devel and so everyone should se them, and when adding new properties it would make the patch author more likely to look around a bit before adding another slighty incompatible version of the same property. If someone has a better suggestion how to encforce this I'm all ears. Of course this idea can still fail if our esteemed maintainer merges stuff without checking for violations of this policy. Dave, any thoughts on the subject? Either way I can tell you that I'm not very enthusiastic about reviewing any property patches until some kind of decision about this is reached, be it "docbook", "text", "plan c", or "fuck it, let the world burn!". -- = Ville Syrj=E4l=E4 Intel OTC From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rob Clark Subject: Re: [PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers Date: Sat, 10 May 2014 06:56:36 -0400 Message-ID: References: <1394016990-5218-1-git-send-email-sagar.a.kamble@intel.com> <2919182.UBDg5nOr7Z@avalon> <1394622965.18918.12.camel@sagar-desktop> <3136468.2PAlK4Gq8k@avalon> <20140510103937.GC18465@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <20140510103937.GC18465@intel.com> Sender: linux-doc-owner@vger.kernel.org To: =?UTF-8?B?VmlsbGUgU3lyasOkbMOk?= Cc: Laurent Pinchart , Laurent Pinchart , linux-doc@vger.kernel.org, Daniel Vetter , intel-gfx , "dri-devel@lists.freedesktop.org" , "Purushothaman, Vijay A" , Rob Landley , Alex Deucher , Dave Airlie , Sagar Arun Kamble List-Id: dri-devel@lists.freedesktop.org On Sat, May 10, 2014 at 6:39 AM, Ville Syrj=C3=A4l=C3=A4 wrote: > On Wed, Mar 12, 2014 at 12:25:06PM +0100, Laurent Pinchart wrote: >> Hi Sagar, >> >> On Wednesday 12 March 2014 16:46:05 Sagar Arun Kamble wrote: >> > On Mon, 2014-03-10 at 15:36 +0100, Laurent Pinchart wrote: >> > > On Monday 10 March 2014 06:21:49 Daniel Vetter wrote: >> > > > On Wed, Mar 5, 2014 at 11:56 AM, w= rote: >> > > > > +
Owner Module/DriversGroupProperty ObjectProperty NameTypeProperty ValuesObject attachedDescription
>> > > > > + >> > > > > + >> > > > > + >> > > > > + >> > > > > + >> > > > > + >> > > > > + >> > > > > + >> > > > > + >> > > > > + >> > > > > + >> > > > >> > > > In my opinion this is a horrible way to write property documen= tations >> > > > - explicitly constructing html tables is error prone and reall= y hard >> > > > to read in the source. Imo docbook in general is rather horrib= le, >> > > > which is way I write almost all my docs as kerneldoc ;-) >> > > > >> > > > I think a simple asciidoc/markdown would be much simpler, with= a bit >> > > > of free-form structure to group properties into relevant group= s. >> > > > Long-term we might even need to split it up into different spe= c files >> > > > to keep a good overview. >> > > >> > > Docbook is indeed hard to read and write when it comes to such t= ables. >> > > However I like having the properties documented in the DRM core >> > > documentation. Maybe we could come up with a simpler text format= that >> > > would be transformed into docbook when compiling the documentati= on ? >> > >> > Does this mean we need to create comment block with "Doc: drm >> > properties" style section in each driver where drm properties are >> > instantiated. And then in drm.tmpl collect all these using !P esca= pe >> > sequence? >> > How do create table out of these across all drivers? >> >> I don't have a strong preference here. Documenting properties in sou= rce code >> comments would be fine, so would an external central documentation f= ile in a >> non Docbook format. For the record I'm personally fine with using Do= cbook as >> in this patch :-) >> >> If we decide to go for property documentation inside the source code= then I >> believe we'll have to create our own format, as creating a propertie= s table >> from kerneldoc information extracted from comments is probably not p= ossible. > > Can comeone pick up the ball here and figure out what needs to be don= e? > > The reason why I want a central place for the documentation is to for= ce > people to collaborate outside their own sandbox when adding propertie= s. > Whether that's docbook or some text file I don't care so much at this > point. The fact that it's a central place should mandate that the > patches changing it will go through dri-devel and so everyone should = se > them, and when adding new properties it would make the patch author m= ore > likely to look around a bit before adding another slighty incompatibl= e > version of the same property. If someone has a better suggestion how = to > encforce this I'm all ears. > > Of course this idea can still fail if our esteemed maintainer merges > stuff without checking for violations of this policy. Dave, any thoug= hts > on the subject? > > Either way I can tell you that I'm not very enthusiastic about review= ing > any property patches until some kind of decision about this is reache= d, > be it "docbook", "text", "plan c", or "fuck it, let the world burn!". any of the first three options would be vastly superior to what we do n= ow tbh, I'd suggest imposing a no-new-properties-without-docs rule even if we haven't finished bikeshedding about the docs format. That might motivate someone to hurry up and just pick one. We can change the format, figure out some way to get it into docbook, etc, later.. it's not such a huge volume of words we have to type here that we can't reformat it later. BR, -R > > -- > Ville Syrj=C3=A4l=C3=A4 > Intel OTC > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sagar Arun Kamble Subject: Re: [PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers Date: Mon, 12 May 2014 11:37:53 +0530 Message-ID: <1399874873.15218.32.camel@sagar-desktop> References: <1394016990-5218-1-git-send-email-sagar.a.kamble@intel.com> <2919182.UBDg5nOr7Z@avalon> <1394622965.18918.12.camel@sagar-desktop> <3136468.2PAlK4Gq8k@avalon> <20140510103937.GC18465@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Rob Clark Cc: Laurent Pinchart , linux-doc@vger.kernel.org, Daniel Vetter , intel-gfx , shashidhar.hiremath@intel.com, "dri-devel@lists.freedesktop.org" , "Purushothaman, Vijay A" , Laurent Pinchart , Rob Landley , Alex Deucher , Dave Airlie List-Id: dri-devel@lists.freedesktop.org SSBzdXBwb3J0IGFwcHJvYWNoIHVzaW5nIGRvY2Jvb2sgdG8gc3RhcnQgc2luY2UgdGhlcmUgYXJl IG5vdCBsb3Qgb2YKcHJvcGVydGllcy4gTGF1cmVudCBoYXMgYWNrJ2VkIHRoaXMgb25lLiBDYW4g d2UgZ28gYWhlYWQgd2l0aCB0aGlzPwpodHRwOi8vbGlzdHMuZnJlZWRlc2t0b3Aub3JnL2FyY2hp dmVzL2ludGVsLWdmeC8yMDE0LU1hcmNoLzA0MTUyNy5odG1sCgpBZGRpbmcgZGVzY3JpcHRpb24g b2YgbmV3IHByb3BlcnR5IGlzIG5vdCB2ZXJ5IGNvbXBsZXggKGFzc3VtaW5nIHRhYmxlCmZvcm1h dCBpcyB1bmRlcnN0b29kIGFuZCBiZWluZyBjb21mb3J0YWJsZSB3aXRoIEhUTUwgcm93L3RhYmxl Cm1hbmlwdWxhdGlvbikuCgpBZGRpbmcgZGVzY3JpcHRpb24gb2YgZWFjaCBwcm9wZXJ0eSBpbiB0 aGVpciBzb3VyY2UgbWlnaHQgYmUgdGltZQpjb25zdW1pbmcgdGFzay4KCnRoYW5rcywKU2FnYXIK CgpPbiBTYXQsIDIwMTQtMDUtMTAgYXQgMDY6NTYgLTA0MDAsIFJvYiBDbGFyayB3cm90ZToKPiBP biBTYXQsIE1heSAxMCwgMjAxNCBhdCA2OjM5IEFNLCBWaWxsZSBTeXJqw6Rsw6QKPiA8dmlsbGUu c3lyamFsYUBsaW51eC5pbnRlbC5jb20+IHdyb3RlOgo+ID4gT24gV2VkLCBNYXIgMTIsIDIwMTQg YXQgMTI6MjU6MDZQTSArMDEwMCwgTGF1cmVudCBQaW5jaGFydCB3cm90ZToKPiA+PiBIaSBTYWdh ciwKPiA+Pgo+ID4+IE9uIFdlZG5lc2RheSAxMiBNYXJjaCAyMDE0IDE2OjQ2OjA1IFNhZ2FyIEFy dW4gS2FtYmxlIHdyb3RlOgo+ID4+ID4gT24gTW9uLCAyMDE0LTAzLTEwIGF0IDE1OjM2ICswMTAw LCBMYXVyZW50IFBpbmNoYXJ0IHdyb3RlOgo+ID4+ID4gPiBPbiBNb25kYXkgMTAgTWFyY2ggMjAx NCAwNjoyMTo0OSBEYW5pZWwgVmV0dGVyIHdyb3RlOgo+ID4+ID4gPiA+IE9uIFdlZCwgTWFyIDUs IDIwMTQgYXQgMTE6NTYgQU0sICA8c2FnYXIuYS5rYW1ibGVAaW50ZWwuY29tPiB3cm90ZToKPiA+ PiA+ID4gPiA+ICs8dGFibGUgYm9yZGVyPSIxIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9 IjAiID4KPiA+PiA+ID4gPiA+ICs8dGJvZHk+Cj4gPj4gPiA+ID4gPiArPHRyIHN0eWxlPSJmb250 LXdlaWdodDogYm9sZDsiID4KPiA+PiA+ID4gPiA+ICs8dGQgdmFsaWduPSJ0b3AiID5Pd25lciBN b2R1bGUvRHJpdmVyczwvdGQ+Cj4gPj4gPiA+ID4gPiArPHRkIHZhbGlnbj0idG9wIiA+R3JvdXA8 L3RkPgo+ID4+ID4gPiA+ID4gKzx0ZCB2YWxpZ249InRvcCIgPlByb3BlcnR5IE9iamVjdDwvdGQ+ Cj4gPj4gPiA+ID4gPiArPHRkIHZhbGlnbj0idG9wIiA+UHJvcGVydHkgTmFtZTwvdGQ+Cj4gPj4g PiA+ID4gPiArPHRkIHZhbGlnbj0idG9wIiA+VHlwZTwvdGQ+Cj4gPj4gPiA+ID4gPiArPHRkIHZh bGlnbj0idG9wIiA+UHJvcGVydHkgVmFsdWVzPC90ZD4KPiA+PiA+ID4gPiA+ICs8dGQgdmFsaWdu PSJ0b3AiID5PYmplY3QgYXR0YWNoZWQ8L3RkPgo+ID4+ID4gPiA+ID4gKzx0ZCB2YWxpZ249InRv cCIgPkRlc2NyaXB0aW9uPC90ZD4KPiA+PiA+ID4gPiA+ICs8L3RyPgo+ID4+ID4gPiA+Cj4gPj4g PiA+ID4gSW4gbXkgb3BpbmlvbiB0aGlzIGlzIGEgaG9ycmlibGUgd2F5IHRvIHdyaXRlIHByb3Bl cnR5IGRvY3VtZW50YXRpb25zCj4gPj4gPiA+ID4gLSBleHBsaWNpdGx5IGNvbnN0cnVjdGluZyBo dG1sIHRhYmxlcyBpcyBlcnJvciBwcm9uZSBhbmQgcmVhbGx5IGhhcmQKPiA+PiA+ID4gPiB0byBy ZWFkIGluIHRoZSBzb3VyY2UuIEltbyBkb2Nib29rIGluIGdlbmVyYWwgaXMgcmF0aGVyIGhvcnJp YmxlLAo+ID4+ID4gPiA+IHdoaWNoIGlzIHdheSBJIHdyaXRlIGFsbW9zdCBhbGwgbXkgZG9jcyBh cyBrZXJuZWxkb2MgOy0pCj4gPj4gPiA+ID4KPiA+PiA+ID4gPiBJIHRoaW5rIGEgc2ltcGxlIGFz Y2lpZG9jL21hcmtkb3duIHdvdWxkIGJlIG11Y2ggc2ltcGxlciwgd2l0aCBhIGJpdAo+ID4+ID4g PiA+IG9mIGZyZWUtZm9ybSBzdHJ1Y3R1cmUgdG8gZ3JvdXAgcHJvcGVydGllcyBpbnRvIHJlbGV2 YW50IGdyb3Vwcy4KPiA+PiA+ID4gPiBMb25nLXRlcm0gd2UgbWlnaHQgZXZlbiBuZWVkIHRvIHNw bGl0IGl0IHVwIGludG8gZGlmZmVyZW50IHNwZWMgZmlsZXMKPiA+PiA+ID4gPiB0byBrZWVwIGEg Z29vZCBvdmVydmlldy4KPiA+PiA+ID4KPiA+PiA+ID4gRG9jYm9vayBpcyBpbmRlZWQgaGFyZCB0 byByZWFkIGFuZCB3cml0ZSB3aGVuIGl0IGNvbWVzIHRvIHN1Y2ggdGFibGVzLgo+ID4+ID4gPiBI b3dldmVyIEkgbGlrZSBoYXZpbmcgdGhlIHByb3BlcnRpZXMgZG9jdW1lbnRlZCBpbiB0aGUgRFJN IGNvcmUKPiA+PiA+ID4gZG9jdW1lbnRhdGlvbi4gTWF5YmUgd2UgY291bGQgY29tZSB1cCB3aXRo IGEgc2ltcGxlciB0ZXh0IGZvcm1hdCB0aGF0Cj4gPj4gPiA+IHdvdWxkIGJlIHRyYW5zZm9ybWVk IGludG8gZG9jYm9vayB3aGVuIGNvbXBpbGluZyB0aGUgZG9jdW1lbnRhdGlvbiA/Cj4gPj4gPgo+ ID4+ID4gRG9lcyB0aGlzIG1lYW4gd2UgbmVlZCB0byBjcmVhdGUgY29tbWVudCBibG9jayB3aXRo ICJEb2M6IGRybQo+ID4+ID4gcHJvcGVydGllcyIgc3R5bGUgc2VjdGlvbiBpbiBlYWNoIGRyaXZl ciB3aGVyZSBkcm0gcHJvcGVydGllcyBhcmUKPiA+PiA+IGluc3RhbnRpYXRlZC4gQW5kIHRoZW4g aW4gZHJtLnRtcGwgY29sbGVjdCBhbGwgdGhlc2UgdXNpbmcgIVAgZXNjYXBlCj4gPj4gPiBzZXF1 ZW5jZT8KPiA+PiA+IEhvdyBkbyBjcmVhdGUgdGFibGUgb3V0IG9mIHRoZXNlIGFjcm9zcyBhbGwg ZHJpdmVycz8KPiA+Pgo+ID4+IEkgZG9uJ3QgaGF2ZSBhIHN0cm9uZyBwcmVmZXJlbmNlIGhlcmUu IERvY3VtZW50aW5nIHByb3BlcnRpZXMgaW4gc291cmNlIGNvZGUKPiA+PiBjb21tZW50cyB3b3Vs ZCBiZSBmaW5lLCBzbyB3b3VsZCBhbiBleHRlcm5hbCBjZW50cmFsIGRvY3VtZW50YXRpb24gZmls ZSBpbiBhCj4gPj4gbm9uIERvY2Jvb2sgZm9ybWF0LiBGb3IgdGhlIHJlY29yZCBJJ20gcGVyc29u YWxseSBmaW5lIHdpdGggdXNpbmcgRG9jYm9vayBhcwo+ID4+IGluIHRoaXMgcGF0Y2ggOi0pCj4g Pj4KPiA+PiBJZiB3ZSBkZWNpZGUgdG8gZ28gZm9yIHByb3BlcnR5IGRvY3VtZW50YXRpb24gaW5z aWRlIHRoZSBzb3VyY2UgY29kZSB0aGVuIEkKPiA+PiBiZWxpZXZlIHdlJ2xsIGhhdmUgdG8gY3Jl YXRlIG91ciBvd24gZm9ybWF0LCBhcyBjcmVhdGluZyBhIHByb3BlcnRpZXMgdGFibGUKPiA+PiBm cm9tIGtlcm5lbGRvYyBpbmZvcm1hdGlvbiBleHRyYWN0ZWQgZnJvbSBjb21tZW50cyBpcyBwcm9i YWJseSBub3QgcG9zc2libGUuCj4gPgo+ID4gQ2FuIGNvbWVvbmUgcGljayB1cCB0aGUgYmFsbCBo ZXJlIGFuZCBmaWd1cmUgb3V0IHdoYXQgbmVlZHMgdG8gYmUgZG9uZT8KPiA+Cj4gPiBUaGUgcmVh c29uIHdoeSBJIHdhbnQgYSBjZW50cmFsIHBsYWNlIGZvciB0aGUgZG9jdW1lbnRhdGlvbiBpcyB0 byBmb3JjZQo+ID4gcGVvcGxlIHRvIGNvbGxhYm9yYXRlIG91dHNpZGUgdGhlaXIgb3duIHNhbmRi b3ggd2hlbiBhZGRpbmcgcHJvcGVydGllcy4KPiA+IFdoZXRoZXIgdGhhdCdzIGRvY2Jvb2sgb3Ig c29tZSB0ZXh0IGZpbGUgSSBkb24ndCBjYXJlIHNvIG11Y2ggYXQgdGhpcwo+ID4gcG9pbnQuIFRo ZSBmYWN0IHRoYXQgaXQncyBhIGNlbnRyYWwgcGxhY2Ugc2hvdWxkIG1hbmRhdGUgdGhhdCB0aGUK PiA+IHBhdGNoZXMgY2hhbmdpbmcgaXQgd2lsbCBnbyB0aHJvdWdoIGRyaS1kZXZlbCBhbmQgc28g ZXZlcnlvbmUgc2hvdWxkIHNlCj4gPiB0aGVtLCBhbmQgd2hlbiBhZGRpbmcgbmV3IHByb3BlcnRp ZXMgaXQgd291bGQgbWFrZSB0aGUgcGF0Y2ggYXV0aG9yIG1vcmUKPiA+IGxpa2VseSB0byBsb29r IGFyb3VuZCBhIGJpdCBiZWZvcmUgYWRkaW5nIGFub3RoZXIgc2xpZ2h0eSBpbmNvbXBhdGlibGUK PiA+IHZlcnNpb24gb2YgdGhlIHNhbWUgcHJvcGVydHkuIElmIHNvbWVvbmUgaGFzIGEgYmV0dGVy IHN1Z2dlc3Rpb24gaG93IHRvCj4gPiBlbmNmb3JjZSB0aGlzIEknbSBhbGwgZWFycy4KPiA+Cj4g PiBPZiBjb3Vyc2UgdGhpcyBpZGVhIGNhbiBzdGlsbCBmYWlsIGlmIG91ciBlc3RlZW1lZCBtYWlu dGFpbmVyIG1lcmdlcwo+ID4gc3R1ZmYgd2l0aG91dCBjaGVja2luZyBmb3IgdmlvbGF0aW9ucyBv ZiB0aGlzIHBvbGljeS4gRGF2ZSwgYW55IHRob3VnaHRzCj4gPiBvbiB0aGUgc3ViamVjdD8KPiA+ Cj4gPiBFaXRoZXIgd2F5IEkgY2FuIHRlbGwgeW91IHRoYXQgSSdtIG5vdCB2ZXJ5IGVudGh1c2lh c3RpYyBhYm91dCByZXZpZXdpbmcKPiA+IGFueSBwcm9wZXJ0eSBwYXRjaGVzIHVudGlsIHNvbWUg a2luZCBvZiBkZWNpc2lvbiBhYm91dCB0aGlzIGlzIHJlYWNoZWQsCj4gPiBiZSBpdCAiZG9jYm9v ayIsICJ0ZXh0IiwgInBsYW4gYyIsIG9yICJmdWNrIGl0LCBsZXQgdGhlIHdvcmxkIGJ1cm4hIi4K PiAKPiBhbnkgb2YgdGhlIGZpcnN0IHRocmVlIG9wdGlvbnMgd291bGQgYmUgdmFzdGx5IHN1cGVy aW9yIHRvIHdoYXQgd2UgZG8gbm93Cj4gCj4gdGJoLCBJJ2Qgc3VnZ2VzdCBpbXBvc2luZyBhIG5v LW5ldy1wcm9wZXJ0aWVzLXdpdGhvdXQtZG9jcyBydWxlIGV2ZW4KPiBpZiB3ZSBoYXZlbid0IGZp bmlzaGVkIGJpa2VzaGVkZGluZyBhYm91dCB0aGUgZG9jcyBmb3JtYXQuICBUaGF0IG1pZ2h0Cj4g bW90aXZhdGUgc29tZW9uZSB0byBodXJyeSB1cCBhbmQganVzdCBwaWNrIG9uZS4KPiAKPiBXZSBj YW4gY2hhbmdlIHRoZSBmb3JtYXQsIGZpZ3VyZSBvdXQgc29tZSB3YXkgdG8gZ2V0IGl0IGludG8g ZG9jYm9vaywKPiBldGMsIGxhdGVyLi4gaXQncyBub3Qgc3VjaCBhIGh1Z2Ugdm9sdW1lIG9mIHdv cmRzIHdlIGhhdmUgdG8gdHlwZSBoZXJlCj4gdGhhdCB3ZSBjYW4ndCByZWZvcm1hdCBpdCBsYXRl ci4KPiAKPiBCUiwKPiAtUgo+IAo+IAo+ID4KPiA+IC0tCj4gPiBWaWxsZSBTeXJqw6Rsw6QKPiA+ IEludGVsIE9UQwo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18KPiA+IGRyaS1kZXZlbCBtYWlsaW5nIGxpc3QKPiA+IGRyaS1kZXZlbEBsaXN0cy5mcmVl ZGVza3RvcC5vcmcKPiA+IGh0dHA6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0 aW5mby9kcmktZGV2ZWwKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXwpkcmktZGV2ZWwgbWFpbGluZyBsaXN0CmRyaS1kZXZlbEBsaXN0cy5mcmVlZGVza3Rv cC5vcmcKaHR0cDovL2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RyaS1k ZXZlbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers Date: Mon, 12 May 2014 10:03:55 +0200 Message-ID: <20140512080355.GB25056@phenom.ffwll.local> References: <1394016990-5218-1-git-send-email-sagar.a.kamble@intel.com> <2919182.UBDg5nOr7Z@avalon> <1394622965.18918.12.camel@sagar-desktop> <3136468.2PAlK4Gq8k@avalon> <20140510103937.GC18465@intel.com> <1399874873.15218.32.camel@sagar-desktop> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mail-ee0-f43.google.com (mail-ee0-f43.google.com [74.125.83.43]) by gabe.freedesktop.org (Postfix) with ESMTP id 215116E458 for ; Mon, 12 May 2014 01:04:00 -0700 (PDT) Received: by mail-ee0-f43.google.com with SMTP id d17so4326498eek.16 for ; Mon, 12 May 2014 01:04:00 -0700 (PDT) Content-Disposition: inline In-Reply-To: <1399874873.15218.32.camel@sagar-desktop> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Sagar Arun Kamble Cc: Laurent Pinchart , linux-doc@vger.kernel.org, Daniel Vetter , intel-gfx , shashidhar.hiremath@intel.com, "dri-devel@lists.freedesktop.org" , "Purushothaman, Vijay A" , Laurent Pinchart , Rob Landley , Alex Deucher , Dave Airlie List-Id: dri-devel@lists.freedesktop.org On Mon, May 12, 2014 at 11:37:53AM +0530, Sagar Arun Kamble wrote: > I support approach using docbook to start since there are not lot of > properties. Laurent has ack'ed this one. Can we go ahead with this? > http://lists.freedesktop.org/archives/intel-gfx/2014-March/041527.html > = > Adding description of new property is not very complex (assuming table > format is understood and being comfortable with HTML row/table > manipulation). > = > Adding description of each property in their source might be time > consuming task. Yeah I'm ok with docbook for the time being. My long-term plan is to fix up kerneldoc to support markdown and then we can move such neat tables into the code. There's lots other places that would benefit from proper list formatting and tables. So Ack from my side on both the docbook patch and the no-more-props-without-doc-patch rule (which is kinda what I've been doing thus far). -Daniel > = > thanks, > Sagar > = > = > On Sat, 2014-05-10 at 06:56 -0400, Rob Clark wrote: > > On Sat, May 10, 2014 at 6:39 AM, Ville Syrj=E4l=E4 > > wrote: > > > On Wed, Mar 12, 2014 at 12:25:06PM +0100, Laurent Pinchart wrote: > > >> Hi Sagar, > > >> > > >> On Wednesday 12 March 2014 16:46:05 Sagar Arun Kamble wrote: > > >> > On Mon, 2014-03-10 at 15:36 +0100, Laurent Pinchart wrote: > > >> > > On Monday 10 March 2014 06:21:49 Daniel Vetter wrote: > > >> > > > On Wed, Mar 5, 2014 at 11:56 AM, w= rote: > > >> > > > > +
Owner Module/DriversGroupProperty ObjectProperty NameTypeProperty ValuesObject attachedDescription
> > >> > > > > + > > >> > > > > + > > >> > > > > + > > >> > > > > + > > >> > > > > + > > >> > > > > + > > >> > > > > + > > >> > > > > + > > >> > > > > + > > >> > > > > + > > >> > > > > + > > >> > > > > > >> > > > In my opinion this is a horrible way to write property documen= tations > > >> > > > - explicitly constructing html tables is error prone and reall= y hard > > >> > > > to read in the source. Imo docbook in general is rather horrib= le, > > >> > > > which is way I write almost all my docs as kerneldoc ;-) > > >> > > > > > >> > > > I think a simple asciidoc/markdown would be much simpler, with= a bit > > >> > > > of free-form structure to group properties into relevant group= s. > > >> > > > Long-term we might even need to split it up into different spe= c files > > >> > > > to keep a good overview. > > >> > > > > >> > > Docbook is indeed hard to read and write when it comes to such t= ables. > > >> > > However I like having the properties documented in the DRM core > > >> > > documentation. Maybe we could come up with a simpler text format= that > > >> > > would be transformed into docbook when compiling the documentati= on ? > > >> > > > >> > Does this mean we need to create comment block with "Doc: drm > > >> > properties" style section in each driver where drm properties are > > >> > instantiated. And then in drm.tmpl collect all these using !P esca= pe > > >> > sequence? > > >> > How do create table out of these across all drivers? > > >> > > >> I don't have a strong preference here. Documenting properties in sou= rce code > > >> comments would be fine, so would an external central documentation f= ile in a > > >> non Docbook format. For the record I'm personally fine with using Do= cbook as > > >> in this patch :-) > > >> > > >> If we decide to go for property documentation inside the source code= then I > > >> believe we'll have to create our own format, as creating a propertie= s table > > >> from kerneldoc information extracted from comments is probably not p= ossible. > > > > > > Can comeone pick up the ball here and figure out what needs to be don= e? > > > > > > The reason why I want a central place for the documentation is to for= ce > > > people to collaborate outside their own sandbox when adding propertie= s. > > > Whether that's docbook or some text file I don't care so much at this > > > point. The fact that it's a central place should mandate that the > > > patches changing it will go through dri-devel and so everyone should = se > > > them, and when adding new properties it would make the patch author m= ore > > > likely to look around a bit before adding another slighty incompatible > > > version of the same property. If someone has a better suggestion how = to > > > encforce this I'm all ears. > > > > > > Of course this idea can still fail if our esteemed maintainer merges > > > stuff without checking for violations of this policy. Dave, any thoug= hts > > > on the subject? > > > > > > Either way I can tell you that I'm not very enthusiastic about review= ing > > > any property patches until some kind of decision about this is reache= d, > > > be it "docbook", "text", "plan c", or "fuck it, let the world burn!". > > = > > any of the first three options would be vastly superior to what we do n= ow > > = > > tbh, I'd suggest imposing a no-new-properties-without-docs rule even > > if we haven't finished bikeshedding about the docs format. That might > > motivate someone to hurry up and just pick one. > > = > > We can change the format, figure out some way to get it into docbook, > > etc, later.. it's not such a huge volume of words we have to type here > > that we can't reformat it later. > > = > > BR, > > -R > > = > > = > > > > > > -- > > > Ville Syrj=E4l=E4 > > > Intel OTC > > > _______________________________________________ > > > dri-devel mailing list > > > dri-devel@lists.freedesktop.org > > > http://lists.freedesktop.org/mailman/listinfo/dri-devel > = > = -- = Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Airlie Subject: Re: [PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers Date: Mon, 12 May 2014 18:24:57 +1000 Message-ID: References: <1394016990-5218-1-git-send-email-sagar.a.kamble@intel.com> <2919182.UBDg5nOr7Z@avalon> <1394622965.18918.12.camel@sagar-desktop> <3136468.2PAlK4Gq8k@avalon> <20140510103937.GC18465@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20140510103937.GC18465@intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: =?UTF-8?B?VmlsbGUgU3lyasOkbMOk?= Cc: Laurent Pinchart , linux-doc@vger.kernel.org, Daniel Vetter , intel-gfx , dri-devel , Laurent Pinchart , Rob Landley , Alex Deucher , Dave Airlie , Sagar Arun Kamble List-Id: dri-devel@lists.freedesktop.org >> >> If we decide to go for property documentation inside the source code then I >> believe we'll have to create our own format, as creating a properties table >> from kerneldoc information extracted from comments is probably not possible. > > Can comeone pick up the ball here and figure out what needs to be done? > > The reason why I want a central place for the documentation is to force > people to collaborate outside their own sandbox when adding properties. > Whether that's docbook or some text file I don't care so much at this > point. The fact that it's a central place should mandate that the > patches changing it will go through dri-devel and so everyone should se > them, and when adding new properties it would make the patch author more > likely to look around a bit before adding another slighty incompatible > version of the same property. If someone has a better suggestion how to > encforce this I'm all ears. > > Of course this idea can still fail if our esteemed maintainer merges > stuff without checking for violations of this policy. Dave, any thoughts > on the subject? Yeah I'm happy to block merging stuff, if we can spot new properties when stuff is posted on dri-devel, so much the better, most drivers still send everything via dri-devel anyways, its only really Intel I have to worry about so far, But we should definitely add it to the new driver review checklist as well. I'm also on the side of this patch is ugly and makes my eyes burn, please please get a plan to use something else ASAP, I'm willing to merge this but I'm tempted to give it a lifetime of a kernel or two before I burn it. Dave. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers Date: Mon, 12 May 2014 10:58:27 +0200 Message-ID: <20140512085827.GD25056@phenom.ffwll.local> References: <1394016990-5218-1-git-send-email-sagar.a.kamble@intel.com> <2919182.UBDg5nOr7Z@avalon> <1394622965.18918.12.camel@sagar-desktop> <3136468.2PAlK4Gq8k@avalon> <20140510103937.GC18465@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-doc-owner@vger.kernel.org To: Dave Airlie Cc: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= , Laurent Pinchart , Laurent Pinchart , linux-doc@vger.kernel.org, Daniel Vetter , intel-gfx , dri-devel , "Purushothaman, Vijay A" , Rob Landley , Alex Deucher , Dave Airlie , Sagar Arun Kamble List-Id: dri-devel@lists.freedesktop.org On Mon, May 12, 2014 at 06:24:57PM +1000, Dave Airlie wrote: > >> > >> If we decide to go for property documentation inside the source code then I > >> believe we'll have to create our own format, as creating a properties table > >> from kerneldoc information extracted from comments is probably not possible. > > > > Can comeone pick up the ball here and figure out what needs to be done? > > > > The reason why I want a central place for the documentation is to force > > people to collaborate outside their own sandbox when adding properties. > > Whether that's docbook or some text file I don't care so much at this > > point. The fact that it's a central place should mandate that the > > patches changing it will go through dri-devel and so everyone should se > > them, and when adding new properties it would make the patch author more > > likely to look around a bit before adding another slighty incompatible > > version of the same property. If someone has a better suggestion how to > > encforce this I'm all ears. > > > > Of course this idea can still fail if our esteemed maintainer merges > > stuff without checking for violations of this policy. Dave, any thoughts > > on the subject? > > Yeah I'm happy to block merging stuff, if we can spot new properties > when stuff is posted on dri-devel, so much the better, > > most drivers still send everything via dri-devel anyways, its only > really Intel I have to worry about so far, I'll enforce that all prop stuff gets cc: dri-devel and that it has updates for the prop docs. > But we should definitely add it to the new driver review checklist as well. > > I'm also on the side of this patch is ugly and makes my eyes burn, > please please get a plan to use something else ASAP, I'm willing to > merge this but I'm tempted to give it a lifetime of a kernel or two > before I burn it. Ok, I'll try to move "make kerneldoc suck less" up the task list and maybe find someone to do it for me internally ;-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch From mboxrd@z Thu Jan 1 00:00:00 1970 From: Randy Dunlap Subject: Re: [PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers Date: Mon, 12 May 2014 08:23:45 -0700 Message-ID: <5370E781.1080308@infradead.org> References: <1394016990-5218-1-git-send-email-sagar.a.kamble@intel.com> <2919182.UBDg5nOr7Z@avalon> <1394622965.18918.12.camel@sagar-desktop> <3136468.2PAlK4Gq8k@avalon> <20140510103937.GC18465@intel.com> <20140512085827.GD25056@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20140512085827.GD25056@phenom.ffwll.local> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Daniel Vetter , Dave Airlie Cc: Laurent Pinchart , linux-doc@vger.kernel.org, Daniel Vetter , intel-gfx , dri-devel , Laurent Pinchart , Rob Landley , Alex Deucher , Dave Airlie , Sagar Arun Kamble List-Id: dri-devel@lists.freedesktop.org On 05/12/2014 01:58 AM, Daniel Vetter wrote: > On Mon, May 12, 2014 at 06:24:57PM +1000, Dave Airlie wrote: >>>> >>>> If we decide to go for property documentation inside the source code then I >>>> believe we'll have to create our own format, as creating a properties table >>>> from kerneldoc information extracted from comments is probably not possible. >>> >>> Can comeone pick up the ball here and figure out what needs to be done? >>> >>> The reason why I want a central place for the documentation is to force >>> people to collaborate outside their own sandbox when adding properties. >>> Whether that's docbook or some text file I don't care so much at this >>> point. The fact that it's a central place should mandate that the >>> patches changing it will go through dri-devel and so everyone should se >>> them, and when adding new properties it would make the patch author more >>> likely to look around a bit before adding another slighty incompatible >>> version of the same property. If someone has a better suggestion how to >>> encforce this I'm all ears. >>> >>> Of course this idea can still fail if our esteemed maintainer merges >>> stuff without checking for violations of this policy. Dave, any thoughts >>> on the subject? >> >> Yeah I'm happy to block merging stuff, if we can spot new properties >> when stuff is posted on dri-devel, so much the better, >> >> most drivers still send everything via dri-devel anyways, its only >> really Intel I have to worry about so far, > > I'll enforce that all prop stuff gets cc: dri-devel and that it has > updates for the prop docs. > >> But we should definitely add it to the new driver review checklist as well. >> >> I'm also on the side of this patch is ugly and makes my eyes burn, >> please please get a plan to use something else ASAP, I'm willing to >> merge this but I'm tempted to give it a lifetime of a kernel or two >> before I burn it. > > Ok, I'll try to move "make kerneldoc suck less" up the task list and maybe > find someone to do it for me internally ;-) > -Daniel > I certainly have no objections to making kerneldoc suck less. There was already an attempt to use asciidoc (like git uses) for kernel-doc (a few years ago, by Sam Ravnborg). I support(ed) that effort. OTOH, I would only want to add another way to do kernel-doc if it can be a full replacement for all of our docbook usage, i.e., it should provide a way that we can eliminate docbook and stop using it completely. thanks, -- ~Randy From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers Date: Mon, 12 May 2014 17:54:03 +0200 Message-ID: <20140512155403.GF25056@phenom.ffwll.local> References: <1394016990-5218-1-git-send-email-sagar.a.kamble@intel.com> <2919182.UBDg5nOr7Z@avalon> <1394622965.18918.12.camel@sagar-desktop> <3136468.2PAlK4Gq8k@avalon> <20140510103937.GC18465@intel.com> <20140512085827.GD25056@phenom.ffwll.local> <5370E781.1080308@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by gabe.freedesktop.org (Postfix) with ESMTP id 264036E710 for ; Mon, 12 May 2014 08:54:09 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id c41so4759615eek.31 for ; Mon, 12 May 2014 08:54:08 -0700 (PDT) Content-Disposition: inline In-Reply-To: <5370E781.1080308@infradead.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Randy Dunlap Cc: Laurent Pinchart , Rob Landley , linux-doc@vger.kernel.org, Sagar Arun Kamble , Daniel Vetter , intel-gfx , dri-devel , "Purushothaman, Vijay A" , Laurent Pinchart , Alex Deucher , Dave Airlie List-Id: dri-devel@lists.freedesktop.org On Mon, May 12, 2014 at 08:23:45AM -0700, Randy Dunlap wrote: > On 05/12/2014 01:58 AM, Daniel Vetter wrote: > > On Mon, May 12, 2014 at 06:24:57PM +1000, Dave Airlie wrote: > >>>> > >>>> If we decide to go for property documentation inside the source code then I > >>>> believe we'll have to create our own format, as creating a properties table > >>>> from kerneldoc information extracted from comments is probably not possible. > >>> > >>> Can comeone pick up the ball here and figure out what needs to be done? > >>> > >>> The reason why I want a central place for the documentation is to force > >>> people to collaborate outside their own sandbox when adding properties. > >>> Whether that's docbook or some text file I don't care so much at this > >>> point. The fact that it's a central place should mandate that the > >>> patches changing it will go through dri-devel and so everyone should se > >>> them, and when adding new properties it would make the patch author more > >>> likely to look around a bit before adding another slighty incompatible > >>> version of the same property. If someone has a better suggestion how to > >>> encforce this I'm all ears. > >>> > >>> Of course this idea can still fail if our esteemed maintainer merges > >>> stuff without checking for violations of this policy. Dave, any thoughts > >>> on the subject? > >> > >> Yeah I'm happy to block merging stuff, if we can spot new properties > >> when stuff is posted on dri-devel, so much the better, > >> > >> most drivers still send everything via dri-devel anyways, its only > >> really Intel I have to worry about so far, > > > > I'll enforce that all prop stuff gets cc: dri-devel and that it has > > updates for the prop docs. > > > >> But we should definitely add it to the new driver review checklist as well. > >> > >> I'm also on the side of this patch is ugly and makes my eyes burn, > >> please please get a plan to use something else ASAP, I'm willing to > >> merge this but I'm tempted to give it a lifetime of a kernel or two > >> before I burn it. > > > > Ok, I'll try to move "make kerneldoc suck less" up the task list and maybe > > find someone to do it for me internally ;-) > > -Daniel > > > > I certainly have no objections to making kerneldoc suck less. > There was already an attempt to use asciidoc (like git uses) for kernel-doc > (a few years ago, by Sam Ravnborg). I support(ed) that effort. Hm, do you have pointers to those? My google-fu seems lacking ... Ok, let's move this to the top and start discussions. The past few months I've written piles of kerneldoc comments for the DRM DocBook (all pulled in as kerneldoc, docbook .tmpl has just the chapter structure). DOC: sections are really useful to pull all the actual documentation out of the docbook xml into kerneldoc. But I've also done piles of docs for intel-gpu-tools, which is using gtkdoc. And there are some clear deficiencies: - No markdown for inline coments. Lack of lists and tables is hurting especially badly. If we add this (and I don't care one iota whether it's markdown or asciidoc or something else as long as it's readable plain text in comments) we should be able to move all the existing docbook xml paragraphs/lists/tables into kerneldoc comments. - Automatic cross-referencing of functions. If you place e.g. function() or #struct anywhere in a documentation comment gtk-doc automatically inserts a hyperlink to the relevant documentation page across the entire project. Really powerful and makes overview sections much more useful entry points for beginners since they can easily jump back&forth betweeen the high-level overview and low-level per-function documentation. - In a really perfect world it would help if kerneldoc could collect structure member kerneldoc from per-member comments. Especially for large structures with lots of comments this would bring the kerneldoc and struct member much closer together. So that's my wishlist. > OTOH, I would only want to add another way to do kernel-doc if it can be a > full replacement for all of our docbook usage, i.e., it should provide a > way that we can eliminate docbook and stop using it completely. Hm, I don't mind docbook at all, as long as all the real content is embedded into source files as kerneldoc and the docbook template just pulls in all the right bits and pieces. Even gtkdoc allos you to do that and pull in the different libararies (== header files with declarations for C) in the order you want. So imo the docbook toolchain is good enough for my needs. Or what do you mean by getting rid of all docbook usage? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch From mboxrd@z Thu Jan 1 00:00:00 1970 From: Randy Dunlap Subject: Re: [PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers Date: Mon, 12 May 2014 11:04:14 -0700 Message-ID: <53710D1E.7040102@infradead.org> References: <1394016990-5218-1-git-send-email-sagar.a.kamble@intel.com> <2919182.UBDg5nOr7Z@avalon> <1394622965.18918.12.camel@sagar-desktop> <3136468.2PAlK4Gq8k@avalon> <20140510103937.GC18465@intel.com> <20140512085827.GD25056@phenom.ffwll.local> <5370E781.1080308@infradead.org> <20140512155403.GF25056@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20140512155403.GF25056@phenom.ffwll.local> Sender: linux-doc-owner@vger.kernel.org To: Daniel Vetter Cc: Dave Airlie , =?ISO-8859-1?Q?Ville_Syrj=E4l=E4?= , Laurent Pinchart , Laurent Pinchart , linux-doc@vger.kernel.org, Daniel Vetter , intel-gfx , dri-devel , "Purushothaman, Vijay A" , Rob Landley , Alex Deucher , Dave Airlie , Sagar Arun Kamble List-Id: dri-devel@lists.freedesktop.org On 05/12/2014 08:54 AM, Daniel Vetter wrote: > On Mon, May 12, 2014 at 08:23:45AM -0700, Randy Dunlap wrote: >> On 05/12/2014 01:58 AM, Daniel Vetter wrote: >>> On Mon, May 12, 2014 at 06:24:57PM +1000, Dave Airlie wrote: >>>>>> >>>>>> If we decide to go for property documentation inside the source code then I >>>>>> believe we'll have to create our own format, as creating a properties table >>>>>> from kerneldoc information extracted from comments is probably not possible. >>>>> >>>>> Can comeone pick up the ball here and figure out what needs to be done? >>>>> >>>>> The reason why I want a central place for the documentation is to force >>>>> people to collaborate outside their own sandbox when adding properties. >>>>> Whether that's docbook or some text file I don't care so much at this >>>>> point. The fact that it's a central place should mandate that the >>>>> patches changing it will go through dri-devel and so everyone should se >>>>> them, and when adding new properties it would make the patch author more >>>>> likely to look around a bit before adding another slighty incompatible >>>>> version of the same property. If someone has a better suggestion how to >>>>> encforce this I'm all ears. >>>>> >>>>> Of course this idea can still fail if our esteemed maintainer merges >>>>> stuff without checking for violations of this policy. Dave, any thoughts >>>>> on the subject? >>>> >>>> Yeah I'm happy to block merging stuff, if we can spot new properties >>>> when stuff is posted on dri-devel, so much the better, >>>> >>>> most drivers still send everything via dri-devel anyways, its only >>>> really Intel I have to worry about so far, >>> >>> I'll enforce that all prop stuff gets cc: dri-devel and that it has >>> updates for the prop docs. >>> >>>> But we should definitely add it to the new driver review checklist as well. >>>> >>>> I'm also on the side of this patch is ugly and makes my eyes burn, >>>> please please get a plan to use something else ASAP, I'm willing to >>>> merge this but I'm tempted to give it a lifetime of a kernel or two >>>> before I burn it. >>> >>> Ok, I'll try to move "make kerneldoc suck less" up the task list and maybe >>> find someone to do it for me internally ;-) >>> -Daniel >>> >> >> I certainly have no objections to making kerneldoc suck less. >> There was already an attempt to use asciidoc (like git uses) for kernel-doc >> (a few years ago, by Sam Ravnborg). I support(ed) that effort. > > Hm, do you have pointers to those? My google-fu seems lacking ... I googled for /kernel doc asciidoc ravnborg/ and found several hits for them. > Ok, let's move this to the top and start discussions. The past few months > I've written piles of kerneldoc comments for the DRM DocBook (all pulled > in as kerneldoc, docbook .tmpl has just the chapter structure). DOC: > sections are really useful to pull all the actual documentation out of the > docbook xml into kerneldoc. > > But I've also done piles of docs for intel-gpu-tools, which is using > gtkdoc. And there are some clear deficiencies: > > - No markdown for inline coments. Lack of lists and tables is hurting > especially badly. If we add this (and I don't care one iota whether it's Yes, I've tried to add lists to kernel-doc notation but have failed so far. > markdown or asciidoc or something else as long as it's readable plain > text in comments) we should be able to move all the existing docbook xml > paragraphs/lists/tables into kerneldoc comments. > > - Automatic cross-referencing of functions. If you place e.g. function() > or #struct anywhere in a documentation comment gtk-doc automatically > inserts a hyperlink to the relevant documentation page across the entire > project. Really powerful and makes overview sections much more useful > entry points for beginners since they can easily jump back&forth > betweeen the high-level overview and low-level per-function > documentation. > That's a nice-to-have IMO, but a really nice one. > - In a really perfect world it would help if kerneldoc could collect > structure member kerneldoc from per-member comments. Especially for > large structures with lots of comments this would bring the kerneldoc > and struct member much closer together. > > So that's my wishlist. > >> OTOH, I would only want to add another way to do kernel-doc if it can be a >> full replacement for all of our docbook usage, i.e., it should provide a >> way that we can eliminate docbook and stop using it completely. > > Hm, I don't mind docbook at all, as long as all the real content is > embedded into source files as kerneldoc and the docbook template just > pulls in all the right bits and pieces. Even gtkdoc allos you to do that > and pull in the different libararies (== header files with declarations > for C) in the order you want. So imo the docbook toolchain is good enough > for my needs. > > Or what do you mean by getting rid of all docbook usage? I meant no docbook style sheets, no 'xmlto', the whole ball of wax. But primarily I don't want to see drivers/video/ using one set of doc tools and drivers/media/ using another set and drivers/xyz/ using its own set of tools, etc. etc. etc. -- ~Randy From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thierry Reding Subject: Re: [PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers Date: Tue, 13 May 2014 09:17:42 +0200 Message-ID: <20140513071741.GB6754@ulmo> References: <1394016990-5218-1-git-send-email-sagar.a.kamble@intel.com> <2919182.UBDg5nOr7Z@avalon> <1394622965.18918.12.camel@sagar-desktop> <3136468.2PAlK4Gq8k@avalon> <20140510103937.GC18465@intel.com> <1399874873.15218.32.camel@sagar-desktop> <20140512080355.GB25056@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2039188887==" Return-path: In-Reply-To: <20140512080355.GB25056@phenom.ffwll.local> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Daniel Vetter Cc: Laurent Pinchart , linux-doc@vger.kernel.org, Daniel Vetter , intel-gfx , shashidhar.hiremath@intel.com, "dri-devel@lists.freedesktop.org" , Laurent Pinchart , Rob Landley , Alex Deucher , Dave Airlie , Sagar Arun Kamble List-Id: dri-devel@lists.freedesktop.org --===============2039188887== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="R3G7APHDIzY6R/pk" Content-Disposition: inline --R3G7APHDIzY6R/pk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 12, 2014 at 10:03:55AM +0200, Daniel Vetter wrote: > On Mon, May 12, 2014 at 11:37:53AM +0530, Sagar Arun Kamble wrote: > > I support approach using docbook to start since there are not lot of > > properties. Laurent has ack'ed this one. Can we go ahead with this? > > http://lists.freedesktop.org/archives/intel-gfx/2014-March/041527.html > >=20 > > Adding description of new property is not very complex (assuming table > > format is understood and being comfortable with HTML row/table > > manipulation). > >=20 > > Adding description of each property in their source might be time > > consuming task. >=20 > Yeah I'm ok with docbook for the time being. My long-term plan is to fix > up kerneldoc to support markdown and then we can move such neat tables > into the code. There's lots other places that would benefit from proper > list formatting and tables. So Ack from my side on both the docbook patch > and the no-more-props-without-doc-patch rule (which is kinda what I've > been doing thus far). What happened to the proposal to add this to the Documentation/ABI directory? That already contains a bunch of files describing userspace ABI (although most of it is sysfs-related). The objection that I have to including property documentation in docbook is that the DRM docbook is documentation targetted at driver developers, but properties are userspace ABI. Therefore I think we should be using mechanisms that have been used to document other userspace ABI before to make it easier for people to find (and for consistency). One big advantage in using Documentation/ABI is that there's a fairly well documented process of how to add, deprecate and remove ABI. There's also a template that should be followed when writing these files. People have obviously put some thought into this before, so it would be a bit of a waste trying to come up with our own. The README file has some good information about all of this and I think it matches what we need fairly well. In particular I like the concept of the "Users" section, which could save us a lot of work trying to track potential users of crufty ABI retrospectively. Thierry --R3G7APHDIzY6R/pk Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTcccVAAoJEN0jrNd/PrOhA68QAIllaLrSNC2+MjB7h7zLjtT/ P1u46mSgvvwA6p7D/9YJYEjAQv4EtLUMKtd1Hiht5CTKXAs0+SZqSm6nTg43oN0U k9e43of6jRhtuqrUaGGw0sS1Ch+T3WPATk7yhVozbOzGOqXvpaMagAt6B6A7TIGX TQCVuVPrBqGmvln3Dw5FARxUbEdBy8ZpsRemN0HGNq8DOZlvAklE3ahhDmf5PbrE DTXlyLxfB2MPyEJNd9OQMfpNlOR3Lo/rD/GVmjYk3bUxZUyxrYIWjNaefNzcZlGa H4yu6i2P5g6D9uDf1pMWBVCradmcfxXmtCA/Y95IUdr3+yJDMqxhwz9FQtUn/DVs 5VTKeOJ0sR6CPR/fm8sbP5gkMjTkM9MLVOE/vBUL5uXPJurbuGX9rQzXaDmM/R+A O/ufxcXg56MHRRwde1RbTwc6FX9Sy97fWrT92A6qJZk53ol7syYM2Hx2vd/iMdPm MkDNxYd9pzzzfXYKWyr9wLOclobIt8+fa0R/u10L/DAtpQ9POMgs2A08upvJfQ0y 2K2H4rNbB7rL75/X/OKzq24e0Us2XojTeyS3JZJRBrAz5MR6Uia3mnVKMpEnzI6y FZkTSzz61uqaPDxDc+TpN3DjNCyo1ZJjXoJ8rfO5hlosYtq803fWCKuX3spAgzfC Bem+ZpbLHAcqGvpT16EL =vH/M -----END PGP SIGNATURE----- --R3G7APHDIzY6R/pk-- --===============2039188887== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx --===============2039188887==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers Date: Tue, 13 May 2014 09:34:45 +0200 Message-ID: References: <1394016990-5218-1-git-send-email-sagar.a.kamble@intel.com> <2919182.UBDg5nOr7Z@avalon> <1394622965.18918.12.camel@sagar-desktop> <3136468.2PAlK4Gq8k@avalon> <20140510103937.GC18465@intel.com> <1399874873.15218.32.camel@sagar-desktop> <20140512080355.GB25056@phenom.ffwll.local> <20140513071741.GB6754@ulmo> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: In-Reply-To: <20140513071741.GB6754@ulmo> Sender: linux-doc-owner@vger.kernel.org To: Thierry Reding Cc: Sagar Arun Kamble , Laurent Pinchart , linux-doc@vger.kernel.org, intel-gfx , "Hiremath, Shashidhar" , "dri-devel@lists.freedesktop.org" , "Purushothaman, Vijay A" , Laurent Pinchart , Rob Landley , Alex Deucher , Dave Airlie List-Id: dri-devel@lists.freedesktop.org On Tue, May 13, 2014 at 9:17 AM, Thierry Reding wrote: > On Mon, May 12, 2014 at 10:03:55AM +0200, Daniel Vetter wrote: >> On Mon, May 12, 2014 at 11:37:53AM +0530, Sagar Arun Kamble wrote: >> > I support approach using docbook to start since there are not lot of >> > properties. Laurent has ack'ed this one. Can we go ahead with this? >> > http://lists.freedesktop.org/archives/intel-gfx/2014-March/041527.html >> > >> > Adding description of new property is not very complex (assuming table >> > format is understood and being comfortable with HTML row/table >> > manipulation). >> > >> > Adding description of each property in their source might be time >> > consuming task. >> >> Yeah I'm ok with docbook for the time being. My long-term plan is to fix >> up kerneldoc to support markdown and then we can move such neat tables >> into the code. There's lots other places that would benefit from proper >> list formatting and tables. So Ack from my side on both the docbook patch >> and the no-more-props-without-doc-patch rule (which is kinda what I've >> been doing thus far). > > What happened to the proposal to add this to the Documentation/ABI > directory? That already contains a bunch of files describing userspace > ABI (although most of it is sysfs-related). > > The objection that I have to including property documentation in docbook > is that the DRM docbook is documentation targetted at driver developers, > but properties are userspace ABI. Therefore I think we should be using > mechanisms that have been used to document other userspace ABI before to > make it easier for people to find (and for consistency). > > One big advantage in using Documentation/ABI is that there's a fairly > well documented process of how to add, deprecate and remove ABI. There's > also a template that should be followed when writing these files. People > have obviously put some thought into this before, so it would be a bit > of a waste trying to come up with our own. > > The README file has some good information about all of this and I think > it matches what we need fairly well. In particular I like the concept of > the "Users" section, which could save us a lot of work trying to track > potential users of crufty ABI retrospectively. Not really sold on this, since in the end if we break userspace we have to fix it up anyway. And all these properties are meant to be used by userspace after all. I think for properties it's more important to keep them all grouped together so that if new driver writes look for something to use they don't reinvent a slight variation of something existing again. Documentation/ABI otoh seems to split things up per-knob, even across stable/testing/deprecated directories. Also eventually I want to pull these tables directly out of source code comments - everything else tends to never get updated when the code changes. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thierry Reding Subject: Re: [PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers Date: Tue, 13 May 2014 11:05:37 +0200 Message-ID: <20140513090535.GM6754@ulmo> References: <1394016990-5218-1-git-send-email-sagar.a.kamble@intel.com> <2919182.UBDg5nOr7Z@avalon> <1394622965.18918.12.camel@sagar-desktop> <3136468.2PAlK4Gq8k@avalon> <20140510103937.GC18465@intel.com> <1399874873.15218.32.camel@sagar-desktop> <20140512080355.GB25056@phenom.ffwll.local> <20140513071741.GB6754@ulmo> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0178369256==" Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Daniel Vetter Cc: Laurent Pinchart , linux-doc@vger.kernel.org, intel-gfx , "Hiremath, Shashidhar" , "dri-devel@lists.freedesktop.org" , Laurent Pinchart , Rob Landley , Alex Deucher , Dave Airlie , Sagar Arun Kamble List-Id: dri-devel@lists.freedesktop.org --===============0178369256== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="t5NgoZwlhlUmGr82" Content-Disposition: inline --t5NgoZwlhlUmGr82 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 13, 2014 at 09:34:45AM +0200, Daniel Vetter wrote: > On Tue, May 13, 2014 at 9:17 AM, Thierry Reding > wrote: > > On Mon, May 12, 2014 at 10:03:55AM +0200, Daniel Vetter wrote: > >> On Mon, May 12, 2014 at 11:37:53AM +0530, Sagar Arun Kamble wrote: > >> > I support approach using docbook to start since there are not lot of > >> > properties. Laurent has ack'ed this one. Can we go ahead with this? > >> > http://lists.freedesktop.org/archives/intel-gfx/2014-March/041527.ht= ml > >> > > >> > Adding description of new property is not very complex (assuming tab= le > >> > format is understood and being comfortable with HTML row/table > >> > manipulation). > >> > > >> > Adding description of each property in their source might be time > >> > consuming task. > >> > >> Yeah I'm ok with docbook for the time being. My long-term plan is to f= ix > >> up kerneldoc to support markdown and then we can move such neat tables > >> into the code. There's lots other places that would benefit from proper > >> list formatting and tables. So Ack from my side on both the docbook pa= tch > >> and the no-more-props-without-doc-patch rule (which is kinda what I've > >> been doing thus far). > > > > What happened to the proposal to add this to the Documentation/ABI > > directory? That already contains a bunch of files describing userspace > > ABI (although most of it is sysfs-related). > > > > The objection that I have to including property documentation in docbook > > is that the DRM docbook is documentation targetted at driver developers, > > but properties are userspace ABI. Therefore I think we should be using > > mechanisms that have been used to document other userspace ABI before to > > make it easier for people to find (and for consistency). > > > > One big advantage in using Documentation/ABI is that there's a fairly > > well documented process of how to add, deprecate and remove ABI. There's > > also a template that should be followed when writing these files. People > > have obviously put some thought into this before, so it would be a bit > > of a waste trying to come up with our own. > > > > The README file has some good information about all of this and I think > > it matches what we need fairly well. In particular I like the concept of > > the "Users" section, which could save us a lot of work trying to track > > potential users of crufty ABI retrospectively. >=20 > Not really sold on this, since in the end if we break userspace we > have to fix it up anyway. And all these properties are meant to be > used by userspace after all. It's precisely because they are used by userspace that I think it's a good idea to have them documented in a place where userspace developers would look for them. I don't think anyone will look at the DRM docbook because it's targetted at driver developers. That said there is a tiny section called "Userland interfaces", so perhaps adding code to that and pointing everyone at it would be an option. In which case I still think we should follow some of the same guidelines as outlined in the ABI documentation about deprecating and versioning properties. Keeping a list of known users would also be great to have in case we ever need to modify or want to remove ABI. > I think for properties it's more important to keep them all grouped > together so that if new driver writes look for something to use they > don't reinvent a slight variation of something existing again. > Documentation/ABI otoh seems to split things up per-knob, even across > stable/testing/deprecated directories. I guess that's mostly a matter of convention. We could easily add a "drm" subdirectory that contains the DRM property documentation. And in my opinion having to scan a list of file names, such as: drm-connector-property-foo drm-plane-property-bar drm-plane-property-baz isn't any more difficult than scanning the same list in docbook format. So either way people will have to know where to look and then bother to look in order for this to work. Whether it's in Documentation/ABI or docbook is irrelevant. Also there's a good reason for having the stable/testing/deprecated split. That could also give additional hints as to whether it's a good idea to add some property or not. If somebody were to add a property to their driver that's been deprecated or removed for some other driver, a look at the corresponding file should indicate why it was removed. That could be valuable in pointing people in the right direction. Similarly, if some property was documented in the stable subdirectory, that would indicate that it's been deemed ready for prime time and give more credibility. It also means that more userspace is likely to use it and therefore might be higher priority to implement in new drivers. > Also eventually I want to pull these tables directly out of source > code comments - everything else tends to never get updated when the > code changes. There are no guarantees that people will keep code comments up-to-date either. The only way you can make sure of that is by reviewing patches carefully. And if you do that, the same applies to external documentation. I agree, though, that it's slightly easier to update code comments, so if we can make this work together with some of the stricter requirements for ABI as given above I think I could be happy as well. Thierry --t5NgoZwlhlUmGr82 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTceBfAAoJEN0jrNd/PrOhKeEQAK1OWTCpiLXAgQVpep37OKZR V5JfQfHUs4OlniMsbAPYbwkfwvtjMBzqNh1iZIuzqLGQzCW0Y+oKC639Ldq2srtV dvUL7xC6XZ3LbFBuvn1LzsS3XpXZ4vAydOdRfVBr2Ag2TkOR3aS6BHRn3g5lsPEs EBvBH+g6ii83jEWzIQvBLcnc+7/citKhsOwDh7ZcvagN+0zhGNhoiDkvU9Q2x7Y3 yMxPa9AooculEiyH85BOAcCvNH/zA7CaC17C9kPPXDAe/N4iDtHYYsS0KApDvjgl 0Klxw4QA6y7lvvGWvDBCoLCGuUV24yWlnxi6A6zRZVI151lLF6XRGDOq3bZX0aMi p4nAKLaj3EniH2J9iRHKeDwXeXr4lG0YTypLvXzCiXO5x7whcrnXIxTvIfHByKIL Yi9uYTBZagTCbBN8FLfeOj7Cirvafxxzt4yFKuKPHC/gOTK3ibQCi6jmGS8r50cF vpwHiraPs9Xcuj6pSzdp5NpnU9wWQgpWNussW/hM+8MOfuXm6s6QAsqZWQJ7O+lu 3BSYIAefO1Cl06VIaRMZO2V/PnX07jIy4J3uAm/DFymL+qhmQt9F+DUxBnjXF4Mx CAytKnLmAXhHK+43aX9WAUWzVafr7BY/Iqk0xar1lYZklh8Teiwx6iJzDTIr4gx0 DnpHEEHGVPX4Zg1kZe/4 =GDav -----END PGP SIGNATURE----- --t5NgoZwlhlUmGr82-- --===============0178369256== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx --===============0178369256==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Laurent Pinchart Subject: Re: [PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers Date: Tue, 13 May 2014 13:02:14 +0200 Message-ID: <6636875.Q6Yvl742tP@avalon> References: <1394016990-5218-1-git-send-email-sagar.a.kamble@intel.com> <20140513071741.GB6754@ulmo> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [95.142.166.194]) by gabe.freedesktop.org (Postfix) with ESMTP id 7D13D6EA6F for ; Tue, 13 May 2014 04:02:15 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Daniel Vetter Cc: Laurent Pinchart , linux-doc@vger.kernel.org, intel-gfx , "Hiremath, Shashidhar" , "dri-devel@lists.freedesktop.org" , "Purushothaman, Vijay A" , Rob Landley , Alex Deucher , Dave Airlie , Sagar Arun Kamble List-Id: dri-devel@lists.freedesktop.org Hi Daniel, On Tuesday 13 May 2014 09:34:45 Daniel Vetter wrote: > On Tue, May 13, 2014 at 9:17 AM, Thierry Reding wrote: > > On Mon, May 12, 2014 at 10:03:55AM +0200, Daniel Vetter wrote: > >> On Mon, May 12, 2014 at 11:37:53AM +0530, Sagar Arun Kamble wrote: > >> > I support approach using docbook to start since there are not lot of > >> > properties. Laurent has ack'ed this one. Can we go ahead with this? > >> > http://lists.freedesktop.org/archives/intel-gfx/2014-March/041527.html > >> > > >> > Adding description of new property is not very complex (assuming table > >> > format is understood and being comfortable with HTML row/table > >> > manipulation). > >> > > >> > Adding description of each property in their source might be time > >> > consuming task. > >> > >> Yeah I'm ok with docbook for the time being. My long-term plan is to fix > >> up kerneldoc to support markdown and then we can move such neat tables > >> into the code. There's lots other places that would benefit from proper > >> list formatting and tables. So Ack from my side on both the docbook patch > >> and the no-more-props-without-doc-patch rule (which is kinda what I've > >> been doing thus far). > > > > What happened to the proposal to add this to the Documentation/ABI > > directory? That already contains a bunch of files describing userspace > > ABI (although most of it is sysfs-related). > > > > The objection that I have to including property documentation in docbook > > is that the DRM docbook is documentation targetted at driver developers, > > but properties are userspace ABI. Therefore I think we should be using > > mechanisms that have been used to document other userspace ABI before to > > make it easier for people to find (and for consistency). > > > > One big advantage in using Documentation/ABI is that there's a fairly > > well documented process of how to add, deprecate and remove ABI. There's > > also a template that should be followed when writing these files. People > > have obviously put some thought into this before, so it would be a bit > > of a waste trying to come up with our own. > > > > The README file has some good information about all of this and I think > > it matches what we need fairly well. In particular I like the concept of > > the "Users" section, which could save us a lot of work trying to track > > potential users of crufty ABI retrospectively. > > Not really sold on this, since in the end if we break userspace we > have to fix it up anyway. And all these properties are meant to be > used by userspace after all. I think for properties it's more > important to keep them all grouped together so that if new driver > writes look for something to use they don't reinvent a slight > variation of something existing again. Documentation/ABI otoh seems to > split things up per-knob, even across stable/testing/deprecated > directories. > > Also eventually I want to pull these tables directly out of source > code comments - everything else tends to never get updated when the > code changes. On the subject of moving documentation from docbook to source code, do your kerneldoc extensions plans include supporting images ? A drawing is worth a thousand words (see http://linuxtv.org/downloads/v4l-dvb-apis/subdev.html#subdev-image-processing-scaling-multi-source for instance), and that's currently a pretty important feature of the docbook format. -- Regards, Laurent Pinchart From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers Date: Tue, 13 May 2014 13:51:37 +0200 Message-ID: References: <1394016990-5218-1-git-send-email-sagar.a.kamble@intel.com> <20140513071741.GB6754@ulmo> <6636875.Q6Yvl742tP@avalon> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: In-Reply-To: <6636875.Q6Yvl742tP@avalon> Sender: linux-doc-owner@vger.kernel.org To: Laurent Pinchart Cc: Thierry Reding , Sagar Arun Kamble , Laurent Pinchart , linux-doc@vger.kernel.org, intel-gfx , "Hiremath, Shashidhar" , "dri-devel@lists.freedesktop.org" , "Purushothaman, Vijay A" , Rob Landley , Alex Deucher , Dave Airlie List-Id: dri-devel@lists.freedesktop.org On Tue, May 13, 2014 at 1:02 PM, Laurent Pinchart wrote: >> Also eventually I want to pull these tables directly out of source >> code comments - everything else tends to never get updated when the >> code changes. > > On the subject of moving documentation from docbook to source code, do your > kerneldoc extensions plans include supporting images ? A drawing is worth a > thousand words (see http://linuxtv.org/downloads/v4l-dvb-apis/subdev.html#subdev-image-processing-scaling-multi-source for instance), > and that's currently a pretty important feature of the docbook format. That looks great I think I'll get a bit of doc envy ;-) I don't think there's any reasonable way to generate such figures from comments, maybe for simple ones some ascii art might work out. But converting that to svg for the docbook seems to be an unsovled problem (I've only found some hacks), so I think we need to manually pull those into the docbook still. But excellent point for consideration. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch From mboxrd@z Thu Jan 1 00:00:00 1970 From: Randy Dunlap Subject: Re: [PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers Date: Thu, 31 Jul 2014 15:16:21 -0700 Message-ID: <53DAC035.4060507@infradead.org> References: <1394016990-5218-1-git-send-email-sagar.a.kamble@intel.com> <2919182.UBDg5nOr7Z@avalon> <1394622965.18918.12.camel@sagar-desktop> <3136468.2PAlK4Gq8k@avalon> <20140510103937.GC18465@intel.com> <20140512085827.GD25056@phenom.ffwll.local> <5370E781.1080308@infradead.org> <20140512155403.GF25056@phenom.ffwll.local> <53710D1E.7040102@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <53710D1E.7040102@infradead.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Daniel Vetter Cc: Laurent Pinchart , linux-doc@vger.kernel.org, Sagar Arun Kamble , Daniel Vetter , intel-gfx , dri-devel , Laurent Pinchart , Rob Landley , Alex Deucher , Dave Airlie List-Id: dri-devel@lists.freedesktop.org On 05/12/14 11:04, Randy Dunlap wrote: > On 05/12/2014 08:54 AM, Daniel Vetter wrote: >> On Mon, May 12, 2014 at 08:23:45AM -0700, Randy Dunlap wrote: >>> On 05/12/2014 01:58 AM, Daniel Vetter wrote: >>>> On Mon, May 12, 2014 at 06:24:57PM +1000, Dave Airlie wrote: >>>>>>> >>>>>>> If we decide to go for property documentation inside the source code then I >>>>>>> believe we'll have to create our own format, as creating a properties table >>>>>>> from kerneldoc information extracted from comments is probably not possible. >>>>>> >>>>>> Can comeone pick up the ball here and figure out what needs to be done? >>>>>> >>>>>> The reason why I want a central place for the documentation is to force >>>>>> people to collaborate outside their own sandbox when adding properties. >>>>>> Whether that's docbook or some text file I don't care so much at this >>>>>> point. The fact that it's a central place should mandate that the >>>>>> patches changing it will go through dri-devel and so everyone should se >>>>>> them, and when adding new properties it would make the patch author more >>>>>> likely to look around a bit before adding another slighty incompatible >>>>>> version of the same property. If someone has a better suggestion how to >>>>>> encforce this I'm all ears. >>>>>> >>>>>> Of course this idea can still fail if our esteemed maintainer merges >>>>>> stuff without checking for violations of this policy. Dave, any thoughts >>>>>> on the subject? >>>>> >>>>> Yeah I'm happy to block merging stuff, if we can spot new properties >>>>> when stuff is posted on dri-devel, so much the better, >>>>> >>>>> most drivers still send everything via dri-devel anyways, its only >>>>> really Intel I have to worry about so far, >>>> >>>> I'll enforce that all prop stuff gets cc: dri-devel and that it has >>>> updates for the prop docs. >>>> >>>>> But we should definitely add it to the new driver review checklist as well. >>>>> >>>>> I'm also on the side of this patch is ugly and makes my eyes burn, >>>>> please please get a plan to use something else ASAP, I'm willing to >>>>> merge this but I'm tempted to give it a lifetime of a kernel or two >>>>> before I burn it. >>>> >>>> Ok, I'll try to move "make kerneldoc suck less" up the task list and maybe >>>> find someone to do it for me internally ;-) >>>> -Daniel >>>> >>> >>> I certainly have no objections to making kerneldoc suck less. >>> There was already an attempt to use asciidoc (like git uses) for kernel-doc >>> (a few years ago, by Sam Ravnborg). I support(ed) that effort. >> >> Hm, do you have pointers to those? My google-fu seems lacking ... > > I googled for /kernel doc asciidoc ravnborg/ and found several hits for them. > >> Ok, let's move this to the top and start discussions. The past few months >> I've written piles of kerneldoc comments for the DRM DocBook (all pulled >> in as kerneldoc, docbook .tmpl has just the chapter structure). DOC: >> sections are really useful to pull all the actual documentation out of the >> docbook xml into kerneldoc. >> >> But I've also done piles of docs for intel-gpu-tools, which is using >> gtkdoc. And there are some clear deficiencies: >> >> - No markdown for inline coments. Lack of lists and tables is hurting >> especially badly. If we add this (and I don't care one iota whether it's > > Yes, I've tried to add lists to kernel-doc notation but have failed so far. > >> markdown or asciidoc or something else as long as it's readable plain >> text in comments) we should be able to move all the existing docbook xml >> paragraphs/lists/tables into kerneldoc comments. >> >> - Automatic cross-referencing of functions. If you place e.g. function() >> or #struct anywhere in a documentation comment gtk-doc automatically >> inserts a hyperlink to the relevant documentation page across the entire >> project. Really powerful and makes overview sections much more useful >> entry points for beginners since they can easily jump back&forth >> betweeen the high-level overview and low-level per-function >> documentation. >> > > That's a nice-to-have IMO, but a really nice one. > >> - In a really perfect world it would help if kerneldoc could collect >> structure member kerneldoc from per-member comments. Especially for >> large structures with lots of comments this would bring the kerneldoc >> and struct member much closer together. >> >> So that's my wishlist. >> >>> OTOH, I would only want to add another way to do kernel-doc if it can be a >>> full replacement for all of our docbook usage, i.e., it should provide a >>> way that we can eliminate docbook and stop using it completely. >> >> Hm, I don't mind docbook at all, as long as all the real content is >> embedded into source files as kerneldoc and the docbook template just >> pulls in all the right bits and pieces. Even gtkdoc allos you to do that >> and pull in the different libararies (== header files with declarations >> for C) in the order you want. So imo the docbook toolchain is good enough >> for my needs. >> >> Or what do you mean by getting rid of all docbook usage? > > I meant no docbook style sheets, no 'xmlto', the whole ball of wax. > > But primarily I don't want to see drivers/video/ using one set of doc tools > and drivers/media/ using another set and drivers/xyz/ using its own set of > tools, etc. etc. etc. Hi Daniel and others, I don't know what your plans are for drm docs (tables, etc.), but I think that I misspoke above. My primary/major concern is that there be some useful documentation. What form or format it is in is secondary. It's not a good thing that media DocBook is so different from all of the others, but it's OK. It's not a good thing that drivers/lguest/ uses its own tools to extract comments from source files to create documentation, but it's OK -- at least it generates some (hopefully useful) documentation. I also note that a new autofs doc file (not yet merged) uses markdown. Please feel free to use kernel-doc or markdown or asciidoc or plain text. :) or even your own tools, even though that is less preferred. Thanks. -- ~Randy From mboxrd@z Thu Jan 1 00:00:00 1970 From: Laurent Pinchart Subject: Re: [PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers Date: Fri, 01 Aug 2014 14:58:21 +0200 Message-ID: <1989663.VGMKAdAlB9@avalon> References: <1394016990-5218-1-git-send-email-sagar.a.kamble@intel.com> <53710D1E.7040102@infradead.org> <53DAC035.4060507@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <53DAC035.4060507@infradead.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Randy Dunlap Cc: Laurent Pinchart , Rob Landley , linux-doc@vger.kernel.org, Sagar Arun Kamble , Daniel Vetter , intel-gfx , dri-devel , Alex Deucher , Dave Airlie List-Id: dri-devel@lists.freedesktop.org Hi Randy, On Thursday 31 July 2014 15:16:21 Randy Dunlap wrote: > On 05/12/14 11:04, Randy Dunlap wrote: > > On 05/12/2014 08:54 AM, Daniel Vetter wrote: > >> On Mon, May 12, 2014 at 08:23:45AM -0700, Randy Dunlap wrote: > >>> On 05/12/2014 01:58 AM, Daniel Vetter wrote: > >>>> On Mon, May 12, 2014 at 06:24:57PM +1000, Dave Airlie wrote: > >>>>>>> If we decide to go for property documentation inside the source code > >>>>>>> then I believe we'll have to create our own format, as creating a > >>>>>>> properties table from kerneldoc information extracted from comments > >>>>>>> is probably not possible. > >>>>>> > >>>>>> Can comeone pick up the ball here and figure out what needs to be > >>>>>> done? > >>>>>> > >>>>>> The reason why I want a central place for the documentation is to > >>>>>> force people to collaborate outside their own sandbox when adding > >>>>>> properties. Whether that's docbook or some text file I don't care so > >>>>>> much at this point. The fact that it's a central place should mandate > >>>>>> that the patches changing it will go through dri-devel and so > >>>>>> everyone should se them, and when adding new properties it would make > >>>>>> the patch author more likely to look around a bit before adding > >>>>>> another slighty incompatible version of the same property. If someone > >>>>>> has a better suggestion how to encforce this I'm all ears. > >>>>>> > >>>>>> Of course this idea can still fail if our esteemed maintainer merges > >>>>>> stuff without checking for violations of this policy. Dave, any > >>>>>> thoughts on the subject? > >>>>> > >>>>> Yeah I'm happy to block merging stuff, if we can spot new properties > >>>>> when stuff is posted on dri-devel, so much the better, > >>>>> > >>>>> most drivers still send everything via dri-devel anyways, its only > >>>>> really Intel I have to worry about so far, > >>>> > >>>> I'll enforce that all prop stuff gets cc: dri-devel and that it has > >>>> updates for the prop docs. > >>>> > >>>>> But we should definitely add it to the new driver review checklist as > >>>>> well. > >>>>> > >>>>> I'm also on the side of this patch is ugly and makes my eyes burn, > >>>>> please please get a plan to use something else ASAP, I'm willing to > >>>>> merge this but I'm tempted to give it a lifetime of a kernel or two > >>>>> before I burn it. > >>>> > >>>> Ok, I'll try to move "make kerneldoc suck less" up the task list and > >>>> maybe find someone to do it for me internally ;-) > >>> > >>> I certainly have no objections to making kerneldoc suck less. > >>> There was already an attempt to use asciidoc (like git uses) for > >>> kernel-doc (a few years ago, by Sam Ravnborg). I support(ed) that > >>> effort. > >> > >> Hm, do you have pointers to those? My google-fu seems lacking ... > > > > I googled for /kernel doc asciidoc ravnborg/ and found several hits for > > them. > > > >> Ok, let's move this to the top and start discussions. The past few months > >> I've written piles of kerneldoc comments for the DRM DocBook (all pulled > >> in as kerneldoc, docbook .tmpl has just the chapter structure). DOC: > >> sections are really useful to pull all the actual documentation out of > >> the docbook xml into kerneldoc. > >> > >> But I've also done piles of docs for intel-gpu-tools, which is using > >> gtkdoc. And there are some clear deficiencies: > >> > >> - No markdown for inline coments. Lack of lists and tables is hurting > >> especially badly. If we add this (and I don't care one iota whether > >> it's > > > > Yes, I've tried to add lists to kernel-doc notation but have failed so > > far. > > > >> markdown or asciidoc or something else as long as it's readable plain > >> text in comments) we should be able to move all the existing docbook > >> xml paragraphs/lists/tables into kerneldoc comments. > >> > >> - Automatic cross-referencing of functions. If you place e.g. function() > >> or #struct anywhere in a documentation comment gtk-doc automatically > >> inserts a hyperlink to the relevant documentation page across the > >> entire project. Really powerful and makes overview sections much more > >> useful entry points for beginners since they can easily jump back&forth > >> betweeen the high-level overview and low-level per-function > >> documentation. > > > > That's a nice-to-have IMO, but a really nice one. > > > >> - In a really perfect world it would help if kerneldoc could collect > >> structure member kerneldoc from per-member comments. Especially for > >> large structures with lots of comments this would bring the kerneldoc > >> and struct member much closer together. > >> > >> So that's my wishlist. > >> > >>> OTOH, I would only want to add another way to do kernel-doc if it can be > >>> a full replacement for all of our docbook usage, i.e., it should provide > >>> a way that we can eliminate docbook and stop using it completely. > >> > >> Hm, I don't mind docbook at all, as long as all the real content is > >> embedded into source files as kerneldoc and the docbook template just > >> pulls in all the right bits and pieces. Even gtkdoc allos you to do that > >> and pull in the different libararies (== header files with declarations > >> for C) in the order you want. So imo the docbook toolchain is good enough > >> for my needs. > >> > >> Or what do you mean by getting rid of all docbook usage? > > > > I meant no docbook style sheets, no 'xmlto', the whole ball of wax. > > > > But primarily I don't want to see drivers/video/ using one set of doc > > tools and drivers/media/ using another set and drivers/xyz/ using its own > > set of tools, etc. etc. etc. > > Hi Daniel and others, > > I don't know what your plans are for drm docs (tables, etc.), but I think > that I misspoke above. My primary/major concern is that there be some > useful documentation. What form or format it is in is secondary. I agree with you, there's no reason to block your patch just because we might get a better documentation tool at a still unknown point in the future. Daniel, are you fine with merging the documentation in DocBook format for now ? Randy, could you please check whether your patch still applies and rebase and resubmit it if it doesn't ? > It's not a good thing that media DocBook is so different from all of the > others, but it's OK. > > It's not a good thing that drivers/lguest/ uses its own tools to extract > comments from source files to create documentation, but it's OK -- at least > it generates some (hopefully useful) documentation. > > I also note that a new autofs doc file (not yet merged) uses markdown. > > Please feel free to use kernel-doc or markdown or asciidoc or plain text. :) > or even your own tools, even though that is less preferred. -- Regards, Laurent Pinchart From mboxrd@z Thu Jan 1 00:00:00 1970 From: Randy Dunlap Subject: Re: [PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers Date: Fri, 01 Aug 2014 15:21:43 -0700 Message-ID: <53DC12F7.8070004@infradead.org> References: <1394016990-5218-1-git-send-email-sagar.a.kamble@intel.com> <53710D1E.7040102@infradead.org> <53DAC035.4060507@infradead.org> <1989663.VGMKAdAlB9@avalon> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1989663.VGMKAdAlB9@avalon> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Laurent Pinchart Cc: Laurent Pinchart , Rob Landley , linux-doc@vger.kernel.org, Sagar Arun Kamble , Daniel Vetter , intel-gfx , dri-devel , Alex Deucher , Dave Airlie List-Id: dri-devel@lists.freedesktop.org On 08/01/14 05:58, Laurent Pinchart wrote: > Hi Randy, > > On Thursday 31 July 2014 15:16:21 Randy Dunlap wrote: >> On 05/12/14 11:04, Randy Dunlap wrote: >>> On 05/12/2014 08:54 AM, Daniel Vetter wrote: >>>> On Mon, May 12, 2014 at 08:23:45AM -0700, Randy Dunlap wrote: >>>>> On 05/12/2014 01:58 AM, Daniel Vetter wrote: >>>>>> On Mon, May 12, 2014 at 06:24:57PM +1000, Dave Airlie wrote: >>>>>>>>> If we decide to go for property documentation inside the source code >>>>>>>>> then I believe we'll have to create our own format, as creating a >>>>>>>>> properties table from kerneldoc information extracted from comments >>>>>>>>> is probably not possible. >>>>>>>> >>>>>>>> Can comeone pick up the ball here and figure out what needs to be >>>>>>>> done? >>>>>>>> >>>>>>>> The reason why I want a central place for the documentation is to >>>>>>>> force people to collaborate outside their own sandbox when adding >>>>>>>> properties. Whether that's docbook or some text file I don't care so >>>>>>>> much at this point. The fact that it's a central place should mandate >>>>>>>> that the patches changing it will go through dri-devel and so >>>>>>>> everyone should se them, and when adding new properties it would make >>>>>>>> the patch author more likely to look around a bit before adding >>>>>>>> another slighty incompatible version of the same property. If someone >>>>>>>> has a better suggestion how to encforce this I'm all ears. >>>>>>>> >>>>>>>> Of course this idea can still fail if our esteemed maintainer merges >>>>>>>> stuff without checking for violations of this policy. Dave, any >>>>>>>> thoughts on the subject? >>>>>>> >>>>>>> Yeah I'm happy to block merging stuff, if we can spot new properties >>>>>>> when stuff is posted on dri-devel, so much the better, >>>>>>> >>>>>>> most drivers still send everything via dri-devel anyways, its only >>>>>>> really Intel I have to worry about so far, >>>>>> >>>>>> I'll enforce that all prop stuff gets cc: dri-devel and that it has >>>>>> updates for the prop docs. >>>>>> >>>>>>> But we should definitely add it to the new driver review checklist as >>>>>>> well. >>>>>>> >>>>>>> I'm also on the side of this patch is ugly and makes my eyes burn, >>>>>>> please please get a plan to use something else ASAP, I'm willing to >>>>>>> merge this but I'm tempted to give it a lifetime of a kernel or two >>>>>>> before I burn it. >>>>>> >>>>>> Ok, I'll try to move "make kerneldoc suck less" up the task list and >>>>>> maybe find someone to do it for me internally ;-) >>>>> >>>>> I certainly have no objections to making kerneldoc suck less. >>>>> There was already an attempt to use asciidoc (like git uses) for >>>>> kernel-doc (a few years ago, by Sam Ravnborg). I support(ed) that >>>>> effort. >>>> >>>> Hm, do you have pointers to those? My google-fu seems lacking ... >>> >>> I googled for /kernel doc asciidoc ravnborg/ and found several hits for >>> them. >>> >>>> Ok, let's move this to the top and start discussions. The past few months >>>> I've written piles of kerneldoc comments for the DRM DocBook (all pulled >>>> in as kerneldoc, docbook .tmpl has just the chapter structure). DOC: >>>> sections are really useful to pull all the actual documentation out of >>>> the docbook xml into kerneldoc. >>>> >>>> But I've also done piles of docs for intel-gpu-tools, which is using >>>> gtkdoc. And there are some clear deficiencies: >>>> >>>> - No markdown for inline coments. Lack of lists and tables is hurting >>>> especially badly. If we add this (and I don't care one iota whether >>>> it's >>> >>> Yes, I've tried to add lists to kernel-doc notation but have failed so >>> far. >>> >>>> markdown or asciidoc or something else as long as it's readable plain >>>> text in comments) we should be able to move all the existing docbook >>>> xml paragraphs/lists/tables into kerneldoc comments. >>>> >>>> - Automatic cross-referencing of functions. If you place e.g. function() >>>> or #struct anywhere in a documentation comment gtk-doc automatically >>>> inserts a hyperlink to the relevant documentation page across the >>>> entire project. Really powerful and makes overview sections much more >>>> useful entry points for beginners since they can easily jump back&forth >>>> betweeen the high-level overview and low-level per-function >>>> documentation. >>> >>> That's a nice-to-have IMO, but a really nice one. >>> >>>> - In a really perfect world it would help if kerneldoc could collect >>>> structure member kerneldoc from per-member comments. Especially for >>>> large structures with lots of comments this would bring the kerneldoc >>>> and struct member much closer together. >>>> >>>> So that's my wishlist. >>>> >>>>> OTOH, I would only want to add another way to do kernel-doc if it can be >>>>> a full replacement for all of our docbook usage, i.e., it should provide >>>>> a way that we can eliminate docbook and stop using it completely. >>>> >>>> Hm, I don't mind docbook at all, as long as all the real content is >>>> embedded into source files as kerneldoc and the docbook template just >>>> pulls in all the right bits and pieces. Even gtkdoc allos you to do that >>>> and pull in the different libararies (== header files with declarations >>>> for C) in the order you want. So imo the docbook toolchain is good enough >>>> for my needs. >>>> >>>> Or what do you mean by getting rid of all docbook usage? >>> >>> I meant no docbook style sheets, no 'xmlto', the whole ball of wax. >>> >>> But primarily I don't want to see drivers/video/ using one set of doc >>> tools and drivers/media/ using another set and drivers/xyz/ using its own >>> set of tools, etc. etc. etc. >> >> Hi Daniel and others, >> >> I don't know what your plans are for drm docs (tables, etc.), but I think >> that I misspoke above. My primary/major concern is that there be some >> useful documentation. What form or format it is in is secondary. > > I agree with you, there's no reason to block your patch just because we might > get a better documentation tool at a still unknown point in the future. > Daniel, are you fine with merging the documentation in DocBook format for now > ? > > Randy, could you please check whether your patch still applies and rebase and > resubmit it if it doesn't ? Hi Laurent, What patch are you referring to here? Thanks. >> It's not a good thing that media DocBook is so different from all of the >> others, but it's OK. >> >> It's not a good thing that drivers/lguest/ uses its own tools to extract >> comments from source files to create documentation, but it's OK -- at least >> it generates some (hopefully useful) documentation. >> >> I also note that a new autofs doc file (not yet merged) uses markdown. >> >> Please feel free to use kernel-doc or markdown or asciidoc or plain text. :) >> or even your own tools, even though that is less preferred. > -- ~Randy From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers Date: Mon, 4 Aug 2014 09:30:04 +0200 Message-ID: <20140804073004.GE8727@phenom.ffwll.local> References: <1394016990-5218-1-git-send-email-sagar.a.kamble@intel.com> <53710D1E.7040102@infradead.org> <53DAC035.4060507@infradead.org> <1989663.VGMKAdAlB9@avalon> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <1989663.VGMKAdAlB9@avalon> Sender: linux-doc-owner@vger.kernel.org To: Laurent Pinchart Cc: Randy Dunlap , Daniel Vetter , Dave Airlie , Ville =?iso-8859-1?Q?Syrj=E4l=E4?= , Laurent Pinchart , linux-doc@vger.kernel.org, Daniel Vetter , intel-gfx , dri-devel , "Purushothaman, Vijay A" , Rob Landley , Alex Deucher , Dave Airlie , Sagar Arun Kamble List-Id: dri-devel@lists.freedesktop.org On Fri, Aug 01, 2014 at 02:58:21PM +0200, Laurent Pinchart wrote: > Hi Randy, > > On Thursday 31 July 2014 15:16:21 Randy Dunlap wrote: > > On 05/12/14 11:04, Randy Dunlap wrote: > > > On 05/12/2014 08:54 AM, Daniel Vetter wrote: > > >> On Mon, May 12, 2014 at 08:23:45AM -0700, Randy Dunlap wrote: > > >>> On 05/12/2014 01:58 AM, Daniel Vetter wrote: > > >>>> On Mon, May 12, 2014 at 06:24:57PM +1000, Dave Airlie wrote: > > >>>>>>> If we decide to go for property documentation inside the source code > > >>>>>>> then I believe we'll have to create our own format, as creating a > > >>>>>>> properties table from kerneldoc information extracted from comments > > >>>>>>> is probably not possible. > > >>>>>> > > >>>>>> Can comeone pick up the ball here and figure out what needs to be > > >>>>>> done? > > >>>>>> > > >>>>>> The reason why I want a central place for the documentation is to > > >>>>>> force people to collaborate outside their own sandbox when adding > > >>>>>> properties. Whether that's docbook or some text file I don't care so > > >>>>>> much at this point. The fact that it's a central place should mandate > > >>>>>> that the patches changing it will go through dri-devel and so > > >>>>>> everyone should se them, and when adding new properties it would make > > >>>>>> the patch author more likely to look around a bit before adding > > >>>>>> another slighty incompatible version of the same property. If someone > > >>>>>> has a better suggestion how to encforce this I'm all ears. > > >>>>>> > > >>>>>> Of course this idea can still fail if our esteemed maintainer merges > > >>>>>> stuff without checking for violations of this policy. Dave, any > > >>>>>> thoughts on the subject? > > >>>>> > > >>>>> Yeah I'm happy to block merging stuff, if we can spot new properties > > >>>>> when stuff is posted on dri-devel, so much the better, > > >>>>> > > >>>>> most drivers still send everything via dri-devel anyways, its only > > >>>>> really Intel I have to worry about so far, > > >>>> > > >>>> I'll enforce that all prop stuff gets cc: dri-devel and that it has > > >>>> updates for the prop docs. > > >>>> > > >>>>> But we should definitely add it to the new driver review checklist as > > >>>>> well. > > >>>>> > > >>>>> I'm also on the side of this patch is ugly and makes my eyes burn, > > >>>>> please please get a plan to use something else ASAP, I'm willing to > > >>>>> merge this but I'm tempted to give it a lifetime of a kernel or two > > >>>>> before I burn it. > > >>>> > > >>>> Ok, I'll try to move "make kerneldoc suck less" up the task list and > > >>>> maybe find someone to do it for me internally ;-) > > >>> > > >>> I certainly have no objections to making kerneldoc suck less. > > >>> There was already an attempt to use asciidoc (like git uses) for > > >>> kernel-doc (a few years ago, by Sam Ravnborg). I support(ed) that > > >>> effort. > > >> > > >> Hm, do you have pointers to those? My google-fu seems lacking ... > > > > > > I googled for /kernel doc asciidoc ravnborg/ and found several hits for > > > them. > > > > > >> Ok, let's move this to the top and start discussions. The past few months > > >> I've written piles of kerneldoc comments for the DRM DocBook (all pulled > > >> in as kerneldoc, docbook .tmpl has just the chapter structure). DOC: > > >> sections are really useful to pull all the actual documentation out of > > >> the docbook xml into kerneldoc. > > >> > > >> But I've also done piles of docs for intel-gpu-tools, which is using > > >> gtkdoc. And there are some clear deficiencies: > > >> > > >> - No markdown for inline coments. Lack of lists and tables is hurting > > >> especially badly. If we add this (and I don't care one iota whether > > >> it's > > > > > > Yes, I've tried to add lists to kernel-doc notation but have failed so > > > far. > > > > > >> markdown or asciidoc or something else as long as it's readable plain > > >> text in comments) we should be able to move all the existing docbook > > >> xml paragraphs/lists/tables into kerneldoc comments. > > >> > > >> - Automatic cross-referencing of functions. If you place e.g. function() > > >> or #struct anywhere in a documentation comment gtk-doc automatically > > >> inserts a hyperlink to the relevant documentation page across the > > >> entire project. Really powerful and makes overview sections much more > > >> useful entry points for beginners since they can easily jump back&forth > > >> betweeen the high-level overview and low-level per-function > > >> documentation. > > > > > > That's a nice-to-have IMO, but a really nice one. > > > > > >> - In a really perfect world it would help if kerneldoc could collect > > >> structure member kerneldoc from per-member comments. Especially for > > >> large structures with lots of comments this would bring the kerneldoc > > >> and struct member much closer together. > > >> > > >> So that's my wishlist. > > >> > > >>> OTOH, I would only want to add another way to do kernel-doc if it can be > > >>> a full replacement for all of our docbook usage, i.e., it should provide > > >>> a way that we can eliminate docbook and stop using it completely. > > >> > > >> Hm, I don't mind docbook at all, as long as all the real content is > > >> embedded into source files as kerneldoc and the docbook template just > > >> pulls in all the right bits and pieces. Even gtkdoc allos you to do that > > >> and pull in the different libararies (== header files with declarations > > >> for C) in the order you want. So imo the docbook toolchain is good enough > > >> for my needs. > > >> > > >> Or what do you mean by getting rid of all docbook usage? > > > > > > I meant no docbook style sheets, no 'xmlto', the whole ball of wax. > > > > > > But primarily I don't want to see drivers/video/ using one set of doc > > > tools and drivers/media/ using another set and drivers/xyz/ using its own > > > set of tools, etc. etc. etc. > > > > Hi Daniel and others, > > > > I don't know what your plans are for drm docs (tables, etc.), but I think > > that I misspoke above. My primary/major concern is that there be some > > useful documentation. What form or format it is in is secondary. > > I agree with you, there's no reason to block your patch just because we might > get a better documentation tool at a still unknown point in the future. > Daniel, are you fine with merging the documentation in DocBook format for now > ? It was already merged ... My mail was really just to make people aware of what I'd like to have (and what I'll try to get) so that could coordinate (if other people also work on this). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch From mboxrd@z Thu Jan 1 00:00:00 1970 From: Laurent Pinchart Subject: Re: [PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers Date: Mon, 04 Aug 2014 15:58:42 +0200 Message-ID: <117291664.gofJ9L5rHm@avalon> References: <1394016990-5218-1-git-send-email-sagar.a.kamble@intel.com> <1989663.VGMKAdAlB9@avalon> <20140804073004.GE8727@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20140804073004.GE8727@phenom.ffwll.local> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Daniel Vetter Cc: Laurent Pinchart , linux-doc@vger.kernel.org, Sagar Arun Kamble , Daniel Vetter , intel-gfx , Randy Dunlap , dri-devel , Rob Landley , Alex Deucher , Dave Airlie List-Id: dri-devel@lists.freedesktop.org On Monday 04 August 2014 09:30:04 Daniel Vetter wrote: > On Fri, Aug 01, 2014 at 02:58:21PM +0200, Laurent Pinchart wrote: > > On Thursday 31 July 2014 15:16:21 Randy Dunlap wrote: > >> On 05/12/14 11:04, Randy Dunlap wrote: > >>> On 05/12/2014 08:54 AM, Daniel Vetter wrote: > >>>> On Mon, May 12, 2014 at 08:23:45AM -0700, Randy Dunlap wrote: > >>>>> On 05/12/2014 01:58 AM, Daniel Vetter wrote: > >>>>>> On Mon, May 12, 2014 at 06:24:57PM +1000, Dave Airlie wrote: > >>>>>>>>> If we decide to go for property documentation inside the source > >>>>>>>>> code then I believe we'll have to create our own format, as > >>>>>>>>> creating a properties table from kerneldoc information extracted > >>>>>>>>> from comments is probably not possible. > >>>>>>>> > >>>>>>>> Can comeone pick up the ball here and figure out what needs to be > >>>>>>>> done? > >>>>>>>> > >>>>>>>> The reason why I want a central place for the documentation is to > >>>>>>>> force people to collaborate outside their own sandbox when adding > >>>>>>>> properties. Whether that's docbook or some text file I don't care > >>>>>>>> so much at this point. The fact that it's a central place should > >>>>>>>> mandate that the patches changing it will go through dri-devel > >>>>>>>> and so everyone should se them, and when adding new properties it > >>>>>>>> would make the patch author more likely to look around a bit > >>>>>>>> before adding another slighty incompatible version of the same > >>>>>>>> property. If someone has a better suggestion how to encforce this > >>>>>>>> I'm all ears. > >>>>>>>> > >>>>>>>> Of course this idea can still fail if our esteemed maintainer > >>>>>>>> merges stuff without checking for violations of this policy. > >>>>>>>> Dave, any thoughts on the subject? > >>>>>>> > >>>>>>> Yeah I'm happy to block merging stuff, if we can spot new > >>>>>>> properties when stuff is posted on dri-devel, so much the better, > >>>>>>> > >>>>>>> most drivers still send everything via dri-devel anyways, its only > >>>>>>> really Intel I have to worry about so far, > >>>>>> > >>>>>> I'll enforce that all prop stuff gets cc: dri-devel and that it has > >>>>>> updates for the prop docs. > >>>>>> > >>>>>>> But we should definitely add it to the new driver review checklist > >>>>>>> as well. > >>>>>>> > >>>>>>> I'm also on the side of this patch is ugly and makes my eyes burn, > >>>>>>> please please get a plan to use something else ASAP, I'm willing > >>>>>>> to merge this but I'm tempted to give it a lifetime of a kernel or > >>>>>>> two before I burn it. > >>>>>> > >>>>>> Ok, I'll try to move "make kerneldoc suck less" up the task list > >>>>>> and maybe find someone to do it for me internally ;-) > >>>>> > >>>>> I certainly have no objections to making kerneldoc suck less. > >>>>> There was already an attempt to use asciidoc (like git uses) for > >>>>> kernel-doc (a few years ago, by Sam Ravnborg). I support(ed) that > >>>>> effort. > >>>> > >>>> Hm, do you have pointers to those? My google-fu seems lacking ... > >>> > >>> I googled for /kernel doc asciidoc ravnborg/ and found several hits > >>> for them. > >>> > >>>> Ok, let's move this to the top and start discussions. The past few > >>>> months I've written piles of kerneldoc comments for the DRM DocBook > >>>> (all pulled in as kerneldoc, docbook .tmpl has just the chapter > >>>> structure). DOC: sections are really useful to pull all the actual > >>>> documentation out of the docbook xml into kerneldoc. > >>>> > >>>> But I've also done piles of docs for intel-gpu-tools, which is using > >>>> gtkdoc. And there are some clear deficiencies: > >>>> > >>>> - No markdown for inline coments. Lack of lists and tables is hurting > >>>> especially badly. If we add this (and I don't care one iota whether > >>>> it's > >>> > >>> Yes, I've tried to add lists to kernel-doc notation but have failed so > >>> far. > >>> > >>>> markdown or asciidoc or something else as long as it's readable > >>>> plain text in comments) we should be able to move all the existing > >>>> docbook xml paragraphs/lists/tables into kerneldoc comments. > >>>> > >>>> - Automatic cross-referencing of functions. If you place e.g. > >>>> function() or #struct anywhere in a documentation comment gtk-doc > >>>> automatically inserts a hyperlink to the relevant documentation > >>>> page across the entire project. Really powerful and makes overview > >>>> sections much more useful entry points for beginners since they can > >>>> easily jump back&forth betweeen the high-level overview and low- > >>>> level per-function documentation. > >>> > >>> That's a nice-to-have IMO, but a really nice one. > >>> > >>>> - In a really perfect world it would help if kerneldoc could collect > >>>> structure member kerneldoc from per-member comments. Especially for > >>>> large structures with lots of comments this would bring the > >>>> kerneldoc and struct member much closer together. > >>>> > >>>> So that's my wishlist. > >>>> > >>>>> OTOH, I would only want to add another way to do kernel-doc if it > >>>>> can be a full replacement for all of our docbook usage, i.e., it > >>>>> should provide a way that we can eliminate docbook and stop using it > >>>>> completely. > >>>> > >>>> Hm, I don't mind docbook at all, as long as all the real content is > >>>> embedded into source files as kerneldoc and the docbook template just > >>>> pulls in all the right bits and pieces. Even gtkdoc allos you to do > >>>> that and pull in the different libararies (== header files with > >>>> declarations for C) in the order you want. So imo the docbook > >>>> toolchain is good enough for my needs. > >>>> > >>>> Or what do you mean by getting rid of all docbook usage? > >>> > >>> I meant no docbook style sheets, no 'xmlto', the whole ball of wax. > >>> > >>> But primarily I don't want to see drivers/video/ using one set of doc > >>> tools and drivers/media/ using another set and drivers/xyz/ using its > >>> own set of tools, etc. etc. etc. > >> > >> Hi Daniel and others, > >> > >> I don't know what your plans are for drm docs (tables, etc.), but I > >> think that I misspoke above. My primary/major concern is that there be > >> some useful documentation. What form or format it is in is secondary. > > > > I agree with you, there's no reason to block your patch just because we > > might get a better documentation tool at a still unknown point in the > > future. Daniel, are you fine with merging the documentation in DocBook > > format for now ? > > It was already merged ... Sorry, my bad, I should have checked that. And the patch doesn't originate from Randy, double screw-up... *sigh* sorry for the noise. > My mail was really just to make people aware of what I'd like to have (and > what I'll try to get) so that could coordinate (if other people also work on > this). -- Regards, Laurent Pinchart
Owner Module/DriversGroupProperty ObjectProperty NameTypeProperty ValuesObject attachedDescription