Wayland support

[smlx]

Hi, I've had a bug reported in Debian against pasystray running under wayland. Basically, pasystray crashes on startup.

From the backtrace, it looks very similar to this bug reported against Empathy in Gnome. Apparently, according to that bug report, gdk_x11_* calls aren't expected to work at all under wayland?

[fsateler]

Hi,

I was told on IRC that the gdk_x11_* calls are indeed not expected to work when not running under X. Therefore one needs to guard them with GDK_IS_X11_DISPLAY(display). The following diff (against 0.6.0) avoids the crash:

--- a/src/x11-property.c
+++ b/src/x11-property.c
@@ -43,11 +43,15 @@ static Window window;
 void x11_property_init()
 {
     display = gdk_x11_get_default_xdisplay();
+    if (!GDK_IS_X11_DISPLAY(display)) return;
+    Screen* scr = ScreenOfDisplay(display, 0);
+
     window = RootWindow(display, 0);
 }
 
 void x11_property_set(const char* key, const char* value)
 {
+    if (!GDK_IS_X11_DISPLAY(display)) return;
     g_debug("[x11-property] setting '%s' to '%s'", key, value);
 
     Atom atom = XInternAtom(display, key, False);
@@ -57,6 +61,7 @@ void x11_property_set(const char* key, c
 
 void x11_property_del(const char* key)
 {
+    if (!GDK_IS_X11_DISPLAY(display)) return;
     g_debug("[x11-property] deleting '%s'", key);
 
     Atom atom = XInternAtom(display, key, False);
@@ -65,6 +70,7 @@ void x11_property_del(const char* key)
 
 char* x11_property_get(const char* key)
 {
+    if (!GDK_IS_X11_DISPLAY(display)) return NULL;
     Atom property = XInternAtom(display, key, False);
     Atom actual_type;
     int actual_format;

Unfortunately, this is not enough 😞 . Under wayland the tray icon is not showing, so even if pasystray is not crashing, it is still not very useful yet.

[christophgysin]

I'm not sure GtkStatusIcon will ever be supported under wayland, see e.g.:
https://bugzilla.gnome.org/show_bug.cgi?id=758677

Try configuring pasystray with:

./configure --disable-statusicon --disable-appindicator --disable-x11

It should fall back to drawing a window instead of a system tray icon.

I'm happy to implement a system tray backend for wayland if you can point me to a working implementation.

[fsateler]

Hmm. Appindicator is supposed to work under wayland. But I see the debian package (where I tested this) does not have it enabled (see eg https://buildd.debian.org/status/fetch.php?pkg=pasystray&arch=arm64&ver=0.6.0-1&stamp=1468880631&raw=0) . I will try enabling that first, and will report back.

[fsateler]

AppIndicator does not work either. Interestingly, the HP systray applet based on Qt5 does work.

Building as @christophgysin suggested results in a window being opened... but that is not precisely a nice UI 😉

[fsateler]

BTW, smuxi appears to be able to use the gtk status icon. It uses the gtk 2 bindings to .net. Unfortunately the gtk 2 support is broken in pasystray: the glade file requires gtk3 so I can't check if the problem is in the gtk library.

[christophgysin]

pasystray ships with separate glade files for gtk2 and gtk3.

[smcv]

If pasystray relies on X11 (which it seems to), then it should probably force use of X11 rather than native Wayland by calling gdk_set_allowed_backends ("x11"); like gvim does:

vim/vim@f80663f

(gvim assumes that it can do X11 things with a GTK top-level window, so native Wayland would require a completely separate graphics backend.)

[WeaponMan]

Can confirm that adding gdk_set_allowed_backends ("x11"); with ./configure --prefix=/usr --with-gtk=3 works with waybar.

[999eagle]

At least for Arch I've created an AUR package called pasystray-wayland that builds and runs without problems on Wayland. I've tested it on sway with waybar.

[ahmadraniri1994]

@999eagle thanks for your aur package, gonna try it soon. 🙏

[BerkeleyTrue]

@999eagle this also solved my issues with Taffybar's SNI Tray. The regular package would not show up. Thanks!

[maaarghk]

@christophgysin - I've just installed @999eagle's aur package with the suggested --disable-x11 workaround. However, I have both X11 and Wayland installed so it's not very convenient - when I go back to X, the key grabbing no longer works.

Is there any chance the GDK_IS_X11_DISPLAY(display) guards mentioned above can be added? This would mean there is no need to use --disable-x11 to avoid crashing on Wayland whilst still enabling the same build to be used on X11.

I can do a PR for this if you want - just checking first if there's a reason you've not already done this.

[christophgysin]

@maaarghk I'm happy to merge a PR that adds wayland support without breaking any existing functionality. I haven't tested this in a while, but the above guards were not enough to make pasystray work correctly.

[smcv]

#156 looks like a plausible solution - even if it's not perfect, it seems like it's going in the right direction.

[maaarghk]

I've made #171 which at least fixes the crashes but does not contribute towards feature parity:

• PULSE_SERVER root xprop is used by pulse client-conf to choose a server, and can be configured with this tool. The fixes suggested so far just do nothing instead, but client-conf will fall back to an env variable of the same name. I only just installed a Wayland compositor for the first time today so I'm not sure if there's a reasonable way to achieve the same thing, or an alternative props subsystem that pulse should implement. I'll dig into the pulse source code at some point unless anyone already knows the answer.

• Media key binding just throws an error saying it doesn't work under Wayland (existing patches would silently fail). There is no equivalent functionality under Wayland and the philosophy is it's more secure to configure your WM to bind the keys to some cli function. But, do we have the option of e.g. binding to acpi button/volumeup or some dbus interface libinput instead?