On 2022-08-30 10:16, Pekka Paalanen wrote: > On Mon, 29 Aug 2022 15:37:52 +0000 > Simon Ser <contact@xxxxxxxxxxx> wrote: >> On Friday, August 26th, 2022 at 10:53, Pekka Paalanen <ppaalanen@xxxxxxxxx> wrote: >> >>>> +/** >>>> + * DRM_MODE_PAGE_FLIP_ASYNC >>>> + * >>>> + * 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. >>> >>> Btw. does the kernel fail the flip if the driver does not support async? >>> Or does it silently fall back to sync flip? >>> Asking for both legacy and atomic APIs. >> >> Atomic doesn't support this yet, so it's pretty much TBD (see Ville's reply [1]). > > So atomic commit ioctl will fail with EINVAL because userspace is > giving it an unrecognized flag? > > [1] is interesting. Apparently the atomic async flag will only be a > hint, "make it tear if possible". That seems fine to me. To me it would seem better for the driver to return an error if the async flag is passed in, but the driver can't actually do an async update. Otherwise it's tricky for a Wayland compositor to decide if it should use an async commit (which needs to be done ASAP to serve the intended purpose) or not (in which case the compositor may want to delay the commit as long as possible for minimal latency). >> For legacy, it seems like drivers do what they want. AFAIU, i915 will reject >> (see intel_async_flip_check_uapi etc), and amdgpu will silently fall back to >> vsync (see the `acrtc_state->update_type == UPDATE_TYPE_FAST` check in >> amdgpu_dm_commit_planes). >> >> Maybe one of the drivers is wrong here and should be fixed? >> >> [1]: https://lore.kernel.org/dri-devel/YwiB%2FxQf6Z6ScU+Z@xxxxxxxxx -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and Xwayland developer
