[RFCv1 02/12] drm: add object property type

Rob Clark robdclark at gmail.com
Mon Oct 7 16:44:43 CEST 2013


On Mon, Oct 7, 2013 at 9:43 AM, Ville Syrjälä
<ville.syrjala at linux.intel.com> wrote:
> On Sat, Oct 05, 2013 at 08:45:40PM -0400, Rob Clark wrote:
>> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
>> index 5508117..35921ba 100644
>> --- a/include/uapi/drm/drm_mode.h
>> +++ b/include/uapi/drm/drm_mode.h
>> @@ -231,6 +231,7 @@ struct drm_mode_get_connector {
>>  #define DRM_MODE_PROP_ENUM   (1<<3) /* enumerated type with text strings */
>>  #define DRM_MODE_PROP_BLOB   (1<<4)
>>  #define DRM_MODE_PROP_BITMASK        (1<<5) /* bitmask of enumerated types */
>> +#define DRM_MODE_PROP_OBJECT (1<<6) /* drm mode object */
>
> This way to using up one bit for each type sucks big time. IIRC we
> discussed this at Fosdem and one idea was to leave the current bits as
> sort of base types, and reserve a bunch of the other bits to indicate a
> sub-type. For instance the new signed range and object ID prop types
> could be sub-types of the current range type.

oh, right..  current object-prop is just a straight rebase of the
original patch, so I didn't change this yet.

We probably don't want to use sub-type in cases where old userspace
could misinterpret things, so not sure about signed-range to be a
sub-type of range (if that is what you meant)... but maybe a good idea
for PROP_MISC + PROP_SUBTYPE_OBJECT.  Otoh, at the moment, the only
other prop type I have in mind is ARRAY (although not sure if we can
do single PROP_ARRAY or if we end up needing PROP_ARRAY_foo, for
everything we might want an array of..)

BR,
-R

> Maybe we should reserve a few more bits for new base types in case we
> need them in the future, or just add sometime king DRM_MODE_PROP_MISC,
> which is where we'd stick every sub-type that doesn't fit the current
> base types.
>
> --
> Ville Syrjälä
> Intel OTC


More information about the dri-devel mailing list