Some apps freeze when switching between monitors

[eljamm]

Describe the bug In a multi-monitor setup, some apps freeze when switching to another monitor.

To Reproduce Steps to reproduce the behavior:

1. Open affected app (kitty, calibre's ebook-viewer, ...)
2. Switch to another monitor
3. Apps on the previous monitor are frozen

Expected behavior The apps continue to work and render correctly after switching to another monitor.

Screenshots

https://github.com/user-attachments/assets/eece69cc-5e20-4d46-989b-83d556cbfb32

System information:

Distribution: NixOS 24.11 (Vicuna)
GNOME Shell: 46.4
Display server: Xorg
PaperWM version: 46.17.0
Enabled extensions:
- paperwm@paperwm.github.com
- user-theme@gnome-shell-extensions.gcampax.github.com

Additional context Right now, I'm only experiencing this with kitty terminal and calibre, but other apps might be affected.

Also, this happens both in X11 and Wayland.

[jtaala]

Thanks for reporting @eljamm.

I can't reproduce this with Calibre. Can you please tell me exactly how you're switching monitors? (i.e. are you just moving your mouse to another monitor, or using PaperWM's workspace switching keybinds?).

[jtaala]

Let me know if I'm doing anything different from you in the video below (p.s I have both calibre ebook-viewer and kitty on my right monitor, and am switching to the left monitor with my mouse multiple times):

https://github.com/user-attachments/assets/e6072440-449b-471e-8623-5bf904b7d2af

Not sure if you can see my mouse cursor, but I'm switching to the left monitor multiple times.

P.S. that terminal is kitty with htop running P.S.S. the ebooks are ones I downloaded for my daughter (for her kindle).

[eljamm]

Can you please tell me exactly how you're switching monitors? (i.e. are you just moving your mouse to another monitor, or using PaperWM's workspace switching keybinds?).

It seems that I can reproduce this with all workspace/monitor switching methods including the mouse and the switch-to-workspace-x, switch-monitor-{left,right}, switch-{up,down}-or-else-workspace keybinds.

Let me know if I'm doing anything different from you in the video below (p.s I have both calibre ebook-viewer and kitty on my right monitor, and am switching to the left monitor with my mouse multiple times):

No, that seems about right.

---

Running the debug script from the repo, I get the following PaperWM.log.

Switching to a workspace with no apps results in this message:

09:18:30: Window manager warning: META_CURRENT_TIME used to choose focus window; focus window may not be correct.
09:18:32: Window manager warning: META_CURRENT_TIME used to choose focus window; focus window may not be correct.
09:18:34: Window manager warning: META_CURRENT_TIME used to choose focus window; focus window may not be correct.

But if I open an app, that message doesn't show up anymore when I switch.

Aside from this, I also notice the following warnings:

09:18:05: Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0xa0000e
09:18:08: Window manager warning: Invalid WM_TRANSIENT_FOR window 0x1c0000a specified for 0x1c00008.

Is there anything more I can do to debug this further, perhaps?

---

Note: I found this issue in the kitty repo where another user was having the same problem using PaperWM.

Although it has been suggested that it was a Wayland issue, I'm experiencing this under X11 as well.

[jtaala]

Aside from this, I also notice the following warnings:

09:18:05: Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0xa0000e
09:18:08: Window manager warning: Invalid WM_TRANSIENT_FOR window 0x1c0000a specified for 0x1c00008.

Is there anything more I can do to debug this further, perhaps?

That last one looks interesting but nothing really stands out in those logs.

I've never seen this and can't reproduce with either calibre or kitty. I wonder if it's anything to do with a video card? What video card / driver are you using (e.g. nvidia / optimus etc.?). Just trying to think of other things since that might help in reproducing.

For calibre and kitty - how were they installed (just checking if anything like flatpak etc. was used).

I put a couple of tags up to see if anyone else is seeing this.

[eljamm]

What video card / driver are you using (e.g. nvidia / optimus etc.?).

I'm using a laptop with AMD and Nvidia (using PRIME) graphics:

$ lspci -nnk | grep -A2 -e VGA
pcilib: Error reading /sys/bus/pci/devices/0000:00:08.3/label: Operation not permitted
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GA106M [GeForce RTX 3060 Mobile / Max-Q] [10de:2560] (rev a1)
    Subsystem: Lenovo Device [17aa:3afe]
    Kernel driver in use: nouveau
--
34:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Rembrandt [Radeon 680M] [1002:1681] (rev c8)
    Subsystem: Lenovo Device [17aa:3afe]
    Kernel driver in use: amdgpu

I tried using:

• iGPU (Mesa 24.1.5) with the dGPU disabled
• iGPU + proprietary Nvidia driver (v560.35.03 with the open modules enabled)
• iGPU + nouveau

But the problem persists across all these cases.

I also tried rolling back my kernel from 6.10.6-xanmod to 6.6.47-xanmod because I though it could have been related to the 6.10 amdgpu regression, but that wasn't the case.

For calibre and kitty - how were they installed (just checking if anything like flatpak etc. was used).

I'm using NixOS, so I'm just installing these using Nix. Kitty is installed as a user package here and calibre as a system package here.

More information about my system

``` $ nix-info -m - system: `"x86_64-linux"` - host os: `Linux 6.6.47-xanmod1, NixOS, 24.11 (Vicuna), 24.11.20240830.84174e7` - multi-user?: `yes` - sandbox: `yes` - version: `nix-env (Lix, like Nix) 2.91.0 System type: x86_64-linux Additional system types: i686-linux, x86_64-v1-linux, x86_64-v2-linux, x86_64-v3-linux Features: gc, signed-caches System configuration file: /etc/nix/nix.conf User configuration files: /home/kuroko/.config/nix/nix.conf:/etc/xdg/nix/nix.conf:/home/kuroko/.nix-profile/etc/xdg/nix/nix.conf:/home/kuroko/.local/state/nix/profile/etc/xdg/nix/nix.conf:/home/kuroko/.local/state/nix/profile/etc/xdg/nix/nix.conf:/etc/profiles/per-user/kuroko/etc/xdg/nix/nix.conf:/nix/var/nix/profiles/default/etc/xdg/nix/nix.conf:/run/current-system/sw/etc/xdg/nix/nix.conf:/nix/store/9mjmw3mcvhicd3pajn0jh379xwx674hx-gnome-settings-daemon-46.0/etc/xdg/nix/nix.conf Store directory: /nix/store State directory: /nix/var/nix Data directory: /nix/store/apms7kqjgl9lxb1gqmhj4kxcbvlnfg4w-lix-2.91.0/share` - nixpkgs: `/nix/store/j70ghapac5gfvrqs6cwfppc83wl9kvnq-source` ```

I put a couple of tags up to see if anyone else is seeing this.

Thanks, I really appreciate any help. PaperWM has been amazing so far and this is the only issue I'm having with it.

[eljamm]

I kinda found a workaround which is to use the Always on Visible Workspace option:

https://github.com/user-attachments/assets/dcaf4728-ad9d-4b37-b69e-f7fe94b004dd

Having this option enabled, the affected apps seem to function normally when switching between monitors. However, this isn't perfect as it messes up the visibility between windows. The toggled window also appears in all workspaces in that monitor, which is expected since it's what the option does but it's a bit annoying.

Moreover, sometimes the window with this option stutters without being in fullscreen:

https://github.com/user-attachments/assets/36ebecde-1b94-406f-addb-a8e6eb88dac1

[jtaala]

@eljamm, are you able to create a new test user on your system, login to said user, install paperwm and test if you still reproduce this? A new user will be in a clean gnome env.

Just trying to rule out anything in your current setup / environment.

[jtaala]

Hey @Thesola10 - iirc, you're also a nixos user(?). Have you seen this type of issue before?

[eljamm]

@jtaala I tried with a new user, but that unfortunately doesn't work. However, that gave me the idea to try booting into a live ISO, which did work both for calibre and kitty.

Distribution: NixOS 24.05 (Uakari)
GNOME Shell: 46.2
Display server: Wayland
PaperWM version: 46.17.1
Enabled extensions:
- paperwm@paperwm.github.com

Since the ISO is running the stable NixOS release, its packages are a few versions behind my system which is on an unstable branch. The user who was having the same issue in the kitty issue above was also running Gnome 46.4 (albeit on EndeavourOS), so I'm suspecting that the issue appeared somewhere between 46.2 and 46.4.

I'll try downgrading my Mutter version and try again.

[eljamm]

I downgraded Gnome shell and mutter to 46.2 but the problem still happens on my main configuration, even with the new user.

[jtaala]

Interestingly, I can reproduce the hiding/non-rendering in calibre ebook-viewer but only in X11 - not in wayland.

Looking at the info from the live iso you posted - it looks to be running wayland. You mentioned also seeing in wayland, can you confirm that your session is actually wayland (in PaperWM settings, you can see if wayland in the info tab).

Re the hiding-page issue in calibre, I suspect that it might be something in mutter (or Calibre itself) for efficiency(?), e.g. if it's on another workspace then stop rendering (kind of like js/browser tabs deferring/sleeping processes when tab is not active).

This kind of makes sense in vanilla gnome, since you can't view two workspaces at once (i.e. Gnome has a "one workspace across all monitors" paradigm). PaperWM actually implements a "distinct workspace per monitor" paradigm, so you can actually see multiple workspaces at once (note, this does have it's own issues).

