[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0e5f6e41-5fa4-2989-f4b8-89a9471db931@gmail.com>
Date: Sat, 25 Jul 2020 20:48:03 +0200
From: Alex Bee <knaerzche@...il.com>
To: Daniel Vetter <daniel@...ll.ch>
Cc: Sandy Huang <hjc@...k-chips.com>,
Heiko Stübner <heiko@...ech.de>,
David Airlie <airlied@...ux.ie>,
dri-devel <dri-devel@...ts.freedesktop.org>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
"open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 0/5] drm: rockchip: various ports for older VOPs
Am 25.07.20 um 17:54 schrieb Daniel Vetter:
> On Sat, Jul 25, 2020 at 3:52 PM Alex Bee <knaerzche@...il.com> wrote:
>>
>> Am 22.07.20 um 23:43 schrieb Daniel Vetter:
>>> On Wed, Jul 22, 2020 at 8:13 PM Alex Bee <knaerzche@...il.com> wrote:
>>>> Hi,
>>>>
>>>> this series mainly ports existining functionality to older SoCs - most
>>>> importantly enables alpha blending for RK3036, RK3066, RK3126 and
>>>> RK3188.
>>>> Besides that, it also changes the window type from DRM_PLANE_TYPE_CURSOR
>>>> to DRM_PLANE_TYPE_OVERLAY for VOPs that have only one (1) overlay window.
>>> This doesn't make much sense, the cursor overlay is really just a hint
>>> for legacy ioctls that this is the overlay that should be used for
>>> cursors. Compositors should try to use such planes as full overlays
>>> (if they don't want to use them as a cursor). So sounds like a case of
>>> "fix your compositor".
>> I agree here - but: If HWC windows would have been implemented in this
>> particular driver, their max size would be 128x128 on some SoCs - so
>> they woudn't be really suitable to create an OSD overlay at 4K, for
>> example. I don't know, but I guess other vendors implement their HWC
>> windows on this reduced HW resources as well. I guess that is one of the
>> reasons, why userspace, which aims to be cross-plattfrom, avoids
>> DRM_PLANE_TYPE_CURSOR when its looking for an usable overlay plane. (a
>> heuristic, indeed)
> Which userspace does that?
kodi-gbm:
https://github.com/xbmc/xbmc/blob/master/xbmc/windowing/gbm/DRMUtils.cpp#L406
> We should fix that, not try to work around
> that in all the drivers in upstream, that wont work.
You're right I'll drop this part.
> -Daniel
>
>>> For atomic there's 0 difference between a overlay or a cursor (primary
>>> plane is still treated somewhat special in the RMFB ioctl, but again
>>> that's for backwards compat reasons with existing uapi, not because
>>> the primary plane is different).
>>>
>>> What does happen though is that this breaks cursor for legacy
>>> userspace, which is probably not really what you want.
>> Indeed not.
>>
>> Beforhand I was submiiting this, I looked arround and couldn't find
>> anything which relies or even depends of a cursor window to be
>> available. Even if: as per spec only one DRM_PLANE_TYPE_PRIMARY is
>> mandatory, everything else is optional.
>>
>>> -Daniel
>>>
>>>
>>>> Regards,
>>>> Alex
>>>>
>>>> Changes in v2:
>>>> - drop not yet upstreamed dsp_data_swap from RK3188 regs
>>>> - rephrase most commit messages
>>>>
>>>> Alex Bee (5):
>>>> drm: rockchip: add scaling for RK3036 win1
>>>> drm: rockchip: add missing registers for RK3188
>>>> drm: rockchip: add alpha support for RK3036, RK3066, RK3126 and RK3188
>>>> drm: rockchip: set alpha_en to 0 if it is not used
>>>> drm: rockchip: use overlay windows as such
>>>>
>>>> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 1 +
>>>> drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 42 ++++++++++++++++++---
>>>> drivers/gpu/drm/rockchip/rockchip_vop_reg.h | 1 +
>>>> 3 files changed, 38 insertions(+), 6 deletions(-)
>>>>
>>>> --
>>>> 2.17.1
>>>>
>>> --
>>> Daniel Vetter
>>> Software Engineer, Intel Corporation
>>> http://blog.ffwll.ch
>> Best Regards
>>
>
Best regards
Powered by blists - more mailing lists