On Wed, Aug 31, 2022 at 02:56:12PM +0000, Simon Ser wrote:
> On Wednesday, August 31st, 2022 at 09:50, Pekka Paalanen <ppaalanen@xxxxxxxxx> wrote:
>
> > > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > > index 86a292c3185a..cce1a1bea645 100644
> > > --- a/include/uapi/drm/drm_mode.h
> > > +++ b/include/uapi/drm/drm_mode.h
> > > @@ -942,6 +942,10 @@ struct hdr_output_metadata {
> > > * Request that the page-flip is performed as soon as possible, ie. with no
> > > * delay due to waiting for vblank. This may cause tearing to be visible on
> > > * the screen.
> > > + *
> > > + * When used with atomic uAPI, the driver will return an error if the hardware
> > > + * doesn't support performing an asynchronous page-flip for this update.
> > > + * User-space should handle this, e.g. by falling back to a regular page-flip.
> > > */
> > > #define DRM_MODE_PAGE_FLIP_ASYNC 0x02
> > > #define DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE 0x4
> >
> > Hi Simon,
> >
> > recalling what Ville explained that enabling async flips might require
> > one more sync flip first, how is that supposed to work?
> >
> > A TEST_ONLY commit is not allowed to change hardware state, and a
> > failing real commit is not allowed to change hardware state either
> > (right?), therefore a failing async flip cannot prepare the next flip
> > to be async, meaning async will never work.
>
> I'd blame it on bad hw, and make it one special quirk in the driver,
> just like it does now.
>
> Ville, thoughts?
I suppose it might be worth mentioning that special case here,
to avoid people getting confused why the first async flip was
accepted but took a full frame to complete.
--
Ville Syrjälä
Intel
