dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Sam Ravnborg <sam@ravnborg.org>
To: Alex Deucher <alexdeucher@gmail.com>
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>,
	David Airlie <airlied@linux.ie>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	Liviu Dudau <liviu.dudau@arm.com>,
	Maling list - DRI developers <dri-devel@lists.freedesktop.org>,
	Thomas Zimmermann <tzimmermann@suse.de>
Subject: Re: [PATCH v2 1/3] drm/vblank: Add intro to documentation
Date: Tue, 7 Apr 2020 18:42:32 +0200	[thread overview]
Message-ID: <20200407164232.GA2220@ravnborg.org> (raw)
In-Reply-To: <CADnq5_MtFw5KaNCW8G8RvxYW7S4-KoZg5-6GSn-59TS-QvOBYQ@mail.gmail.com>

Hi Alex.

On Tue, Apr 07, 2020 at 10:42:46AM -0400, Alex Deucher wrote:
> On Mon, Apr 6, 2020 at 3:48 PM Sam Ravnborg <sam@ravnborg.org> wrote:
> >
> > Lyude Paul wrote a very good intro to vblank here:
> > https://lore.kernel.org/dri-devel/faf63d8a9ed23c16af69762f59d0dca6b2bf085f.camel@redhat.com/T/#mce6480be738160e9d07c5d023e88fd78d7a06d27
> >
> > Add this to the intro chapter in drm_vblank.c so others
> > can benefit from it too.
> >
> > v2:
> >   - Reworded to improve readability (Thomas)
> >
> > v3:
> >   - Added nice ascii drawing from Lyude (Lyude)
> >   - Added referende to high-precision timestamp (Daniel)
> >   - Improved grammar (Thomas)
> >   - Combined it all and made kernel-doc happy
> >   - Dropped any a-b, r-b do to the amount of changes
> >
> > Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
> > Co-developed-by: Lyude Paul <lyude@redhat.com>
> > Cc: Lyude Paul <lyude@redhat.com>
> > Cc: Thomas Zimmermann <tzimmermann@suse.de>
> > Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > Cc: Maxime Ripard <mripard@kernel.org>
> > Cc: Thomas Zimmermann <tzimmermann@suse.de>
> > Cc: David Airlie <airlied@linux.ie>
> > ---
> >  drivers/gpu/drm/drm_vblank.c | 53 ++++++++++++++++++++++++++++++++++++
> >  1 file changed, 53 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> > index bcf346b3e486..9633092c9ad5 100644
> > --- a/drivers/gpu/drm/drm_vblank.c
> > +++ b/drivers/gpu/drm/drm_vblank.c
> > @@ -41,6 +41,59 @@
> >  /**
> >   * DOC: vblank handling
> >   *
> > + * From the computer's perspective, every time the monitor displays
> > + * a new frame the scanout engine have "scanned out" the display image
> > + * from top to bottom, one row of pixels at a time.
> > + * The current row of pixels is referred to as the current scanline.
> > + *
> > + * In addition to the display's visible area, there's usually a couple of
> > + * extra scanlines which aren't actually displayed on the screen.
> > + * These extra scanlines don't contain image data and are occasionally used
> > + * for features like audio and infoframes. The region made up of these
> > + * scanlines is referred to as the vertical blanking region, or vblank for
> > + * short.
> 
> For historical reference, the vertical blanking period was designed to
> give the electron gun (on CRTs) enough time to move back to the top of
> the screen to start scanning out the next frame.  Similar for
> horizontal blanking periods.  They were designed to give the electron
> gun enough time to move back to the other side of the screen to start
> scanning the next scanline.  Might be worth adding something like
> that.  Either way:
> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>

Thanks. Added this nice historical lesson and committed
and pushed out.
And to all, thanks for the inputs. We managed to improve this piece
of the documetation.

	Sam

> 
> > + *
> > + * ::
> > + *
> > + *
> > + *    physical →   ⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽
> > + *    top of      |                                        |
> > + *    display     |                                        |
> > + *                |               New frame                |
> > + *                |                                        |
> > + *                |↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓|
> > + *                |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| ← Scanline, updates
> > + *                |↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓|   the frame as it
> > + *                |                                        |   travels down
> > + *                |                                        |   ("scan out")
> > + *                |                                        |
> > + *                |               Old frame                |
> > + *                |                                        |
> > + *                |                                        |
> > + *                |                                        |
> > + *                |                                        |   physical
> > + *                |                                        |   bottom of
> > + *    vertical    |⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽| ← display
> > + *    blanking    ┆xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx┆
> > + *    region   →  ┆xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx┆
> > + *                ┆xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx┆
> > + *    start of →   ⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽
> > + *    new frame
> > + *
> > + * "Physical top of display" is the reference point for the high-precision/
> > + * corrected timestamp.
> > + *
> > + * On a lot of display hardware, programming needs to take effect during the
> > + * vertical blanking period so that settings like gamma, the image buffer
> > + * buffer to be scanned out, etc. can safely be changed without showing
> > + * any visual artifacts on the screen. In some unforgiving hardware, some of
> > + * this programming has to both start and end in the same vblank.
> > + *
> > + * The vblank interrupt may be fired at different points depending on the
> > + * hardware. Some hardware implementations will fire the interrupt when the
> > + * new frame start, other implementations will fire the interrupt at different
> > + * points in time.
> > + *
> >   * Vertical blanking plays a major role in graphics rendering. To achieve
> >   * tear-free display, users must synchronize page flips and/or rendering to
> >   * vertical blanking. The DRM API offers ioctls to perform page flips
> > --
> > 2.20.1
> >
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2020-04-07 16:42 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-06 19:47 [PATCH v2 0/3] drm: kernel-doc stuff Sam Ravnborg
2020-04-06 19:47 ` [PATCH v2 1/3] drm/vblank: Add intro to documentation Sam Ravnborg
2020-04-06 22:53   ` Lyude Paul
2020-04-07  6:24   ` Thomas Zimmermann
2020-04-07 12:03   ` Liviu Dudau
2020-04-07 14:42   ` Alex Deucher
2020-04-07 16:42     ` Sam Ravnborg [this message]
2020-04-06 19:47 ` [PATCH v2 2/3] drm: writeback: document callbacks Sam Ravnborg
2020-04-07 12:04   ` Liviu Dudau
2020-04-07 15:51     ` Sam Ravnborg
2020-04-06 19:47 ` [PATCH v2 3/3] drm/writeback: wire drm_writeback.h to kernel-doc Sam Ravnborg
2020-04-07  8:08   ` Daniel Vetter
2020-04-07 15:51     ` Sam Ravnborg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200407164232.GA2220@ravnborg.org \
    --to=sam@ravnborg.org \
    --cc=airlied@linux.ie \
    --cc=alexdeucher@gmail.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=laurent.pinchart+renesas@ideasonboard.com \
    --cc=liviu.dudau@arm.com \
    --cc=tzimmermann@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox