On Monday, October 16th, 2023 at 17:10, Ville Syrjälä <ville.syrj...@linux.intel.com> wrote:
> On Mon, Oct 16, 2023 at 05:52:22PM +0300, Pekka Paalanen wrote: > > > On Mon, 16 Oct 2023 15:42:16 +0200 > > André Almeida andrealm...@igalia.com wrote: > > > > > Hi Pekka, > > > > > > On 10/16/23 14:18, Pekka Paalanen wrote: > > > > > > > On Mon, 16 Oct 2023 12:52:32 +0200 > > > > André Almeida andrealm...@igalia.com wrote: > > > > > > > > > Hi Michel, > > > > > > > > > > On 8/17/23 12:37, Michel Dänzer wrote: > > > > > > > > > > > On 8/15/23 20:57, André Almeida wrote: > > > > > > > > > > > > > From: Pekka Paalanen pekka.paala...@collabora.com > > > > > > > > > > > > > > Specify how the atomic state is maintained between userspace and > > > > > > > kernel, plus the special case for async flips. > > > > > > > > > > > > > > Signed-off-by: Pekka Paalanen pekka.paala...@collabora.com > > > > > > > Signed-off-by: André Almeida andrealm...@igalia.com > > > > > > > [...] > > > > > > > > > > > > > +An atomic commit with the flag DRM_MODE_PAGE_FLIP_ASYNC is > > > > > > > allowed to > > > > > > > +effectively change only the FB_ID property on any planes. > > > > > > > No-operation changes > > > > > > > +are ignored as always. [...] > > > > > > > During the hackfest in Brno, it was mentioned that a commit which > > > > > > > re-sets the same FB_ID could actually have an effect with VRR: It > > > > > > > could trigger scanout of the next frame before vertical blank has > > > > > > > reached its maximum duration. Some kind of mechanism is required > > > > > > > for this in order to allow user space to perform low frame rate > > > > > > > compensation. > > > > > > > > > > Xaver tested this hypothesis in a flipping the same fb in a VRR > > > > > monitor > > > > > and it worked as expected, so this shouldn't be a concern. > > > > > Right, so it must have some effect. It cannot be simply ignored like > > > > > in > > > > > the proposed doc wording. Do we special-case re-setting the same FB_ID > > > > > as "not a no-op" or "not ignored" or some other way? > > > > > There's an effect in the refresh rate, the image won't change but it > > > > > will report that a flip had happened asynchronously so the reported > > > > > framerate will be increased. Maybe an additional wording could be > > > > > like: > > > > > > Flipping to the same FB_ID will result in a immediate flip as if it was > > > changing to a different one, with no effect on the image but effecting > > > the reported frame rate. > > > > Re-setting FB_ID to its current value is a special case regardless of > > PAGE_FLIP_ASYNC, is it not? > > No. The rule has so far been that all side effects are observed > even if you flip to the same fb. And that is one of my annoyances > with this proposal. The rules will now be different for async flips > vs. everything else. Well with the patches the async page-flip case is exactly the same as the non-async page-flip case. In both cases, if a FB_ID is included in an atomic commit then the side effects are triggered even if the property value didn't change. The rules are the same for everything.
