On Wed, Dec 17, 2014 at 06:31:13PM +0900, Michel Dänzer wrote:
> On 17.12.2014 16:20, Pekka Paalanen wrote:
> > On Wed, 17 Dec 2014 11:48:51 +0900
> > Michel Dänzer <michel@xxxxxxxxxxx> 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.
>
> I agree. The main reason I brought it up is because I'd like to avoid
> getting into the same situation as with the current
> DRM_IOCTL_MODE_PAGE_FLIP ioctl, which doesn't explicitly communicate
> between userspace and kernel when the flip is supposed/expected to
> occur. We recently had to jump through some hoops in the radeon kernel
> driver to prevent flips from occurring sooner than expected by userspace.
The current approach is to ask for a vblank event 1 frame earlier in the
ddx and schedule the flip when you receive that. And hope for the best.
There shouldn't be anything really required in the kernel.
> But I also think it would be a shame at this point to add new ioctls
> which aren't designed with variable refresh rate displays in mind.
Let's please not aim for the kitchen sink, we won't get this in anytime
soon otherwise. And there is _lots_ more little features all over that we
want but don't yet have:
- update rectangle for manual/selective update panels
- async flips/flip merging and precise semantics
- integration with android syncpts
- flip queues and cancelling flips
- ...
It doesn't make sense to add everything in v1. And the atomic ioctl
extends fairly well (maybe we need write-only properties for some of this
stuff). Worst case we get atomic_2/3/4 ioctls. After all we're fairly good
at rev'ing interface in drm.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
