Re: [RFCv1 03/12] drm: add DRM_MODE_PROP_DYNAMIC property flag

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Oct 7, 2013 at 9:46 AM, Ville Syrjälä
<ville.syrjala@xxxxxxxxxxxxxxx> wrote:
> On Sat, Oct 05, 2013 at 08:45:41PM -0400, Rob Clark wrote:
>> This indicates to userspace that the property is something that can
>> be set dynamically without requiring a "test" step to check if the
>> hw is capable.  This allows a userspace compositor, such as weston,
>> to avoid an extra ioctl to check whether it needs to fall-back to
>> GPU to composite some surface prior to submission of GPU render
>> commands.
>> ---
>>  include/uapi/drm/drm_mode.h | 9 +++++++++
>>  1 file changed, 9 insertions(+)
>>
>> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
>> index 35921ba..15db837 100644
>> --- a/include/uapi/drm/drm_mode.h
>> +++ b/include/uapi/drm/drm_mode.h
>> @@ -232,6 +232,15 @@ struct drm_mode_get_connector {
>>  #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 */
>> +/* Properties that are not dynamic cannot safely be changed without a
>> + * atomic-modeset / atomic-pageflip test step.  But if userspace is
>> + * only changing dynamic properties, it is guaranteed that the change
>> + * will not exceed hw limits, so no test step is required.
>> + *
>> + * Note that fb_id properties are a bit ambiguous.. they of course can
>> + * be changed dynamically, assuming the pixel format does not change.
>> + */
>> +#define DRM_MODE_PROP_DYNAMIC        (1<<24)
>
> I'm still not convinced that this is useful. We can't even flag the FB
> ID with this flag since the FB encompasses stride/bpp/etc. parameters
> that for sure can't just be changed w/o first checking the new
> configuration.

well, I know of at least some hw that can change plane src/crtc coords
without requiring a check step.  So I think it is useful as an
optimization.  But it is also something that could be easily/safely
added later so maybe I should drop it from the initial atomic
patchset.

BR,
-R

> --
> Ville Syrjälä
> Intel OTC
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel





[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux