Freezing external programs

[carlhenrikek]

Certain programs when opened in EXWM seems to freeze as when they are left out of focus for too long. Spotify, m$ Teams, Zoom etc. Its only the GUI that freezes leaving a completely black screen but it is still possible to interact with them (spotify through helm-spotify for example). When active C-k is not able to kill the buffer but it is possible by marking it in list-processes. I had this problem both when running EXWM on Debian and Manjaroo. I'm not really sure how to address but it happens very regularly.

[ch11ng]

What does 'left out of focus for too long' mean and is there a reliable way to reproduce this problem? Also what happened after a buffer/workspace switch?

[carlhenrikek]

Thank you for the reply. With "out of focus" I mean the program not being one of the visible buffers in the current workspace.

Lets say I open Spotify using S-& (same thing happens if open in xterm or vterm) on workspace 0 and then swap to workspace 1 and then back to 0 again. Now the spotify buffer will be all black and there is no way of interacting with the program through the UI. Same thing happens if I stay in workspace 0 but swap buffer so that Spotify is "out of focus" i.e. not the active buffer and then swap back to Spotify. It happens with every program I start except Firefox for some reason. Mind I do not use too many other programs but it happens reliably with Teams, Spotify etc. There seem to be a correlation with how long the program have been "out of focus" if just briefly its less likely that the program goes unresponsive.

[fagg]

I am also experiencing this with EXWM on Arch. Like @carlhenrikek I don't use too many external programs, but I have noticed this happen with Spotify, Discord and Signal Desktop. Chromium doesn't seem to exhibit this behavior.

@ch11ng Let me know what is useful to you in terms of debugging info and I'll try capture it next time it happens.

[fagg]

@carlhenrikek @ch11ng I think I know what the problem may be.

I did some Googling, and it seems that there are certain apps (in particular, those built with Electron - like most of the apps we've listed above) that have problems with other WMs when they aren't launched in a dbus-session. One going theory is that when put it into the background, they try to talk to dbus to determine if there's a notification daemon running so they can ping you with notifications. Conveniently, if they can't do this instead of just giving up or erroring out they decide to hang - quality software at its finest.

In my unscientific testing, I did the following and it seems to work much better now (I haven't experienced this in the last 10 mins of flipping back and forth between apps - this would normally happen pretty quickly).

1. Install and make sure a notification daemon is running. I'm using dunst. I had this installed prior to switching to EXWM, but it wasn't started in my ~/.xinitrc.

2. Instead of exec emacs in your ~/.xinitrc. Try this: exec dbus-launch --exit-with-session emacs. This makes sure all the dbus pipes are connected.

I would prefer not to use dbus, and previously with dwm this worked fine with just an exec dwm. I don't know why this is different. Nonetheless, give that a try. It seems to be working much better for me now. I've got Spotify, Signal and Discord all running now, and have done so for the last 30 mins or so - no hang.

[carlhenrikek]

@fagg thank you so much for this. I've been running faultlessly for about 1h now. This is really bad software practice to assume that a notification deamon is running. Thanks a lot for this, I've had to resort to another WM when running other programs where critical.

[fagg]

Carl Henrik Ek notifications@github.com writes:

@fagg thank you so much for this. I've been running faultlessly for about 1h now. This is really bad software practice to assume that a notification deamon is running. Thanks a lot for this, I've had to resort to another WM when running other programs where critical.

Glad it helped.

Btw, if you encounter other issues with things randomly freezing now that you've added that option to ~/.xinitrc, you might wish to change it to:

exec dbus-launch exwm

On some implementations the dbus-launch argument I originally posted about seems to cause other issues. I noticed a while after I did this originally that my backlight keys would cause X to completely hang. Googling around suggested omitting the extra argument and just calling exwm with dbus-launch. That seems to have fixed that problem, and the issue with Electron apps also seems fine.

(again, you might not encounter this - it seems specific to some distros based on what I read)

People on other WMs also reported that issue, but the original one we were discussing seems that info is more scarce as it doesn't appear to be consistent even amongst user of the same WM...

I'm not sure what software is more worthy of a roasting here (Electron or dbus), but I will say this definitely isn't exwm's problem...

[carlhenrikek]

@fagg so I might have got excited slightly too quickly about this. The behavior has changed. Spotify still ends up with a black unresponsive screen but the difference now is that I can kill it using C-x k which wasn't possible before. It is clearly a distro issue as I tried this on a debian install and it worked without issues. I did alter the exec command but the same thing seems to happen.

[fagg]

Carl Henrik Ek notifications@github.com writes:

@fagg so I might have got excited slightly too quickly about this. The behavior has changed. Spotify still ends up with a black unresponsive screen but the difference now is that I can kill it using C-x k which wasn't possible before. It is clearly a distro issue as I tried this on a debian install and it worked without issues. I did alter the exec command but the same thing seems to happen.

Hmm, that's annoying. I have no insight into that unfortunately. It certainly could be a distro problem.

The only thing I can suggest is maybe try some difference dbus-launch arguments. Based on the reading I did related to the original issue, some distros ship versions of dbus that are buggy or otherwise broken or configured differently - and different options may help.

All I can say is that when I changed to using the arguments I suggested (and later, just exec dbus-launch emacs), on Arch Linux at least everything worked as it should.

[carlhenrikek]

I think I've managed to finally fix this behavior and is indeed an issue with dbus. By installing dbus-broker and then starting emacs without dbus-launch. The issue is now gone.