Two fixes for tidss: The first one helps Weston deal with the planes,
the second fixes a possible sync-lost issue with multiple displays.
Signed-off-by: Tomi Valkeinen <[email protected]>
---
Tomi Valkeinen (2):
drm/tidss: Fix initial plane zpos values
drm/tidss: Fix sync-lost issue with two displays
drivers/gpu/drm/tidss/tidss_crtc.c | 10 ++++++++++
drivers/gpu/drm/tidss/tidss_plane.c | 2 +-
2 files changed, 11 insertions(+), 1 deletion(-)
---
base-commit: 423af970da74db7eed1b14f2b7f115714a67aeb8
change-id: 20240213-tidss-fixes-cc3741cd604c
Best regards,
--
Tomi Valkeinen <[email protected]>
When the driver sets up the zpos property it sets the default zpos value
to the HW id of the plane. That is fine as such, but as on many DSS
versions the driver arranges the DRM planes in a different order than
the HW planes (to keep the non-scalable planes first), this leads to odd
initial zpos values. An example is J721e, where the initial zpos values
for DRM planes are 1, 3, 0, 2.
In theory the userspace should configure the zpos values properly when
using multiple planes, and in that sense the initial zpos values
shouldn't matter, but there's really no reason not to fix this and help
the userspace apps which don't handle zpos perfectly. In particular,
Weston seems to have issues dealing with the planes with the current
default zpos values.
So let's change the zpos values for the DRM planes to 0, 1, 2, 3.
Another option would be to configure the planes marked as primary planes
to zpos 0. On a two display system this would give us plane zpos values
of 0, 0, 1, 2. The end result and behavior would be very similar in this
option, and I'm not aware that this would actually help us in any way.
So, to keep the code simple, I opted for the 0, 1, 2, 3 values.
Signed-off-by: Tomi Valkeinen <[email protected]>
Fixes: 32a1795f57ee ("drm/tidss: New driver for TI Keystone platform Display SubSystem")
---
drivers/gpu/drm/tidss/tidss_plane.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tidss/tidss_plane.c b/drivers/gpu/drm/tidss/tidss_plane.c
index e1c0ef0c3894..68fed531f6a7 100644
--- a/drivers/gpu/drm/tidss/tidss_plane.c
+++ b/drivers/gpu/drm/tidss/tidss_plane.c
@@ -213,7 +213,7 @@ struct tidss_plane *tidss_plane_create(struct tidss_device *tidss,
drm_plane_helper_add(&tplane->plane, &tidss_plane_helper_funcs);
- drm_plane_create_zpos_property(&tplane->plane, hw_plane_id, 0,
+ drm_plane_create_zpos_property(&tplane->plane, tidss->num_planes, 0,
num_planes - 1);
ret = drm_plane_create_color_properties(&tplane->plane,
--
2.34.1
A sync lost issue can be observed with two displays, when moving a plane
from one disabled display to an another disabled display, and then
enabling the display to which the plane was moved to. The exact
requirements for this to trigger are not clear.
It looks like the issue is that the layers are left enabled in the first
display's OVR registers. Even if the corresponding VP is disabled, it
still causes an issue, as if the disabled VP and its OVR would still be
in use, leading to the same VID being used by two OVRs. However, this is
just speculation based on testing the DSS behavior.
Experimentation shows that as a workaround, we can disable all the
layers in the OVR when disabling a VP. There should be no downside to
this, as the OVR is anyway effectively disabled if its VP is disabled,
and it seems to solve the sync lost issue.
However, there may be a bigger issue in play here, related to J721e
erratum i2097 ("DSS: Disabling a Layer Connected to Overlay May Result
in Synclost During the Next Frame"). Experimentation also shows that the
OVR's CHANNELIN field has similar issue. So we may need to revisit this
when we find out more about the core issue.
Signed-off-by: Tomi Valkeinen <[email protected]>
Fixes: 32a1795f57ee ("drm/tidss: New driver for TI Keystone platform Display SubSystem")
---
drivers/gpu/drm/tidss/tidss_crtc.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/tidss/tidss_crtc.c b/drivers/gpu/drm/tidss/tidss_crtc.c
index 5f838980c7a1..94f8e3178df5 100644
--- a/drivers/gpu/drm/tidss/tidss_crtc.c
+++ b/drivers/gpu/drm/tidss/tidss_crtc.c
@@ -265,6 +265,16 @@ static void tidss_crtc_atomic_disable(struct drm_crtc *crtc,
reinit_completion(&tcrtc->framedone_completion);
+ /*
+ * If a layer is left enabled when the videoport is disabled, and the
+ * vid pipeline that was used for the layer is taken into use on
+ * another videoport, the DSS will report sync lost issues. Disable all
+ * the layers here as a work-around.
+ */
+ for (u32 layer = 0; layer < tidss->feat->num_planes; layer++)
+ dispc_ovr_enable_layer(tidss->dispc, tcrtc->hw_videoport, layer,
+ false);
+
dispc_vp_disable(tidss->dispc, tcrtc->hw_videoport);
if (!wait_for_completion_timeout(&tcrtc->framedone_completion,
--
2.34.1
On Tue, 13 Feb 2024 10:16:36 +0200
Tomi Valkeinen <[email protected]> wrote:
> When the driver sets up the zpos property it sets the default zpos value
> to the HW id of the plane. That is fine as such, but as on many DSS
> versions the driver arranges the DRM planes in a different order than
> the HW planes (to keep the non-scalable planes first), this leads to odd
> initial zpos values. An example is J721e, where the initial zpos values
> for DRM planes are 1, 3, 0, 2.
>
> In theory the userspace should configure the zpos values properly when
> using multiple planes, and in that sense the initial zpos values
> shouldn't matter, but there's really no reason not to fix this and help
> the userspace apps which don't handle zpos perfectly. In particular,
> Weston seems to have issues dealing with the planes with the current
> default zpos values.
>
> So let's change the zpos values for the DRM planes to 0, 1, 2, 3.
>
> Another option would be to configure the planes marked as primary planes
> to zpos 0. On a two display system this would give us plane zpos values
> of 0, 0, 1, 2. The end result and behavior would be very similar in this
> option, and I'm not aware that this would actually help us in any way.
> So, to keep the code simple, I opted for the 0, 1, 2, 3 values.
>
> Signed-off-by: Tomi Valkeinen <[email protected]>
> Fixes: 32a1795f57ee ("drm/tidss: New driver for TI Keystone platform Display SubSystem")
Hi Tomi,
have you reported this to Weston? What exactly is the problem?
It doesn't seem like a good idea to work around userspace bugs
(non-regression, I presume?) with kernel changes.
Thanks,
pq
> ---
> drivers/gpu/drm/tidss/tidss_plane.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/tidss/tidss_plane.c b/drivers/gpu/drm/tidss/tidss_plane.c
> index e1c0ef0c3894..68fed531f6a7 100644
> --- a/drivers/gpu/drm/tidss/tidss_plane.c
> +++ b/drivers/gpu/drm/tidss/tidss_plane.c
> @@ -213,7 +213,7 @@ struct tidss_plane *tidss_plane_create(struct tidss_device *tidss,
>
> drm_plane_helper_add(&tplane->plane, &tidss_plane_helper_funcs);
>
> - drm_plane_create_zpos_property(&tplane->plane, hw_plane_id, 0,
> + drm_plane_create_zpos_property(&tplane->plane, tidss->num_planes, 0,
> num_planes - 1);
>
> ret = drm_plane_create_color_properties(&tplane->plane,
>
Hi,
On 13/02/2024 11:04, Pekka Paalanen wrote:
> On Tue, 13 Feb 2024 10:16:36 +0200
> Tomi Valkeinen <[email protected]> wrote:
>
>> When the driver sets up the zpos property it sets the default zpos value
>> to the HW id of the plane. That is fine as such, but as on many DSS
>> versions the driver arranges the DRM planes in a different order than
>> the HW planes (to keep the non-scalable planes first), this leads to odd
>> initial zpos values. An example is J721e, where the initial zpos values
>> for DRM planes are 1, 3, 0, 2.
>>
>> In theory the userspace should configure the zpos values properly when
>> using multiple planes, and in that sense the initial zpos values
>> shouldn't matter, but there's really no reason not to fix this and help
>> the userspace apps which don't handle zpos perfectly. In particular,
>> Weston seems to have issues dealing with the planes with the current
>> default zpos values.
>>
>> So let's change the zpos values for the DRM planes to 0, 1, 2, 3.
>>
>> Another option would be to configure the planes marked as primary planes
>> to zpos 0. On a two display system this would give us plane zpos values
>> of 0, 0, 1, 2. The end result and behavior would be very similar in this
>> option, and I'm not aware that this would actually help us in any way.
>> So, to keep the code simple, I opted for the 0, 1, 2, 3 values.
>>
>> Signed-off-by: Tomi Valkeinen <[email protected]>
>> Fixes: 32a1795f57ee ("drm/tidss: New driver for TI Keystone platform Display SubSystem")
>
> Hi Tomi,
>
> have you reported this to Weston? What exactly is the problem?
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).
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.
> It doesn't seem like a good idea to work around userspace bugs
> (non-regression, I presume?) with kernel changes.
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.
I agree with you, this patch shouldn't be merged to "fix" issues with
tidss + Weston. However, the current default zpos values really don't
make sense, so I think this patch can stand on its own, and should be
merged just to make the tidss behavior a bit saner.
But even if this patch merged, the issue with Weston should be looked at
(*poke* Randolph =).
Tomi
>
>
> Thanks,
> pq
>
>> ---
>> drivers/gpu/drm/tidss/tidss_plane.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/tidss/tidss_plane.c b/drivers/gpu/drm/tidss/tidss_plane.c
>> index e1c0ef0c3894..68fed531f6a7 100644
>> --- a/drivers/gpu/drm/tidss/tidss_plane.c
>> +++ b/drivers/gpu/drm/tidss/tidss_plane.c
>> @@ -213,7 +213,7 @@ struct tidss_plane *tidss_plane_create(struct tidss_device *tidss,
>>
>> drm_plane_helper_add(&tplane->plane, &tidss_plane_helper_funcs);
>>
>> - drm_plane_create_zpos_property(&tplane->plane, hw_plane_id, 0,
>> + drm_plane_create_zpos_property(&tplane->plane, tidss->num_planes, 0,
>> num_planes - 1);
>>
>> ret = drm_plane_create_color_properties(&tplane->plane,
>>
>
On Tue, Feb 13, 2024 at 11:57:59AM +0200, Tomi Valkeinen wrote:
> Hi,
Hi,
>
> On 13/02/2024 11:04, Pekka Paalanen wrote:
> > On Tue, 13 Feb 2024 10:16:36 +0200
> > Tomi Valkeinen <[email protected]> wrote:
> >
> > > When the driver sets up the zpos property it sets the default zpos value
> > > to the HW id of the plane. That is fine as such, but as on many DSS
> > > versions the driver arranges the DRM planes in a different order than
> > > the HW planes (to keep the non-scalable planes first), this leads to odd
> > > initial zpos values. An example is J721e, where the initial zpos values
> > > for DRM planes are 1, 3, 0, 2.
> > >
> > > In theory the userspace should configure the zpos values properly when
> > > using multiple planes, and in that sense the initial zpos values
> > > shouldn't matter, but there's really no reason not to fix this and help
> > > the userspace apps which don't handle zpos perfectly. In particular,
> > > Weston seems to have issues dealing with the planes with the current
> > > default zpos values.
> > >
> > > So let's change the zpos values for the DRM planes to 0, 1, 2, 3.
> > >
> > > Another option would be to configure the planes marked as primary planes
> > > to zpos 0. On a two display system this would give us plane zpos values
> > > of 0, 0, 1, 2. The end result and behavior would be very similar in this
> > > option, and I'm not aware that this would actually help us in any way.
> > > So, to keep the code simple, I opted for the 0, 1, 2, 3 values.
> > >
> > > Signed-off-by: Tomi Valkeinen <[email protected]>
> > > Fixes: 32a1795f57ee ("drm/tidss: New driver for TI Keystone platform Display SubSystem")
> >
> > Hi Tomi,
> >
> > have you reported this to Weston? What exactly is the problem?
>
> 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).
>
> 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.
>
> > It doesn't seem like a good idea to work around userspace bugs
> > (non-regression, I presume?) with kernel changes.
>
> 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.
>
> I agree with you, this patch shouldn't be merged to "fix" issues with tidss
> + Weston. However, the current default zpos values really don't make sense,
> so I think this patch can stand on its own, and should be merged just to
> make the tidss behavior a bit saner.
>
> But even if this patch merged, the issue with Weston should be looked at
> (*poke* Randolph =).
>
> Tomi
>
> >
> >
> > Thanks,
> > pq
> >
> > > ---
> > > drivers/gpu/drm/tidss/tidss_plane.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/tidss/tidss_plane.c b/drivers/gpu/drm/tidss/tidss_plane.c
> > > index e1c0ef0c3894..68fed531f6a7 100644
> > > --- a/drivers/gpu/drm/tidss/tidss_plane.c
> > > +++ b/drivers/gpu/drm/tidss/tidss_plane.c
> > > @@ -213,7 +213,7 @@ struct tidss_plane *tidss_plane_create(struct tidss_device *tidss,
> > > drm_plane_helper_add(&tplane->plane, &tidss_plane_helper_funcs);
> > > - drm_plane_create_zpos_property(&tplane->plane, hw_plane_id, 0,
> > > + drm_plane_create_zpos_property(&tplane->plane, tidss->num_planes, 0,
> > > num_planes - 1);
> > > ret = drm_plane_create_color_properties(&tplane->plane,
> > >
> >
>
Hi,
On Tue, 13 Feb 2024 at 10:18, Marius Vlad <[email protected]> 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.
> > 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. ;)
Cheers,
Daniel
Tomi, thank you for the fixes.
On 13/02/24 13:46, Tomi Valkeinen wrote:
> When the driver sets up the zpos property it sets the default zpos value
> to the HW id of the plane. That is fine as such, but as on many DSS
> versions the driver arranges the DRM planes in a different order than
> the HW planes (to keep the non-scalable planes first), this leads to odd
> initial zpos values. An example is J721e, where the initial zpos values
> for DRM planes are 1, 3, 0, 2.
>
> In theory the userspace should configure the zpos values properly when
> using multiple planes, and in that sense the initial zpos values
> shouldn't matter, but there's really no reason not to fix this and help
> the userspace apps which don't handle zpos perfectly. In particular,
> Weston seems to have issues dealing with the planes with the current
> default zpos values.
>
> So let's change the zpos values for the DRM planes to 0, 1, 2, 3.
>
> Another option would be to configure the planes marked as primary planes
> to zpos 0. On a two display system this would give us plane zpos values
> of 0, 0, 1, 2. The end result and behavior would be very similar in this
> option, and I'm not aware that this would actually help us in any way.
> So, to keep the code simple, I opted for the 0, 1, 2, 3 values.
>
> Signed-off-by: Tomi Valkeinen <[email protected]>
> Fixes: 32a1795f57ee ("drm/tidss: New driver for TI Keystone platform Display SubSystem")
Reviewed-by: Aradhya Bhatia <[email protected]>
> ---
> drivers/gpu/drm/tidss/tidss_plane.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/tidss/tidss_plane.c b/drivers/gpu/drm/tidss/tidss_plane.c
> index e1c0ef0c3894..68fed531f6a7 100644
> --- a/drivers/gpu/drm/tidss/tidss_plane.c
> +++ b/drivers/gpu/drm/tidss/tidss_plane.c
> @@ -213,7 +213,7 @@ struct tidss_plane *tidss_plane_create(struct tidss_device *tidss,
>
> drm_plane_helper_add(&tplane->plane, &tidss_plane_helper_funcs);
>
> - drm_plane_create_zpos_property(&tplane->plane, hw_plane_id, 0,
> + drm_plane_create_zpos_property(&tplane->plane, tidss->num_planes, 0,
> num_planes - 1);
>
> ret = drm_plane_create_color_properties(&tplane->plane,
>
On 13/02/24 13:46, Tomi Valkeinen wrote:
> A sync lost issue can be observed with two displays, when moving a plane
> from one disabled display to an another disabled display, and then
> enabling the display to which the plane was moved to. The exact
> requirements for this to trigger are not clear.
>
> It looks like the issue is that the layers are left enabled in the first
> display's OVR registers. Even if the corresponding VP is disabled, it
> still causes an issue, as if the disabled VP and its OVR would still be
> in use, leading to the same VID being used by two OVRs. However, this is
> just speculation based on testing the DSS behavior.
>
> Experimentation shows that as a workaround, we can disable all the
> layers in the OVR when disabling a VP. There should be no downside to
> this, as the OVR is anyway effectively disabled if its VP is disabled,
> and it seems to solve the sync lost issue.
>
> However, there may be a bigger issue in play here, related to J721e
> erratum i2097 ("DSS: Disabling a Layer Connected to Overlay May Result
> in Synclost During the Next Frame"). Experimentation also shows that the
> OVR's CHANNELIN field has similar issue. So we may need to revisit this
> when we find out more about the core issue.
>
> Signed-off-by: Tomi Valkeinen <[email protected]>
> Fixes: 32a1795f57ee ("drm/tidss: New driver for TI Keystone platform Display SubSystem")
Reviewed-by: Aradhya Bhatia <[email protected]>
> ---
> drivers/gpu/drm/tidss/tidss_crtc.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/gpu/drm/tidss/tidss_crtc.c b/drivers/gpu/drm/tidss/tidss_crtc.c
> index 5f838980c7a1..94f8e3178df5 100644
> --- a/drivers/gpu/drm/tidss/tidss_crtc.c
> +++ b/drivers/gpu/drm/tidss/tidss_crtc.c
> @@ -265,6 +265,16 @@ static void tidss_crtc_atomic_disable(struct drm_crtc *crtc,
>
> reinit_completion(&tcrtc->framedone_completion);
>
> + /*
> + * If a layer is left enabled when the videoport is disabled, and the
> + * vid pipeline that was used for the layer is taken into use on
> + * another videoport, the DSS will report sync lost issues. Disable all
> + * the layers here as a work-around.
> + */
> + for (u32 layer = 0; layer < tidss->feat->num_planes; layer++)
> + dispc_ovr_enable_layer(tidss->dispc, tcrtc->hw_videoport, layer,
> + false);
> +
> dispc_vp_disable(tidss->dispc, tcrtc->hw_videoport);
>
> if (!wait_for_completion_timeout(&tcrtc->framedone_completion,
>
Hi,
On 13/02/2024 13:39, Daniel Stone wrote:
> Hi,
>
> On Tue, 13 Feb 2024 at 10:18, Marius Vlad <[email protected]> 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
Hi,
On Fri, 16 Feb 2024 at 09:00, Tomi Valkeinen
<[email protected]> wrote:
> On 13/02/2024 13:39, Daniel Stone wrote:
> > 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?
We always had plane support but pre-zpos; we added support for zpos a
couple/few releases ago, but then massively refactored it ... so it
could've always been broken, or could've been broken for as long as we
have zpos, or it could've just been a small window in between the
refactor.