Re: [PATCH 13/13] RFC: drm: Atomic modeset ioctl

[Pekka Paalanen <ppaalanen@gmail.com>]

On Wed, 17 Dec 2014 11:48:51 +0900
Michel Dänzer <michel@daenzer.net> wrote:

> On 17.12.2014 08:05, Rob Clark wrote:
> > The atomic modeset ioctl can be used to push any number of new values
> > for object properties. The driver can then check the full device
> > configuration as single unit, and try to apply the changes atomically.
> > 
> > The ioctl simply takes a list of object IDs and property IDs and their
> > values.
> 
> [...]
> 
> > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > index 86574b0..3459778 100644
> > --- a/include/uapi/drm/drm_mode.h
> > +++ b/include/uapi/drm/drm_mode.h
> > @@ -519,4 +519,25 @@ struct drm_mode_destroy_dumb {
> >  	uint32_t handle;
> >  };
> >  
> > +/* page-flip flags are valid, plus: */
> > +#define DRM_MODE_ATOMIC_TEST_ONLY 0x0100
> > +#define DRM_MODE_ATOMIC_NONBLOCK  0x0200
> > +
> > +#define DRM_MODE_ATOMIC_FLAGS (\
> > +		DRM_MODE_PAGE_FLIP_EVENT |\
> > +		DRM_MODE_PAGE_FLIP_ASYNC |\
> > +		DRM_MODE_ATOMIC_TEST_ONLY |\
> > +		DRM_MODE_ATOMIC_NONBLOCK)
> > +
> > +struct drm_mode_atomic {
> > +	__u32 flags;
> > +	__u32 count_objs;
> > +	__u64 objs_ptr;
> > +	__u64 count_props_ptr;
> > +	__u64 props_ptr;
> > +	__u64 prop_values_ptr;
> > +	__u64 blob_values_ptr;  /* remove? */
> > +	__u64 user_data;
> > +};
> > +
> >  #endif
> > 
> 
> The new ioctl(s) should take an explicit parameter specifying when the
> changes should take effect. And since variable refresh rate displays are
> becoming mainstream, that parameter should probably be a timestamp
> rather than a frame counter.

That sounds cool to me, but also a rabbit hole. While having worked on
the Wayland Presentation queueing extension, I'd like to ask the
following questions:

- If you set the atomic kick to happen in the future, is there any way
  to cancel it? I'd be ok with not being able to cancel initially, but
  if one wants to add that later, we should already know how to
  reference this atomic submission in the cancel request. What if user
  space has a bug and schedules an update at one hour or three days from
  now, how would we abort that?

- Can you VT-switch or drop DRM master if you have a pending atomic
  update?

- Should one be able to set multiple pending atomic updates?

- If I schedule an atomic update for one CTRC, can I schedule another
  update for another CRTC before the first one completes? Or am I
  forced to gather all updates over all outputs in the same atomic
  submission even if I don't care about or want inter-output sync and
  the outputs might even be running at different refresh rates?
  (Actually, this seems to be a valid question even without any target
  time parameter.)

- If there can be multiple pending atomic updates on the same DRM
  device, is there any way to guarantee that the
  DRM_MODE_ATOMIC_TEST_ONLY results will be accurate also when the
  atomic update actually kicks in? Another update may have changed the
  configuration before this update kicks in, which means the overall
  state isn't the same that was tested.

- Does a pending atomic update prevent immediate (old style) KMS
  changes?

- Assuming hardware cannot do arbitrary time updates, how do you round
  the given timestamp? Strictly "not before" given time? Round to
  nearest possible time? The effect of required vs. unwanted sync to
  vblank?

- How would user space match the page flip event to the atomic
  submission it did?

I wonder if there is a way to postpone these hard(?) questions, so that
we could have atomic sooner and add scheduling later? I would imagine
solving everything above is quite some work.


Thanks,
pq
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel