On Fri, Jan 16, 2015 at 11:06 PM, Daniel Vetter <daniel@xxxxxxxx> wrote: > 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. something that could merge multiple intra-vsync updates would, I think, make cursor planes usable > Merging legacy code just because the new stuff isn't 100% perfect yet imo > just doesn't make that much sense. but merging legacy because new stuff isn't usable yet does ;-) BR, -R > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
