After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 768183 - kmssink: only works on overlay planes
kmssink: only works on overlay planes
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal normal
: 1.9.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-06-29 13:21 UTC by Javier Martinez Canillas
Modified: 2016-10-31 14:25 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
modetest output for Peach Pi Chromebook (5.19 KB, text/plain)
2016-06-29 13:21 UTC, Javier Martinez Canillas
  Details
[PATCH 1/2] kmssink: add a plane-id property (3.82 KB, patch)
2016-06-29 13:24 UTC, Javier Martinez Canillas
committed Details | Review
[PATCH 2/2] kmssink: add universal-plane property (4.78 KB, patch)
2016-06-29 13:25 UTC, Javier Martinez Canillas
rejected Details | Review
[PATCH 2/2] kmssink: fallback to universal planes if no overlay plane is found (2.26 KB, patch)
2016-06-29 19:32 UTC, Javier Martinez Canillas
none Details | Review
[PATCH v2 2/2] kmssink: fallback to universal planes if no overlay plane is found (2.52 KB, patch)
2016-06-29 20:38 UTC, Javier Martinez Canillas
committed Details | Review

Description Javier Martinez Canillas 2016-06-29 13:21:41 UTC
Created attachment 330580 [details]
modetest output for Peach Pi Chromebook

By default, only overlay planes are returned by the DRM_IOCTL_MODE_GETPLANERESOURCES ioctl unless a client user-space application sets the DRM_CLIENT_CAP_UNIVERSAL_PLANES capability bit to also get the primary and cursor planes.

So if a CRTC only has primary planes and not overlay planes associated, kmssink will fail to find a suitable plane for the CRTC, i.e:

kmssink gstkmssink.c:482:gst_kms_sink_start:<kmssink0> Could not find a plane for crtc

I'm having this issue when trying to use the CRTC of the HDMI connector in both an Exynos5422 Odroid XU4 board and an Exynos5800 Peach Pi Chromebook, were the HDMI CRTC only has a primary plane associated but no overlay plane. I've attached the modetest output on my Peach Pi Chromebook.

I came up with two possible approaches to solve this:

a) Add a plane-id property so a specific plane can be used instead kmssink finding the first overlay plane that's possible to use with a CRTC, i.e:

$ gst-launch-1.0 foo ! kmssink connector-id=36 plane-id=30

The disadvantage of this approach is that it won't work automagically as is the case with overlay planes.

b) Add a universal-planes property to specify that universal planes is supported and not restrict the output to only overlay planes, i.e:

$ gst-launch-1.0 foo ! kmssink connector-id=36 universal-planes=true

The disadvantage of this approach is that I believe it would be preferable to use an overlay plane instead of a primary plane but find_plane_for_crtc () will just return the first possible plane regardless of its type (the type can be queried but with another ioctl call so maybe as a follow-up patch).

I'll add patches for both approaches but these are also not mutually exclusive. Even when either of these could solve the issue, I think having both options makes sense since solve slightly different things: choosing a specific plane to use vs allowing to use primary planes.
Comment 1 Javier Martinez Canillas 2016-06-29 13:24:27 UTC
Created attachment 330582 [details] [review]
[PATCH 1/2] kmssink: add a plane-id property
Comment 2 Javier Martinez Canillas 2016-06-29 13:25:22 UTC
Created attachment 330584 [details] [review]
[PATCH 2/2] kmssink: add universal-plane property
Comment 3 Luis de Bethencourt 2016-06-29 13:29:20 UTC
I have checked these and they look good to me.

Suggested to Javier to ask for comments here since it adds properties and those should be added with care. In this case they make a lot of sense but any API changes should be done thoroughly.

Thanks Javier! :)
Comment 4 Víctor Manuel Jáquez Leal 2016-06-29 15:07:28 UTC
Review of attachment 330582 [details] [review]:

This patch makes perfectly sense to me.
Comment 5 Víctor Manuel Jáquez Leal 2016-06-29 15:09:34 UTC
Review of attachment 330584 [details] [review]:

I'm not sure about this. I wonder if we could add it as a fallback: if a plane cannot be found, then enable this capability and ask again for a plane.
Comment 6 Víctor Manuel Jáquez Leal 2016-06-29 15:10:31 UTC
@Nicolas, I would like to know what do you think.

And thanks @Javier :DDD
Comment 7 Nicolas Dufresne (ndufresne) 2016-06-29 15:20:14 UTC
I think you bring a good point, in the end we want it to just work on most platforms, even if it means RGB only. How much work is it to run this twice, once without, and if there is no overlay, run it again ?
Comment 8 Javier Martinez Canillas 2016-06-29 15:37:56 UTC
@Victor, @Nicolas yes, I in fact considered that option but then discarded since I thought it would be kind of brute force.

But as @Nicolas said to me, sometimes we have to do this due lack of information.

I'll propose an alternate patch for 2/2 that does the fallback as you suggested. Probably later today.

Thanks a lot for your feedback!
Comment 9 Javier Martinez Canillas 2016-06-29 19:32:05 UTC
Created attachment 330620 [details] [review]
[PATCH 2/2] kmssink: fallback to universal planes if no overlay plane is found

Hello, this patch supersedes "[PATCH 2/2] kmssink: add universal-plane property" and fallbacks to universal planes if no overlay plane associated with the CRTC is found as suggested by @Victor, instead of using a universal-plane property like the previous approach.
Comment 10 Javier Martinez Canillas 2016-06-29 19:35:43 UTC
Comment on attachment 330584 [details] [review]
[PATCH 2/2] kmssink: add universal-plane property

Forgot to mark this patch as superseded when attaching the new patch, so I'm marking it as obsolete. Sorry for the noise...
Comment 11 Víctor Manuel Jáquez Leal 2016-06-29 20:06:30 UTC
Review of attachment 330620 [details] [review]:

Looks neat. Just a nitpìck :(

::: sys/kms/gstkmssink.c
@@ +495,3 @@
 plane_failed:
   {
     GST_ERROR_OBJECT (self, "Could not find a plane for crtc");

I would demote this message to a WARNING or lesser.
Comment 12 Javier Martinez Canillas 2016-06-29 20:19:14 UTC
Right, I think the correct would be to only show the error message on the second try (when universal_planes == TRUE) and not if another try with universal planes is going to be made.

What do you think of that instead?
Comment 13 Javier Martinez Canillas 2016-06-29 20:38:04 UTC
Created attachment 330623 [details] [review]
[PATCH v2 2/2] kmssink: fallback to universal planes if no overlay  plane is found

@Victor, I attached a v2 of patch 2/2 which I think addresses correctly the issue you pointed out. Please let me know what you think.

Thanks a lot for your feedback!
Comment 14 Víctor Manuel Jáquez Leal 2016-06-29 20:44:11 UTC
Comment on attachment 330623 [details] [review]
[PATCH v2 2/2] kmssink: fallback to universal planes if no overlay  plane is found

lgtm! Thanks!
Comment 15 Víctor Manuel Jáquez Leal 2016-06-29 20:44:30 UTC
Comment on attachment 330582 [details] [review]
[PATCH 1/2] kmssink: add a plane-id property

lgtm!
Comment 16 Víctor Manuel Jáquez Leal 2016-06-29 20:45:49 UTC
I will wait to @Nicolas if he has any input and if not, tomorrow I'll push them.

Thanks @Javier!
Comment 17 Javier Martinez Canillas 2016-06-29 20:47:38 UTC
Awesome, thanks a lot for your help @Victor!
Comment 18 Nicolas Dufresne (ndufresne) 2016-06-29 21:26:28 UTC
Review of attachment 330623 [details] [review]:

Looks good to me to.
Comment 19 Nicolas Dufresne (ndufresne) 2016-06-29 21:27:43 UTC
Review of attachment 330582 [details] [review]:

Looks good to me to.