Arch Linux

$nake

Member

Registered: 2014-10-18

Posts: 30

[SOLVED] Display of some graphical applications freezing with Xmonad

My window manager is xmonad 0.15-21.

The display of some graphical applications (thunderbird 68.2.2-2 and vlc 3.0.8-6) tend to freeze. When the display change, either due to user interaction (e.g. clicking on an inbox mail in thunderbird) or to some functionality (change in the progress bar when a track is being played in vlc), the change is affected by variable delays ; sometimes none, sometimes several seconds, often forever (completely stuck until next refresh, see below).

Now, if the display of another window within the current xmonad's workspace is being changed, this refreshes also the problematic window (containing thunderbird or vlc) immediately. So for instance if I click on a mail in thunderbird and the display is stuck, I can modify the tiling of the workspace or change the focused window, and the mail is immediately displayed as it should. To explain further this phenomenon, if I set up a small floating window containing a terminal running

while true; do; echo refresh; sleep 0.04; done

on top of my workspace, then the delay is never more than 0.04 seconds and thus is no problem (but this constitutes a poor workaround!).

Other functionalities of these applications does not seem to be affected at all. Interestingly, both applications use Qt5 ; let me mention however that qutebrowser, also using Qt5, does not seem to be affected. (thunderbird not using Qt5)

Last edited by $nake (2019-11-20 18:05:25)

V1del

Forum Moderator

Registered: 2012-10-16

Posts: 21,660

Re: [SOLVED] Display of some graphical applications freezing with Xmonad

If you have xf86-video-intel installed try removing it. Also your inference of QT5 applications doesn't really hold as thunderbird does not use Qt5 but if anything GTK3 (but even that not "purely" so) You might want to post a journal log of the boot of when you notice the issue

$nake

Member

Registered: 2014-10-18

Posts: 30

Re: [SOLVED] Display of some graphical applications freezing with Xmonad

Removing xf86-video-intel (and modifying xorg.conf.d/ accordingly) solved the problem. Many thanks.
I really thought it was required for having any graphical server at all. Should I expect some drops in performance without it?

V1del

Forum Moderator

Registered: 2012-10-16

Posts: 21,660

Re: [SOLVED] Display of some graphical applications freezing with Xmonad

Not really noticeably so no, unless you rely on old 2D xorg screensavers and are bothered by their performance it's an old module for 2D acceleration in xorg that is largely unmaintained since a few years only receiving small bugfixes here and there. On any kind of more modern hardware it's often recommended to rely on xorg's built in modesetting driver, which does the 2D acceleration over 3D APIs. This might have slight perf implication in stuff that renders purely using xorgs 2D api, but the drawbacks seldom outweigh that benefit. You might see some occasional tearing, in which case you will want to set up some compositor like picom or so.

$nake

Member

Registered: 2014-10-18

Posts: 30

Re: [SOLVED] Display of some graphical applications freezing with Xmonad

Thank you for these precisions, I'll keep that in mind for the future.

Z2h-A6n

Member

Registered: 2014-08-06

Posts: 7

Re: [SOLVED] Display of some graphical applications freezing with Xmonad

If you have xf86-video-intel installed try removing it.

How did you know this was related to xf86-video-intel?

I was having a similar problem (XMonad would often, but not always, hang for several seconds when switching desktops using switchProjectPrompt from XMonad.Actions.DynamicProjects), and removing xf86-video-intel seems to have fixed the problem. I'm curious how I could have figured this out (other than finding useful forum posts).

Thanks.

V1del

Forum Moderator

Registered: 2012-10-16

Posts: 21,660

Re: [SOLVED] Display of some graphical applications freezing with Xmonad

Well for the reasons noted, I will generally recommend people off of xf86-video-intel when "weird" stuff like this happens, as it has been somewhat susceptible to this since - well - years (nothing of this is new, most mainstream distributions will not set it up for "modern" (2007ish) CPUs[1], intel themselves do not include it in their stack recipe anymore[2], KDE explicitly recommends off of it[3]...)  but in this particular instance it seems that the 5.3 kernel introduced a change in it's graphics subsystem that seems to have further pronounced to these kind of issues, of which I also just know of from being around the boards often.

Afaik this isn't visibly logged anywhere so you won't see a direct indicator on the system as such.

[1] https://tjaalton.wordpress.com/2016/07/ … iver-on-x/
[2] https://01.org/linuxgraphics/downloads/ … ack-recipe
[3] https://community.kde.org/Plasma/5.9_Errata