Re: [RFC PATCH 00/18] Generic DRRS implementation across the encoders

Daniel Vetter
2015-06-29T16:24:53Z

On Mon, Jun 29, 2015 at 04:52:14PM +0530, Ramalingam C wrote:
> On Friday 26 June 2015 10:46 PM, Daniel Vetter wrote:
> >On Fri, Jun 26, 2015 at 07:21:44PM +0530, Ramalingam C wrote:
> >- Static DRRS and generalized seamless DRRS are imo separate features and
> > we should split the patch series. seamless DRRS is already implemented
> > using the fb tracking, maybe extended with some hints to userspace.
> >
> > Static DRRS otoh is just a modeset with a different clock (plus a better
> > internal implementation to avoid flicker). So from that pov two
> > completely different features, both in the implementation and the
> > userspace ABI.
> Yup. Static is not even in our development radar :). All the code that I
> have shared is
> concerned only with seamless DRRS and it's two usecase scenarios( Idleness
> and Content based).
> Mentioned the Static DRRS in cover letter, just to give the two different
> DRRS supports available in general.

Hm then I'm confused how the content based DRRS is supposed to work. I
thought userspace requires a precise vrefresh rate (adjusted to content,
within the limits of what the panel can do ofc) and the kernel tries to
obey. That's what I consider static DRRS, i.e. userspace makes a fixed
request, kernel executes it exactly.

Seamless DRRS for me is when the kernel tries to change vrefresh when
everything is idle behind everyone's back.

I'm doing this split since seamless doesn't require new userspace
interfaces (we just use the frontbuffer tracking system), whereas static
needs explicit action from userspace and hence the dreaded userspace ABI
problem starts to kick in.

Do you have different definitions? What exactly are those?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation