On Thu, Jan 15, 2015 at 08:46:46AM -0500, Rob Clark wrote: > On Wed, Jan 14, 2015 at 7:55 PM, Daniel Vetter <daniel@xxxxxxxx> wrote: > > On Tue, Jan 13, 2015 at 05:18:04PM -0500, Stephane Viau wrote: > >> From: Beeresh Gopal <gbeeresh@xxxxxxxxxxxxxx> > >> > >> This patch implements the hardware accelarated cursor > >> support for MDP5 platforms. > >> > >> Signed-off-by: Beeresh Gopal <gbeeresh@xxxxxxxxxxxxxx> > >> Signed-off-by: Wentao Xu <wentaox@xxxxxxxxxxxxxx> > >> Signed-off-by: Stephane Viau <sviau@xxxxxxxxxxxxxx> > > > > Imo implementing legacy cursor support instead of with universal planes > > makes no sense. Especially since msm is converted to atomic already, and > > you can't move the cursor with atomic when it's legacy only. See the > > cursor argument for the drm_crtc_init_with_planes function and how it's > > used in e.g. i915. > > > > well, I'm still not 100% convinced about going through the whole > atomic mechanism for cursors.. in particular stuff that tries to > enable/disable the cursor at 1000fps, goes *really* badly when things > start waiting for vsync. > > I'll probably try some experiments with it at some point, but at this > point something that works with x11 is a lot more interesting for me > (since every time I switch from mdp4 device to mdp5 device I forget to > disable hw cursor the first time I start x) Well for one this uses the legacy cursor callbacks directly, at least a cursor plane is imo in order. Otoh we just need to fix up the cursor atomic implementation to allow drivers to do fully async updates which get merged down to one update. Which Ville's original atomic stuff already had. So all recoverable by adding a flag somewhere and setting that in the plane_update-on-atomic function. Merging legacy code just because the new stuff isn't 100% perfect yet imo just doesn't make that much sense. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
