mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Alex Bee <knaerzche@gmail.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: "Sandy Huang" <hjc@rock-chips.com>,
	"Heiko Stübner" <heiko@sntech.de>,
	"David Airlie" <airlied@linux.ie>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	"Linux ARM" <linux-arm-kernel@lists.infradead.org>,
	"open list:ARM/Rockchip SoC..."
	<linux-rockchip@lists.infradead.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 0/5] drm: rockchip: various ports for older VOPs
Date: Sat, 25 Jul 2020 15:52:34 +0200	[thread overview]
Message-ID: <47599ce1-2a3b-87eb-c46e-8f7f79ca945e@gmail.com> (raw)
In-Reply-To: <CAKMK7uGKyYea_9MamAQw2=ebjW=raYCDeFCf_5jyyJPHL9AZWA@mail.gmail.com>


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)
> 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


  reply	other threads:[~2020-07-25 13:52 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-22 18:13 Alex Bee
2020-07-22 18:13 ` [PATCH v2 1/5] drm: rockchip: add scaling for RK3036 win1 Alex Bee
2020-07-22 18:13 ` [PATCH v2 2/5] drm: rockchip: add missing registers for RK3188 Alex Bee
2020-07-22 18:13 ` [PATCH v2 3/5] drm: rockchip: add alpha support for RK3036, RK3066, RK3126 and RK3188 Alex Bee
2020-07-22 18:13 ` [PATCH v2 4/5] drm: rockchip: set alpha_en to 0 if it is not used Alex Bee
2020-07-22 18:13 ` [PATCH v2 5/5] drm: rockchip: use overlay windows as such Alex Bee
2020-07-22 21:43 ` [PATCH v2 0/5] drm: rockchip: various ports for older VOPs Daniel Vetter
2020-07-25 13:52   ` Alex Bee [this message]
2020-07-25 15:54     ` Daniel Vetter
2020-07-25 18:48       ` Alex Bee
2020-07-26 10:55         ` Daniel Vetter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47599ce1-2a3b-87eb-c46e-8f7f79ca945e@gmail.com \
    --to=knaerzche@gmail.com \
    --cc=airlied@linux.ie \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=heiko@sntech.de \
    --cc=hjc@rock-chips.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®