[jtaala]

For reference, here's my info:

Distribution: EndeavourOS
GNOME Shell: 46.4
Display server: Wayland
PaperWM version: 46.17.1
Enabled extensions:
- Vitals@CoreCoding.com
- caffeine@patapon.info
- advanced-alt-tab@G-dH.github.com
- extension-list@tu.berry
- launch-new-instance@gnome-shell-extensions.gcampax.github.com
- appindicatorsupport@rgcjonas.gmail.com
- gpu-switcher-supergfxctl@chikobara.github.io
- paperwm@paperwm.github.com

[eljamm]

Looking at the info from the live iso you posted - it looks to be running wayland. You mentioned also seeing in wayland, can you confirm that your session is actually wayland (in PaperWM settings, you can see if wayland in the info tab).

I actually can't open the info tab in Wayland:

But I can confirm that the issue happens inside a Wayland session:

14:10:14: Running GNOME Shell (using mutter 46.4) as a Wayland display server

Calibre's behavior is the same, but kitty takes a 3-4 seconds to freeze under Wayland whereas in X11 it just instantly freezes.

Also, I think the live ISO only runs in Wayland, so I think I'll have to create a custom ISO to make it run on X11.

[eljamm]

I made two custom ISO, one for NixOS stable (24.05) and the other following my system's unstable branch (24.11). They are configured exactly the same with only Gnome enabled and the apps necessary to reproduce the issue (kitty, calibre and htop).

