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

[swesterfeld]

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]

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]

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.

[swesterfeld]

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:

https://github.com/tim-janik/anklang/commit/e7098a4e14439cc8ede5ecb228d12be4179b39ac https://github.com/tim-janik/anklang/commit/d2653b1a08acff0a960fd31b3adc4835ee618e77

[tim-janik]

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?