On Tue, Jun 30, 2015 at 11:59:30AM +0530, Ramalingam C wrote: > > On Monday 29 June 2015 09:57 PM, Daniel Vetter wrote: > >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. > If panel does support the static DRRS only and you are ok to do a complete > modeset on a usecase then > Whatever you have explained stands true for content based DRRS. I believe > its another complete modeset w.r.t kernel. > Which I am not addressing in this RFC. > > But If the panel supports seamless DRRS and userspace want a precise > vrefresh rate (adjusted to the > content, within the limits of what panel can do) then kernel can achieve the > vrefresh change seamlessly > (the way its done with Idleness scenario). This is the second usecase of > seamless DRRS support of the panel. > Infact We have implemented this and verified on android already for video > playback. > > > >Seamless DRRS for me is when the kernel tries to change vrefresh when > >everything is idle behind everyone's back. > Seamless DRRS is a capability of the host and the panel. Usercase definition > is upto us to do. > > > >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. > Based on above usecase of the seamless drrs we need a fast modeset path > which I have addressed at the RFC PATCH 16/18. > And drm connector property to expose the SEAMLESS DRRS capability to the > userspace. implemented at RFC PATCH 18/18 Summarizing our discussion from the mtg, there's 3 different cases here: - transparent seamless DRRS where the kernel lowers vrefresh on idle behind userspace's back. This is what we currently have integrated. No new ABI required. - seamless DRRS but upon explicit request from userspace. This is essentially just a mode change, but excuted by the kernel without any blanking or otherwise stalling. We can reuse the modeset ioctls for this, just need a fast path (similar to the fast pfit update Maarten already has in his atomic branches). For figuring out whether seamless is possible we could reuse the atomic TEST_ONLY and ALLOW_MODESET flags. Good chances that we don't need a new ABI. - just changing the vrefresh of the panel, with full modeset/blanking. We have the interface for that (we can do modesets), but currently our panel compute_config code hardcodes the vrefresh to the preferred mode of the panel. We need to change that and pick the vrefresh userspace asked for. I think from an implementation pov it makes sense to first fix up this case, and then in a 2nd step implement the seamless DRRS for explicit mode changes. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
