From: "Ville Syrjälä" <ville.syrjala-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
To: "Kazlauskas,
Nicholas" <Nicholas.Kazlauskas-5C7GfCeVMHo@public.gmane.org>
Cc: "daniel.vetter-/w4YWyX8dFk@public.gmane.org"
<daniel.vetter-/w4YWyX8dFk@public.gmane.org>,
"michel-otUistvHUpPR7s880joybQ@public.gmane.org"
<michel-otUistvHUpPR7s880joybQ@public.gmane.org>,
"dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org"
<dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
"manasi.d.navare-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org"
<manasi.d.navare-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
Pekka Paalanen
<ppaalanen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
"amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org"
<amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
"Deucher,
Alexander" <Alexander.Deucher-5C7GfCeVMHo@public.gmane.org>,
"Olsak, Marek" <Marek.Olsak-5C7GfCeVMHo@public.gmane.org>
Subject: Re: [PATCH v4 3/4] drm: Document variable refresh properties
Date: Fri, 26 Oct 2018 17:53:21 +0300 [thread overview]
Message-ID: <20181026145321.GV9144@intel.com> (raw)
In-Reply-To: <bdda3a3b-c912-98bf-8dbd-29a5b58086df-5C7GfCeVMHo@public.gmane.org>
On Fri, Oct 26, 2018 at 02:49:31PM +0000, Kazlauskas, Nicholas wrote:
> On 10/26/18 7:37 AM, Pekka Paalanen wrote:
> > On Thu, 11 Oct 2018 12:39:41 -0400
> > Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> wrote:
> >
> >> These include the drm_connector 'vrr_capable' and the drm_crtc
> >> 'vrr_enabled' properties.
> >>
> >> Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
> >> ---
> >> Documentation/gpu/drm-kms.rst | 7 +++++++
> >> drivers/gpu/drm/drm_connector.c | 22 ++++++++++++++++++++++
> >> 2 files changed, 29 insertions(+)
> >>
> >> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> >> index 4b1501b4835b..8da2a178cf85 100644
> >> --- a/Documentation/gpu/drm-kms.rst
> >> +++ b/Documentation/gpu/drm-kms.rst
> >> @@ -575,6 +575,13 @@ Explicit Fencing Properties
> >> .. kernel-doc:: drivers/gpu/drm/drm_atomic_uapi.c
> >> :doc: explicit fencing properties
> >>
> >> +
> >> +Variable Refresh Properties
> >> +---------------------------
> >> +
> >> +.. kernel-doc:: drivers/gpu/drm/drm_connector.c
> >> + :doc: Variable refresh properties
> >> +
> >> Existing KMS Properties
> >> -----------------------
> >>
> >> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> >> index f0deeb7298d0..2a12853ca917 100644
> >> --- a/drivers/gpu/drm/drm_connector.c
> >> +++ b/drivers/gpu/drm/drm_connector.c
> >> @@ -1254,6 +1254,28 @@ int drm_mode_create_scaling_mode_property(struct drm_device *dev)
> >> }
> >> EXPORT_SYMBOL(drm_mode_create_scaling_mode_property);
> >>
> >> +/**
> >> + * DOC: Variable refresh properties
> >> + *
> >> + * Variable refresh rate control is supported via properties on the
> >> + * &drm_connector and &drm_crtc objects.
> >> + *
> >> + * "vrr_capable":
> >> + * Optional &drm_connector boolean property that drivers should attach
> >> + * with drm_connector_attach_vrr_capable_property() on connectors that
> >> + * could support variable refresh rates. Drivers should update the
> >> + * property value by calling drm_connector_set_vrr_capable_property().
> >> + *
> >> + * Absence of the property should indicate absence of support.
> >> + *
> >> + * "vrr_enabled":
> >> + * Default &drm_crtc boolean property that notifies the driver that the
> >> + * variable refresh rate adjustment should be enabled for the CRTC.
> >
> > Hi,
> >
> > where is the documentation that explains how drivers must implement
> > "variable refresh rate adjustment"?
> >
> > What should and could userspace expect to get if it flicks this switch?
> >
> > I also think the kernel documentation should include a description of
> > what VRR actually is and how it conceptually works as far as userspace
> > is concerned.
> >
> > That is, the kernel documentation should describe what this thing does,
> > so that we avoid every driver implementing a different thing. For
> > example, one driver could prevent the luminance flickering itself by
> > tuning the timings while another driver might not do that, which means
> > that an application tested on the former driver will look just fine
> > while it is unbearable to watch on the latter.
> >
> >
> > Thanks,
> > pq
>
> I felt it was best to leave this more on the vague side to not impose
> restrictions yet on what a driver must do.
>
> If you think it's worth defining what the "baseline" expectation is for
> userspace, I would probably describe it as "utilizing the monitor's
> variable refresh rate to reduce stuttering or tearing that can occur
> during flipping". This is currently what the amdgpu driver has enabled
> for support. The implementation also isn't much more complex than just
> passing the variable refresh range to the hardware.
>
> I wouldn't want every driver to be forced to implement some sort of
> luminance flickering by default. It's not noticeable on many panels and
> any tuning would inherently add latency to the output. It would probably
> be better left as a new property or a driver specific feature.
>
> In general I would imagine that most future VRR features would end up as
> new properties. Anything that's purely software could be implemented as
> a drm helper that every driver can use. I think the target presentation
> timestamp feature is a good example for that.
Speaking of timestamps. What is the expected behaviour of vblank
timestamps when vrr is enabled?
--
Ville Syrjälä
Intel
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
next prev parent reply other threads:[~2018-10-26 14:53 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-11 16:39 [PATCH v4 0/4] A DRM API for adaptive sync and variable refresh rate support Nicholas Kazlauskas
2018-10-11 16:39 ` [PATCH v4 2/4] drm: Add vrr_enabled property to drm CRTC Nicholas Kazlauskas
2018-10-11 16:39 ` [PATCH v4 3/4] drm: Document variable refresh properties Nicholas Kazlauskas
[not found] ` <20181011163942.28267-4-nicholas.kazlauskas-5C7GfCeVMHo@public.gmane.org>
2018-10-26 11:37 ` Pekka Paalanen
2018-10-26 14:49 ` Kazlauskas, Nicholas
[not found] ` <bdda3a3b-c912-98bf-8dbd-29a5b58086df-5C7GfCeVMHo@public.gmane.org>
2018-10-26 14:53 ` Ville Syrjälä [this message]
[not found] ` <20181026145321.GV9144-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2018-10-26 17:34 ` Kazlauskas, Nicholas
[not found] ` <f21251f7-10e2-e0f7-702d-bd3868ac8edc-5C7GfCeVMHo@public.gmane.org>
2018-10-26 17:59 ` Ville Syrjälä
2018-10-29 16:37 ` Michel Dänzer
[not found] ` <481ae686-adda-5857-5538-2b0af2e25427-otUistvHUpPR7s880joybQ@public.gmane.org>
2018-10-29 18:03 ` Ville Syrjälä
[not found] ` <20181029180341.GN9144-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2018-10-29 19:11 ` Kazlauskas, Nicholas
[not found] ` <3b03a13a-5418-b4fc-137f-2f917b3947d3-5C7GfCeVMHo@public.gmane.org>
2018-10-30 9:07 ` Michel Dänzer
2018-10-30 9:29 ` Michel Dänzer
2018-10-30 15:34 ` Kazlauskas, Nicholas
[not found] ` <1c1c0f6f-ccbd-bfc2-f249-a01f6fc997ec-5C7GfCeVMHo@public.gmane.org>
2018-10-31 13:38 ` Kazlauskas, Nicholas
[not found] ` <311638a8-eb8a-cb8d-3f7a-109aaa4b046b-5C7GfCeVMHo@public.gmane.org>
2018-10-31 14:12 ` Michel Dänzer
2018-10-31 14:41 ` Kazlauskas, Nicholas
2018-10-31 16:20 ` Michel Dänzer
2018-10-31 17:54 ` Kazlauskas, Nicholas
2018-11-01 8:37 ` Pekka Paalanen
[not found] ` <87bcab42-e377-259c-13ea-0cfe9c675cf9-5C7GfCeVMHo@public.gmane.org>
2018-11-01 10:58 ` Michel Dänzer
[not found] ` <99214cf0-9717-3c23-9457-791288d4d252-otUistvHUpPR7s880joybQ@public.gmane.org>
2018-11-01 14:58 ` Kazlauskas, Nicholas
2018-11-01 17:05 ` Michel Dänzer
[not found] ` <8617ac72-ec32-8146-cead-e28e78067ec0-otUistvHUpPR7s880joybQ@public.gmane.org>
2018-11-01 17:19 ` Kazlauskas, Nicholas
2018-10-26 19:13 ` Manasi Navare
2018-10-26 20:06 ` Kazlauskas, Nicholas
2018-10-26 20:58 ` Manasi Navare
2018-10-29 8:36 ` Pekka Paalanen
2018-10-29 14:31 ` Kazlauskas, Nicholas
[not found] ` <20181011163942.28267-1-nicholas.kazlauskas-5C7GfCeVMHo@public.gmane.org>
2018-10-11 16:39 ` [PATCH v4 1/4] drm: Add vrr_capable property to the drm connector Nicholas Kazlauskas
2018-10-11 16:39 ` [PATCH v4 4/4] drm/amd/display: Set FreeSync state using drm VRR properties Nicholas Kazlauskas
[not found] ` <20181011163942.28267-5-nicholas.kazlauskas-5C7GfCeVMHo@public.gmane.org>
2018-10-11 20:39 ` Harry Wentland
[not found] ` <42b237df-9c30-4cd0-0891-d0b05b54533e-5C7GfCeVMHo@public.gmane.org>
2018-10-11 20:56 ` Kazlauskas, Nicholas
2018-10-11 21:24 ` Harry Wentland
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=20181026145321.GV9144@intel.com \
--to=ville.syrjala-vuqaysv1563yd54fqh9/ca@public.gmane.org \
--cc=Alexander.Deucher-5C7GfCeVMHo@public.gmane.org \
--cc=Marek.Olsak-5C7GfCeVMHo@public.gmane.org \
--cc=Nicholas.Kazlauskas-5C7GfCeVMHo@public.gmane.org \
--cc=amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=daniel.vetter-/w4YWyX8dFk@public.gmane.org \
--cc=dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=manasi.d.navare-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=michel-otUistvHUpPR7s880joybQ@public.gmane.org \
--cc=ppaalanen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
/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;
as well as URLs for NNTP newsgroup(s).