* Re: [PATCH v2 1/1] Documentation: drm: describing drm properties exposed by various drivers [not found] ` <1394090125-30029-1-git-send-email-sagar.a.kamble@intel.com> @ 2014-03-06 12:09 ` Ville Syrjälä 2014-03-06 14:01 ` Sagar Arun Kamble 0 siblings, 1 reply; 22+ messages in thread From: Ville Syrjälä @ 2014-03-06 12:09 UTC (permalink / raw) To: sagar.a.kamble Cc: intel-gfx, Rob Landley, Dave Airlie, Daniel Vetter, Laurent Pinchart, David Herrmann, Alex Deucher, Purushothaman, Vijay A, linux-doc, dri-devel On Thu, Mar 06, 2014 at 12:45:25PM +0530, sagar.a.kamble@intel.com wrote: > From: Sagar Kamble <sagar.a.kamble@intel.com> > > Started documenting drm properties for drm drivers. This patch provides > information about properties in drm, i915, psb and cdv/gma-500. Information > about other properties can be added on top of these. > > 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. > > Cc: Rob Landley <rob@landley.net> > Cc: Dave Airlie <airlied@redhat.com> > Cc: Daniel Vetter <daniel.vetter@ffwll.ch> > Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> > Cc: David Herrmann <dh.herrmann@gmail.com> > Cc: Alex Deucher <alexander.deucher@amd.com> > Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com> > Cc: Sagar Kamble <sagar.a.kamble@intel.com> > Cc: "Purushothaman, Vijay A" <vijay.a.purushothaman@intel.com> > Cc: linux-doc@vger.kernel.org > > Signed-off-by: Sagar Kamble <sagar.a.kamble@intel.com> > --- > Documentation/DocBook/drm.tmpl | 1163 ++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 1163 insertions(+) > > diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.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 created property > and an initial instance value. > </para> > + <para> > + Following table gives description of drm properties exposed by various > + modules/drivers. > + </para> > +<table border="1" cellpadding="0" cellspacing="0" > > +<tbody> > +<tr style="font-weight: bold;" > > +<td valign="top" >Owner Module/Drivers</td> > +<td valign="top" >Group</td> > +<td valign="top" >Property Object</td> > +<td valign="top" >Property Name</td> > +<td valign="top" >Type</td> > +<td valign="top" >Property Values</td> > +<td valign="top" >Object attached</td> > +<td valign="top" >Description/Restrictions</td> > +</tr> > + > +<tr> > +<td rowspan="19" valign="top" >DRM</td> > +<td rowspan="2" valign="top" >Generic Properties</td> > +<td valign="top" >edid_property</td> > +<td valign="top" >“EDID”</td> > +<td valign="top" >DRM_MODE_PROP_BLOB | DRM_MODE_PROP_IMMUTABLE</td> > +<td valign="top" >0</td> > +<td valign="top" >Connector</td> > +<td valign="top" >Contains id of edid blob ptr object.</td> > +</tr> > + > +<tr> > +<td valign="top" >dpms_property</td> > +<td valign="top" >“DPMS”</td> > +<td valign="top" >DRM_MODE_PROP_ENUM</td> > +<td valign="top" >{ DRM_MODE_DPMS_ON, “On”}, > +{ DRM_MODE_DPMS_STANDBY, “Standby”}, > +{ DRM_MODE_DPMS_SUSPEND, “Suspend”}, > +{ DRM_MODE_DPMS_OFF, “Off”}</td> > +<td valign="top" >Connector</td> > +<td valign="top" >Contains DPMS operation mode value.</td> > +</tr> > + > +<tr> > +<td rowspan="2" valign="top" >DVI-I Properties</td> > +<td valign="top" >dvi_i_subconnector_property</td> > +<td valign="top" >“subconnector”</td> > +<td valign="top" >DRM_MODE_PROP_ENUM</td> > +<td valign="top" >{ DRM_MODE_SUBCONNECTOR_Unknown, “Unknown”}, > +{ DRM_MODE_SUBCONNECTOR_DVID, “DVI-D”}, > +{ DRM_MODE_SUBCONNECTOR_DVIA, “DVI-A”}</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >dvi_i_select_subconnector_property</td> > +<td valign="top" >“select subconnector”</td> > +<td valign="top" >DRM_MODE_PROP_ENUM</td> > +<td valign="top" >{ DRM_MODE_SUBCONNECTOR_Automatic, “Automatic”}, > +{ DRM_MODE_SUBCONNECTOR_DVID, “DVI-D”}, > +{ DRM_MODE_SUBCONNECTOR_DVIA, “DVI-A”}</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td rowspan="13" valign="top" >TV Properties</td> > +<td valign="top" >tv_subconnector_property</td> > +<td valign="top" >“subconnector”</td> > +<td valign="top" >DRM_MODE_PROP_ENUM</td> > +<td valign="top" >{ 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"}</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >tv_select_subconnector_property</td> > +<td valign="top" >“select subconnector”</td> > +<td valign="top" >DRM_MODE_PROP_ENUM</td> > +<td valign="top" >{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"}</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >tv_mode_property</td> > +<td valign="top" >“mode”</td> > +<td valign="top" >DRM_MODE_PROP_ENUM</td> > +<td valign="top" >{0, "NTSC_M"} , {1, "NTSC_J"} , > +{2, "NTSC_443"}, {3, "PAL_B"} etc.</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >tv_left_margin_property</td> > +<td valign="top" >“left margin”</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max=100</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >tv_right_margin_property</td> > +<td valign="top" >“right margin”</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max=100</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >tv_top_margin_property</td> > +<td valign="top" >“top margin”</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max=100</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >tv_bottom_margin_property</td> > +<td valign="top" >“bottom margin”</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max=100</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >tv_brightness_property</td> > +<td valign="top" >“brightness”</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max=100</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >tv_contrast_property</td> > +<td valign="top" >“contrast”</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max=100</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >tv_flicker_reduction_property</td> > +<td valign="top" >“flicker reduction”</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max=100</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >tv_overscan_property</td> > +<td valign="top" >“overscan”</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max=100</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >tv_saturation_property</td> > +<td valign="top" >“saturation”</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max=100</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >tv_hue_property</td> > +<td valign="top" >“hue”</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max=100</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td rowspan="2" valign="top" >Optional Properties</td> > +<td valign="top" >scaling_mode_property</td> > +<td valign="top" >“scaling mode”</td> > +<td valign="top" >DRM_MODE_PROP_ENUM</td> > +<td valign="top" >{ DRM_MODE_SCALE_NONE, "None" }, > +{ DRM_MODE_SCALE_FULLSCREEN, "Full" }, > +{ DRM_MODE_SCALE_CENTER, "Center" }, > +{ DRM_MODE_SCALE_ASPECT, "Full aspect" }</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >dirty_info_property</td> > +<td valign="top" >“dirty”</td> > +<td valign="top" >DRM_MODE_PROP_ENUM | DRM_MODE_PROP_IMMUTABLE</td> > +<td valign="top" >{ DRM_MODE_DIRTY_OFF, "Off" }, > +{ DRM_MODE_DIRTY_ON, "On" }, > +{ DRM_MODE_DIRTY_ANNOTATE, "Annotate" }</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td rowspan="21" valign="top">i915</td> > +<td rowspan="3" valign="top">Generic</td> > +<td valign="top" >broadcast_rgb_property</td> > +<td valign="top" >"Broadcast RGB"</td> > +<td valign="top" >DRM_MODE_PROP_ENUM</td> > +<td valign="top" >{ INTEL_BROADCAST_RGB_AUTO, "Automatic" }, > +{ INTEL_BROADCAST_RGB_FULL, "Full" }, > +{ INTEL_BROADCAST_RGB_LIMITED, "Limited 16:235" }</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >force_audio_property</td> > +<td valign="top" >“audio”</td> > +<td valign="top" >DRM_MODE_PROP_ENUM</td> > +<td valign="top" >{ HDMI_AUDIO_OFF_DVI, "force-dvi" }, > +{ HDMI_AUDIO_OFF, "off" }, > +{ HDMI_AUDIO_AUTO, "auto" }, > +{ HDMI_AUDIO_ON, "on" }</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >scaling_mode_property > + > +</td> > +<td valign="top" >Standard name as in DRM</td> > +<td valign="top" >Standard type as in DRM</td> > +<td valign="top" >Standard value as in DRM</td> > +<td valign="top" >Standard Object as in DRM</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td rowspan="17" valign="top">SDVO-TV</td> > +<td valign="top" >tv_format</td> > +<td valign="top" >“mode”</td> > +<td valign="top" >DRM_MODE_PROP_ENUM</td> > +<td valign="top" >{0, "NTSC_M"} , {1, "NTSC_J"} , > +{2, "NTSC_443"}, {3, "PAL_B"} etc.</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >left</td> > +<td valign="top" >"left_margin"</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max= SDVO dependent</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >right</td> > +<td valign="top" >"right_margin"</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max= SDVO dependent</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >top</td> > +<td valign="top" >"top_margin"</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max= SDVO dependent</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >bottom</td> > +<td valign="top" >"bottom_margin"</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max= SDVO dependent</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >hpos</td> > +<td valign="top" >“hpos”</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max= SDVO dependent</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >vpos</td> > +<td valign="top" >“vpos”</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max= SDVO dependent</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >contrast</td> > +<td valign="top" >“contrast”</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max= SDVO dependent</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >saturation</td> > +<td valign="top" >“saturation”</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max= SDVO dependent</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >hue</td> > +<td valign="top" >“hue”</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max= SDVO dependent</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >sharpness</td> > +<td valign="top" >“sharpness”</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max= SDVO dependent</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >flicker_filter</td> > +<td valign="top" >“flicker_filter”</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max= SDVO dependent</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >flicker_filter_adaptive</td> > +<td valign="top" >“flicker_filter_adaptive”</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max= SDVO dependent</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >flicker_filter_2d</td> > +<td valign="top" >“flicker_filter_2d”</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max= SDVO dependent</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >tv_chroma_filter</td> > +<td valign="top" >“tv_chroma_filter”</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max= SDVO dependent</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >tv_luma_filter</td> > +<td valign="top" >“tv_luma_filter”</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max= SDVO dependent</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >dot_crawl</td> > +<td valign="top" >“dot_crawl”</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max=1</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top">SDVO-TV/LVDS</td> > +<td valign="top" >brightness</td> > +<td valign="top" >“brightness”</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max= SDVO dependent</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td rowspan="3" valign="top">CDV gma-500</td> > +<td rowspan="3" valign="top">Generic</td> > +<td valign="top" >broadcast_rgb_property</td> > +<td valign="top" >"Broadcast RGB"</td> > +<td valign="top" >DRM_MODE_PROP_ENUM</td> > +<td valign="top" >{ 0, “Full”}, > +{ 1, “Limited 16:235”}</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >force_audio_property</td> > +<td valign="top" >"Broadcast RGB"</td> > +<td valign="top" >DRM_MODE_PROP_ENUM</td> > +<td valign="top" >{ -1, “off”}, > +{ 0, “auto”}, > +{ 1, “on”}</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >scaling_mode_property > + > +</td> > +<td valign="top" >Standard name as in DRM</td> > +<td valign="top" >Standard type as in DRM</td> > +<td valign="top" >Standard value as in DRM</td> > +<td valign="top" >Standard Object as in DRM</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td rowspan="20" valign="top">Poulsbo</td> > +<td rowspan="2" valign="top">Generic</td> > +<td valign="top" >backlight_property</td> > +<td valign="top" >“backlight”</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max=100</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >scaling_mode_property > + > +</td> > +<td valign="top" >Standard name as in DRM</td> > +<td valign="top" >Standard type as in DRM</td> > +<td valign="top" >Standard value as in DRM</td> > +<td valign="top" >Standard Object as in DRM</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td rowspan="17" valign="top">SDVO-TV</td> > +<td valign="top" >tv_format</td> > +<td valign="top" >“mode”</td> > +<td valign="top" >DRM_MODE_PROP_ENUM</td> > +<td valign="top" >{0, "NTSC_M"} , {1, "NTSC_J"} , > + > +{2, "NTSC_443"}, {3, "PAL_B"} etc.</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >left</td> > +<td valign="top" >"left_margin"</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max= SDVO dependent</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >right</td> > +<td valign="top" >"right_margin"</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max= SDVO dependent</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >top</td> > +<td valign="top" >"top_margin"</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max= SDVO dependent</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >bottom</td> > +<td valign="top" >"bottom_margin"</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max= SDVO dependent</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >hpos</td> > +<td valign="top" >“hpos”</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max= SDVO dependent</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >vpos</td> > +<td valign="top" >“vpos”</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max= SDVO dependent</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >contrast</td> > +<td valign="top" >“contrast”</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max= SDVO dependent</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >saturation</td> > +<td valign="top" >“saturation”</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max= SDVO dependent</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >hue</td> > +<td valign="top" >“hue”</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max= SDVO dependent</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >sharpness</td> > +<td valign="top" >“sharpness”</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max= SDVO dependent</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >flicker_filter</td> > +<td valign="top" >“flicker_filter”</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max= SDVO dependent</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >flicker_filter_adaptive</td> > +<td valign="top" >“flicker_filter_adaptive”</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max= SDVO dependent</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >flicker_filter_2d</td> > +<td valign="top" >“flicker_filter_2d”</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max= SDVO dependent</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >tv_chroma_filter</td> > +<td valign="top" >“tv_chroma_filter”</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max= SDVO dependent</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >tv_luma_filter</td> > +<td valign="top" >“tv_luma_filter”</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max= SDVO dependent</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >dot_crawl</td> > +<td valign="top" >“dot_crawl”</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max=1</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top">SDVO-TV/LVDS</td> > +<td valign="top" >brightness</td> > +<td valign="top" >“brightness”</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max= SDVO dependent</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td rowspan="11" valign="top">armada</td> > +<td rowspan="2" valign="top">CRTC</td> > +<td valign="top" >csc_yuv_prop</td> > +<td valign="top" >"CSC_YUV"</td> > +<td valign="top" >DRM_MODE_PROP_ENUM</td> > +<td valign="top" >{ CSC_AUTO, "Auto" }, > +{ CSC_YUV_CCIR601, "CCIR601" }, > +{ CSC_YUV_CCIR709, "CCIR709" }</td> > +<td valign="top" >CRTC</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >csc_rgb_prop</td> > +<td valign="top" >"CSC_RGB"</td> > +<td valign="top" >DRM_MODE_PROP_ENUM</td> > +<td valign="top" >{ CSC_AUTO, "Auto" }, > +{ CSC_RGB_COMPUTER, "Computer system" }, > +{ CSC_RGB_STUDIO, "Studio" }</td> > +<td valign="top" >CRTC</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td rowspan="9" valign="top">Overlay</td> > +<td valign="top" >colorkey_prop</td> > +<td valign="top" >"colorkey"</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max=0xffffff</td> > +<td valign="top" >Plane</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >colorkey_min_prop</td> > +<td valign="top" >"colorkey_min"</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max=0xffffff</td> > +<td valign="top" >Plane</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >colorkey_max_prop</td> > +<td valign="top" >"colorkey_max"</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max=0xffffff</td> > +<td valign="top" >Plane</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >colorkey_val_prop</td> > +<td valign="top" >"colorkey_val"</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max=0xffffff</td> > +<td valign="top" >Plane</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >colorkey_alpha_prop</td> > +<td valign="top" >"colorkey_alpha"</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max=0xffffff</td> > +<td valign="top" >Plane</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >colorkey_mode_prop</td> > +<td valign="top" >"colorkey_mode"</td> > +<td valign="top" >DRM_MODE_PROP_ENUM</td> > +<td valign="top" >{ CKMODE_DISABLE, "disabled" }, > +{ CKMODE_Y, "Y component" }, > +{ CKMODE_U, "U component" }, > +{ CKMODE_V, "V component" }, > +{ CKMODE_RGB, "RGB" }, > +{ CKMODE_R, “R component" }, > +{ CKMODE_G, "G component" }, > +{ CKMODE_B, "B component" }</td> > +<td valign="top" >Plane</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >brightness_prop</td> > +<td valign="top" >"brightness"</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max=256 + 255</td> > +<td valign="top" >Plane</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >contrast_prop</td> > +<td valign="top" >"contrast"</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max=0x7fff</td> > +<td valign="top" >Plane</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >saturation_prop</td> > +<td valign="top" >"saturation"</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max=0x7fff</td> > +<td valign="top" >Plane</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td rowspan="2" valign="top">exynos</td> > +<td valign="top">CRTC</td> > +<td valign="top" >crtc_mode_property</td> > +<td valign="top" >“mode”</td> > +<td valign="top" >DRM_MODE_PROP_ENUM</td> > +<td valign="top" >{ CRTC_MODE_NORMAL, "normal" }, > +{ CRTC_MODE_BLANK, "blank" }</td> > +<td valign="top" >CRTC</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top">Overlay</td> > +<td valign="top" >plane_zpos_property</td> > +<td valign="top" >“zpos”</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max=MAX_PLANE-1</td> > +<td valign="top" >Plane</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td rowspan="3" valign="top">i2c/ch7006_drv</td> > +<td valign="top">Generic</td> > +<td valign="top" >scale_property</td> > +<td valign="top" >“scale”</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max=2</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td rowspan="2" valign="top">TV-Properties</td> > +<td valign="top" >left, > +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,</td> > +<td valign="top" >Standard names as in DRM</td> > +<td valign="top" >Standard types as in DRM</td> > +<td valign="top" >Standard Values as in DRM</td> > +<td valign="top" >Standard object as in DRM</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >tv_format</td> > +<td valign="top" >“mode”</td> > +<td valign="top" >DRM_MODE_PROP_ENUM</td> > +<td valign="top" >{0, "PAL"}, {1, "PAL-M"}, {2,"PAL-N"}, > +{2,”PAL-Nc"}, {3, "PAL-60"}, {4, "NTSC-M"}, > +{5,"NTSC-J"}</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td rowspan="16" valign="top">noveau</td> > +<td rowspan="6" valign="top">NV10 Overlay</td> > +<td valign="top" >colorkey</td> > +<td valign="top" >"colorkey"</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max=0x01ffffff</td> > +<td valign="top" >Plane</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >contrast</td> > +<td valign="top" >“contrast”</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max=8192-1</td> > +<td valign="top" >Plane</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >brightness</td> > +<td valign="top" >“brightness”</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max=1024</td> > +<td valign="top" >Plane</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >hue</td> > +<td valign="top" >“hue”</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max=359</td> > +<td valign="top" >Plane</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >saturation</td> > +<td valign="top" >“saturation”</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max=8192-1</td> > +<td valign="top" >Plane</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >iturbt_709</td> > +<td valign="top" >“iturbt_709”</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max=1</td> > +<td valign="top" >Plane</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td rowspan="2" valign="top">Nv04 Overlay</td> > +<td valign="top" >colorkey</td> > +<td valign="top" >“colorkey”</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max=0x01ffffff</td> > +<td valign="top" >Plane</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >brightness</td> > +<td valign="top" >“brightness”</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max=1024</td> > +<td valign="top" >Plane</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td rowspan="7" valign="top">Display</td> > +<td valign="top" >dithering_mode</td> > +<td valign="top" >“dithering mode”</td> > +<td valign="top" >DRM_MODE_PROP_ENUM</td> > +<td valign="top" >Custom values which has gen info as well. > +{ 6, UNDERSCAN_AUTO, "auto" }, > +{ 6, UNDERSCAN_OFF, "off" }, > +{ 6, UNDERSCAN_ON, "on" }</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >dithering_depth</td> > +<td valign="top" >“dithering depth”</td> > +<td valign="top" >DRM_MODE_PROP_ENUM</td> > +<td valign="top" >Custom 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" }</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >underscan_property</td> > +<td valign="top" >“underscan”</td> > +<td valign="top" >DRM_MODE_PROP_ENUM</td> > +<td valign="top" >Custom values which has gen info as well. > +{ 6, DITHERING_DEPTH_AUTO, "auto" }, > +{ 6, DITHERING_DEPTH_6BPC, "6 bpc" }, > +{ 6, DITHERING_DEPTH_8BPC, "8 bpc" }</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >underscan_hborder_property</td> > +<td valign="top" >“underscan hborder”</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max=128</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >underscan_vborder_property</td> > +<td valign="top" >“underscan vborder”</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max=128</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >vibrant_hue_property</td> > +<td valign="top" >“vibrant hue”</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max=180</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >color_vibrance_property</td> > +<td valign="top" >“color vibrance”</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max=200</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top">Generic</td> > +<td valign="top" >scaling_mode_property > + > +</td> > +<td valign="top" >Standard name as in DRM</td> > +<td valign="top" >Standard type as in DRM</td> > +<td valign="top" >Standard value as in DRM</td> > +<td valign="top" >Standard Object as in DRM</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td rowspan="2" valign="top">omap</td> > +<td rowspan="2" valign="top">Generic</td> > +<td valign="top" >rotation_prop</td> > +<td valign="top" >“rotation”</td> > +<td valign="top" >DRM_MODE_PROP_BITMASK</td> > +<td valign="top" >{ 0, "rotate-0" }, > +{ 1, "rotate-90" }, > +{ 2, "rotate-180" }, > +{ 3, "rotate-270" }, > +{ 4, "reflect-x" }, > +{ 5, "reflect-y" }</td> > +<td valign="top" >CRTC, Plane</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >zorder_prop</td> > +<td valign="top" >“zorder”</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max=3</td> > +<td valign="top" >CRTC, Plane</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top">qxl</td> > +<td valign="top">Generic</td> > +<td valign="top" >hotplug_mode_update_property</td> > +<td valign="top" >“hotplug_mode_update"</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max=1</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td rowspan="10" valign="top">radeon</td> > +<td valign="top">DVI-I</td> > +<td valign="top" >coherent_mode_property</td> > +<td valign="top" >“coherent”</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max=1</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top">DAC enable load detect</td> > +<td valign="top" >load_detect_property</td> > +<td valign="top" >“load detection”</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max=1</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top">TV Standard</td> > +<td valign="top" >tv_std_property</td> > +<td valign="top" >"tv standard"</td> > +<td valign="top" >DRM_MODE_PROP_ENUM</td> > +<td valign="top" >{ 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" }</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top">legacy TMDS PLL detect</td> > +<td valign="top" >tmds_pll_property</td> > +<td valign="top" >"tmds_pll"</td> > +<td valign="top" >DRM_MODE_PROP_ENUM</td> > +<td valign="top" >{ 0, "driver" }, > +{ 1, "bios" }</td> > +<td valign="top" >-</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td rowspan="3" valign="top">Underscan</td> > +<td valign="top" >underscan_property</td> > +<td valign="top" >"underscan"</td> > +<td valign="top" >DRM_MODE_PROP_ENUM</td> > +<td valign="top" >{ UNDERSCAN_OFF, "off" }, > +{ UNDERSCAN_ON, "on" }, > +{ UNDERSCAN_AUTO, "auto" }</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >underscan_hborder_property</td> > +<td valign="top" >"underscan hborder"</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max=128</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >underscan_vborder_property</td> > +<td valign="top" >"underscan vborder"</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max=128</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top">Audio</td> > +<td valign="top" >audio_property</td> > +<td valign="top" >“audio”</td> > +<td valign="top" >DRM_MODE_PROP_ENUM</td> > +<td valign="top" >{ RADEON_AUDIO_DISABLE, "off" }, > +{ RADEON_AUDIO_ENABLE, "on" }, > +{ RADEON_AUDIO_AUTO, "auto" }</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top">FMT Dithering</td> > +<td valign="top" >dither_property</td> > +<td valign="top" >“dither”</td> > +<td valign="top" >DRM_MODE_PROP_ENUM</td> > +<td valign="top" >{ RADEON_FMT_DITHER_DISABLE, "off" }, > +{ RADEON_FMT_DITHER_ENABLE, "on" }</td> > +<td valign="top" >Connector</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top">Generic</td> > +<td valign="top" >scaling_mode_property > + > +</td> > +<td valign="top" >Standard name as in DRM</td> > +<td valign="top" >Standard type as in DRM</td> > +<td valign="top" >Standard value as in DRM</td> > +<td valign="top" >Standard Object as in DRM</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td rowspan="3" valign="top">rcar-du</td> > +<td rowspan="3" valign="top">Generic</td> > +<td valign="top" >alpha</td> > +<td valign="top" >"alpha"</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max=255</td> > +<td valign="top" >Plane</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >colorkey</td> > +<td valign="top" >"colorkey"</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=0, Max=0x01ffffff</td> > +<td valign="top" >Plane</td> > +<td valign="top" >TBD</td> > +</tr> > + > +<tr> > +<td valign="top" >zpos</td> > +<td valign="top" >"zpos"</td> > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > +<td valign="top" >Min=1, Max=7</td> > +<td valign="top" >Plane</td> > +<td valign="top" >TBD</td> > +</tr> > + > +</tbody> > +</table> > </sect1> > > <!-- Internals: vertical blanking --> > -- > 1.8.5 -- Ville Syrjälä Intel OTC ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v2 1/1] Documentation: drm: describing drm properties exposed by various drivers 2014-03-06 12:09 ` [PATCH v2 1/1] Documentation: drm: describing drm properties exposed by various drivers Ville Syrjälä @ 2014-03-06 14:01 ` Sagar Arun Kamble 2014-03-06 14:41 ` [PATCH v3 " sagar.a.kamble 0 siblings, 1 reply; 22+ messages in thread From: Sagar Arun Kamble @ 2014-03-06 14:01 UTC (permalink / raw) To: Ville Syrjälä Cc: Laurent Pinchart, linux-doc, Daniel Vetter, intel-gfx, dri-devel, Rob Landley, David Herrmann, Alex Deucher, Dave Airlie On Thu, 2014-03-06 at 14:09 +0200, Ville Syrjälä wrote: > On Thu, Mar 06, 2014 at 12:45:25PM +0530, sagar.a.kamble@intel.com wrote: > > From: Sagar Kamble <sagar.a.kamble@intel.com> > > > > Started documenting drm properties for drm drivers. This patch provides > > information about properties in drm, i915, psb and cdv/gma-500. Information > > about other properties can be added on top of these. > > > > 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. Will incorporate these changes. DRM_MODE_PROP prefix is kind of redundant so will remove it. > > 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. Agree with this. > > > > > Cc: Rob Landley <rob@landley.net> > > Cc: Dave Airlie <airlied@redhat.com> > > Cc: Daniel Vetter <daniel.vetter@ffwll.ch> > > Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> > > Cc: David Herrmann <dh.herrmann@gmail.com> > > Cc: Alex Deucher <alexander.deucher@amd.com> > > Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com> > > Cc: Sagar Kamble <sagar.a.kamble@intel.com> > > Cc: "Purushothaman, Vijay A" <vijay.a.purushothaman@intel.com> > > Cc: linux-doc@vger.kernel.org > > > > Signed-off-by: Sagar Kamble <sagar.a.kamble@intel.com> > > --- > > Documentation/DocBook/drm.tmpl | 1163 ++++++++++++++++++++++++++++++++++++++++ > > 1 file changed, 1163 insertions(+) > > > > diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.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 created property > > and an initial instance value. > > </para> > > + <para> > > + Following table gives description of drm properties exposed by various > > + modules/drivers. > > + </para> > > +<table border="1" cellpadding="0" cellspacing="0" > > > +<tbody> > > +<tr style="font-weight: bold;" > > > +<td valign="top" >Owner Module/Drivers</td> > > +<td valign="top" >Group</td> > > +<td valign="top" >Property Object</td> > > +<td valign="top" >Property Name</td> > > +<td valign="top" >Type</td> > > +<td valign="top" >Property Values</td> > > +<td valign="top" >Object attached</td> > > +<td valign="top" >Description/Restrictions</td> > > +</tr> > > + > > +<tr> > > +<td rowspan="19" valign="top" >DRM</td> > > +<td rowspan="2" valign="top" >Generic Properties</td> > > +<td valign="top" >edid_property</td> > > +<td valign="top" >“EDID”</td> > > +<td valign="top" >DRM_MODE_PROP_BLOB | DRM_MODE_PROP_IMMUTABLE</td> > > +<td valign="top" >0</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >Contains id of edid blob ptr object.</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >dpms_property</td> > > +<td valign="top" >“DPMS”</td> > > +<td valign="top" >DRM_MODE_PROP_ENUM</td> > > +<td valign="top" >{ DRM_MODE_DPMS_ON, “On”}, > > +{ DRM_MODE_DPMS_STANDBY, “Standby”}, > > +{ DRM_MODE_DPMS_SUSPEND, “Suspend”}, > > +{ DRM_MODE_DPMS_OFF, “Off”}</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >Contains DPMS operation mode value.</td> > > +</tr> > > + > > +<tr> > > +<td rowspan="2" valign="top" >DVI-I Properties</td> > > +<td valign="top" >dvi_i_subconnector_property</td> > > +<td valign="top" >“subconnector”</td> > > +<td valign="top" >DRM_MODE_PROP_ENUM</td> > > +<td valign="top" >{ DRM_MODE_SUBCONNECTOR_Unknown, “Unknown”}, > > +{ DRM_MODE_SUBCONNECTOR_DVID, “DVI-D”}, > > +{ DRM_MODE_SUBCONNECTOR_DVIA, “DVI-A”}</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >dvi_i_select_subconnector_property</td> > > +<td valign="top" >“select subconnector”</td> > > +<td valign="top" >DRM_MODE_PROP_ENUM</td> > > +<td valign="top" >{ DRM_MODE_SUBCONNECTOR_Automatic, “Automatic”}, > > +{ DRM_MODE_SUBCONNECTOR_DVID, “DVI-D”}, > > +{ DRM_MODE_SUBCONNECTOR_DVIA, “DVI-A”}</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td rowspan="13" valign="top" >TV Properties</td> > > +<td valign="top" >tv_subconnector_property</td> > > +<td valign="top" >“subconnector”</td> > > +<td valign="top" >DRM_MODE_PROP_ENUM</td> > > +<td valign="top" >{ 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"}</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >tv_select_subconnector_property</td> > > +<td valign="top" >“select subconnector”</td> > > +<td valign="top" >DRM_MODE_PROP_ENUM</td> > > +<td valign="top" >{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"}</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >tv_mode_property</td> > > +<td valign="top" >“mode”</td> > > +<td valign="top" >DRM_MODE_PROP_ENUM</td> > > +<td valign="top" >{0, "NTSC_M"} , {1, "NTSC_J"} , > > +{2, "NTSC_443"}, {3, "PAL_B"} etc.</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >tv_left_margin_property</td> > > +<td valign="top" >“left margin”</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max=100</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >tv_right_margin_property</td> > > +<td valign="top" >“right margin”</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max=100</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >tv_top_margin_property</td> > > +<td valign="top" >“top margin”</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max=100</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >tv_bottom_margin_property</td> > > +<td valign="top" >“bottom margin”</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max=100</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >tv_brightness_property</td> > > +<td valign="top" >“brightness”</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max=100</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >tv_contrast_property</td> > > +<td valign="top" >“contrast”</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max=100</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >tv_flicker_reduction_property</td> > > +<td valign="top" >“flicker reduction”</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max=100</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >tv_overscan_property</td> > > +<td valign="top" >“overscan”</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max=100</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >tv_saturation_property</td> > > +<td valign="top" >“saturation”</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max=100</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >tv_hue_property</td> > > +<td valign="top" >“hue”</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max=100</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td rowspan="2" valign="top" >Optional Properties</td> > > +<td valign="top" >scaling_mode_property</td> > > +<td valign="top" >“scaling mode”</td> > > +<td valign="top" >DRM_MODE_PROP_ENUM</td> > > +<td valign="top" >{ DRM_MODE_SCALE_NONE, "None" }, > > +{ DRM_MODE_SCALE_FULLSCREEN, "Full" }, > > +{ DRM_MODE_SCALE_CENTER, "Center" }, > > +{ DRM_MODE_SCALE_ASPECT, "Full aspect" }</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >dirty_info_property</td> > > +<td valign="top" >“dirty”</td> > > +<td valign="top" >DRM_MODE_PROP_ENUM | DRM_MODE_PROP_IMMUTABLE</td> > > +<td valign="top" >{ DRM_MODE_DIRTY_OFF, "Off" }, > > +{ DRM_MODE_DIRTY_ON, "On" }, > > +{ DRM_MODE_DIRTY_ANNOTATE, "Annotate" }</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td rowspan="21" valign="top">i915</td> > > +<td rowspan="3" valign="top">Generic</td> > > +<td valign="top" >broadcast_rgb_property</td> > > +<td valign="top" >"Broadcast RGB"</td> > > +<td valign="top" >DRM_MODE_PROP_ENUM</td> > > +<td valign="top" >{ INTEL_BROADCAST_RGB_AUTO, "Automatic" }, > > +{ INTEL_BROADCAST_RGB_FULL, "Full" }, > > +{ INTEL_BROADCAST_RGB_LIMITED, "Limited 16:235" }</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >force_audio_property</td> > > +<td valign="top" >“audio”</td> > > +<td valign="top" >DRM_MODE_PROP_ENUM</td> > > +<td valign="top" >{ HDMI_AUDIO_OFF_DVI, "force-dvi" }, > > +{ HDMI_AUDIO_OFF, "off" }, > > +{ HDMI_AUDIO_AUTO, "auto" }, > > +{ HDMI_AUDIO_ON, "on" }</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >scaling_mode_property > > + > > +</td> > > +<td valign="top" >Standard name as in DRM</td> > > +<td valign="top" >Standard type as in DRM</td> > > +<td valign="top" >Standard value as in DRM</td> > > +<td valign="top" >Standard Object as in DRM</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td rowspan="17" valign="top">SDVO-TV</td> > > +<td valign="top" >tv_format</td> > > +<td valign="top" >“mode”</td> > > +<td valign="top" >DRM_MODE_PROP_ENUM</td> > > +<td valign="top" >{0, "NTSC_M"} , {1, "NTSC_J"} , > > +{2, "NTSC_443"}, {3, "PAL_B"} etc.</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >left</td> > > +<td valign="top" >"left_margin"</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max= SDVO dependent</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >right</td> > > +<td valign="top" >"right_margin"</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max= SDVO dependent</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >top</td> > > +<td valign="top" >"top_margin"</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max= SDVO dependent</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >bottom</td> > > +<td valign="top" >"bottom_margin"</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max= SDVO dependent</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >hpos</td> > > +<td valign="top" >“hpos”</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max= SDVO dependent</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >vpos</td> > > +<td valign="top" >“vpos”</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max= SDVO dependent</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >contrast</td> > > +<td valign="top" >“contrast”</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max= SDVO dependent</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >saturation</td> > > +<td valign="top" >“saturation”</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max= SDVO dependent</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >hue</td> > > +<td valign="top" >“hue”</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max= SDVO dependent</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >sharpness</td> > > +<td valign="top" >“sharpness”</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max= SDVO dependent</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >flicker_filter</td> > > +<td valign="top" >“flicker_filter”</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max= SDVO dependent</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >flicker_filter_adaptive</td> > > +<td valign="top" >“flicker_filter_adaptive”</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max= SDVO dependent</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >flicker_filter_2d</td> > > +<td valign="top" >“flicker_filter_2d”</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max= SDVO dependent</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >tv_chroma_filter</td> > > +<td valign="top" >“tv_chroma_filter”</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max= SDVO dependent</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >tv_luma_filter</td> > > +<td valign="top" >“tv_luma_filter”</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max= SDVO dependent</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >dot_crawl</td> > > +<td valign="top" >“dot_crawl”</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max=1</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top">SDVO-TV/LVDS</td> > > +<td valign="top" >brightness</td> > > +<td valign="top" >“brightness”</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max= SDVO dependent</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td rowspan="3" valign="top">CDV gma-500</td> > > +<td rowspan="3" valign="top">Generic</td> > > +<td valign="top" >broadcast_rgb_property</td> > > +<td valign="top" >"Broadcast RGB"</td> > > +<td valign="top" >DRM_MODE_PROP_ENUM</td> > > +<td valign="top" >{ 0, “Full”}, > > +{ 1, “Limited 16:235”}</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >force_audio_property</td> > > +<td valign="top" >"Broadcast RGB"</td> > > +<td valign="top" >DRM_MODE_PROP_ENUM</td> > > +<td valign="top" >{ -1, “off”}, > > +{ 0, “auto”}, > > +{ 1, “on”}</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >scaling_mode_property > > + > > +</td> > > +<td valign="top" >Standard name as in DRM</td> > > +<td valign="top" >Standard type as in DRM</td> > > +<td valign="top" >Standard value as in DRM</td> > > +<td valign="top" >Standard Object as in DRM</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td rowspan="20" valign="top">Poulsbo</td> > > +<td rowspan="2" valign="top">Generic</td> > > +<td valign="top" >backlight_property</td> > > +<td valign="top" >“backlight”</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max=100</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >scaling_mode_property > > + > > +</td> > > +<td valign="top" >Standard name as in DRM</td> > > +<td valign="top" >Standard type as in DRM</td> > > +<td valign="top" >Standard value as in DRM</td> > > +<td valign="top" >Standard Object as in DRM</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td rowspan="17" valign="top">SDVO-TV</td> > > +<td valign="top" >tv_format</td> > > +<td valign="top" >“mode”</td> > > +<td valign="top" >DRM_MODE_PROP_ENUM</td> > > +<td valign="top" >{0, "NTSC_M"} , {1, "NTSC_J"} , > > + > > +{2, "NTSC_443"}, {3, "PAL_B"} etc.</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >left</td> > > +<td valign="top" >"left_margin"</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max= SDVO dependent</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >right</td> > > +<td valign="top" >"right_margin"</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max= SDVO dependent</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >top</td> > > +<td valign="top" >"top_margin"</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max= SDVO dependent</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >bottom</td> > > +<td valign="top" >"bottom_margin"</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max= SDVO dependent</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >hpos</td> > > +<td valign="top" >“hpos”</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max= SDVO dependent</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >vpos</td> > > +<td valign="top" >“vpos”</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max= SDVO dependent</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >contrast</td> > > +<td valign="top" >“contrast”</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max= SDVO dependent</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >saturation</td> > > +<td valign="top" >“saturation”</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max= SDVO dependent</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >hue</td> > > +<td valign="top" >“hue”</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max= SDVO dependent</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >sharpness</td> > > +<td valign="top" >“sharpness”</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max= SDVO dependent</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >flicker_filter</td> > > +<td valign="top" >“flicker_filter”</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max= SDVO dependent</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >flicker_filter_adaptive</td> > > +<td valign="top" >“flicker_filter_adaptive”</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max= SDVO dependent</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >flicker_filter_2d</td> > > +<td valign="top" >“flicker_filter_2d”</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max= SDVO dependent</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >tv_chroma_filter</td> > > +<td valign="top" >“tv_chroma_filter”</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max= SDVO dependent</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >tv_luma_filter</td> > > +<td valign="top" >“tv_luma_filter”</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max= SDVO dependent</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >dot_crawl</td> > > +<td valign="top" >“dot_crawl”</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max=1</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top">SDVO-TV/LVDS</td> > > +<td valign="top" >brightness</td> > > +<td valign="top" >“brightness”</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max= SDVO dependent</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td rowspan="11" valign="top">armada</td> > > +<td rowspan="2" valign="top">CRTC</td> > > +<td valign="top" >csc_yuv_prop</td> > > +<td valign="top" >"CSC_YUV"</td> > > +<td valign="top" >DRM_MODE_PROP_ENUM</td> > > +<td valign="top" >{ CSC_AUTO, "Auto" }, > > +{ CSC_YUV_CCIR601, "CCIR601" }, > > +{ CSC_YUV_CCIR709, "CCIR709" }</td> > > +<td valign="top" >CRTC</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >csc_rgb_prop</td> > > +<td valign="top" >"CSC_RGB"</td> > > +<td valign="top" >DRM_MODE_PROP_ENUM</td> > > +<td valign="top" >{ CSC_AUTO, "Auto" }, > > +{ CSC_RGB_COMPUTER, "Computer system" }, > > +{ CSC_RGB_STUDIO, "Studio" }</td> > > +<td valign="top" >CRTC</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td rowspan="9" valign="top">Overlay</td> > > +<td valign="top" >colorkey_prop</td> > > +<td valign="top" >"colorkey"</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max=0xffffff</td> > > +<td valign="top" >Plane</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >colorkey_min_prop</td> > > +<td valign="top" >"colorkey_min"</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max=0xffffff</td> > > +<td valign="top" >Plane</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >colorkey_max_prop</td> > > +<td valign="top" >"colorkey_max"</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max=0xffffff</td> > > +<td valign="top" >Plane</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >colorkey_val_prop</td> > > +<td valign="top" >"colorkey_val"</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max=0xffffff</td> > > +<td valign="top" >Plane</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >colorkey_alpha_prop</td> > > +<td valign="top" >"colorkey_alpha"</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max=0xffffff</td> > > +<td valign="top" >Plane</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >colorkey_mode_prop</td> > > +<td valign="top" >"colorkey_mode"</td> > > +<td valign="top" >DRM_MODE_PROP_ENUM</td> > > +<td valign="top" >{ CKMODE_DISABLE, "disabled" }, > > +{ CKMODE_Y, "Y component" }, > > +{ CKMODE_U, "U component" }, > > +{ CKMODE_V, "V component" }, > > +{ CKMODE_RGB, "RGB" }, > > +{ CKMODE_R, “R component" }, > > +{ CKMODE_G, "G component" }, > > +{ CKMODE_B, "B component" }</td> > > +<td valign="top" >Plane</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >brightness_prop</td> > > +<td valign="top" >"brightness"</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max=256 + 255</td> > > +<td valign="top" >Plane</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >contrast_prop</td> > > +<td valign="top" >"contrast"</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max=0x7fff</td> > > +<td valign="top" >Plane</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >saturation_prop</td> > > +<td valign="top" >"saturation"</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max=0x7fff</td> > > +<td valign="top" >Plane</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td rowspan="2" valign="top">exynos</td> > > +<td valign="top">CRTC</td> > > +<td valign="top" >crtc_mode_property</td> > > +<td valign="top" >“mode”</td> > > +<td valign="top" >DRM_MODE_PROP_ENUM</td> > > +<td valign="top" >{ CRTC_MODE_NORMAL, "normal" }, > > +{ CRTC_MODE_BLANK, "blank" }</td> > > +<td valign="top" >CRTC</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top">Overlay</td> > > +<td valign="top" >plane_zpos_property</td> > > +<td valign="top" >“zpos”</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max=MAX_PLANE-1</td> > > +<td valign="top" >Plane</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td rowspan="3" valign="top">i2c/ch7006_drv</td> > > +<td valign="top">Generic</td> > > +<td valign="top" >scale_property</td> > > +<td valign="top" >“scale”</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max=2</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td rowspan="2" valign="top">TV-Properties</td> > > +<td valign="top" >left, > > +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,</td> > > +<td valign="top" >Standard names as in DRM</td> > > +<td valign="top" >Standard types as in DRM</td> > > +<td valign="top" >Standard Values as in DRM</td> > > +<td valign="top" >Standard object as in DRM</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >tv_format</td> > > +<td valign="top" >“mode”</td> > > +<td valign="top" >DRM_MODE_PROP_ENUM</td> > > +<td valign="top" >{0, "PAL"}, {1, "PAL-M"}, {2,"PAL-N"}, > > +{2,”PAL-Nc"}, {3, "PAL-60"}, {4, "NTSC-M"}, > > +{5,"NTSC-J"}</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td rowspan="16" valign="top">noveau</td> > > +<td rowspan="6" valign="top">NV10 Overlay</td> > > +<td valign="top" >colorkey</td> > > +<td valign="top" >"colorkey"</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max=0x01ffffff</td> > > +<td valign="top" >Plane</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >contrast</td> > > +<td valign="top" >“contrast”</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max=8192-1</td> > > +<td valign="top" >Plane</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >brightness</td> > > +<td valign="top" >“brightness”</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max=1024</td> > > +<td valign="top" >Plane</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >hue</td> > > +<td valign="top" >“hue”</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max=359</td> > > +<td valign="top" >Plane</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >saturation</td> > > +<td valign="top" >“saturation”</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max=8192-1</td> > > +<td valign="top" >Plane</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >iturbt_709</td> > > +<td valign="top" >“iturbt_709”</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max=1</td> > > +<td valign="top" >Plane</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td rowspan="2" valign="top">Nv04 Overlay</td> > > +<td valign="top" >colorkey</td> > > +<td valign="top" >“colorkey”</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max=0x01ffffff</td> > > +<td valign="top" >Plane</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >brightness</td> > > +<td valign="top" >“brightness”</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max=1024</td> > > +<td valign="top" >Plane</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td rowspan="7" valign="top">Display</td> > > +<td valign="top" >dithering_mode</td> > > +<td valign="top" >“dithering mode”</td> > > +<td valign="top" >DRM_MODE_PROP_ENUM</td> > > +<td valign="top" >Custom values which has gen info as well. > > +{ 6, UNDERSCAN_AUTO, "auto" }, > > +{ 6, UNDERSCAN_OFF, "off" }, > > +{ 6, UNDERSCAN_ON, "on" }</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >dithering_depth</td> > > +<td valign="top" >“dithering depth”</td> > > +<td valign="top" >DRM_MODE_PROP_ENUM</td> > > +<td valign="top" >Custom 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" }</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >underscan_property</td> > > +<td valign="top" >“underscan”</td> > > +<td valign="top" >DRM_MODE_PROP_ENUM</td> > > +<td valign="top" >Custom values which has gen info as well. > > +{ 6, DITHERING_DEPTH_AUTO, "auto" }, > > +{ 6, DITHERING_DEPTH_6BPC, "6 bpc" }, > > +{ 6, DITHERING_DEPTH_8BPC, "8 bpc" }</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >underscan_hborder_property</td> > > +<td valign="top" >“underscan hborder”</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max=128</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >underscan_vborder_property</td> > > +<td valign="top" >“underscan vborder”</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max=128</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >vibrant_hue_property</td> > > +<td valign="top" >“vibrant hue”</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max=180</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >color_vibrance_property</td> > > +<td valign="top" >“color vibrance”</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max=200</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top">Generic</td> > > +<td valign="top" >scaling_mode_property > > + > > +</td> > > +<td valign="top" >Standard name as in DRM</td> > > +<td valign="top" >Standard type as in DRM</td> > > +<td valign="top" >Standard value as in DRM</td> > > +<td valign="top" >Standard Object as in DRM</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td rowspan="2" valign="top">omap</td> > > +<td rowspan="2" valign="top">Generic</td> > > +<td valign="top" >rotation_prop</td> > > +<td valign="top" >“rotation”</td> > > +<td valign="top" >DRM_MODE_PROP_BITMASK</td> > > +<td valign="top" >{ 0, "rotate-0" }, > > +{ 1, "rotate-90" }, > > +{ 2, "rotate-180" }, > > +{ 3, "rotate-270" }, > > +{ 4, "reflect-x" }, > > +{ 5, "reflect-y" }</td> > > +<td valign="top" >CRTC, Plane</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >zorder_prop</td> > > +<td valign="top" >“zorder”</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max=3</td> > > +<td valign="top" >CRTC, Plane</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top">qxl</td> > > +<td valign="top">Generic</td> > > +<td valign="top" >hotplug_mode_update_property</td> > > +<td valign="top" >“hotplug_mode_update"</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max=1</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td rowspan="10" valign="top">radeon</td> > > +<td valign="top">DVI-I</td> > > +<td valign="top" >coherent_mode_property</td> > > +<td valign="top" >“coherent”</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max=1</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top">DAC enable load detect</td> > > +<td valign="top" >load_detect_property</td> > > +<td valign="top" >“load detection”</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max=1</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top">TV Standard</td> > > +<td valign="top" >tv_std_property</td> > > +<td valign="top" >"tv standard"</td> > > +<td valign="top" >DRM_MODE_PROP_ENUM</td> > > +<td valign="top" >{ 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" }</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top">legacy TMDS PLL detect</td> > > +<td valign="top" >tmds_pll_property</td> > > +<td valign="top" >"tmds_pll"</td> > > +<td valign="top" >DRM_MODE_PROP_ENUM</td> > > +<td valign="top" >{ 0, "driver" }, > > +{ 1, "bios" }</td> > > +<td valign="top" >-</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td rowspan="3" valign="top">Underscan</td> > > +<td valign="top" >underscan_property</td> > > +<td valign="top" >"underscan"</td> > > +<td valign="top" >DRM_MODE_PROP_ENUM</td> > > +<td valign="top" >{ UNDERSCAN_OFF, "off" }, > > +{ UNDERSCAN_ON, "on" }, > > +{ UNDERSCAN_AUTO, "auto" }</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >underscan_hborder_property</td> > > +<td valign="top" >"underscan hborder"</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max=128</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >underscan_vborder_property</td> > > +<td valign="top" >"underscan vborder"</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max=128</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top">Audio</td> > > +<td valign="top" >audio_property</td> > > +<td valign="top" >“audio”</td> > > +<td valign="top" >DRM_MODE_PROP_ENUM</td> > > +<td valign="top" >{ RADEON_AUDIO_DISABLE, "off" }, > > +{ RADEON_AUDIO_ENABLE, "on" }, > > +{ RADEON_AUDIO_AUTO, "auto" }</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top">FMT Dithering</td> > > +<td valign="top" >dither_property</td> > > +<td valign="top" >“dither”</td> > > +<td valign="top" >DRM_MODE_PROP_ENUM</td> > > +<td valign="top" >{ RADEON_FMT_DITHER_DISABLE, "off" }, > > +{ RADEON_FMT_DITHER_ENABLE, "on" }</td> > > +<td valign="top" >Connector</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top">Generic</td> > > +<td valign="top" >scaling_mode_property > > + > > +</td> > > +<td valign="top" >Standard name as in DRM</td> > > +<td valign="top" >Standard type as in DRM</td> > > +<td valign="top" >Standard value as in DRM</td> > > +<td valign="top" >Standard Object as in DRM</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td rowspan="3" valign="top">rcar-du</td> > > +<td rowspan="3" valign="top">Generic</td> > > +<td valign="top" >alpha</td> > > +<td valign="top" >"alpha"</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max=255</td> > > +<td valign="top" >Plane</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >colorkey</td> > > +<td valign="top" >"colorkey"</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=0, Max=0x01ffffff</td> > > +<td valign="top" >Plane</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +<tr> > > +<td valign="top" >zpos</td> > > +<td valign="top" >"zpos"</td> > > +<td valign="top" >DRM_MODE_PROP_RANGE</td> > > +<td valign="top" >Min=1, Max=7</td> > > +<td valign="top" >Plane</td> > > +<td valign="top" >TBD</td> > > +</tr> > > + > > +</tbody> > > +</table> > > </sect1> > > > > <!-- Internals: vertical blanking --> > > -- > > 1.8.5 > _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH v3 1/1] Documentation: drm: describing drm properties exposed by various drivers 2014-03-06 14:01 ` Sagar Arun Kamble @ 2014-03-06 14:41 ` sagar.a.kamble 0 siblings, 0 replies; 22+ messages in thread From: sagar.a.kamble @ 2014-03-06 14:41 UTC (permalink / raw) To: intel-gfx Cc: Laurent Pinchart, linux-doc, Daniel Vetter, dri-devel, Rob Landley, David Herrmann, Alex Deucher, Dave Airlie, Sagar Kamble From: Sagar Kamble <sagar.a.kamble@intel.com> Started documenting drm properties for drm drivers. This patch provides information about properties in drm, i915, psb and cdv/gma-500. Information about other properties can be added on top of these. v2: Added description of drm properties in armada, exynos, i2c/ch7006, noveau, omap, qxl, radeon, rcar-du v3: Removed "Property Object" column since it is implementation related. Property type column refined.[Ville's review comments] Cc: Rob Landley <rob@landley.net> Cc: Dave Airlie <airlied@redhat.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Cc: David Herrmann <dh.herrmann@gmail.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com> Cc: Sagar Kamble <sagar.a.kamble@intel.com> Cc: "Purushothaman, Vijay A" <vijay.a.purushothaman@intel.com> Cc: linux-doc@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Sagar Kamble <sagar.a.kamble@intel.com> --- Documentation/DocBook/drm.tmpl | 1025 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1025 insertions(+) diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index ed1d6d2..f38c505 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -2317,6 +2317,1031 @@ void intel_crt_init(struct drm_device *dev) pointer to the target object, a pointer to the previously created property and an initial instance value. </para> + <para> + Following table gives description of drm properties exposed by various + modules/drivers. + </para> +<table border="1" cellpadding="0" cellspacing="0" > +<tbody> +<tr style="font-weight: bold;"> +<td valign="top" >Owner Module/Drivers</td> +<td valign="top" >Group</td> +<td valign="top" >Property Name</td> +<td valign="top" >Type</td> +<td valign="top" >Property Values</td> +<td valign="top" >Object attached</td> +<td valign="top" >Description/Restrictions</td> +</tr> + +<tr> +<td rowspan="19" valign="top" >DRM</td> +<td rowspan="2" valign="top" >Generic</td> +<td valign="top" >“EDID”</td> +<td valign="top" >BLOB | IMMUTABLE</td> +<td valign="top" >0</td> +<td valign="top" >Connector</td> +<td valign="top" >Contains id of edid blob ptr object.</td> +</tr> + +<tr> +<td valign="top" >“DPMS”</td> +<td valign="top" >ENUM</td> +<td valign="top" >{ DRM_MODE_DPMS_ON, “On”}, +{ DRM_MODE_DPMS_STANDBY, “Standby”}, +{ DRM_MODE_DPMS_SUSPEND, “Suspend”}, +{ DRM_MODE_DPMS_OFF, “Off”}</td> +<td valign="top" >Connector</td> +<td valign="top" >Contains DPMS operation mode value.</td> +</tr> + +<tr> +<td rowspan="2" valign="top" >DVI-I</td> +<td valign="top" >“subconnector”</td> +<td valign="top" >ENUM</td> +<td valign="top" >{ DRM_MODE_SUBCONNECTOR_Unknown, “Unknown”}, +{ DRM_MODE_SUBCONNECTOR_DVID, “DVI-D”}, +{ DRM_MODE_SUBCONNECTOR_DVIA, “DVI-A”}</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >“select subconnector”</td> +<td valign="top" >ENUM</td> +<td valign="top" >{ DRM_MODE_SUBCONNECTOR_Automatic, “Automatic”}, +{ DRM_MODE_SUBCONNECTOR_DVID, “DVI-D”}, +{ DRM_MODE_SUBCONNECTOR_DVIA, “DVI-A”}</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td rowspan="13" valign="top" >TV</td> +<td valign="top" >“subconnector”</td> +<td valign="top" >ENUM</td> +<td valign="top" >{ 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"}</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >“select subconnector”</td> +<td valign="top" >ENUM</td> +<td valign="top" >{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"}</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >“mode”</td> +<td valign="top" >ENUM</td> +<td valign="top" >{0, "NTSC_M"} , {1, "NTSC_J"} , +{2, "NTSC_443"}, {3, "PAL_B"} etc.</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >“left margin”</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max=100</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >“right margin”</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max=100</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >“top margin”</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max=100</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >“bottom margin”</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max=100</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >“brightness”</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max=100</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >“contrast”</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max=100</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >“flicker reduction”</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max=100</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >“overscan”</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max=100</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >“saturation”</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max=100</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >“hue”</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max=100</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td rowspan="2" valign="top" >Optional</td> +<td valign="top" >“scaling mode”</td> +<td valign="top" >ENUM</td> +<td valign="top" >{ DRM_MODE_SCALE_NONE, "None" }, +{ DRM_MODE_SCALE_FULLSCREEN, "Full" }, +{ DRM_MODE_SCALE_CENTER, "Center" }, +{ DRM_MODE_SCALE_ASPECT, "Full aspect" }</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >“dirty”</td> +<td valign="top" >ENUM | IMMUTABLE</td> +<td valign="top" >{ DRM_MODE_DIRTY_OFF, "Off" }, +{ DRM_MODE_DIRTY_ON, "On" }, +{ DRM_MODE_DIRTY_ANNOTATE, "Annotate" }</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td rowspan="21" valign="top" >i915</td> +<td rowspan="3" valign="top" >Generic</td> +<td valign="top" >"Broadcast RGB"</td> +<td valign="top" >ENUM</td> +<td valign="top" >{ INTEL_BROADCAST_RGB_AUTO, "Automatic" }, +{ INTEL_BROADCAST_RGB_FULL, "Full" }, +{ INTEL_BROADCAST_RGB_LIMITED, "Limited 16:235" }</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >“audio”</td> +<td valign="top" >ENUM</td> +<td valign="top" >{ HDMI_AUDIO_OFF_DVI, "force-dvi" }, +{ HDMI_AUDIO_OFF, "off" }, +{ HDMI_AUDIO_AUTO, "auto" }, +{ HDMI_AUDIO_ON, "on" }</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >Standard name as in DRM</td> +<td valign="top" >Standard type as in DRM</td> +<td valign="top" >Standard value as in DRM</td> +<td valign="top" >Standard Object as in DRM</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td rowspan="17" valign="top" >SDVO-TV</td> +<td valign="top" >“mode”</td> +<td valign="top" >ENUM</td> +<td valign="top" >{0, "NTSC_M"} , {1, "NTSC_J"} , +{2, "NTSC_443"}, {3, "PAL_B"} etc.</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >"left_margin"</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max= SDVO dependent</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >"right_margin"</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max= SDVO dependent</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >"top_margin"</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max= SDVO dependent</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >"bottom_margin"</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max= SDVO dependent</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >“hpos”</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max= SDVO dependent</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >“vpos”</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max= SDVO dependent</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >“contrast”</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max= SDVO dependent</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >“saturation”</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max= SDVO dependent</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >“hue”</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max= SDVO dependent</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >“sharpness”</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max= SDVO dependent</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >“flicker_filter”</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max= SDVO dependent</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >“flicker_filter_adaptive”</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max= SDVO dependent</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >“flicker_filter_2d”</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max= SDVO dependent</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >“tv_chroma_filter”</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max= SDVO dependent</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >“tv_luma_filter”</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max= SDVO dependent</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >“dot_crawl”</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max=1</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >SDVO-TV/LVDS</td> +<td valign="top" >“brightness”</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max= SDVO dependent</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td rowspan="3" valign="top" >CDV gma-500</td> +<td rowspan="3" valign="top" >Generic</td> +<td valign="top" >"Broadcast RGB"</td> +<td valign="top" >ENUM</td> +<td valign="top" >{ 0, “Full”}, +{ 1, “Limited 16:235”}</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >"Broadcast RGB"</td> +<td valign="top" >ENUM</td> +<td valign="top" >{ -1, “off”}, +{ 0, “auto”}, +{ 1, “on”}</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >Standard name as in DRM</td> +<td valign="top" >Standard type as in DRM</td> +<td valign="top" >Standard value as in DRM</td> +<td valign="top" >Standard Object as in DRM</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td rowspan="20" valign="top" >Poulsbo</td> +<td rowspan="2" valign="top" >Generic</td> +<td valign="top" >“backlight”</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max=100</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >Standard name as in DRM</td> +<td valign="top" >Standard type as in DRM</td> +<td valign="top" >Standard value as in DRM</td> +<td valign="top" >Standard Object as in DRM</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td rowspan="17" valign="top" >SDVO-TV</td> +<td valign="top" >“mode”</td> +<td valign="top" >ENUM</td> +<td valign="top" >{0, "NTSC_M"} , {1, "NTSC_J"} , +{2, "NTSC_443"}, {3, "PAL_B"} etc.</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >"left_margin"</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max= SDVO dependent</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >"right_margin"</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max= SDVO dependent</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >"top_margin"</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max= SDVO dependent</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >"bottom_margin"</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max= SDVO dependent</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >“hpos”</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max= SDVO dependent</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >“vpos”</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max= SDVO dependent</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >“contrast”</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max= SDVO dependent</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >“saturation”</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max= SDVO dependent</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >“hue”</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max= SDVO dependent</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >“sharpness”</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max= SDVO dependent</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >“flicker_filter”</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max= SDVO dependent</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >“flicker_filter_adaptive”</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max= SDVO dependent</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >“flicker_filter_2d”</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max= SDVO dependent</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >“tv_chroma_filter”</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max= SDVO dependent</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >“tv_luma_filter”</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max= SDVO dependent</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >“dot_crawl”</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max=1</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >SDVO-TV/LVDS</td> +<td valign="top" >“brightness”</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max= SDVO dependent</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td rowspan="11" valign="top" >armada</td> +<td rowspan="2" valign="top" >CRTC</td> +<td valign="top" >"CSC_YUV"</td> +<td valign="top" >ENUM</td> +<td valign="top" >{ CSC_AUTO, "Auto" }, +{ CSC_YUV_CCIR601, "CCIR601" }, +{ CSC_YUV_CCIR709, "CCIR709" }</td> +<td valign="top" >CRTC</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >"CSC_RGB"</td> +<td valign="top" >ENUM</td> +<td valign="top" >{ CSC_AUTO, "Auto" }, +{ CSC_RGB_COMPUTER, "Computer system" }, +{ CSC_RGB_STUDIO, "Studio" }</td> +<td valign="top" >CRTC</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td rowspan="9" valign="top" >Overlay</td> +<td valign="top" >"colorkey"</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max=0xffffff</td> +<td valign="top" >Plane</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >"colorkey_min"</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max=0xffffff</td> +<td valign="top" >Plane</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >"colorkey_max"</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max=0xffffff</td> +<td valign="top" >Plane</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >"colorkey_val"</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max=0xffffff</td> +<td valign="top" >Plane</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >"colorkey_alpha"</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max=0xffffff</td> +<td valign="top" >Plane</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >"colorkey_mode"</td> +<td valign="top" >ENUM</td> +<td valign="top" >{ CKMODE_DISABLE, "disabled" }, +{ CKMODE_Y, "Y component" }, +{ CKMODE_U, "U component" }, +{ CKMODE_V, "V component" }, +{ CKMODE_RGB, "RGB" }, +{ CKMODE_R, “R component" }, +{ CKMODE_G, "G component" }, + CKMODE_B, "B component" }</td> +<td valign="top" >Plane</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >"brightness"</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max=256 + 255</td> +<td valign="top" >Plane</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >"contrast"</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max=0x7fff</td> +<td valign="top" >Plane</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >"saturation"</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max=0x7fff</td> +<td valign="top" >Plane</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td rowspan="2" valign="top" >exynos</td> +<td valign="top" >CRTC</td> +<td valign="top" >“mode”</td> +<td valign="top" >ENUM</td> +<td valign="top" >{ CRTC_MODE_NORMAL, "normal" }, +{ CRTC_MODE_BLANK, "blank" }</td> +<td valign="top" >CRTC</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >Overlay</td> +<td valign="top" >“zpos”</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max=MAX_PLANE-1</td> +<td valign="top" >Plane</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td rowspan="3" valign="top" >i2c/ch7006_drv</td> +<td valign="top" >Generic</td> +<td valign="top" >“scale”</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max=2</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td rowspan="2" valign="top" >TV</td> +<td valign="top" >Standard names as in DRM</td> +<td valign="top" >Standard types as in DRM</td> +<td valign="top" >Standard Values as in DRM</td> +<td valign="top" >Standard object as in DRM</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >“mode”</td> +<td valign="top" >ENUM</td> +<td valign="top" >{0, "PAL"}, {1, "PAL-M"}, {2,"PAL-N"}, +{2,”PAL-Nc"}, {3, "PAL-60"}, {4, "NTSC-M"}, +{5,"NTSC-J"}</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td rowspan="16" valign="top" >noveau</td> +<td rowspan="6" valign="top" >NV10 Overlay</td> +<td valign="top" >"colorkey"</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max=0x01ffffff</td> +<td valign="top" >Plane</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >“contrast”</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max=8192-1</td> +<td valign="top" >Plane</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >“brightness”</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max=1024</td> +<td valign="top" >Plane</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >“hue”</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max=359</td> +<td valign="top" >Plane</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >“saturation”</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max=8192-1</td> +<td valign="top" >Plane</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >“iturbt_709”</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max=1</td> +<td valign="top" >Plane</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td rowspan="2" valign="top" >Nv04 Overlay</td> +<td valign="top" >“colorkey”</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max=0x01ffffff</td> +<td valign="top" >Plane</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >“brightness”</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max=1024</td> +<td valign="top" >Plane</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td rowspan="7" valign="top" >Display</td> +<td valign="top" >“dithering mode”</td> +<td valign="top" >ENUM</td> +<td valign="top" >Custom values which has gen info as well. +{ 6, UNDERSCAN_AUTO, "auto" }, +{ 6, UNDERSCAN_OFF, "off" }, +{ 6, UNDERSCAN_ON, "on" }</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >“dithering depth”</td> +<td valign="top" >ENUM</td> +<td valign="top" >Custom 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" }</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >“underscan”</td> +<td valign="top" >ENUM</td> +<td valign="top" >Custom values which has gen info as well. +{ 6, DITHERING_DEPTH_AUTO, "auto" }, +{ 6, DITHERING_DEPTH_6BPC, "6 bpc" }, +{ 6, DITHERING_DEPTH_8BPC, "8 bpc" }</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >“underscan hborder”</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max=128</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >“underscan vborder”</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max=128</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >“vibrant hue”</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max=180</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >“color vibrance”</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max=200</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >Generic</td> +<td valign="top" >Standard name as in DRM</td> +<td valign="top" >Standard type as in DRM</td> +<td valign="top" >Standard value as in DRM</td> +<td valign="top" >Standard Object as in DRM</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td rowspan="2" valign="top" >omap</td> +<td rowspan="2" valign="top" >Generic</td> +<td valign="top" >“rotation”</td> +<td valign="top" >BITMASK</td> +<td valign="top" >{ 0, "rotate-0" }, +{ 1, "rotate-90" }, +{ 2, "rotate-180" }, +{ 3, "rotate-270" }, +{ 4, "reflect-x" }, +{ 5, "reflect-y" }</td> +<td valign="top" >CRTC, Plane</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >“zorder”</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max=3</td> +<td valign="top" >CRTC, Plane</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >qxl</td> +<td valign="top" >Generic</td> +<td valign="top" >“hotplug_mode_update"</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max=1</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td rowspan="10" valign="top" >radeon</td> +<td valign="top" >DVI-I</td> +<td valign="top" >“coherent”</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max=1</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >DAC enable load detect</td> +<td valign="top" >“load detection”</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max=1</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >TV Standard</td> +<td valign="top" >"tv standard"</td> +<td valign="top" >ENUM</td> +<td valign="top" >{ 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" }</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >legacy TMDS PLL detect</td> +<td valign="top" >"tmds_pll"</td> +<td valign="top" >ENUM</td> +<td valign="top" >{ 0, "driver" }, +{ 1, "bios" }</td> +<td valign="top" >-</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td rowspan="3" valign="top" >Underscan</td> +<td valign="top" >"underscan"</td> +<td valign="top" >ENUM</td> +<td valign="top" >{ UNDERSCAN_OFF, "off" }, +{ UNDERSCAN_ON, "on" }, +{ UNDERSCAN_AUTO, "auto" }</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >"underscan hborder"</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max=128</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >"underscan vborder"</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max=128</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >Audio</td> +<td valign="top" >“audio”</td> +<td valign="top" >ENUM</td> +<td valign="top" >{ RADEON_AUDIO_DISABLE, "off" }, +{ RADEON_AUDIO_ENABLE, "on" }, +{ RADEON_AUDIO_AUTO, "auto" }</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >FMT Dithering</td> +<td valign="top" >“dither”</td> +<td valign="top" >ENUM</td> +<td valign="top" >{ RADEON_FMT_DITHER_DISABLE, "off" }, +{ RADEON_FMT_DITHER_ENABLE, "on" }</td> +<td valign="top" >Connector</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >Generic</td> +<td valign="top" >Standard name as in DRM</td> +<td valign="top" >Standard type as in DRM</td> +<td valign="top" >Standard value as in DRM</td> +<td valign="top" >Standard Object as in DRM</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td rowspan="3" valign="top" >rcar-du</td> +<td rowspan="3" valign="top" >Generic</td> +<td valign="top" >"alpha"</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max=255</td> +<td valign="top" >Plane</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >"colorkey"</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=0, Max=0x01ffffff</td> +<td valign="top" >Plane</td> +<td valign="top" >TBD</td> +</tr> + +<tr> +<td valign="top" >"zpos"</td> +<td valign="top" >RANGE</td> +<td valign="top" >Min=1, Max=7</td> +<td valign="top" >Plane</td> +<td valign="top" >TBD</td> +</tr> + +</tbody> +</table> </sect1> <!-- Internals: vertical blanking --> -- 1.8.5 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply related [flat|nested] 22+ messages in thread
[parent not found: <2919182.UBDg5nOr7Z@avalon>]
[parent not found: <1394622965.18918.12.camel@sagar-desktop>]
[parent not found: <3136468.2PAlK4Gq8k@avalon>]
* Re: [PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers [not found] ` <3136468.2PAlK4Gq8k@avalon> @ 2014-05-10 10:39 ` Ville Syrjälä 2014-05-10 10:56 ` Rob Clark 2014-05-12 8:24 ` Dave Airlie 0 siblings, 2 replies; 22+ messages in thread From: Ville Syrjälä @ 2014-05-10 10:39 UTC (permalink / raw) To: Laurent Pinchart Cc: Laurent Pinchart, linux-doc, Daniel Vetter, intel-gfx, dri-devel, Purushothaman, Vijay A, Rob Landley, Alex Deucher, Dave Airlie, Sagar Arun Kamble 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, <sagar.a.kamble@intel.com> wrote: > > > > > +<table border="1" cellpadding="0" cellspacing="0" > > > > > > +<tbody> > > > > > +<tr style="font-weight: bold;" > > > > > > +<td valign="top" >Owner Module/Drivers</td> > > > > > +<td valign="top" >Group</td> > > > > > +<td valign="top" >Property Object</td> > > > > > +<td valign="top" >Property Name</td> > > > > > +<td valign="top" >Type</td> > > > > > +<td valign="top" >Property Values</td> > > > > > +<td valign="top" >Object attached</td> > > > > > +<td valign="top" >Description</td> > > > > > +</tr> > > > > > > > > In my opinion this is a horrible way to write property documentations > > > > - 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 files > > > > 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 code > comments would be fine, so would an external central documentation file in 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 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? 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älä Intel OTC ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers 2014-05-10 10:39 ` [PATCH " Ville Syrjälä @ 2014-05-10 10:56 ` Rob Clark 2014-05-12 6:07 ` Sagar Arun Kamble 2014-05-12 8:24 ` Dave Airlie 1 sibling, 1 reply; 22+ messages in thread From: Rob Clark @ 2014-05-10 10:56 UTC (permalink / raw) To: Ville Syrjälä Cc: Laurent Pinchart, Laurent Pinchart, linux-doc, Daniel Vetter, intel-gfx, dri-devel@lists.freedesktop.org, Purushothaman, Vijay A, Rob Landley, Alex Deucher, Dave Airlie, Sagar Arun Kamble On Sat, May 10, 2014 at 6:39 AM, Ville Syrjälä <ville.syrjala@linux.intel.com> 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, <sagar.a.kamble@intel.com> wrote: >> > > > > +<table border="1" cellpadding="0" cellspacing="0" > >> > > > > +<tbody> >> > > > > +<tr style="font-weight: bold;" > >> > > > > +<td valign="top" >Owner Module/Drivers</td> >> > > > > +<td valign="top" >Group</td> >> > > > > +<td valign="top" >Property Object</td> >> > > > > +<td valign="top" >Property Name</td> >> > > > > +<td valign="top" >Type</td> >> > > > > +<td valign="top" >Property Values</td> >> > > > > +<td valign="top" >Object attached</td> >> > > > > +<td valign="top" >Description</td> >> > > > > +</tr> >> > > > >> > > > In my opinion this is a horrible way to write property documentations >> > > > - 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 files >> > > > 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 code >> comments would be fine, so would an external central documentation file in 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 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? > > 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!". any of the first three options would be vastly superior to what we do now 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älä > Intel OTC > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers 2014-05-10 10:56 ` Rob Clark @ 2014-05-12 6:07 ` Sagar Arun Kamble 2014-05-12 8:03 ` Daniel Vetter 0 siblings, 1 reply; 22+ messages in thread From: Sagar Arun Kamble @ 2014-05-12 6:07 UTC (permalink / raw) To: Rob Clark Cc: Laurent Pinchart, linux-doc, Daniel Vetter, intel-gfx, shashidhar.hiremath, dri-devel@lists.freedesktop.org, Purushothaman, Vijay A, Laurent Pinchart, Rob Landley, Alex Deucher, Dave Airlie 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. 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älä > <ville.syrjala@linux.intel.com> 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, <sagar.a.kamble@intel.com> wrote: > >> > > > > +<table border="1" cellpadding="0" cellspacing="0" > > >> > > > > +<tbody> > >> > > > > +<tr style="font-weight: bold;" > > >> > > > > +<td valign="top" >Owner Module/Drivers</td> > >> > > > > +<td valign="top" >Group</td> > >> > > > > +<td valign="top" >Property Object</td> > >> > > > > +<td valign="top" >Property Name</td> > >> > > > > +<td valign="top" >Type</td> > >> > > > > +<td valign="top" >Property Values</td> > >> > > > > +<td valign="top" >Object attached</td> > >> > > > > +<td valign="top" >Description</td> > >> > > > > +</tr> > >> > > > > >> > > > In my opinion this is a horrible way to write property documentations > >> > > > - 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 files > >> > > > 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 code > >> comments would be fine, so would an external central documentation file in 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 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? > > > > 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!". > > any of the first three options would be vastly superior to what we do now > > 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älä > > Intel OTC > > _______________________________________________ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/dri-devel _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers 2014-05-12 6:07 ` Sagar Arun Kamble @ 2014-05-12 8:03 ` Daniel Vetter 2014-05-13 7:17 ` Thierry Reding 0 siblings, 1 reply; 22+ messages in thread From: Daniel Vetter @ 2014-05-12 8:03 UTC (permalink / raw) To: Sagar Arun Kamble Cc: Laurent Pinchart, linux-doc, Daniel Vetter, intel-gfx, shashidhar.hiremath, dri-devel@lists.freedesktop.org, Purushothaman, Vijay A, Laurent Pinchart, Rob Landley, Alex Deucher, Dave Airlie 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älä > > <ville.syrjala@linux.intel.com> 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, <sagar.a.kamble@intel.com> wrote: > > >> > > > > +<table border="1" cellpadding="0" cellspacing="0" > > > >> > > > > +<tbody> > > >> > > > > +<tr style="font-weight: bold;" > > > >> > > > > +<td valign="top" >Owner Module/Drivers</td> > > >> > > > > +<td valign="top" >Group</td> > > >> > > > > +<td valign="top" >Property Object</td> > > >> > > > > +<td valign="top" >Property Name</td> > > >> > > > > +<td valign="top" >Type</td> > > >> > > > > +<td valign="top" >Property Values</td> > > >> > > > > +<td valign="top" >Object attached</td> > > >> > > > > +<td valign="top" >Description</td> > > >> > > > > +</tr> > > >> > > > > > >> > > > In my opinion this is a horrible way to write property documentations > > >> > > > - 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 files > > >> > > > 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 code > > >> comments would be fine, so would an external central documentation file in 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 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? > > > > > > 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!". > > > > any of the first three options would be vastly superior to what we do now > > > > 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älä > > > 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers 2014-05-12 8:03 ` Daniel Vetter @ 2014-05-13 7:17 ` Thierry Reding 2014-05-13 7:34 ` Daniel Vetter 0 siblings, 1 reply; 22+ messages in thread From: Thierry Reding @ 2014-05-13 7:17 UTC (permalink / raw) To: Daniel Vetter Cc: Laurent Pinchart, linux-doc, Daniel Vetter, intel-gfx, shashidhar.hiremath, dri-devel@lists.freedesktop.org, Laurent Pinchart, Rob Landley, Alex Deucher, Dave Airlie, Sagar Arun Kamble [-- Attachment #1.1: Type: text/plain, Size: 2188 bytes --] 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. Thierry [-- Attachment #1.2: Type: application/pgp-signature, Size: 836 bytes --] [-- Attachment #2: Type: text/plain, Size: 159 bytes --] _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers 2014-05-13 7:17 ` Thierry Reding @ 2014-05-13 7:34 ` Daniel Vetter 2014-05-13 9:05 ` Thierry Reding 2014-05-13 11:02 ` Laurent Pinchart 0 siblings, 2 replies; 22+ messages in thread From: Daniel Vetter @ 2014-05-13 7:34 UTC (permalink / raw) To: Thierry Reding Cc: Sagar Arun Kamble, Laurent Pinchart, linux-doc, intel-gfx, Hiremath, Shashidhar, dri-devel@lists.freedesktop.org, Purushothaman, Vijay A, Laurent Pinchart, Rob Landley, Alex Deucher, Dave Airlie On Tue, May 13, 2014 at 9:17 AM, Thierry Reding <thierry.reding@gmail.com> 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers 2014-05-13 7:34 ` Daniel Vetter @ 2014-05-13 9:05 ` Thierry Reding 2014-05-13 11:02 ` Laurent Pinchart 1 sibling, 0 replies; 22+ messages in thread From: Thierry Reding @ 2014-05-13 9:05 UTC (permalink / raw) To: Daniel Vetter Cc: Laurent Pinchart, linux-doc, intel-gfx, Hiremath, Shashidhar, dri-devel@lists.freedesktop.org, Laurent Pinchart, Rob Landley, Alex Deucher, Dave Airlie, Sagar Arun Kamble [-- Attachment #1.1: Type: text/plain, Size: 5481 bytes --] On Tue, May 13, 2014 at 09:34:45AM +0200, Daniel Vetter wrote: > On Tue, May 13, 2014 at 9:17 AM, Thierry Reding > <thierry.reding@gmail.com> 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. 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 [-- Attachment #1.2: Type: application/pgp-signature, Size: 836 bytes --] [-- Attachment #2: Type: text/plain, Size: 159 bytes --] _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers 2014-05-13 7:34 ` Daniel Vetter 2014-05-13 9:05 ` Thierry Reding @ 2014-05-13 11:02 ` Laurent Pinchart 2014-05-13 11:51 ` Daniel Vetter 1 sibling, 1 reply; 22+ messages in thread From: Laurent Pinchart @ 2014-05-13 11:02 UTC (permalink / raw) To: Daniel Vetter Cc: Laurent Pinchart, linux-doc, intel-gfx, Hiremath, Shashidhar, dri-devel@lists.freedesktop.org, Purushothaman, Vijay A, Rob Landley, Alex Deucher, Dave Airlie, Sagar Arun Kamble 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers 2014-05-13 11:02 ` Laurent Pinchart @ 2014-05-13 11:51 ` Daniel Vetter 0 siblings, 0 replies; 22+ messages in thread From: Daniel Vetter @ 2014-05-13 11:51 UTC (permalink / raw) To: Laurent Pinchart Cc: Thierry Reding, Sagar Arun Kamble, Laurent Pinchart, linux-doc, intel-gfx, Hiremath, Shashidhar, dri-devel@lists.freedesktop.org, Purushothaman, Vijay A, Rob Landley, Alex Deucher, Dave Airlie On Tue, May 13, 2014 at 1:02 PM, Laurent Pinchart <laurent.pinchart@ideasonboard.com> 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers 2014-05-10 10:39 ` [PATCH " Ville Syrjälä 2014-05-10 10:56 ` Rob Clark @ 2014-05-12 8:24 ` Dave Airlie 2014-05-12 8:58 ` Daniel Vetter 1 sibling, 1 reply; 22+ messages in thread From: Dave Airlie @ 2014-05-12 8:24 UTC (permalink / raw) To: Ville Syrjälä Cc: Laurent Pinchart, linux-doc, Daniel Vetter, intel-gfx, dri-devel, Laurent Pinchart, Rob Landley, Alex Deucher, Dave Airlie, Sagar Arun Kamble >> >> 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers 2014-05-12 8:24 ` Dave Airlie @ 2014-05-12 8:58 ` Daniel Vetter 2014-05-12 15:23 ` Randy Dunlap 0 siblings, 1 reply; 22+ messages in thread From: Daniel Vetter @ 2014-05-12 8:58 UTC (permalink / raw) To: Dave Airlie Cc: Ville Syrjälä, Laurent Pinchart, Laurent Pinchart, linux-doc, Daniel Vetter, intel-gfx, dri-devel, Purushothaman, Vijay A, Rob Landley, Alex Deucher, Dave Airlie, Sagar Arun Kamble 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers 2014-05-12 8:58 ` Daniel Vetter @ 2014-05-12 15:23 ` Randy Dunlap 2014-05-12 15:54 ` Daniel Vetter 0 siblings, 1 reply; 22+ messages in thread From: Randy Dunlap @ 2014-05-12 15:23 UTC (permalink / raw) To: Daniel Vetter, Dave Airlie Cc: Laurent Pinchart, linux-doc, Daniel Vetter, intel-gfx, dri-devel, Laurent Pinchart, Rob Landley, Alex Deucher, Dave Airlie, Sagar Arun Kamble 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers 2014-05-12 15:23 ` Randy Dunlap @ 2014-05-12 15:54 ` Daniel Vetter 2014-05-12 18:04 ` Randy Dunlap 0 siblings, 1 reply; 22+ messages in thread From: Daniel Vetter @ 2014-05-12 15:54 UTC (permalink / raw) To: Randy Dunlap Cc: Laurent Pinchart, Rob Landley, linux-doc, Sagar Arun Kamble, Daniel Vetter, intel-gfx, dri-devel, Purushothaman, Vijay A, Laurent Pinchart, Alex Deucher, Dave Airlie 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers 2014-05-12 15:54 ` Daniel Vetter @ 2014-05-12 18:04 ` Randy Dunlap 2014-07-31 22:16 ` Randy Dunlap 0 siblings, 1 reply; 22+ messages in thread From: Randy Dunlap @ 2014-05-12 18:04 UTC (permalink / raw) To: Daniel Vetter Cc: Dave Airlie, Ville Syrjälä, Laurent Pinchart, Laurent Pinchart, linux-doc, Daniel Vetter, intel-gfx, dri-devel, Purushothaman, Vijay A, Rob Landley, Alex Deucher, Dave Airlie, Sagar Arun Kamble 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers 2014-05-12 18:04 ` Randy Dunlap @ 2014-07-31 22:16 ` Randy Dunlap 2014-08-01 12:58 ` Laurent Pinchart 0 siblings, 1 reply; 22+ messages in thread From: Randy Dunlap @ 2014-07-31 22:16 UTC (permalink / raw) To: Daniel Vetter Cc: Laurent Pinchart, linux-doc, Sagar Arun Kamble, Daniel Vetter, intel-gfx, dri-devel, Laurent Pinchart, Rob Landley, Alex Deucher, Dave Airlie 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers 2014-07-31 22:16 ` Randy Dunlap @ 2014-08-01 12:58 ` Laurent Pinchart 2014-08-01 22:21 ` Randy Dunlap 2014-08-04 7:30 ` Daniel Vetter 0 siblings, 2 replies; 22+ messages in thread From: Laurent Pinchart @ 2014-08-01 12:58 UTC (permalink / raw) To: Randy Dunlap Cc: Laurent Pinchart, Rob Landley, linux-doc, Sagar Arun Kamble, Daniel Vetter, intel-gfx, dri-devel, Alex Deucher, Dave Airlie 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers 2014-08-01 12:58 ` Laurent Pinchart @ 2014-08-01 22:21 ` Randy Dunlap 2014-08-04 7:30 ` Daniel Vetter 1 sibling, 0 replies; 22+ messages in thread From: Randy Dunlap @ 2014-08-01 22:21 UTC (permalink / raw) To: Laurent Pinchart Cc: Laurent Pinchart, Rob Landley, linux-doc, Sagar Arun Kamble, Daniel Vetter, intel-gfx, dri-devel, Alex Deucher, Dave Airlie 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers 2014-08-01 12:58 ` Laurent Pinchart 2014-08-01 22:21 ` Randy Dunlap @ 2014-08-04 7:30 ` Daniel Vetter 2014-08-04 13:58 ` Laurent Pinchart 1 sibling, 1 reply; 22+ messages in thread From: Daniel Vetter @ 2014-08-04 7:30 UTC (permalink / raw) To: Laurent Pinchart Cc: Randy Dunlap, Daniel Vetter, Dave Airlie, Ville Syrjälä, Laurent Pinchart, linux-doc, Daniel Vetter, intel-gfx, dri-devel, Purushothaman, Vijay A, Rob Landley, Alex Deucher, Dave Airlie, Sagar Arun Kamble 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers 2014-08-04 7:30 ` Daniel Vetter @ 2014-08-04 13:58 ` Laurent Pinchart 0 siblings, 0 replies; 22+ messages in thread From: Laurent Pinchart @ 2014-08-04 13:58 UTC (permalink / raw) To: Daniel Vetter Cc: Laurent Pinchart, linux-doc, Sagar Arun Kamble, Daniel Vetter, intel-gfx, Randy Dunlap, dri-devel, Rob Landley, Alex Deucher, Dave Airlie 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2014-08-04 13:58 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <1394016990-5218-1-git-send-email-sagar.a.kamble@intel.com>
[not found] ` <1394090125-30029-1-git-send-email-sagar.a.kamble@intel.com>
2014-03-06 12:09 ` [PATCH v2 1/1] Documentation: drm: describing drm properties exposed by various drivers Ville Syrjälä
2014-03-06 14:01 ` Sagar Arun Kamble
2014-03-06 14:41 ` [PATCH v3 " sagar.a.kamble
[not found] ` <2919182.UBDg5nOr7Z@avalon>
[not found] ` <1394622965.18918.12.camel@sagar-desktop>
[not found] ` <3136468.2PAlK4Gq8k@avalon>
2014-05-10 10:39 ` [PATCH " Ville Syrjälä
2014-05-10 10:56 ` Rob Clark
2014-05-12 6:07 ` Sagar Arun Kamble
2014-05-12 8:03 ` Daniel Vetter
2014-05-13 7:17 ` Thierry Reding
2014-05-13 7:34 ` Daniel Vetter
2014-05-13 9:05 ` Thierry Reding
2014-05-13 11:02 ` Laurent Pinchart
2014-05-13 11:51 ` Daniel Vetter
2014-05-12 8:24 ` Dave Airlie
2014-05-12 8:58 ` Daniel Vetter
2014-05-12 15:23 ` Randy Dunlap
2014-05-12 15:54 ` Daniel Vetter
2014-05-12 18:04 ` Randy Dunlap
2014-07-31 22:16 ` Randy Dunlap
2014-08-01 12:58 ` Laurent Pinchart
2014-08-01 22:21 ` Randy Dunlap
2014-08-04 7:30 ` Daniel Vetter
2014-08-04 13:58 ` Laurent Pinchart
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).