Interestingly, I can reproduce the hiding/non-rendering in calibre ebook-viewer but only in X11 - not in wayland.

This is the result of my testing:

• Stable ISO: Same as when you reproduced this, the issue happens in X11, but not in Wayland.
• Unstable ISO: Doesn't work neither for X11 nor Wayland.

I actually can't open the info tab in Wayland:

Note: The info tab opened normally inside the custom ISO on Wayland, so it might just be something amiss with my system, but it's not that important.

[jtaala]

Note: The info tab opened normally inside the custom ISO on Wayland, so it might just be something amiss with my system, but it's not that important.

It might give us a clue as the error or issue though(?). Can you run the following (or the equivalent in nixos):

journalctl -f /bin/gjs

then open PaperWM preferences and open the info tab (and check the output and post any errors here)?

[eljamm]

Uh... looks like the menu is hidden for some reason and it always comes back after I unhide it:

https://github.com/user-attachments/assets/d2f84590-2363-4ff1-88a2-9352b78a274c

The log messages in the video are:

nixos .org.gnome.Shel[20155]: GtkImage 0x22847680 reported baselines of minimum -2147483648 and natural -2147483648, but sizes of minimum 16 and natural 16. Baselines must be inside the widget size.
nixos .org.gnome.Shel[20155]: AdwToolbarView 0x21eb4db0 exceeds AdwBreakpointBin height: requested 770 px, 700 px available

I don't think this is related to the focus issue, though.

In that regard, I'm currently bisecting the nixpkgs commit history between the stable and unstable branches in hope of determining the change that introduced this issue. That might take a bit of time, though.

git bisect log

