On Mon, Oct 7, 2013 at 9:43 AM, Ville Syrjälä
<ville.syrjala@xxxxxxxxxxxxxxx> 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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
