On Wed, 12 Jul 2023 13:57:34 +0000 Simon Ser <contact@xxxxxxxxxxx> wrote: > Explain how to perform front-buffer rendering. > > Signed-off-by: Simon Ser <contact@xxxxxxxxxxx> > Cc: Pekka Paalanen <pekka.paalanen@xxxxxxxxxxxxx> > Cc: Daniel Vetter <daniel.vetter@xxxxxxxx> > --- > drivers/gpu/drm/drm_blend.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c > index 6e74de833466..6c55f1da2480 100644 > --- a/drivers/gpu/drm/drm_blend.c > +++ b/drivers/gpu/drm/drm_blend.c > @@ -75,6 +75,9 @@ > * the currently visible vertical area of the &drm_crtc. > * FB_ID: > * Mode object ID of the &drm_framebuffer this plane should scan out. > + * > + * To perform front-buffer rendering, user-space should set FB_ID to the > + * previous framebuffer in atomic commits. > * CRTC_ID: > * Mode object ID of the &drm_crtc this plane should be connected to. > * It's unclear to me what "previous framebuffer" means, although I know what you want to say. How about: When a KMS client is front-buffer rendering, it should set FB_ID to the same front-buffer FB on each atomic commit. This implies to the driver that it needs to re-read the same FB again. Otherwise drivers who do not employ continuously repeated scanout cycles might not update the screen. Btw. is it enough to set only FB_DAMAGE_CLIPS and not touch FB_ID? Thanks, pq
