lkml.org 
[lkml]   [2020]   [Jul]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH v2 0/5] drm: rockchip: various ports for older VOPs
    From
    Date

    Am 25.07.20 um 17:54 schrieb Daniel Vetter:
    > On Sat, Jul 25, 2020 at 3:52 PM Alex Bee <knaerzche@gmail.com> wrote:
    >>
    >> Am 22.07.20 um 23:43 schrieb Daniel Vetter:
    >>> On Wed, Jul 22, 2020 at 8:13 PM Alex Bee <knaerzche@gmail.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

    \
     
     \ /
      Last update: 2020-07-25 20:48    [W:3.118 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site