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

LV2: currently we need a X11 display since the Gtk Thread is unconditionally started #35

Closed
swesterfeld opened this issue Jan 26, 2024 · 4 comments
Assignees
Milestone

Comments

@swesterfeld
Copy link
Collaborator

Using AnklangSynthEngine with LV2 support currently fails without $DISPLAY. This is because LV2 host is a singleton variable that loads gtk2wrap and starts the Gtk thread as soon as its instantiated.

$ ( unset DISPLAY; out/lib/AnklangSynthEngine )
LISTEN: http://127.0.0.1:1777/
[...]

(AnklangSynthEngine:1602159): Gtk-WARNING **: 17:24:01.013: cannot open display: 

The question is of course if the no display case should block the merge? If so, here are two options of how to support no-display, but there may be better solutions:

Option 1

We could disable LV2 support altogether if the Gtk thread could not be started, this has the advantage that it is relatively simple to implement.

Option 2

One way to deal with this would be to try to auto detect whether we have a display. One could use something like gst123 does:

bool
GtkInterface::have_x11_display()
{
  static Display *display = NULL;

  if (!display)
    display = XOpenDisplay (NULL);   // this should work if and only if we do have an X11 server we can use

  return display != NULL;
}

and if that fails, start a thread that is not the Gtk thread in gtk2wrap. Then the LV2 plugins could run in that thread, but any custom UIs would have to be disabled.

@tim-janik
Copy link
Owner

From the Gtk2 docs: https://developer-old.gnome.org/gtk2/stable/gtk2-General.html#gtk-init-check

gtk_init_check()
This function does the same work as gtk_init()
with only a single change: It does not terminate the program if the GUI can't be initialized. Instead it returns FALSE
on failure. This way the application can fall back to some other means of communication with the user - for example
a curses or command line interface.

There is no way we can support LV2 GUIs when DISPLAY is missing, but we can still register plugins and run them in headless mode. That means, try to init gtk and if that is not working, run LV2 plugins in the default glib main loop (the main loop context usually taken over by gtk). I.e. the plugins should still not live in the Anklang main loop.

@tim-janik
Copy link
Owner

Option 1

We could disable LV2 support altogether if the Gtk thread could not be started, this has the advantage that it is relatively simple to implement.

Anklang is meant to provide good support / usability for plugins without custom UIs, why should the stop working in headless mode? I.e. that'd violate the principle of least surprise.

Option 2

One way to deal with this would be to try to auto detect whether we have a display. One could use something like gst123 does:
if (!display)
display = XOpenDisplay (NULL); // this should work if and only if we do have an X11 server we can use

That doesn't support the usual set of gtk options, use gtk_init_check() instead.
In fact, that'd be better to do for gst123 as well.

@tim-janik tim-janik added this to the v0.4.0 milestone Jan 27, 2024
@swesterfeld
Copy link
Collaborator Author

Anklang is meant to provide good support / usability for plugins without custom UIs, why should the stop working in headless mode? I.e. that'd violate the principle of least surprise.

Yes, I thought it might be too much work to get this right for the first version of LV2 support, but it turned out to be easier than I thought. Please review:

e7098a4
d2653b1

@tim-janik
Copy link
Owner

Anklang is meant to provide good support / usability for plugins without custom UIs, why should the stop working in headless mode? I.e. that'd violate the principle of least surprise.

Yes, I thought it might be too much work to get this right for the first version of LV2 support, but it turned out to be easier than I thought. Please review:

e7098a4 d2653b1

Great, looks good (the first patch, i don't really know about suil).
Will this make it into gst123 as well?

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

2 participants