Re: [PATCH] drm/omap: Rework the rotation-on-crtc hack

From: Daniel Vetter <daniel.vetter@ffwll.ch>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>,
	Tomi Valkeinen <tomi.valkeinen@ti.com>,
	DRI Development <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH] drm/omap: Rework the rotation-on-crtc hack
Date: Wed, 2 Aug 2017 10:02:20 +0200	[thread overview]
Message-ID: <CAKMK7uEcoJSievoYYL7UUDpFZMPqDcXvtKUS_guLTxnQ+LRukw@mail.gmail.com> (raw)
In-Reply-To: <2563110.xQjJWl2ggy@avalon>

On Tue, Aug 1, 2017 at 12:20 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Tuesday 01 Aug 2017 07:59:13 Maarten Lankhorst wrote:
>> +       pri_state = drm_atomic_get_new_plane_state(crtc->primary,
>> state->state);
>> +       if (pri_state) {
>> +               struct omap_crtc_state *omap_crtc_state =
>> +                       to_omap_crtc_state(state);
>> +
>> +               omap_crtc_state->zpos = pri_state->zpos;
>> +               omap_crtc_state->rotation = pri_state->rotation;
>> +       }
>>
>> That way even when updating the property through the primary plane, it gets
>> reflected correctly. For example when vt switching with fbdev.
>
> Let's not make it over-complicated. This hack is only needed fo the legacy X
> OMAP modesetting driver. The CRTC zpos and rotation properties should not be
> used through the atomic API.

Marten is right, the atomic properties are all such that you can
unconditionally restore them (e.g. fences report a no-op value), to
make compositor switching easier. Not sure anyone implements that, but
I think it's a useful idea to keep. I'll respin (or maybe Maarten
simply submits his patch with a proper sob ...).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel