Message-ID: <263c5e9b-d6fb-41a8-9d8a-84ea49eef51c@ideasonboard.com>
Date: Fri, 16 Feb 2024 11:00:17 +0200
From: Tomi Valkeinen <tomi.valkeinen@...asonboard.com>
To: Daniel Stone <daniel@...ishbar.org>,
 Marius Vlad <marius.vlad@...labora.com>
Cc: Pekka Paalanen <pekka.paalanen@...oniitty.fi>,
 Jyri Sarha <jyri.sarha@....fi>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>,
 David Airlie <airlied@...il.com>, Daniel Vetter <daniel@...ll.ch>,
 Sam Ravnborg <sam@...nborg.org>, Devarsh Thakkar <devarsht@...com>,
 Aradhya Bhatia <a-bhatia1@...com>, Francesco Dolcini <francesco@...cini.it>,
 Tomi Valkeinen <tomi.valkeinen@...com>, dri-devel@...ts.freedesktop.org,
 linux-kernel@...r.kernel.org,
 "wayland-devel@...ts.freedesktop.org" <wayland-devel@...ts.freedesktop.org>,
 Randolph Sapp <rs@...com>
Subject: Re: [PATCH 1/2] drm/tidss: Fix initial plane zpos values

Hi,

On 13/02/2024 13:39, Daniel Stone wrote:
> Hi,
> 
> On Tue, 13 Feb 2024 at 10:18, Marius Vlad <marius.vlad@...labora.com> 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

Powered by blists - more mailing lists