* [PATCH] drm: two planes with the same zpos have undefined ordering
@ 2019-09-10 10:07 Simon Ser
2019-09-10 11:52 ` ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
` (2 more replies)
0 siblings, 3 replies; 14+ messages in thread
From: Simon Ser @ 2019-09-10 10:07 UTC (permalink / raw
To: intel-gfx
Currently the property docs don't specify whether it's okay for two planes to
have the same zpos value and what user-space should expect in this case.
The rule mentionned in the past was to disambiguate with object IDs. However
some drivers break this rule (that's why the ordering is documented as
unspecified in case the zpos property is missing). Additionally it doesn't
really make sense for a driver to user identical zpos values if it knows their
relative position: the driver can just pick different values instead.
So two solutions would make sense: either disallow completely identical zpos
values for two different planes, either make the ordering unspecified. To allow
drivers that don't know the relative ordering between two planes to still
expose the zpos property, choose the latter solution.
Signed-off-by: Simon Ser <contact@emersion.fr>
---
drivers/gpu/drm/drm_blend.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
index d02709dd2d4a..51bd5454e50a 100644
--- a/drivers/gpu/drm/drm_blend.c
+++ b/drivers/gpu/drm/drm_blend.c
@@ -132,10 +132,10 @@
* planes. Without this property the primary plane is always below the cursor
* plane, and ordering between all other planes is undefined. The positive
* Z axis points towards the user, i.e. planes with lower Z position values
- * are underneath planes with higher Z position values. Note that the Z
- * position value can also be immutable, to inform userspace about the
- * hard-coded stacking of overlay planes, see
- * drm_plane_create_zpos_immutable_property().
+ * are underneath planes with higher Z position values. Two planes with the
+ * same Z position value have undefined ordering. Note that the Z position
+ * value can also be immutable, to inform userspace about the hard-coded
+ * stacking of overlay planes, see drm_plane_create_zpos_immutable_property().
*
* pixel blend mode:
* Pixel blend mode is set up with drm_plane_create_blend_mode_property().
--
2.23.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 14+ messages in thread
* [PATCH] drm: two planes with the same zpos have undefined ordering
@ 2019-09-10 10:09 Simon Ser
2019-09-10 10:38 ` Pekka Paalanen
0 siblings, 1 reply; 14+ messages in thread
From: Simon Ser @ 2019-09-10 10:09 UTC (permalink / raw
To: dri-devel; +Cc: daniel.vetter, pekka.paalanen, daniels
Currently the property docs don't specify whether it's okay for two planes to
have the same zpos value and what user-space should expect in this case.
The rule mentionned in the past was to disambiguate with object IDs. However
some drivers break this rule (that's why the ordering is documented as
unspecified in case the zpos property is missing). Additionally it doesn't
really make sense for a driver to user identical zpos values if it knows their
relative position: the driver can just pick different values instead.
So two solutions would make sense: either disallow completely identical zpos
values for two different planes, either make the ordering unspecified. To allow
drivers that don't know the relative ordering between two planes to still
expose the zpos property, choose the latter solution.
Signed-off-by: Simon Ser <contact@emersion.fr>
---
Err, I'm sorry about the double-post. I sent this to intel-gfx by mistake.
drivers/gpu/drm/drm_blend.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
index d02709dd2d4a..51bd5454e50a 100644
--- a/drivers/gpu/drm/drm_blend.c
+++ b/drivers/gpu/drm/drm_blend.c
@@ -132,10 +132,10 @@
* planes. Without this property the primary plane is always below the cursor
* plane, and ordering between all other planes is undefined. The positive
* Z axis points towards the user, i.e. planes with lower Z position values
- * are underneath planes with higher Z position values. Note that the Z
- * position value can also be immutable, to inform userspace about the
- * hard-coded stacking of overlay planes, see
- * drm_plane_create_zpos_immutable_property().
+ * are underneath planes with higher Z position values. Two planes with the
+ * same Z position value have undefined ordering. Note that the Z position
+ * value can also be immutable, to inform userspace about the hard-coded
+ * stacking of overlay planes, see drm_plane_create_zpos_immutable_property().
*
* pixel blend mode:
* Pixel blend mode is set up with drm_plane_create_blend_mode_property().
--
2.23.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH] drm: two planes with the same zpos have undefined ordering
2019-09-10 10:09 [PATCH] " Simon Ser
@ 2019-09-10 10:38 ` Pekka Paalanen
2019-09-10 11:20 ` Simon Ser
2019-09-16 9:48 ` Daniel Vetter
0 siblings, 2 replies; 14+ messages in thread
From: Pekka Paalanen @ 2019-09-10 10:38 UTC (permalink / raw
To: Simon Ser; +Cc: daniel.vetter, daniels, dri-devel
[-- Attachment #1.1: Type: text/plain, Size: 2925 bytes --]
On Tue, 10 Sep 2019 10:09:55 +0000
Simon Ser <contact@emersion.fr> wrote:
> Currently the property docs don't specify whether it's okay for two planes to
> have the same zpos value and what user-space should expect in this case.
>
> The rule mentionned in the past was to disambiguate with object IDs. However
> some drivers break this rule (that's why the ordering is documented as
> unspecified in case the zpos property is missing). Additionally it doesn't
> really make sense for a driver to user identical zpos values if it knows their
> relative position: the driver can just pick different values instead.
>
> So two solutions would make sense: either disallow completely identical zpos
> values for two different planes, either make the ordering unspecified. To allow
> drivers that don't know the relative ordering between two planes to still
> expose the zpos property, choose the latter solution.
>
> Signed-off-by: Simon Ser <contact@emersion.fr>
> ---
>
> Err, I'm sorry about the double-post. I sent this to intel-gfx by mistake.
>
> drivers/gpu/drm/drm_blend.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> index d02709dd2d4a..51bd5454e50a 100644
> --- a/drivers/gpu/drm/drm_blend.c
> +++ b/drivers/gpu/drm/drm_blend.c
> @@ -132,10 +132,10 @@
> * planes. Without this property the primary plane is always below the cursor
> * plane, and ordering between all other planes is undefined. The positive
> * Z axis points towards the user, i.e. planes with lower Z position values
> - * are underneath planes with higher Z position values. Note that the Z
> - * position value can also be immutable, to inform userspace about the
> - * hard-coded stacking of overlay planes, see
> - * drm_plane_create_zpos_immutable_property().
> + * are underneath planes with higher Z position values. Two planes with the
> + * same Z position value have undefined ordering. Note that the Z position
> + * value can also be immutable, to inform userspace about the hard-coded
> + * stacking of overlay planes, see drm_plane_create_zpos_immutable_property().
> *
> * pixel blend mode:
> * Pixel blend mode is set up with drm_plane_create_blend_mode_property().
Hi,
this seems to contradict what the docs say in another place:
zpos
Priority of the given plane on crtc (optional).
Note that multiple active planes on the same crtc can have an
identical zpos value. The rule to solving the conflict is to
compare the plane object IDs; the plane with a higher ID must be
stacked on top of a plane with a lower ID.
See drm_plane_create_zpos_property() and
drm_plane_create_zpos_immutable_property() for more details.
from https://01.org/linuxgraphics/gfx-docs/drm/gpu/drm-kms.html#plane-functions-reference
Thanks,
pq
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] drm: two planes with the same zpos have undefined ordering
2019-09-10 10:38 ` Pekka Paalanen
@ 2019-09-10 11:20 ` Simon Ser
2019-09-11 7:36 ` Pekka Paalanen
2019-09-16 9:48 ` Daniel Vetter
1 sibling, 1 reply; 14+ messages in thread
From: Simon Ser @ 2019-09-10 11:20 UTC (permalink / raw
To: Pekka Paalanen
Cc: daniel.vetter@ffwll.ch, daniels@collabora.com,
dri-devel@lists.freedesktop.org
On Tuesday, September 10, 2019 1:38 PM, Pekka Paalanen <ppaalanen@gmail.com> wrote:
> On Tue, 10 Sep 2019 10:09:55 +0000
> Simon Ser contact@emersion.fr wrote:
>
> > Currently the property docs don't specify whether it's okay for two planes to
> > have the same zpos value and what user-space should expect in this case.
> > The rule mentionned in the past was to disambiguate with object IDs. However
> > some drivers break this rule (that's why the ordering is documented as
> > unspecified in case the zpos property is missing). Additionally it doesn't
> > really make sense for a driver to user identical zpos values if it knows their
> > relative position: the driver can just pick different values instead.
> > So two solutions would make sense: either disallow completely identical zpos
> > values for two different planes, either make the ordering unspecified. To allow
> > drivers that don't know the relative ordering between two planes to still
> > expose the zpos property, choose the latter solution.
> >
> > Signed-off-by: Simon Ser contact@emersion.fr
> >
> > ---------------------------------------------
> >
> > Err, I'm sorry about the double-post. I sent this to intel-gfx by mistake.
> > drivers/gpu/drm/drm_blend.c | 8 ++++----
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> > diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> > index d02709dd2d4a..51bd5454e50a 100644
> > --- a/drivers/gpu/drm/drm_blend.c
> > +++ b/drivers/gpu/drm/drm_blend.c
> > @@ -132,10 +132,10 @@
> >
> > - planes. Without this property the primary plane is always below the cursor
> > - plane, and ordering between all other planes is undefined. The positive
> > - Z axis points towards the user, i.e. planes with lower Z position values
> >
> > - - are underneath planes with higher Z position values. Note that the Z
> > - - position value can also be immutable, to inform userspace about the
> > - - hard-coded stacking of overlay planes, see
> > - - drm_plane_create_zpos_immutable_property().
> >
> > - - are underneath planes with higher Z position values. Two planes with the
> > - - same Z position value have undefined ordering. Note that the Z position
> > - - value can also be immutable, to inform userspace about the hard-coded
> > - - stacking of overlay planes, see drm_plane_create_zpos_immutable_property().
> > -
> > - pixel blend mode:
> > - Pixel blend mode is set up with drm_plane_create_blend_mode_property().
>
> Hi,
>
> this seems to contradict what the docs say in another place:
Except this comment is about drm_plane_state.zpos, an internal DRM
property. This is not about the zpos property itself.
The comment was introduced in v2 of [1], although the motivation for
the change isn't documented.
[1]: https://patchwork.freedesktop.org/series/13528/#rev2
> zpos
>
> Priority of the given plane on crtc (optional).
>
> Note that multiple active planes on the same crtc can have an
> identical zpos value. The rule to solving the conflict is to
> compare the plane object IDs; the plane with a higher ID must be
> stacked on top of a plane with a lower ID.
>
> See drm_plane_create_zpos_property() and
> drm_plane_create_zpos_immutable_property() for more details.
>
> from https://01.org/linuxgraphics/gfx-docs/drm/gpu/drm-kms.html#plane-functions-reference
>
> Thanks,
> pq
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 14+ messages in thread
* ✗ Fi.CI.CHECKPATCH: warning for drm: two planes with the same zpos have undefined ordering
2019-09-10 10:07 [PATCH] drm: two planes with the same zpos have undefined ordering Simon Ser
@ 2019-09-10 11:52 ` Patchwork
2019-09-10 12:15 ` ✓ Fi.CI.BAT: success " Patchwork
2019-09-10 17:12 ` ✗ Fi.CI.IGT: failure " Patchwork
2 siblings, 0 replies; 14+ messages in thread
From: Patchwork @ 2019-09-10 11:52 UTC (permalink / raw
To: Simon Ser; +Cc: intel-gfx
== Series Details ==
Series: drm: two planes with the same zpos have undefined ordering
URL : https://patchwork.freedesktop.org/series/66480/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
7b8f1c2a9415 drm: two planes with the same zpos have undefined ordering
-:6: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line)
#6:
Currently the property docs don't specify whether it's okay for two planes to
total: 0 errors, 1 warnings, 0 checks, 14 lines checked
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 14+ messages in thread
* ✓ Fi.CI.BAT: success for drm: two planes with the same zpos have undefined ordering
2019-09-10 10:07 [PATCH] drm: two planes with the same zpos have undefined ordering Simon Ser
2019-09-10 11:52 ` ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
@ 2019-09-10 12:15 ` Patchwork
2019-09-10 17:12 ` ✗ Fi.CI.IGT: failure " Patchwork
2 siblings, 0 replies; 14+ messages in thread
From: Patchwork @ 2019-09-10 12:15 UTC (permalink / raw
To: Simon Ser; +Cc: intel-gfx
== Series Details ==
Series: drm: two planes with the same zpos have undefined ordering
URL : https://patchwork.freedesktop.org/series/66480/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6860 -> Patchwork_14337
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14337/
Known issues
------------
Here are the changes found in Patchwork_14337 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_exec_reloc@basic-gtt-noreloc:
- fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724]) +1 similar issue
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/fi-icl-u3/igt@gem_exec_reloc@basic-gtt-noreloc.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14337/fi-icl-u3/igt@gem_exec_reloc@basic-gtt-noreloc.html
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: [PASS][3] -> [INCOMPLETE][4] ([fdo#107718])
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/fi-blb-e6850/igt@gem_exec_suspend@basic-s3.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14337/fi-blb-e6850/igt@gem_exec_suspend@basic-s3.html
* igt@i915_selftest@live_execlists:
- fi-skl-gvtdvm: [PASS][5] -> [DMESG-FAIL][6] ([fdo#111108])
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14337/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [PASS][7] -> [FAIL][8] ([fdo#111407])
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14337/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html
#### Possible fixes ####
* igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy: [DMESG-WARN][9] ([fdo#102614]) -> [PASS][10]
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/fi-hsw-peppy/igt@kms_frontbuffer_tracking@basic.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14337/fi-hsw-peppy/igt@kms_frontbuffer_tracking@basic.html
* igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence:
- {fi-icl-dsi}: [DMESG-WARN][11] ([fdo#106107]) -> [PASS][12]
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/fi-icl-dsi/igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14337/fi-icl-dsi/igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence.html
* igt@prime_vgem@basic-fence-mmap:
- fi-icl-u3: [DMESG-WARN][13] ([fdo#107724]) -> [PASS][14]
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/fi-icl-u3/igt@prime_vgem@basic-fence-mmap.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14337/fi-icl-u3/igt@prime_vgem@basic-fence-mmap.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
[fdo#106107]: https://bugs.freedesktop.org/show_bug.cgi?id=106107
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#111108]: https://bugs.freedesktop.org/show_bug.cgi?id=111108
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
Participating hosts (53 -> 47)
------------------------------
Missing (6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y fi-byt-clapper
Build changes
-------------
* CI: CI-20190529 -> None
* Linux: CI_DRM_6860 -> Patchwork_14337
CI-20190529: 20190529
CI_DRM_6860: 33c00059b084f42f01a168b5f67e4df670293e2c @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_5177: 8f351d693352d21c96cef38c3fd77f778c6d7c33 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14337: 7b8f1c2a9415cd54c1eebbdf2cb50586ed0ccb6d @ git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
7b8f1c2a9415 drm: two planes with the same zpos have undefined ordering
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14337/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 14+ messages in thread
* ✗ Fi.CI.IGT: failure for drm: two planes with the same zpos have undefined ordering
2019-09-10 10:07 [PATCH] drm: two planes with the same zpos have undefined ordering Simon Ser
2019-09-10 11:52 ` ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
2019-09-10 12:15 ` ✓ Fi.CI.BAT: success " Patchwork
@ 2019-09-10 17:12 ` Patchwork
2 siblings, 0 replies; 14+ messages in thread
From: Patchwork @ 2019-09-10 17:12 UTC (permalink / raw
To: Simon Ser; +Cc: intel-gfx
== Series Details ==
Series: drm: two planes with the same zpos have undefined ordering
URL : https://patchwork.freedesktop.org/series/66480/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6860_full -> Patchwork_14337_full
====================================================
Summary
-------
**FAILURE**
Serious unknown changes coming with Patchwork_14337_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_14337_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
-------------------
Here are the unknown changes that may have been introduced in Patchwork_14337_full:
### IGT changes ###
#### Possible regressions ####
* igt@gem_persistent_relocs@forked-thrash-inactive:
- shard-kbl: [PASS][1] -> [DMESG-WARN][2]
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/shard-kbl3/igt@gem_persistent_relocs@forked-thrash-inactive.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14337/shard-kbl6/igt@gem_persistent_relocs@forked-thrash-inactive.html
Known issues
------------
Here are the changes found in Patchwork_14337_full that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_ctx_shared@exec-single-timeline-bsd:
- shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#110841])
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/shard-iclb7/igt@gem_ctx_shared@exec-single-timeline-bsd.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14337/shard-iclb4/igt@gem_ctx_shared@exec-single-timeline-bsd.html
* igt@gem_exec_balancer@smoke:
- shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#110854])
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/shard-iclb2/igt@gem_exec_balancer@smoke.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14337/shard-iclb3/igt@gem_exec_balancer@smoke.html
* igt@gem_exec_schedule@deep-bsd:
- shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#111325]) +3 similar issues
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/shard-iclb7/igt@gem_exec_schedule@deep-bsd.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14337/shard-iclb4/igt@gem_exec_schedule@deep-bsd.html
* igt@gem_exec_schedule@promotion-bsd1:
- shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#109276]) +16 similar issues
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/shard-iclb2/igt@gem_exec_schedule@promotion-bsd1.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14337/shard-iclb8/igt@gem_exec_schedule@promotion-bsd1.html
* igt@gem_tiled_swapping@non-threaded:
- shard-kbl: [PASS][11] -> [DMESG-WARN][12] ([fdo#108686])
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/shard-kbl2/igt@gem_tiled_swapping@non-threaded.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14337/shard-kbl4/igt@gem_tiled_swapping@non-threaded.html
* igt@i915_pm_rpm@gem-execbuf-stress:
- shard-iclb: [PASS][13] -> [INCOMPLETE][14] ([fdo#107713] / [fdo#108840])
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/shard-iclb1/igt@i915_pm_rpm@gem-execbuf-stress.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14337/shard-iclb2/igt@i915_pm_rpm@gem-execbuf-stress.html
* igt@i915_suspend@fence-restore-tiled2untiled:
- shard-apl: [PASS][15] -> [DMESG-WARN][16] ([fdo#108566]) +3 similar issues
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/shard-apl2/igt@i915_suspend@fence-restore-tiled2untiled.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14337/shard-apl6/igt@i915_suspend@fence-restore-tiled2untiled.html
* igt@kms_fbcon_fbt@fbc-suspend:
- shard-skl: [PASS][17] -> [DMESG-WARN][18] ([fdo#106107])
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/shard-skl10/igt@kms_fbcon_fbt@fbc-suspend.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14337/shard-skl3/igt@kms_fbcon_fbt@fbc-suspend.html
* igt@kms_flip@2x-modeset-vs-vblank-race:
- shard-glk: [PASS][19] -> [FAIL][20] ([fdo#111609])
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/shard-glk3/igt@kms_flip@2x-modeset-vs-vblank-race.html
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14337/shard-glk1/igt@kms_flip@2x-modeset-vs-vblank-race.html
* igt@kms_flip@flip-vs-expired-vblank:
- shard-glk: [PASS][21] -> [FAIL][22] ([fdo#105363])
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/shard-glk1/igt@kms_flip@flip-vs-expired-vblank.html
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14337/shard-glk9/igt@kms_flip@flip-vs-expired-vblank.html
* igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-shrfb-msflip-blt:
- shard-iclb: [PASS][23] -> [FAIL][24] ([fdo#103167]) +2 similar issues
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/shard-iclb5/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-shrfb-msflip-blt.html
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14337/shard-iclb5/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-shrfb-msflip-blt.html
* igt@kms_psr@psr2_primary_mmap_cpu:
- shard-iclb: [PASS][25] -> [SKIP][26] ([fdo#109441]) +2 similar issues
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/shard-iclb2/igt@kms_psr@psr2_primary_mmap_cpu.html
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14337/shard-iclb1/igt@kms_psr@psr2_primary_mmap_cpu.html
* igt@kms_setmode@basic:
- shard-apl: [PASS][27] -> [FAIL][28] ([fdo#99912])
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/shard-apl5/igt@kms_setmode@basic.html
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14337/shard-apl2/igt@kms_setmode@basic.html
* igt@perf@blocking:
- shard-skl: [PASS][29] -> [FAIL][30] ([fdo#110728]) +1 similar issue
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/shard-skl9/igt@perf@blocking.html
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14337/shard-skl2/igt@perf@blocking.html
* igt@prime_busy@hang-render:
- shard-apl: [PASS][31] -> [INCOMPLETE][32] ([fdo#103927]) +2 similar issues
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/shard-apl6/igt@prime_busy@hang-render.html
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14337/shard-apl8/igt@prime_busy@hang-render.html
#### Possible fixes ####
* igt@gem_ctx_isolation@bcs0-s3:
- shard-apl: [DMESG-WARN][33] ([fdo#108566]) -> [PASS][34] +3 similar issues
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/shard-apl3/igt@gem_ctx_isolation@bcs0-s3.html
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14337/shard-apl4/igt@gem_ctx_isolation@bcs0-s3.html
* igt@gem_ctx_shared@exec-single-timeline-bsd1:
- shard-iclb: [SKIP][35] ([fdo#109276]) -> [PASS][36] +18 similar issues
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/shard-iclb5/igt@gem_ctx_shared@exec-single-timeline-bsd1.html
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14337/shard-iclb1/igt@gem_ctx_shared@exec-single-timeline-bsd1.html
* igt@gem_exec_schedule@preempt-other-chain-bsd:
- shard-iclb: [SKIP][37] ([fdo#111325]) -> [PASS][38] +3 similar issues
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/shard-iclb2/igt@gem_exec_schedule@preempt-other-chain-bsd.html
[38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14337/shard-iclb3/igt@gem_exec_schedule@preempt-other-chain-bsd.html
* igt@kms_flip@flip-vs-suspend:
- shard-skl: [INCOMPLETE][39] ([fdo#109507]) -> [PASS][40]
[39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/shard-skl10/igt@kms_flip@flip-vs-suspend.html
[40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14337/shard-skl3/igt@kms_flip@flip-vs-suspend.html
* igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-render:
- shard-iclb: [FAIL][41] ([fdo#103167]) -> [PASS][42] +5 similar issues
[41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/shard-iclb2/igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-render.html
[42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14337/shard-iclb1/igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-render.html
* igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
- shard-skl: [FAIL][43] ([fdo#108145] / [fdo#110403]) -> [PASS][44] +1 similar issue
[43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/shard-skl9/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html
[44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14337/shard-skl2/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html
* igt@kms_psr2_su@page_flip:
- shard-iclb: [SKIP][45] ([fdo#109642] / [fdo#111068]) -> [PASS][46]
[45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/shard-iclb1/igt@kms_psr2_su@page_flip.html
[46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14337/shard-iclb2/igt@kms_psr2_su@page_flip.html
* igt@kms_psr@psr2_basic:
- shard-iclb: [SKIP][47] ([fdo#109441]) -> [PASS][48] +1 similar issue
[47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/shard-iclb8/igt@kms_psr@psr2_basic.html
[48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14337/shard-iclb2/igt@kms_psr@psr2_basic.html
* igt@kms_setmode@basic:
- shard-kbl: [FAIL][49] ([fdo#99912]) -> [PASS][50]
[49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/shard-kbl3/igt@kms_setmode@basic.html
[50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14337/shard-kbl6/igt@kms_setmode@basic.html
* igt@kms_vblank@pipe-a-ts-continuation-dpms-suspend:
- shard-skl: [INCOMPLETE][51] ([fdo#104108]) -> [PASS][52] +1 similar issue
[51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/shard-skl9/igt@kms_vblank@pipe-a-ts-continuation-dpms-suspend.html
[52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14337/shard-skl4/igt@kms_vblank@pipe-a-ts-continuation-dpms-suspend.html
#### Warnings ####
* igt@gem_ctx_isolation@vcs1-nonpriv:
- shard-iclb: [SKIP][53] ([fdo#109276]) -> [FAIL][54] ([fdo#111329])
[53]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/shard-iclb3/igt@gem_ctx_isolation@vcs1-nonpriv.html
[54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14337/shard-iclb1/igt@gem_ctx_isolation@vcs1-nonpriv.html
* igt@gem_mocs_settings@mocs-isolation-bsd2:
- shard-iclb: [SKIP][55] ([fdo#109276]) -> [FAIL][56] ([fdo#111330])
[55]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/shard-iclb8/igt@gem_mocs_settings@mocs-isolation-bsd2.html
[56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14337/shard-iclb2/igt@gem_mocs_settings@mocs-isolation-bsd2.html
* igt@gem_mocs_settings@mocs-rc6-bsd2:
- shard-iclb: [FAIL][57] ([fdo#111330]) -> [SKIP][58] ([fdo#109276])
[57]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/shard-iclb2/igt@gem_mocs_settings@mocs-rc6-bsd2.html
[58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14337/shard-iclb8/igt@gem_mocs_settings@mocs-rc6-bsd2.html
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#104108]: https://bugs.freedesktop.org/show_bug.cgi?id=104108
[fdo#105363]: https://bugs.freedesktop.org/show_bug.cgi?id=105363
[fdo#106107]: https://bugs.freedesktop.org/show_bug.cgi?id=106107
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#108566]: https://bugs.freedesktop.org/show_bug.cgi?id=108566
[fdo#108686]: https://bugs.freedesktop.org/show_bug.cgi?id=108686
[fdo#108840]: https://bugs.freedesktop.org/show_bug.cgi?id=108840
[fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
[fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
[fdo#109507]: https://bugs.freedesktop.org/show_bug.cgi?id=109507
[fdo#109642]: https://bugs.freedesktop.org/show_bug.cgi?id=109642
[fdo#110403]: https://bugs.freedesktop.org/show_bug.cgi?id=110403
[fdo#110728]: https://bugs.freedesktop.org/show_bug.cgi?id=110728
[fdo#110841]: https://bugs.freedesktop.org/show_bug.cgi?id=110841
[fdo#110854]: https://bugs.freedesktop.org/show_bug.cgi?id=110854
[fdo#111068]: https://bugs.freedesktop.org/show_bug.cgi?id=111068
[fdo#111325]: https://bugs.freedesktop.org/show_bug.cgi?id=111325
[fdo#111329]: https://bugs.freedesktop.org/show_bug.cgi?id=111329
[fdo#111330]: https://bugs.freedesktop.org/show_bug.cgi?id=111330
[fdo#111609]: https://bugs.freedesktop.org/show_bug.cgi?id=111609
[fdo#99912]: https://bugs.freedesktop.org/show_bug.cgi?id=99912
Participating hosts (10 -> 10)
------------------------------
No changes in participating hosts
Build changes
-------------
* CI: CI-20190529 -> None
* Linux: CI_DRM_6860 -> Patchwork_14337
CI-20190529: 20190529
CI_DRM_6860: 33c00059b084f42f01a168b5f67e4df670293e2c @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_5177: 8f351d693352d21c96cef38c3fd77f778c6d7c33 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14337: 7b8f1c2a9415cd54c1eebbdf2cb50586ed0ccb6d @ git://anongit.freedesktop.org/gfx-ci/linux
piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14337/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] drm: two planes with the same zpos have undefined ordering
2019-09-10 11:20 ` Simon Ser
@ 2019-09-11 7:36 ` Pekka Paalanen
2019-09-16 9:19 ` Simon Ser
0 siblings, 1 reply; 14+ messages in thread
From: Pekka Paalanen @ 2019-09-11 7:36 UTC (permalink / raw
To: Simon Ser
Cc: daniel.vetter@ffwll.ch, daniels@collabora.com,
dri-devel@lists.freedesktop.org, Marius-Cristian Vlad
[-- Attachment #1.1: Type: text/plain, Size: 4830 bytes --]
On Tue, 10 Sep 2019 11:20:16 +0000
Simon Ser <contact@emersion.fr> wrote:
> On Tuesday, September 10, 2019 1:38 PM, Pekka Paalanen <ppaalanen@gmail.com> wrote:
>
> > On Tue, 10 Sep 2019 10:09:55 +0000
> > Simon Ser contact@emersion.fr wrote:
> >
> > > Currently the property docs don't specify whether it's okay for two planes to
> > > have the same zpos value and what user-space should expect in this case.
> > > The rule mentionned in the past was to disambiguate with object IDs. However
> > > some drivers break this rule (that's why the ordering is documented as
> > > unspecified in case the zpos property is missing). Additionally it doesn't
> > > really make sense for a driver to user identical zpos values if it knows their
> > > relative position: the driver can just pick different values instead.
> > > So two solutions would make sense: either disallow completely identical zpos
> > > values for two different planes, either make the ordering unspecified. To allow
> > > drivers that don't know the relative ordering between two planes to still
> > > expose the zpos property, choose the latter solution.
> > >
> > > Signed-off-by: Simon Ser contact@emersion.fr
> > >
> > > ---------------------------------------------
> > >
> > > Err, I'm sorry about the double-post. I sent this to intel-gfx by mistake.
> > > drivers/gpu/drm/drm_blend.c | 8 ++++----
> > > 1 file changed, 4 insertions(+), 4 deletions(-)
> > > diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> > > index d02709dd2d4a..51bd5454e50a 100644
> > > --- a/drivers/gpu/drm/drm_blend.c
> > > +++ b/drivers/gpu/drm/drm_blend.c
> > > @@ -132,10 +132,10 @@
> > >
> > > - planes. Without this property the primary plane is always below the cursor
> > > - plane, and ordering between all other planes is undefined. The positive
> > > - Z axis points towards the user, i.e. planes with lower Z position values
> > >
> > > - - are underneath planes with higher Z position values. Note that the Z
> > > - - position value can also be immutable, to inform userspace about the
> > > - - hard-coded stacking of overlay planes, see
> > > - - drm_plane_create_zpos_immutable_property().
> > >
> > > - - are underneath planes with higher Z position values. Two planes with the
> > > - - same Z position value have undefined ordering. Note that the Z position
> > > - - value can also be immutable, to inform userspace about the hard-coded
> > > - - stacking of overlay planes, see drm_plane_create_zpos_immutable_property().
> > > -
> > > - pixel blend mode:
> > > - Pixel blend mode is set up with drm_plane_create_blend_mode_property().
> >
> > Hi,
> >
> > this seems to contradict what the docs say in another place:
>
> Except this comment is about drm_plane_state.zpos, an internal DRM
> property. This is not about the zpos property itself.
Hi,
then I'm very confused. What's the difference?
The text you are changing was specifically added to explain uAPI
behaviour, that is, what the userspace sees and does with the zpos
property in uAPI.
Having two conflicting pieces of documentation is confusing, especially
when it is not absolutely clear which one is for driver implementors
and which one for uAPI consumers, or that one must ignore the other doc
depending on who you are.
> The comment was introduced in v2 of [1], although the motivation for
> the change isn't documented.
>
> [1]: https://patchwork.freedesktop.org/series/13528/#rev2
That does not look like the comment you are changing.
Wait, which one is "this comment"?
> > zpos
> >
> > Priority of the given plane on crtc (optional).
> >
> > Note that multiple active planes on the same crtc can have an
> > identical zpos value. The rule to solving the conflict is to
> > compare the plane object IDs; the plane with a higher ID must be
> > stacked on top of a plane with a lower ID.
> >
> > See drm_plane_create_zpos_property() and
> > drm_plane_create_zpos_immutable_property() for more details.
> >
> > from https://01.org/linuxgraphics/gfx-docs/drm/gpu/drm-kms.html#plane-functions-reference
Me and others have taken the above to document uAPI. How could that not
be the case?
Is it wrong for userspace to assume that plane object ID order reflects
the plane stacking order? Weston does not do this yet, but since we just
recently found the above comment, we planned to make use of it.
Actually, if the ID ordering is true, then the DRM core could always
expose the zpos property as immutable to userspace, just manufacture it
from object IDs if nothing is set by a driver explicitly.
Or is the comment about object IDs wrong and should be changed to say
the opposite?
Thanks,
pq
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] drm: two planes with the same zpos have undefined ordering
2019-09-11 7:36 ` Pekka Paalanen
@ 2019-09-16 9:19 ` Simon Ser
2019-09-19 7:18 ` Pekka Paalanen
0 siblings, 1 reply; 14+ messages in thread
From: Simon Ser @ 2019-09-16 9:19 UTC (permalink / raw
To: Pekka Paalanen
Cc: daniel.vetter@ffwll.ch, daniels@collabora.com,
dri-devel@lists.freedesktop.org, Marius-Cristian Vlad
> On Tue, 10 Sep 2019 11:20:16 +0000
> Simon Ser <contact@emersion.fr> wrote:
>
> > On Tuesday, September 10, 2019 1:38 PM, Pekka Paalanen <ppaalanen@gmail.com> wrote:
> >
> > > On Tue, 10 Sep 2019 10:09:55 +0000
> > > Simon Ser contact@emersion.fr wrote:
> > >
> > > > Currently the property docs don't specify whether it's okay for two planes to
> > > > have the same zpos value and what user-space should expect in this case.
> > > > The rule mentionned in the past was to disambiguate with object IDs. However
> > > > some drivers break this rule (that's why the ordering is documented as
> > > > unspecified in case the zpos property is missing). Additionally it doesn't
> > > > really make sense for a driver to user identical zpos values if it knows their
> > > > relative position: the driver can just pick different values instead.
> > > > So two solutions would make sense: either disallow completely identical zpos
> > > > values for two different planes, either make the ordering unspecified. To allow
> > > > drivers that don't know the relative ordering between two planes to still
> > > > expose the zpos property, choose the latter solution.
> > > >
> > > > Signed-off-by: Simon Ser contact@emersion.fr
> > > >
> > > > ---------------------------------------------
> > > >
> > > > Err, I'm sorry about the double-post. I sent this to intel-gfx by mistake.
> > > > drivers/gpu/drm/drm_blend.c | 8 ++++----
> > > > 1 file changed, 4 insertions(+), 4 deletions(-)
> > > > diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> > > > index d02709dd2d4a..51bd5454e50a 100644
> > > > --- a/drivers/gpu/drm/drm_blend.c
> > > > +++ b/drivers/gpu/drm/drm_blend.c
> > > > @@ -132,10 +132,10 @@
> > > >
> > > > - planes. Without this property the primary plane is always below the cursor
> > > > - plane, and ordering between all other planes is undefined. The positive
> > > > - Z axis points towards the user, i.e. planes with lower Z position values
> > > >
> > > > - - are underneath planes with higher Z position values. Note that the Z
> > > > - - position value can also be immutable, to inform userspace about the
> > > > - - hard-coded stacking of overlay planes, see
> > > > - - drm_plane_create_zpos_immutable_property().
> > > >
> > > > - - are underneath planes with higher Z position values. Two planes with the
> > > > - - same Z position value have undefined ordering. Note that the Z position
> > > > - - value can also be immutable, to inform userspace about the hard-coded
> > > > - - stacking of overlay planes, see drm_plane_create_zpos_immutable_property().
> > > > -
> > > > - pixel blend mode:
> > > > - Pixel blend mode is set up with drm_plane_create_blend_mode_property().
> > >
> > > Hi,
> > >
> > > this seems to contradict what the docs say in another place:
> >
> > Except this comment is about drm_plane_state.zpos, an internal DRM
> > property. This is not about the zpos property itself.
>
> Hi,
>
> then I'm very confused. What's the difference?
>
> The text you are changing was specifically added to explain uAPI
> behaviour, that is, what the userspace sees and does with the zpos
> property in uAPI.
>
> Having two conflicting pieces of documentation is confusing, especially
> when it is not absolutely clear which one is for driver implementors
> and which one for uAPI consumers, or that one must ignore the other doc
> depending on who you are.
Yes, I agree that this is confusing.
To be completely honest, I don't really care what the outcome of this
discussion is, as long as there are no conflicting documentation comments.
So, my interpretation of the docs is that there are:
1. Some documentation for KMS properties, that is, what is exposed to
user-space via DRM ioctls. This is the KMS uAPI.
2. Some documentation for kernel drivers, that is, internal DRM state that can
be set by kernel developers. This includes helper functions and common
structs.
Obviously as user-space developers we only care about (1).
Now, back to zpos' case: there are two doc comments about zpos.
The first one is [1], the one this patch changes:
> zpos:
> Z position is set up with drm_plane_create_zpos_immutable_property() and
> drm_plane_create_zpos_property(). It controls the visibility of overlapping
> planes. Without this property the primary plane is always below the cursor
> plane, and ordering between all other planes is undefined. The positive Z
> axis points towards the user, i.e. planes with lower Z position values are
> underneath planes with higher Z position values. Note that the Z position
> value can also be immutable, to inform userspace about the hard-coded
> stacking of overlay planes, see drm_plane_create_zpos_immutable_property().
This is in the "Plane Composition Properties". I believe this paragraph
documents the standard plane properties (standard as in not driver-specific).
So I'd say this documents the KMS uAPI.
The second one is [2], the one you've quoted:
> zpos
>
> Priority of the given plane on crtc (optional).
>
> Note that multiple active planes on the same crtc can have an identical zpos
> value. The rule to solving the conflict is to compare the plane object IDs;
> the plane with a higher ID must be stacked on top of a plane with a lower ID.
>
> See drm_plane_create_zpos_property() and
> drm_plane_create_zpos_immutable_property() for more details.
This is in the "Plane Functions Reference" section, more precisely in the
"struct drm_plane_state" docs. I believe this is really just about the common
DRM struct that can be used by all drivers. This struct isn't exposed to
user-space. It's just an implementation detail of DRM.
(We can see that even without this patch, these two comments already
kind of conflict. The first one says that without zpos ordering is
undefined. The second one says that two identical zpos values means the
plane ID should be used. However drm_plane_state is zero-filled, so a
driver not supporting zpos would have all drm_plane_state.zpos fields
set to zero? Since they are all equal, is the object ID ordering rule
relevant?)
[1]: https://01.org/linuxgraphics/gfx-docs/drm/gpu/drm-kms.html#plane-composition-properties
[2]: https://01.org/linuxgraphics/gfx-docs/drm/gpu/drm-kms.html#plane-functions-reference
> > The comment was introduced in v2 of [1], although the motivation for
> > the change isn't documented.
> >
> > [1]: https://patchwork.freedesktop.org/series/13528/#rev2
>
> That does not look like the comment you are changing.
>
> Wait, which one is "this comment"?
>
> > > zpos
> > >
> > > Priority of the given plane on crtc (optional).
> > >
> > > Note that multiple active planes on the same crtc can have an
> > > identical zpos value. The rule to solving the conflict is to
> > > compare the plane object IDs; the plane with a higher ID must be
> > > stacked on top of a plane with a lower ID.
> > >
> > > See drm_plane_create_zpos_property() and
> > > drm_plane_create_zpos_immutable_property() for more details.
> > >
> > > from https://01.org/linuxgraphics/gfx-docs/drm/gpu/drm-kms.html#plane-functions-reference
>
> Me and others have taken the above to document uAPI. How could that not
> be the case?
(See above)
> Is it wrong for userspace to assume that plane object ID order reflects
> the plane stacking order? Weston does not do this yet, but since we just
> recently found the above comment, we planned to make use of it.
>
> Actually, if the ID ordering is true, then the DRM core could always
> expose the zpos property as immutable to userspace, just manufacture it
> from object IDs if nothing is set by a driver explicitly.
>
> Or is the comment about object IDs wrong and should be changed to say
> the opposite?
I believe so. If zpos could always be obtained from plane object IDs, then what
would be the point of exposing the immutable zpos property at all?
I've heard that some drivers break this object ID assumption, which is the
reason why this zpos property exists. Can someone more familiar with the kernel
provide some feedback?
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] drm: two planes with the same zpos have undefined ordering
2019-09-10 10:38 ` Pekka Paalanen
2019-09-10 11:20 ` Simon Ser
@ 2019-09-16 9:48 ` Daniel Vetter
1 sibling, 0 replies; 14+ messages in thread
From: Daniel Vetter @ 2019-09-16 9:48 UTC (permalink / raw
To: Pekka Paalanen; +Cc: Simon Ser, Daniel Stone, dri-devel
On Tue, Sep 10, 2019 at 12:38 PM Pekka Paalanen <ppaalanen@gmail.com> wrote:
>
> On Tue, 10 Sep 2019 10:09:55 +0000
> Simon Ser <contact@emersion.fr> wrote:
>
> > Currently the property docs don't specify whether it's okay for two planes to
> > have the same zpos value and what user-space should expect in this case.
> >
> > The rule mentionned in the past was to disambiguate with object IDs. However
> > some drivers break this rule (that's why the ordering is documented as
> > unspecified in case the zpos property is missing). Additionally it doesn't
> > really make sense for a driver to user identical zpos values if it knows their
> > relative position: the driver can just pick different values instead.
> >
> > So two solutions would make sense: either disallow completely identical zpos
> > values for two different planes, either make the ordering unspecified. To allow
> > drivers that don't know the relative ordering between two planes to still
> > expose the zpos property, choose the latter solution.
> >
> > Signed-off-by: Simon Ser <contact@emersion.fr>
> > ---
> >
> > Err, I'm sorry about the double-post. I sent this to intel-gfx by mistake.
> >
> > drivers/gpu/drm/drm_blend.c | 8 ++++----
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> > index d02709dd2d4a..51bd5454e50a 100644
> > --- a/drivers/gpu/drm/drm_blend.c
> > +++ b/drivers/gpu/drm/drm_blend.c
> > @@ -132,10 +132,10 @@
> > * planes. Without this property the primary plane is always below the cursor
> > * plane, and ordering between all other planes is undefined. The positive
> > * Z axis points towards the user, i.e. planes with lower Z position values
> > - * are underneath planes with higher Z position values. Note that the Z
> > - * position value can also be immutable, to inform userspace about the
> > - * hard-coded stacking of overlay planes, see
> > - * drm_plane_create_zpos_immutable_property().
> > + * are underneath planes with higher Z position values. Two planes with the
> > + * same Z position value have undefined ordering. Note that the Z position
> > + * value can also be immutable, to inform userspace about the hard-coded
> > + * stacking of overlay planes, see drm_plane_create_zpos_immutable_property().
> > *
> > * pixel blend mode:
> > * Pixel blend mode is set up with drm_plane_create_blend_mode_property().
>
> Hi,
>
> this seems to contradict what the docs say in another place:
>
> zpos
>
> Priority of the given plane on crtc (optional).
>
> Note that multiple active planes on the same crtc can have an
> identical zpos value. The rule to solving the conflict is to
I think we should do an s/rule/recommendation to drivers to avoid
surprises in hw programming/ or something like that. Plus we allow
that for legacy ioctl, otherways it's impossible to change zpos with
legacy ioctls (not that I'm sure that's a reasonable use-case, but
whatever). With that also clarified I think Simon's patch is good to
go, same zpos value is really not something we want to encourage. Plus
"implicit by plane id" is already something we use in other places
(like figuring out which primary plan belongs to which crtc), and it's
just terrible uapi.
-Daniel
> compare the plane object IDs; the plane with a higher ID must be
> stacked on top of a plane with a lower ID.
>
> See drm_plane_create_zpos_property() and
> drm_plane_create_zpos_immutable_property() for more details.
>
> from https://01.org/linuxgraphics/gfx-docs/drm/gpu/drm-kms.html#plane-functions-reference
>
>
> Thanks,
> pq
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] drm: two planes with the same zpos have undefined ordering
2019-09-16 9:19 ` Simon Ser
@ 2019-09-19 7:18 ` Pekka Paalanen
2019-09-19 8:18 ` Daniel Vetter
0 siblings, 1 reply; 14+ messages in thread
From: Pekka Paalanen @ 2019-09-19 7:18 UTC (permalink / raw
To: Simon Ser
Cc: daniel.vetter@ffwll.ch, daniels@collabora.com,
dri-devel@lists.freedesktop.org, Marius-Cristian Vlad
[-- Attachment #1.1: Type: text/plain, Size: 7508 bytes --]
On Mon, 16 Sep 2019 09:19:09 +0000
Simon Ser <contact@emersion.fr> wrote:
> > On Tue, 10 Sep 2019 11:20:16 +0000
> > Simon Ser <contact@emersion.fr> wrote:
> >
> > > On Tuesday, September 10, 2019 1:38 PM, Pekka Paalanen <ppaalanen@gmail.com> wrote:
> > >
> > > > On Tue, 10 Sep 2019 10:09:55 +0000
> > > > Simon Ser contact@emersion.fr wrote:
> > > >
> > > > > Currently the property docs don't specify whether it's okay for two planes to
> > > > > have the same zpos value and what user-space should expect in this case.
> > > > > The rule mentionned in the past was to disambiguate with object IDs. However
> > > > > some drivers break this rule (that's why the ordering is documented as
> > > > > unspecified in case the zpos property is missing). Additionally it doesn't
> > > > > really make sense for a driver to user identical zpos values if it knows their
> > > > > relative position: the driver can just pick different values instead.
> > > > > So two solutions would make sense: either disallow completely identical zpos
> > > > > values for two different planes, either make the ordering unspecified. To allow
> > > > > drivers that don't know the relative ordering between two planes to still
> > > > > expose the zpos property, choose the latter solution.
> > > > >
> > > > > Signed-off-by: Simon Ser contact@emersion.fr
> > > > >
> > > > > ---------------------------------------------
> > > > >
> > > > > Err, I'm sorry about the double-post. I sent this to intel-gfx by mistake.
> > > > > drivers/gpu/drm/drm_blend.c | 8 ++++----
> > > > > 1 file changed, 4 insertions(+), 4 deletions(-)
> > > > > diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> > > > > index d02709dd2d4a..51bd5454e50a 100644
> > > > > --- a/drivers/gpu/drm/drm_blend.c
> > > > > +++ b/drivers/gpu/drm/drm_blend.c
> > > > > @@ -132,10 +132,10 @@
> > > > >
> > > > > - planes. Without this property the primary plane is always below the cursor
> > > > > - plane, and ordering between all other planes is undefined. The positive
> > > > > - Z axis points towards the user, i.e. planes with lower Z position values
> > > > >
> > > > > - - are underneath planes with higher Z position values. Note that the Z
> > > > > - - position value can also be immutable, to inform userspace about the
> > > > > - - hard-coded stacking of overlay planes, see
> > > > > - - drm_plane_create_zpos_immutable_property().
> > > > >
> > > > > - - are underneath planes with higher Z position values. Two planes with the
> > > > > - - same Z position value have undefined ordering. Note that the Z position
> > > > > - - value can also be immutable, to inform userspace about the hard-coded
> > > > > - - stacking of overlay planes, see drm_plane_create_zpos_immutable_property().
> > > > > -
> > > > > - pixel blend mode:
> > > > > - Pixel blend mode is set up with drm_plane_create_blend_mode_property().
> > > >
> > > > Hi,
> > > >
> > > > this seems to contradict what the docs say in another place:
> > >
> > > Except this comment is about drm_plane_state.zpos, an internal DRM
> > > property. This is not about the zpos property itself.
> >
> > Hi,
> >
> > then I'm very confused. What's the difference?
> >
> > The text you are changing was specifically added to explain uAPI
> > behaviour, that is, what the userspace sees and does with the zpos
> > property in uAPI.
> >
> > Having two conflicting pieces of documentation is confusing, especially
> > when it is not absolutely clear which one is for driver implementors
> > and which one for uAPI consumers, or that one must ignore the other doc
> > depending on who you are.
>
> Yes, I agree that this is confusing.
>
> To be completely honest, I don't really care what the outcome of this
> discussion is, as long as there are no conflicting documentation comments.
Hi,
that is exactly what I want too.
> So, my interpretation of the docs is that there are:
>
> 1. Some documentation for KMS properties, that is, what is exposed to
> user-space via DRM ioctls. This is the KMS uAPI.
> 2. Some documentation for kernel drivers, that is, internal DRM state that can
> be set by kernel developers. This includes helper functions and common
> structs.
>
> Obviously as user-space developers we only care about (1).
Theoretically yes, but the problem is that one cannot make that
distinction. I'm pretty sure both categories of comments are not
complete, and answers to some questions in one must be dug up from the
other, if documented at all.
So you cannot use wording that looks conflicting between the two. If
the wording is correct nevertheless, it needs more explaining on how it
doesn't actually conflict, so that people randomly reading just one
side or the other don't get the wrong idea.
> Now, back to zpos' case: there are two doc comments about zpos.
>
> The first one is [1], the one this patch changes:
>
> > zpos:
> > Z position is set up with drm_plane_create_zpos_immutable_property() and
> > drm_plane_create_zpos_property(). It controls the visibility of overlapping
> > planes. Without this property the primary plane is always below the cursor
> > plane, and ordering between all other planes is undefined. The positive Z
> > axis points towards the user, i.e. planes with lower Z position values are
> > underneath planes with higher Z position values. Note that the Z position
> > value can also be immutable, to inform userspace about the hard-coded
> > stacking of overlay planes, see drm_plane_create_zpos_immutable_property().
>
> This is in the "Plane Composition Properties". I believe this paragraph
> documents the standard plane properties (standard as in not driver-specific).
> So I'd say this documents the KMS uAPI.
>
> The second one is [2], the one you've quoted:
>
> > zpos
> >
> > Priority of the given plane on crtc (optional).
> >
> > Note that multiple active planes on the same crtc can have an identical zpos
> > value. The rule to solving the conflict is to compare the plane object IDs;
> > the plane with a higher ID must be stacked on top of a plane with a lower ID.
> >
> > See drm_plane_create_zpos_property() and
> > drm_plane_create_zpos_immutable_property() for more details.
>
> This is in the "Plane Functions Reference" section, more precisely in the
> "struct drm_plane_state" docs. I believe this is really just about the common
> DRM struct that can be used by all drivers. This struct isn't exposed to
> user-space. It's just an implementation detail of DRM.
>
> (We can see that even without this patch, these two comments already
> kind of conflict. The first one says that without zpos ordering is
> undefined. The second one says that two identical zpos values means the
> plane ID should be used. However drm_plane_state is zero-filled, so a
> driver not supporting zpos would have all drm_plane_state.zpos fields
> set to zero? Since they are all equal, is the object ID ordering rule
> relevant?)
Right, and we are suffering from that confusion already. Should
userspace use ID order if zpos property is not there or not? I have no
idea.
> [1]: https://01.org/linuxgraphics/gfx-docs/drm/gpu/drm-kms.html#plane-composition-properties
> [2]: https://01.org/linuxgraphics/gfx-docs/drm/gpu/drm-kms.html#plane-functions-reference
Thanks,
pq
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] drm: two planes with the same zpos have undefined ordering
2019-09-19 7:18 ` Pekka Paalanen
@ 2019-09-19 8:18 ` Daniel Vetter
2019-09-19 9:01 ` Pekka Paalanen
0 siblings, 1 reply; 14+ messages in thread
From: Daniel Vetter @ 2019-09-19 8:18 UTC (permalink / raw
To: Pekka Paalanen
Cc: Simon Ser, daniels@collabora.com, dri-devel@lists.freedesktop.org,
Marius-Cristian Vlad
On Thu, Sep 19, 2019 at 9:18 AM Pekka Paalanen <ppaalanen@gmail.com> wrote:
>
> On Mon, 16 Sep 2019 09:19:09 +0000
> Simon Ser <contact@emersion.fr> wrote:
>
> > > On Tue, 10 Sep 2019 11:20:16 +0000
> > > Simon Ser <contact@emersion.fr> wrote:
> > >
> > > > On Tuesday, September 10, 2019 1:38 PM, Pekka Paalanen <ppaalanen@gmail.com> wrote:
> > > >
> > > > > On Tue, 10 Sep 2019 10:09:55 +0000
> > > > > Simon Ser contact@emersion.fr wrote:
> > > > >
> > > > > > Currently the property docs don't specify whether it's okay for two planes to
> > > > > > have the same zpos value and what user-space should expect in this case.
> > > > > > The rule mentionned in the past was to disambiguate with object IDs. However
> > > > > > some drivers break this rule (that's why the ordering is documented as
> > > > > > unspecified in case the zpos property is missing). Additionally it doesn't
> > > > > > really make sense for a driver to user identical zpos values if it knows their
> > > > > > relative position: the driver can just pick different values instead.
> > > > > > So two solutions would make sense: either disallow completely identical zpos
> > > > > > values for two different planes, either make the ordering unspecified. To allow
> > > > > > drivers that don't know the relative ordering between two planes to still
> > > > > > expose the zpos property, choose the latter solution.
> > > > > >
> > > > > > Signed-off-by: Simon Ser contact@emersion.fr
> > > > > >
> > > > > > ---------------------------------------------
> > > > > >
> > > > > > Err, I'm sorry about the double-post. I sent this to intel-gfx by mistake.
> > > > > > drivers/gpu/drm/drm_blend.c | 8 ++++----
> > > > > > 1 file changed, 4 insertions(+), 4 deletions(-)
> > > > > > diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> > > > > > index d02709dd2d4a..51bd5454e50a 100644
> > > > > > --- a/drivers/gpu/drm/drm_blend.c
> > > > > > +++ b/drivers/gpu/drm/drm_blend.c
> > > > > > @@ -132,10 +132,10 @@
> > > > > >
> > > > > > - planes. Without this property the primary plane is always below the cursor
> > > > > > - plane, and ordering between all other planes is undefined. The positive
> > > > > > - Z axis points towards the user, i.e. planes with lower Z position values
> > > > > >
> > > > > > - - are underneath planes with higher Z position values. Note that the Z
> > > > > > - - position value can also be immutable, to inform userspace about the
> > > > > > - - hard-coded stacking of overlay planes, see
> > > > > > - - drm_plane_create_zpos_immutable_property().
> > > > > >
> > > > > > - - are underneath planes with higher Z position values. Two planes with the
> > > > > > - - same Z position value have undefined ordering. Note that the Z position
> > > > > > - - value can also be immutable, to inform userspace about the hard-coded
> > > > > > - - stacking of overlay planes, see drm_plane_create_zpos_immutable_property().
> > > > > > -
> > > > > > - pixel blend mode:
> > > > > > - Pixel blend mode is set up with drm_plane_create_blend_mode_property().
> > > > >
> > > > > Hi,
> > > > >
> > > > > this seems to contradict what the docs say in another place:
> > > >
> > > > Except this comment is about drm_plane_state.zpos, an internal DRM
> > > > property. This is not about the zpos property itself.
> > >
> > > Hi,
> > >
> > > then I'm very confused. What's the difference?
> > >
> > > The text you are changing was specifically added to explain uAPI
> > > behaviour, that is, what the userspace sees and does with the zpos
> > > property in uAPI.
> > >
> > > Having two conflicting pieces of documentation is confusing, especially
> > > when it is not absolutely clear which one is for driver implementors
> > > and which one for uAPI consumers, or that one must ignore the other doc
> > > depending on who you are.
> >
> > Yes, I agree that this is confusing.
> >
> > To be completely honest, I don't really care what the outcome of this
> > discussion is, as long as there are no conflicting documentation comments.
>
> Hi,
>
> that is exactly what I want too.
>
> > So, my interpretation of the docs is that there are:
> >
> > 1. Some documentation for KMS properties, that is, what is exposed to
> > user-space via DRM ioctls. This is the KMS uAPI.
> > 2. Some documentation for kernel drivers, that is, internal DRM state that can
> > be set by kernel developers. This includes helper functions and common
> > structs.
> >
> > Obviously as user-space developers we only care about (1).
>
> Theoretically yes, but the problem is that one cannot make that
> distinction. I'm pretty sure both categories of comments are not
> complete, and answers to some questions in one must be dug up from the
> other, if documented at all.
>
> So you cannot use wording that looks conflicting between the two. If
> the wording is correct nevertheless, it needs more explaining on how it
> doesn't actually conflict, so that people randomly reading just one
> side or the other don't get the wrong idea.
>
> > Now, back to zpos' case: there are two doc comments about zpos.
> >
> > The first one is [1], the one this patch changes:
> >
> > > zpos:
> > > Z position is set up with drm_plane_create_zpos_immutable_property() and
> > > drm_plane_create_zpos_property(). It controls the visibility of overlapping
> > > planes. Without this property the primary plane is always below the cursor
> > > plane, and ordering between all other planes is undefined. The positive Z
> > > axis points towards the user, i.e. planes with lower Z position values are
> > > underneath planes with higher Z position values. Note that the Z position
> > > value can also be immutable, to inform userspace about the hard-coded
> > > stacking of overlay planes, see drm_plane_create_zpos_immutable_property().
> >
> > This is in the "Plane Composition Properties". I believe this paragraph
> > documents the standard plane properties (standard as in not driver-specific).
> > So I'd say this documents the KMS uAPI.
> >
> > The second one is [2], the one you've quoted:
> >
> > > zpos
> > >
> > > Priority of the given plane on crtc (optional).
> > >
> > > Note that multiple active planes on the same crtc can have an identical zpos
> > > value. The rule to solving the conflict is to compare the plane object IDs;
> > > the plane with a higher ID must be stacked on top of a plane with a lower ID.
> > >
> > > See drm_plane_create_zpos_property() and
> > > drm_plane_create_zpos_immutable_property() for more details.
> >
> > This is in the "Plane Functions Reference" section, more precisely in the
> > "struct drm_plane_state" docs. I believe this is really just about the common
> > DRM struct that can be used by all drivers. This struct isn't exposed to
> > user-space. It's just an implementation detail of DRM.
> >
> > (We can see that even without this patch, these two comments already
> > kind of conflict. The first one says that without zpos ordering is
> > undefined. The second one says that two identical zpos values means the
> > plane ID should be used. However drm_plane_state is zero-filled, so a
> > driver not supporting zpos would have all drm_plane_state.zpos fields
> > set to zero? Since they are all equal, is the object ID ordering rule
> > relevant?)
>
> Right, and we are suffering from that confusion already. Should
> userspace use ID order if zpos property is not there or not? I have no
> idea.
Nope. I think the only options for this case are:
- file bug against upstream driver so they add zpos
- you magically know how planes work on that hw
- you don't overlap planes at all
- cursor is above primary, that much we can guarantee
Yes it's kinda uapi fail we didn't add zpos from the start :-/
-Daniel
>
> > [1]: https://01.org/linuxgraphics/gfx-docs/drm/gpu/drm-kms.html#plane-composition-properties
> > [2]: https://01.org/linuxgraphics/gfx-docs/drm/gpu/drm-kms.html#plane-functions-reference
>
>
> Thanks,
> pq
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] drm: two planes with the same zpos have undefined ordering
2019-09-19 8:18 ` Daniel Vetter
@ 2019-09-19 9:01 ` Pekka Paalanen
2019-09-19 9:36 ` Daniel Vetter
0 siblings, 1 reply; 14+ messages in thread
From: Pekka Paalanen @ 2019-09-19 9:01 UTC (permalink / raw
To: Daniel Vetter
Cc: Simon Ser, daniels@collabora.com, dri-devel@lists.freedesktop.org,
Marius-Cristian Vlad
[-- Attachment #1.1: Type: text/plain, Size: 951 bytes --]
On Thu, 19 Sep 2019 10:18:04 +0200
Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> On Thu, Sep 19, 2019 at 9:18 AM Pekka Paalanen <ppaalanen@gmail.com> wrote:
> >
...
> > Right, and we are suffering from that confusion already. Should
> > userspace use ID order if zpos property is not there or not? I have no
> > idea.
>
> Nope. I think the only options for this case are:
> - file bug against upstream driver so they add zpos
> - you magically know how planes work on that hw
> - you don't overlap planes at all
> - cursor is above primary, that much we can guarantee
>
> Yes it's kinda uapi fail we didn't add zpos from the start :-/
Good. Weston does the last two. The confusion did not last long
enough to let us add code using the object ID to infer stacking order.
Although, Weston does have the assumption that overlays are in unknown
order between primary and cursor, which now seems false.
Thanks,
pq
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] drm: two planes with the same zpos have undefined ordering
2019-09-19 9:01 ` Pekka Paalanen
@ 2019-09-19 9:36 ` Daniel Vetter
0 siblings, 0 replies; 14+ messages in thread
From: Daniel Vetter @ 2019-09-19 9:36 UTC (permalink / raw
To: Pekka Paalanen
Cc: Simon Ser, daniels@collabora.com, dri-devel@lists.freedesktop.org,
Marius-Cristian Vlad
On Thu, Sep 19, 2019 at 11:02 AM Pekka Paalanen <ppaalanen@gmail.com> wrote:
>
> On Thu, 19 Sep 2019 10:18:04 +0200
> Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>
> > On Thu, Sep 19, 2019 at 9:18 AM Pekka Paalanen <ppaalanen@gmail.com> wrote:
> > >
>
> ...
>
> > > Right, and we are suffering from that confusion already. Should
> > > userspace use ID order if zpos property is not there or not? I have no
> > > idea.
> >
> > Nope. I think the only options for this case are:
> > - file bug against upstream driver so they add zpos
> > - you magically know how planes work on that hw
> > - you don't overlap planes at all
> > - cursor is above primary, that much we can guarantee
> >
> > Yes it's kinda uapi fail we didn't add zpos from the start :-/
>
> Good. Weston does the last two. The confusion did not last long
> enough to let us add code using the object ID to infer stacking order.
>
> Although, Weston does have the assumption that overlays are in unknown
> order between primary and cursor, which now seems false.
I think cursor is always on top, but some of the overlays can be underlays.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2019-09-19 9:36 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-09-10 10:07 [PATCH] drm: two planes with the same zpos have undefined ordering Simon Ser
2019-09-10 11:52 ` ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
2019-09-10 12:15 ` ✓ Fi.CI.BAT: success " Patchwork
2019-09-10 17:12 ` ✗ Fi.CI.IGT: failure " Patchwork
-- strict thread matches above, loose matches on Subject: below --
2019-09-10 10:09 [PATCH] " Simon Ser
2019-09-10 10:38 ` Pekka Paalanen
2019-09-10 11:20 ` Simon Ser
2019-09-11 7:36 ` Pekka Paalanen
2019-09-16 9:19 ` Simon Ser
2019-09-19 7:18 ` Pekka Paalanen
2019-09-19 8:18 ` Daniel Vetter
2019-09-19 9:01 ` Pekka Paalanen
2019-09-19 9:36 ` Daniel Vetter
2019-09-16 9:48 ` Daniel Vetter
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.