Hi,
On 13/02/2024 13:39, Daniel Stone wrote:
Hi,
On Tue, 13 Feb 2024 at 10:18, Marius Vlad <marius.vlad@xxxxxxxxxxxxx> wrote:
On Tue, Feb 13, 2024 at 11:57:59AM +0200, Tomi Valkeinen wrote:
I haven't. I'm quite unfamiliar with Weston, and Randolph from TI (cc'd) has
been working on the Weston side of things. I also don't know if there's
something TI specific here, as the use case is with non-mainline GPU drivers
and non-mainline Mesa. I should have been a bit clearer in the patch
description, as I didn't mean that upstream Weston has a bug (maybe it has,
maybe it has not).
Don't worry about it. We've had bugs in the past and I'm sure we'll
have more. :) Either way, it's definitely better to have the kernel
expose sensible behaviour rather than weird workarounds, unless
they've been around for so long that they're basically baked into ABI.
Yeah, that's always a worry. I do hope that no user of tidss expects the
plane zpos values to be the current funny ones. But we'll probably find
out when I merge this =).
The issue seen is that when Weston decides to use DRM planes for
composition, the plane zpositions are not configured correctly (or at all?).
Afaics, this leads to e.g. weston showing a window with a DRM "overlay"
plane that is behind the "primary" root plane, so the window is not visible.
And as Weston thinks that the area supposedly covered by the overlay plane
does not need to be rendered on the root plane, there are also artifacts on
that area.
Also, the Weston I used is a bit older one (10.0.1), as I needed to go back
in my buildroot versions to get all that non-mainline GPU stuff compiled and
working. A more recent Weston may behave differently.
Right after Weston 10, we had a few minor changes related to the
zpos-sorting list of planes and how we parse the plan list without having
a temporary zpos ordered list to pick planes from.
And there's another fix for missing out to set out the zpos for scanout
to the minimum available - which seems like a good candidate to explain
what happens in the issue described above. So if trying Weston again,
please try with at least Weston 12, which should have those changes
in.
Specifically, you probably want commits 4cde507be6a1 and 58dde0e0c000.
I think the window of breakage was small enough that - assuming either
those commits or an upgrade to Weston 12/13 fixes it - we can just ask
people to upgrade to a fixed Weston.
Presuming this is not related to any TI specific code, I guess it's a
regression in the sense that at some point Weston added the support to use
planes for composition, so previously with only a single plane per display
there was no issue.
That point was 12 years ago, so not that novel. ;)
Hmm, so do I understand it right, the plane code from 12 years back
supposedly works ok, but somewhere around Weston 10 something broke, but
was fixed with the commits you mention above?
Tomi
