From: Boris Brezillon <bbrezillon@kernel.org>
To: Peter Rosin <peda@axentia.se>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>,
David Airlie <airlied@linux.ie>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
Boris Brezillon <boris.brezillon@bootlin.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 0/4] drm/atmel-hlcdc: fix plane clipping/rotation issues
Date: Thu, 31 Jan 2019 14:21:55 +0100 [thread overview]
Message-ID: <20190131142155.574d1337@bbrezillon> (raw)
In-Reply-To: <d2e24b73-dee1-b31a-dc87-02d2e75b6dd2@axentia.se>
On Thu, 31 Jan 2019 13:13:22 +0000
Peter Rosin <peda@axentia.se> wrote:
> On 2019-01-27 09:27, Boris Brezillon wrote:
> > On Thu, 10 Jan 2019 15:10:28 +0000
> > Peter Rosin <peda@axentia.se> wrote:
> >
> >> Hi!
> >>
> >> I found an unfortunate issue while recoding plane handling to use
> >> drm_atomic_helper_check_plane_state(). The driver rotates clockwise,
> >> which is not correct. I simply fixed it (patch 1/4), but maybe that
> >> will cause regressions for unsuspecting users who simply assumed
> >> that the clockwise rotation was correct? I don't know what to do
> >> about that? Adding an option to get the old broken behavior seems
> >> useless, wouldn't it be just as easy to just fix whatever app to
> >> rotate the other way instead of adding an option somewhere?
> >>
> >> I have only tested this series on sama5d3, but I did check the docs
> >> for various other chips (sama5d2, sama5d4, sam9n12, sam9g15, sam9g35
> >> and sam9x35) supported by the driver (relevant to patch 4/4).
> >>
> >> Cheers,
> >> Peter
> >>
> >> Peter Rosin (4):
> >> drm/atmel-hlcdc: rotate planes counterclockwise
> >> drm/atmel-hlcdc: do not swap w/h of the crtc when a plane is rotated
> >> drm/atmel-hlcdc: fix clipping of planes
> >
> > Queued patches 1-3 to drm-misc-next.
>
> Great, thanks.
>
> >> drm/atmel-hlcdc: do not immediately disable planes, wait for next
> >> frame
> >
> > Still waiting for Nicolas feedback on this one.
>
> [Adding back Nicolas, he seems to have gone missing from the list
> recipients.]
>
> I have done some testing of that patch and for me it's a definite
> improvement. The test I did was removing a white plane from a white
> background. Without the patch, the driver will output black where
> the plane was for the current frame (since the driver does that
> disc-area thing for the largest hidden part of the background).
> With the patch, I get no visual glitches when removing a plane.
>
> I use a plane to scroll a text, and if you know what to look for,
> the black rectangle that flickers by as the plane with the scrolling
> text is removed is little bit disturbing. Not a significant problem,
> and maybe only geeks notice it, but still...
>
> Just wanted to say that the resulting "black hole" mentioned in the
> other thread really does exist and that the patch may make sense
> beyond the fact that it removes usage of undocumented features.
>
> I have not seen any bad side effects fro the patch, but admittedly
> my testing was very limited and I did not try to remove the plane
> while doing other stuff with the driver. So, there might still be
> reasons for removing planes immediately...
Since everything is now synchronized on vsync events thanks to the
atomic modeset infra (including plane/crtc disable requests), I think
the problem I was trying to fix at the time no longer exists (might
re-appear if we start supporting async plane disable requests which is
anyway not supported by the core). So I think I'll just apply your
patch.
Thanks,
Boris
prev parent reply other threads:[~2019-01-31 13:22 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-10 15:10 [PATCH 0/4] drm/atmel-hlcdc: fix plane clipping/rotation issues Peter Rosin
2019-01-10 15:10 ` [PATCH 1/4] drm/atmel-hlcdc: rotate planes counterclockwise Peter Rosin
2019-01-10 15:10 ` [PATCH 2/4] drm/atmel-hlcdc: do not swap w/h of the crtc when a plane is rotated Peter Rosin
2019-01-10 17:48 ` Boris Brezillon
2019-01-11 13:29 ` Peter Rosin
2019-01-11 14:14 ` Nicolas.Ferre
2019-01-10 15:10 ` [PATCH 3/4] drm/atmel-hlcdc: fix clipping of planes Peter Rosin
2019-01-10 15:10 ` [PATCH 4/4] drm/atmel-hlcdc: do not immediately disable planes, wait for next frame Peter Rosin
2019-01-10 17:29 ` Boris Brezillon
2019-01-10 18:51 ` Peter Rosin
2019-01-10 19:25 ` Boris Brezillon
2019-01-11 14:29 ` Peter Rosin
2019-01-16 14:45 ` Boris Brezillon
2019-01-10 17:45 ` [PATCH 0/4] drm/atmel-hlcdc: fix plane clipping/rotation issues Boris Brezillon
2019-01-10 20:16 ` Sam Ravnborg
2019-01-11 9:16 ` Peter Rosin
2019-01-10 21:24 ` Peter Rosin
2019-01-11 14:18 ` Nicolas.Ferre
2019-01-27 8:27 ` Boris Brezillon
2019-01-31 13:13 ` Peter Rosin
2019-01-31 13:21 ` Boris Brezillon [this message]
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=20190131142155.574d1337@bbrezillon \
--to=bbrezillon@kernel.org \
--cc=airlied@linux.ie \
--cc=alexandre.belloni@bootlin.com \
--cc=boris.brezillon@bootlin.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peda@axentia.se \
/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;
as well as URLs for NNTP newsgroup(s).