On 11.12.2018 09:01, Inki Dae wrote: > > 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/ Are you saying it works with latest mainline without my patches? Regards Andrzej > > 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(-) >>>>>> >>>> >> >> >