``` git bisect start # status: waiting for both good and bad commits # bad: [93961c50306be724df8a69cfa60866c2c49d1d06] python312Packages.fastavro: 1.9.5 -> 1.9.7 (#339959) git bisect bad 93961c50306be724df8a69cfa60866c2c49d1d06 # status: waiting for good commit(s), bad commit known # good: [68e7dce0a6532e876980764167ad158174402c6f] [Backport release-24.05] firefox-{beta,devedition}{-bin}-unwrapped: 129.0b9 -> 131.0b2 (#340226) git bisect good 68e7dce0a6532e876980764167ad158174402c6f # good: [0b49ef697b3e5cff1e6f18033de2b422e2fe1f43] Merge pull request #313435 from r-ryantm/auto-update/qq git bisect good 0b49ef697b3e5cff1e6f18033de2b422e2fe1f43 # bad: [d9a71b5511a54ebdabdfec841b310c1102d83e30] Merge pull request #327335 from r-ryantm/auto-update/goperf git bisect bad d9a71b5511a54ebdabdfec841b310c1102d83e30 # bad: [bdf5483015c50776eee629a3123b93246c98aa35] Merge master into staging-next git bisect bad bdf5483015c50776eee629a3123b93246c98aa35 # bad: [e5f8367fc3e2be5d92433ce0e61c4f32daeb219d] Merge pull request #317790 from TomaSajt/keypunch git bisect bad e5f8367fc3e2be5d92433ce0e61c4f32daeb219d # bad: [3b964ec0da493742895d2e6cf4c8751292800663] Merge pull request #315916 from r-ryantm/auto-update/pistol git bisect bad 3b964ec0da493742895d2e6cf4c8751292800663 ```

[eljamm]

So I finished bisecting nixpkgs and I found out that updating kitty from v0.34.1 to v0.35.0 was the issue:

git bisect log

``` git bisect start # status: waiting for both good and bad commits # bad: [93961c50306be724df8a69cfa60866c2c49d1d06] python312Packages.fastavro: 1.9.5 -> 1.9.7 (#339959) git bisect bad 93961c50306be724df8a69cfa60866c2c49d1d06 # good: [68e7dce0a6532e876980764167ad158174402c6f] [Backport release-24.05] firefox-{beta,devedition}{-bin}-unwrapped: 129.0b9 -> 131.0b2 (#340226) git bisect good 68e7dce0a6532e876980764167ad158174402c6f # good: [0b49ef697b3e5cff1e6f18033de2b422e2fe1f43] Merge pull request #313435 from r-ryantm/auto-update/qq git bisect good 0b49ef697b3e5cff1e6f18033de2b422e2fe1f43 # bad: [d9a71b5511a54ebdabdfec841b310c1102d83e30] Merge pull request #327335 from r-ryantm/auto-update/goperf git bisect bad d9a71b5511a54ebdabdfec841b310c1102d83e30 # bad: [bdf5483015c50776eee629a3123b93246c98aa35] Merge master into staging-next git bisect bad bdf5483015c50776eee629a3123b93246c98aa35 # bad: [e5f8367fc3e2be5d92433ce0e61c4f32daeb219d] Merge pull request #317790 from TomaSajt/keypunch git bisect bad e5f8367fc3e2be5d92433ce0e61c4f32daeb219d # bad: [3b964ec0da493742895d2e6cf4c8751292800663] Merge pull request #315916 from r-ryantm/auto-update/pistol git bisect bad 3b964ec0da493742895d2e6cf4c8751292800663 # good: [70ae8e70d91a5ec784f1971efafbb56569f104b2] Merge pull request #314180 from r-ryantm/auto-update/btrfs-assistant git bisect good 70ae8e70d91a5ec784f1971efafbb56569f104b2 # good: [ceb167eb0271c16d57f8b8ee0e27c0251407d16b] Merge pull request #315153 from r-ryantm/auto-update/python311Packages.pytest-testinfra git bisect good ceb167eb0271c16d57f8b8ee0e27c0251407d16b # bad: [41c24ed4c576a41463912a7a4571ce5ba2e9e02e] Merge pull request #315600 from r-ryantm/auto-update/python311Packages.viv-utils git bisect bad 41c24ed4c576a41463912a7a4571ce5ba2e9e02e # good: [618e7f1f75d21b005936bcbfbc1ed1a03154666e] Merge pull request #315259 from r-ryantm/auto-update/whitesur-icon-theme git bisect good 618e7f1f75d21b005936bcbfbc1ed1a03154666e # bad: [122d08d6ad613deacdcc19da4486cd32e444e990] Merge pull request #315382 from r-ryantm/auto-update/protonmail-desktop git bisect bad 122d08d6ad613deacdcc19da4486cd32e444e990 # bad: [8522cc020eae7c446e9136b01049df70f138713c] Merge pull request #315522 from wegank/p3x-onenote-hash git bisect bad 8522cc020eae7c446e9136b01049df70f138713c # bad: [47633b1ed01fb130d79a8b6779ee96faca762f01] Merge pull request #314861 from r-ryantm/auto-update/plantuml-server git bisect bad 47633b1ed01fb130d79a8b6779ee96faca762f01 # bad: [33ce263359c13fb2282a954001c6285d3e3ed42c] Merge pull request #315117 from OPNA2608/fix/lomiri-24.05-buildable git bisect bad 33ce263359c13fb2282a954001c6285d3e3ed42c # good: [5d7aecb102d3200f62b3423e92136e542d1f0fa6] Merge pull request #315105 from r-ryantm/auto-update/lefthook git bisect good 5d7aecb102d3200f62b3423e92136e542d1f0fa6 # bad: [361afb9f34ecec1fea164bbfe8b097342f448922] Merge pull request #315016 from r-ryantm/auto-update/ols git bisect bad 361afb9f34ecec1fea164bbfe8b097342f448922 # bad: [7ae08b8c6e2e7fc9f6f6ea1e1fe2f27f728c3c21] Merge pull request #315080 from natsukagami/kitty-035 git bisect bad 7ae08b8c6e2e7fc9f6f6ea1e1fe2f27f728c3c21 # bad: [c6c63924a4b6dda0d6137e417c1524ecdb0bb354] kitty: 0.34.1 -> 0.35.0 git bisect bad c6c63924a4b6dda0d6137e417c1524ecdb0bb354 # first bad commit: [c6c63924a4b6dda0d6137e417c1524ecdb0bb354] kitty: 0.34.1 -> 0.35.0 ```

