From: Lucas Stach <l.stach@pengutronix.de>
To: Sven Van Asbroeck <thesven73@gmail.com>
Cc: Philipp Zabel <pza@pengutronix.de>,
Nicolas Dufresne <nicolas@ndufresne.ca>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Adrian Ratiu <adrian.ratiu@collabora.com>,
Fabio Estevam <festevam@gmail.com>,
linux-media <linux-media@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [BUG REPORT] media: coda: mpeg4 decode corruption on i.MX6qp only
Date: Mon, 15 Feb 2021 17:10:43 +0100 [thread overview]
Message-ID: <21810344a6b3659e2084727a9e7950133bf294ac.camel@pengutronix.de> (raw)
In-Reply-To: <CAGngYiWxMsko2+6NUt4N0GyBUq4Axz4TRiUrF2ZjNGvZZkTO8A@mail.gmail.com>
Am Montag, dem 15.02.2021 um 10:54 -0500 schrieb Sven Van Asbroeck:
> Hi Lucas,
>
> On Mon, Feb 15, 2021 at 5:15 AM Lucas Stach <l.stach@pengutronix.de> wrote:
> >
> > The straight forward way to fix this would be to just disable the PRE
> > when the stride is getting too large, which might not work well with
> > all userspace requirements, as it effectively disables the ability to
> > scan GPU tiled surfaces when the stride is getting too large.
>
> Thank you for your very knowledgeable input, really appreciate it.
>
> I am wondering why I am the first to notice this particular corner
> case. Is this perhaps because X+armada plugin allocate a huge bitmap
> that fits all displays, and other software frameworks do not? Are
> people on i.MX6 mostly using X or Wayland? If Wayland allocates a
> separate bitmap for each display, this PRE bug will of course never
> show up...
Yep, I really doubt that there are a lot i.MX6QP, multi-display, X.Org
based devices out there.
While it's not anywhere in a protocol or similar fixed API, Wayland
compositors mostly opted to have a separate surface per display. The
weston reference compositor started out this way (as it makes surface
repaint easier) and other followed the lead, so Wayland based stacks
won't hit this case.
Regards,
Lucas
prev parent reply other threads:[~2021-02-15 17:16 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-03 16:33 [BUG REPORT] media: coda: mpeg4 decode corruption on i.MX6qp only Sven Van Asbroeck
2021-02-10 16:11 ` Nicolas Dufresne
2021-02-10 18:11 ` Sven Van Asbroeck
2021-02-10 18:29 ` Sven Van Asbroeck
2021-02-11 14:32 ` Philipp Zabel
2021-02-11 15:15 ` Sven Van Asbroeck
2021-02-12 23:52 ` Sven Van Asbroeck
2021-02-15 10:15 ` Lucas Stach
2021-02-15 15:54 ` Sven Van Asbroeck
2021-02-15 16:10 ` Lucas Stach [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=21810344a6b3659e2084727a9e7950133bf294ac.camel@pengutronix.de \
--to=l.stach@pengutronix.de \
--cc=adrian.ratiu@collabora.com \
--cc=festevam@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=nicolas@ndufresne.ca \
--cc=pza@pengutronix.de \
--cc=thesven73@gmail.com \
/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).