Re: [PATCH 0/3] drm/exynos: add support for dynamic zpos in DECON and FIMD

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




18. 12. 11. 오후 4:49에 Andrzej Hajda 이(가) 쓴 글:
> On 11.12.2018 00:45, Inki Dae wrote:
>> Hi Andrzej,
>>
>> 18. 12. 10. 오후 4:35에 Andrzej Hajda 이(가) 쓴 글:
>>> Hi Inki,
>>>
>>> On 10.12.2018 03:25, Inki Dae wrote:
>>>> Hi Andrzej,
>>>>
>>>> 18. 12. 6. 오후 6:38에 Andrzej Hajda 이(가) 쓴 글:
>>>>> Hi Inki,
>>>>>
>>>>> This small patchset adds dynamic zpos support for DECON and FIMD.
>>>> This patch will allow user space to change zpos. However, DECON and FIMD devices have fixed priority of HW overlays.
>>>> This would mean that zpos change by user space doesn't guarantee correct HW overlay priority.
>>>>
>>>> Why do you want to support mutable zpos?
>>>
>>> Practically you have patches which proves it works, you can see that
>>> changing zpos value results in adequate change in displayed image.
>>>
>>> Conceptually it is just a matter of disconnecting hardware windows
>>> present in DECON and FIMD from DRM planes which are software entities.
>>>
>>> You can reason about it this way:
>>>
>>> - drm plane is a framebuffer plus informations how it should be
>>> transformed/displayed on DECON/FIMD,
>>>
>>> - hw window in DECON/FIMD is just a channel through which plane is send
>>> to the display.
>>>
>>> DECON and FIMD has fixed hw windows order - windows with lower numbers
>>> are displayed below windows with higher number. To display planes in
>>> given z-order you just need to send them via windows with appropriate
>>> index - farthest plane should go always via win0, closer one via win1,
>>> ..., till the last plane.
>>>
>>> So for example if you have three planes and want to display them in
>>> following order (first one farthest, last one closest):
>>>
>>> plane2, plane1, plane3
>>>
>>> you should map them to planes as follow:
>>>
>>> plane2 -> win0, plane1 -> win1, plane3 -> win2
>>>
>>> then for example plane2 is disabled, we will have following mapping:
>>>
>>> plane1 -> win0, plane3 -> win1, win2 - disabled
>> Plane1 is displayed below Plane3.
> 
> 
> And this is what we wanted, the initial order was: plane2, plane1,
> plane3, first farthest (or lowest if you prefer this naming schema).
> 
> 
>>
>>> then if you change zorder of planes to: plane3, plane1:
>>>
>>> plane3 -> win0, plane1 -> win1
>> Plane3 is displayed below Plane1 because DECON/FIMD HW aren't able to change HW overlay priroty.
> 
> 
> No, plane3 is displayed below plane1 because we sent it via win0, if we
> want inverse we can send plane3 via win1 and plane1 via win0.
> 
> 
>> However, user space wanted that Plane1 is displayed below Plane3. Like this, zpos change by user space doesn't guarantee correct HW overlay priority.
> 
> 
> As I said before in this example userspace wanted plane3 below plane1,
> and as I wrote in comment above any order of planes user want driver is
> able to realize with this patch.
> 
> 
>> And there is no any reason to change zpos in user space excepting Mixer device which supports HW overlay priority change.
> 
> 
> Lack of special registry for manipulating windows order does not mean it
> cannot support dynamic zpos.
> 

Why changing zpos in user space is required?

> 
>> In fact, we supported mutable zpos before but changed it to immutable with same reason.
> 
> 
> It was just broken if I remember correctly.
> 

No, I worked well and real user used it I remember.

> 
>>
>> Lastly, your patch made real user broken.
> 
> 
> Who? How?

Window server of Tizen didn't work and you can test it with below image - I didn't check why it doesn't. Anyway, we don't have to break real user.
http://download.tizen.org/snapshots/tizen/unified/latest/images/standard/mobile-wayland-armv7l-tm2/

Thanks,
Inki Dae

> 
> 
> Regards
> 
> Andrzej
> 
> 
>>
>> Thanks,
>> Inki Dae
>>
>>>
>>> As you see there is no relation between plane number and window number,
>>> but window number is equal to plane's position in zpos-ordered list of
>>> planes and this is exact value of normalized_zpos field in drm_plane_state.
>>>
>>>
>>> I hope this extended explanation will clarify things.
>>>
>>>
>>> Regards
>>>
>>> Andrzej
>>>
>>>
>>>
>>>> Thanks,
>>>> Inki Dae
>>>>
>>>>> It was tested on tm2 and trats2.
>>>>>
>>>>> Regards
>>>>> Andrzej
>>>>>
>>>>>
>>>>> Andrzej Hajda (3):
>>>>>   drm/exynos/decon5433: add dynamic zpos support
>>>>>   drm/exynos/fimd: create local helper for disabling hardware window
>>>>>   drm/exynos/fimd: add dynamic zpos support
>>>>>
>>>>>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 23 +++++-----
>>>>>  drivers/gpu/drm/exynos/exynos_drm_fimd.c      | 42 ++++++++-----------
>>>>>  2 files changed, 29 insertions(+), 36 deletions(-)
>>>>>
>>>
>>>
>>
> 
> 
> 



[Index of Archives]     [Linux SoC Development]     [Linux Rockchip Development]     [Linux for Synopsys ARC Processors]     [Linux USB Development]     [Video for Linux]     [Linux Audio Users]     [Linux SCSI]     [Yosemite News]

  Powered by Linux