Reading the changelog, I assume the culprit here is:

Wayland: save energy by not rendering “suspended” windows on compositors that support that

This works fine when PaperWM is disabled since windows on both monitors are on the same workspace so they're not suspended as you previously explained. Unfortunately, even after rolling back kitty to 0.34.1, it still didn't work in my system under Wayland, so this might go deeper than that 😓

As such, I don't think this issue can be fixed by PaperWM directly unless there is a way to disable window-suspending at runtime. For the meantime, I'll just use another terminal on my second monitor and use the workaround for calibre.

That said, I'm still quite confused why X11 is having this issue as well ...

[jtaala]

directly unless there is a way to disable window-suspending at runtime.

I was looking into this one, appears to be this property: https://docs.gtk.org/gtk4/method.Window.is_suspended.html

A window being suspended means it’s currently not visible to the user, for example by being on a inactive workspace, minimized, obstructed.

Yes, It's essentially an assumption that doesn't quite work on PaperWM (since we implement one-workspace-per monitor).

It's gtk though, and couldn't (as yet) find a js binding (i.e. to override / monkey-patch) this one.

[eljamm]

Thank you so much for your support and patience thus far. I'm quite happy with the improvement in workflow that PaperWM brings me that I don't mind working around the issue if it's happening with just 2 programs.

It's gtk though, and couldn't (as yet) find a js binding (i.e. to override / monkey-patch) this one.

Feel free to close this issue if you think it can't be done or if it might be too difficult to implement.

[eljamm]

A small update on this. I was able to fix the issue for Calibre on Wayland by using the QT_QPA_PLATFORM env variable. Before, I was forcing QT apps to run in XWayland with the variable set to xcb (to work around some other issue), but setting it to wayland totally solves the problem.

PS: the issue still persists with kitty.

[eljamm]

Another update. I don't know why kitty 0.34.1 didn't work last time, but I tried it again today and it did work, confirming that the suspend feature introduced in 0.35.0 was indeed the cause of the issue. That said, I can still reproduce it for this version under X11/XWayland.

[luisbc92]

I tried reaching out to Kitty's developer with no luck: https://github.com/kovidgoyal/kitty/issues/7992#issuecomment-2430751167

[luisbc92]

I ended up patching kitty and building from source to disable the suspend feature.

Here's the patch file for anyone interested:

diff --color -ura kitty-0.36.4.orig/glfw/wl_window.c kitty-0.36.4.new/glfw/wl_window.c
--- kitty-0.36.4.orig/glfw/wl_window.c  2024-10-25 21:59:27.151623497 -0700
+++ kitty-0.36.4.new/glfw/wl_window.c   2024-10-25 22:00:40.721019426 -0700
@@ -1673,9 +1673,6 @@

 int _glfwPlatformWindowOccluded(_GLFWwindow* window UNUSED)
 {
-#ifdef XDG_TOPLEVEL_STATE_SUSPENDED_SINCE_VERSION
-    return (window->wl.current.toplevel_states & TOPLEVEL_STATE_SUSPENDED) != 0;
-#endif
     return false;
 }

I don't expect it to break anytime soon since so little code was changed.