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 796772 - waylandsink: check for wl_shell unneeded when surface and display are passed by the application
waylandsink: check for wl_shell unneeded when surface and display are passed ...
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
1.14.0
Other Linux
: Normal enhancement
: 1.15.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2018-07-10 01:33 UTC by Matteo Valdina
Modified: 2018-07-25 12:40 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch for downgrade wl_shell check. (2.50 KB, patch)
2018-07-10 01:33 UTC, Matteo Valdina
none Details | Review
relaxed wl_shell check and zwp_fullscreen_shell support (6.46 KB, patch)
2018-07-11 03:01 UTC, Matteo Valdina
none Details | Review
patch for downgrade wl_shell check and zwp_fullscreen_shell support. (6.44 KB, patch)
2018-07-25 00:49 UTC, Matteo Valdina
committed Details | Review

Description Matteo Valdina 2018-07-10 01:33:26 UTC
Created attachment 372985 [details] [review]
patch for downgrade wl_shell check.

I have an application that uses waylandsink and passed the surface and display handle to the waylandsink.

When I use waylandsink in weston/fullscreen-shell waylandsink fails to check for wl_shell protocol extension. 
But this is not needed because the surface is properly configured by the application (via zwp_fullscreen_shell).

If I comment out the wl_shell check and my scenario start working.

Best
Matteo Valdina
Comment 1 Nicolas Dufresne (ndufresne) 2018-07-10 13:24:22 UTC
Review of attachment 372985 [details] [review]:

Can you provide a small application that demonstrate this ?

::: ext/wayland/wldisplay.c
@@ +354,3 @@
 
+  if (!self->shell) {
+    g_warning ("Could not bind to wp_shell");

you mean wl ?
Comment 2 Matteo Valdina 2018-07-10 16:46:08 UTC
Yes, sorry my bad. It should be wl_shell.

About the small demonstration app, I'll try but it is not easy. To run a Wayland client in these scenario requires a bunch of code.

You also need to run the weston compositor with the fullscreen-shell.so
Comment 3 Nicolas Dufresne (ndufresne) 2018-07-10 17:27:06 UTC
Ok, running weston with that is not a problem for me. What I'm trying to figure-out is if there is any corner case that I may be missing that would leave the pipeline dangling without appropriate error. I'm also wondering, why not add support for the scenario instead, so that gst-launch works without wl_shell ?
Comment 4 Matteo Valdina 2018-07-11 00:10:58 UTC
> I'm also wondering, why not add support for the scenario instead, so that 
> gst-launch works without wl_shell ?

The point of relaxing the wl_shell constrains is to allow the application to run in a Wayland compositor that is not providing wl_shell (for example fullscreen-shell) and let the application to deal with it. 
In this way the application developer can use waylandsink in other wayland compositor or custom compositor.

I know that there are couples of shells that likes wl_shell, for example, fullscreen_shell, xdg_shell, and ivi_shell.

This is different from adding the support of fullscreen_shell that it is more for gst-launch or simpler application.

Anyway, the support of fullscreen_shell is an easy task. I'll try to wrap-up a patch for that.

About the corner case for wl_shell I see that the error condition is handled like a failure of wl_shell_surface.
Comment 5 Matteo Valdina 2018-07-11 03:01:27 UTC
Created attachment 372992 [details] [review]
relaxed wl_shell check and zwp_fullscreen_shell support

Here an updated patch with the relaxed wl_shell check and zwp_fullscreen_shell.

I tested with these commands:

weston -Bwayland-backend.so --shell=fullscreen-shell.so --no-config --use-pixman -Swayland-1
and
gst-launch-1.0 videotestsrc ! waylandsink display=wayland-1
Comment 6 Matteo Valdina 2018-07-17 02:32:43 UTC
Hi,
Any updates/comments on the patch?

Best
Matteo
Comment 7 Nicolas Dufresne (ndufresne) 2018-07-17 14:22:36 UTC
There is conflict when applying on git master, can your rebase and re-submit please ?
Comment 8 Nicolas Dufresne (ndufresne) 2018-07-17 14:41:17 UTC
I've manually merge the thing, which is scary, so please do rebase and re-submit. From the testing:

  gst-launch-1.0 videotestsrc ! waylandsink display=wayland-1

Ends up showing a centered 320x240 video. I was expecting the video to cover the screen, I think more work is needed, weston can scale the video and should in this case imho.
Comment 9 Matteo Valdina 2018-07-17 14:52:19 UTC
Hi, I'll rebase it not a problem. I worked on the 1.14 branch.

About the center, it depends on the arguments passed to the fullscreen_shell.

zwp_fullscreen_shell_v1_present_surface (display->fullscreen_shell,
+        window->area_surface, ZWP_FULLSCREEN_SHELL_V1_PRESENT_METHOD_DEFAULT,
+        NULL);


I pass ZWP_FULLSCREEN_SHELL_V1_PRESENT_METHOD_DEFAULT that it is the default behavior but you can pass ZWP_FULLSCREEN_SHELL_V1_PRESENT_METHOD_ZOOM to zoom the view to fullscreen.
Comment 10 Nicolas Dufresne (ndufresne) 2018-07-17 15:16:37 UTC
(In reply to Matteo Valdina from comment #9)
> I pass ZWP_FULLSCREEN_SHELL_V1_PRESENT_METHOD_DEFAULT that it is the default
> behavior but you can pass ZWP_FULLSCREEN_SHELL_V1_PRESENT_METHOD_ZOOM to
> zoom the view to fullscreen.

I think for video rendering, the zoom method is the one that makes the most sense. The GstVideoOverlay set_render_rectangle() method should deal with the case you want to place the video elsewhere.
Comment 11 Matteo Valdina 2018-07-25 00:49:58 UTC
Created attachment 373150 [details] [review]
patch for downgrade wl_shell check and  zwp_fullscreen_shell support.

 - Rebased GStreamer master.
 - Changed rendering to fullscreen (zoom) instead of default mode.
Comment 12 Nicolas Dufresne (ndufresne) 2018-07-25 02:56:35 UTC
Thanks, I'll do a final check tomorrow and hopefully merge.
Comment 13 Nicolas Dufresne (ndufresne) 2018-07-25 11:55:35 UTC
See commit e0535b44d4dceb3554dd67ff0402730d263e2e04
Comment 14 Matteo Valdina 2018-07-25 12:04:10 UTC
Thanks, for the quick review.

The GitHub mirror is still maintained? 
I don't have access/view on gitlab.
Comment 15 Nicolas Dufresne (ndufresne) 2018-07-25 12:40:04 UTC
The GitHub mirror is read-only, it will update itself eventually (it's automated). The gitlab migration is being delayed / held at the moment. The official repository is still on git.freedesktop.org