Re: [PATCH 2/2] drm/msm/mdp5: Add hardware cursor support

[Rob Clark]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/