Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Galicaster does not run on Wayland #606

Open
ppettit opened this issue Nov 27, 2018 · 4 comments
Open

Galicaster does not run on Wayland #606

ppettit opened this issue Nov 27, 2018 · 4 comments

Comments

@ppettit
Copy link
Collaborator

ppettit commented Nov 27, 2018

Galicaster tries to get the xid of the Gtk.DrawingArea to embed video which obviously does not exist in Wayland. The error is 'GdkWaylandWindow' object has no attribute 'get_xid'.

If started with the GDK_BACKEND=x11 I get GstVideoTestSrc:gc-videotest-src: streaming stopped, reason not-negotiated (-4)

This seems like it might be complicated to fix...

@Alfro
Copy link
Contributor

Alfro commented Nov 28, 2018

Hi @ppettit, are there any differences between setting XDG_BACKEND=x11 and GDK_BACKEND=x11?

In any case, maybe there is a more generic way to embed a GStreamer video on GTK (without using set_window_handle())?

@ppettit
Copy link
Collaborator Author

ppettit commented Nov 28, 2018

@Alfro haha, yes GDK_BACKEND=x11 actually does something and XDG_BACKEND=x11 doesn't 😉 sorry that was just a typo in the issue, I was setting it correctly while testing.

A quick google around doesn't come up with an obvious solution. My understanding is that Wayland is designed to stop you from doing things like this (one process drawing into another processes window) but maybe I am missing something.

@ppettit
Copy link
Collaborator Author

ppettit commented Dec 3, 2018

I did a quick proof of concept using gtksink/gtkglsink and that seems to work for both X and Wayland.

It works in a fundamentally different way though

  • when using xvimagesink etc (the current method) you make a GtkDrawingArea and pass its xid to the sink element
  • when using gtksink the element produces a widget which you pack into a container in the UI

Supporting both methods might be very messy - what do you think about moving to the gtksink/gtkglsink way of doing things completely? It is already pretty messy with all the dancing around between the UI thread and the recorder service. Do you think it is worth me implementing that to see how it works?

@rubenrua
Copy link
Contributor

rubenrua commented Dec 3, 2018

+1 gtksink/gtkglsink

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants