I'm going to use Spotify as an example here, because it's the only application I can *always* reproduce this with. It sometimes happens with LibreOffice applications, but haven't figured the pattern, yet. Reproducible: Always Steps to Reproduce: 1. Make sure compositor is enabled and working. 2. Start Spotify. Actual Results: Right after starting Spotify compositor is getting suspended. When I stop the application compositor resumes by itself. However, I'm able to resume it with my "Suspend compositing" shortcut and it works. Expected Results: Compositor shouldn't suspend when specific applications are being started, when the option "Suspend compositor for full screen windows" is disabled or the application is not on full screen. I've annotated the attached log of `kwin_x11 --replace` with when Spotify was started and stopped using lines starting with `###`.
Created attachment 97294 [details] KWin output when Spotify is being started and stopped
Forgot the mention that I can always reproduce this regardless of the "OpenGL interface" (i.e. EGL or GLX). The attached log is with EGL, though.
can you please provide the xprop output when clicking the spotify window?
Created attachment 97295 [details] xprop output when clicking the spotify window Sure. However this is the output *after* the compositor is already suspended, because it happens before the actual appearance of Spotify's window.
I knew that Spotify is using Chromium now, but I've ruled out Chromium to be responsible for this, because suspend doesn't happen when I start Chromium, Chrome or some Chrome app (like SlackDeck for example). However, I've just learned that Spotify is NOT a Chromium app, but uses Chromium Embedded Framework[1]. According to what I've been able to find the Steam client for Linux is also using CEF. Starting Steam involves updating (if not already up-to-date), logging in (if not already), before showing the actual client. The first two windows cause exactly the same issue: 1. Start Steam for the first time since weeks (i.e. it's not up-to-date) 2. Starts updating, showing a small window it a progress bar. 3. Composite goes to suspend. 4. I resume it with a shortcut. 5. Update is complete and login window is being showed. 6. Composite goes to suspend. 7. I resume it with a shortcut. 8. Successful login leads to opening the actual client window, *without* suspending the compositor. Once updated, if I simply start it (i.e. already logged in and up-to-date) it goes directly to step 8 and everything is fine. However if I log out, stop the client and try starting it again (i.e. still up-to-date, so steps 2, 3, 4 are omitted), the compositor gets suspended because of the login window. I will attach the output from xprop when clicking on the Steam's login window. Could it be that something in CEF is causing this? [1] https://en.wikipedia.org/wiki/Chromium_Embedded_Framework
Created attachment 97296 [details] xprop output when clicking the Steam's login window
What's your frameworks version?
5.19.0
To rule out the obvious: you do not have any rules to block compositing which might (accidentally) apply here? (please attach ~/.config/kwinrulesrc in doubt)
Created attachment 97297 [details] ~/.config/kwinrulesrc No, but I use rules for sending particular windows to exact desktops and Spotify is one of them. What I've tried is to force-fully disable blocking composition for Spotify. (i.e. blockcompositing=false and blockcompositingrule=2), but it doesn't seem to change anything. I assume it doesn't help, because this option applies too late, since compositor is getting suspended before the actual appearance of the window and compositor is already suspended.
It's probably this rule: Description=Football Manager 2016 blockcompositing=true blockcompositingrule=2 clientmachine=localhost clientmachinematch=0 wmclass= wmclasscomplete=false wmclassmatch=1 Notice that "wmclass" is empty. (This also means that spotify resp. CEF illegally change the class after mapping the window ... *sigh*) => try to disable that rule and see what happens.
Thomas, you're right. I'm manually blocking the compositor and then complaining why it blocked. http://i.lvme.me/sgl679d.jpg
It's not exactly your fault either. a) Does that "Football Manager 2016" client never sport (pun intended) a WM_CLASS hint, or did you set it empty manually (because it also adds WM_CLASS late)? b) The pretty much means CEF is setting WM_CLASS after the map request, what's rather an icccm violation Strictly spoken though, it must be set as long as the window is withdrawn, maybe they keep it that state until it gets actually mapped (while that's not helpful ;-) => We might have to sync after mapping the window and before applying the rules? Can you try a patch (for kwin) - doesn't make sense to relax things here if the client sets WM_CLASS some seconds later.
> a) Does that "Football Manager 2016" client never sport (pun intended) > a WM_CLASS hint, or did you set it empty manually (because it also > adds WM_CLASS late)? It doesn't detect it. Even now when I try to create a new rule for it, I get these lines via the "Detect window properties" button: wmclass= wmclasscomplete=false wmclassmatch=1 > b) The pretty much means CEF is setting WM_CLASS after the map > request, what's rather an icccm violation > > Strictly spoken though, it must be set as long as the window is > withdrawn, maybe they keep it that state until it gets actually mapped > (while that's not helpful ;-) > > => We might have to sync after mapping the window and before applying > the rules? Can you try a patch (for kwin) - doesn't make sense to > relax things here if the client sets WM_CLASS some seconds later. I'm currently running a KWin from an offical Arch Linux package, but I could try applying a patch and compiling kwin, as long as I can apply it on top of the 5.5.4 tag.
The detection will be fine. The client simply does not set a WM_CLASS hint, so it's kinda "indetectable" :-( This patch may hunk but should apply to 5.4 (otherwise please ask back) If CEF is *not* violating the spec, your hyperactive rule should not apply to spotify anymore. But if it's this https://aur.archlinux.org/packages/spotify/ , I could just test it myself (the CEF thingy is somehow statically linked? I don't see relevant deps) ----- diff --git a/manage.cpp b/manage.cpp index 4198e60..41636be 100644 --- a/manage.cpp +++ b/manage.cpp @@ -627,6 +627,10 @@ bool Client::manage(xcb_window_t w, bool isMapped) } else updateVisibility(); assert(mapping_state != Withdrawn); + + xcb_connection_t *c = connection(); + free(xcb_get_input_focus_reply(c, xcb_get_input_focus(c), nullptr)); + m_managed = true; blockGeometryUpdates(false);
Okay, I will be able to try this tomorrow and report if the issue is fixed. > But if it's this https://aur.archlinux.org/packages/spotify/ , I could just test it myself (the CEF thingy is somehow statically linked? I don't see relevant deps) Yes, this is the package that I'm using. If it's packaging issue, I will contact the package owner with a fix.
No packaging issue - I installed spotify and can confirm that rules don't apply. Testing now whether an explicit sync between map and ruling helps. If not, it's a CEF bug.
"nope" - WM_CLASS remains empty despite map & sync. => Spotify/CEF bug (icccm violation)