Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Some apps freeze when switching between monitors #943

Open
eljamm opened this issue Sep 6, 2024 · 25 comments
Open

Some apps freeze when switching between monitors #943

eljamm opened this issue Sep 6, 2024 · 25 comments
Labels
anyone-else-seeing-this? bug Undesirable behavior help wanted Don't hesitate to participate!

Comments

@eljamm
Copy link

eljamm commented Sep 6, 2024

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

2024-09-06.11-23-26.mp4

System information:

Distribution: NixOS 24.11 (Vicuna)
GNOME Shell: 46.4
Display server: Xorg
PaperWM version: 46.17.0
Enabled extensions:
- [email protected]
- [email protected]

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.

@eljamm eljamm added the bug Undesirable behavior label Sep 6, 2024
@jtaala jtaala added the can't reproduce Issue doesn't happen on our end label Sep 7, 2024
@jtaala
Copy link
Collaborator

jtaala commented Sep 7, 2024

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
Copy link
Collaborator

jtaala commented Sep 7, 2024

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):

Screencast.from.2024-09-07.15-21-03.mp4

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
Copy link
Author

eljamm commented Sep 7, 2024

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
Copy link
Collaborator

jtaala commented Sep 7, 2024

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
Copy link
Author

eljamm commented Sep 7, 2024

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
Copy link
Author

eljamm commented Sep 7, 2024

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

2024-09-07.16-35-11.mp4

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:

2024-09-07.16-49-58.mp4

@jtaala
Copy link
Collaborator

jtaala commented Sep 8, 2024

@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
Copy link
Collaborator

jtaala commented Sep 8, 2024

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

@eljamm
Copy link
Author

eljamm commented Sep 8, 2024

@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:
- [email protected]

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
Copy link
Author

eljamm commented Sep 8, 2024

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

@jtaala
Copy link
Collaborator

jtaala commented Sep 8, 2024

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
Copy link
Collaborator

jtaala commented Sep 8, 2024

For reference, here's my info:

Distribution: EndeavourOS
GNOME Shell: 46.4
Display server: Wayland
PaperWM version: 46.17.1
Enabled extensions:
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]

@jtaala jtaala removed the can't reproduce Issue doesn't happen on our end label Sep 8, 2024
@eljamm
Copy link
Author

eljamm commented Sep 8, 2024

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:

Screenshot from 2024-09-08 14-11-58

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
Copy link
Author

eljamm commented Sep 8, 2024

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
Copy link
Collaborator

jtaala commented Sep 9, 2024

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
Copy link
Author

eljamm commented Sep 9, 2024

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

2024-09-09.16-18-24.mp4

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
Copy link
Author

eljamm commented Sep 9, 2024

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
Copy link
Collaborator

jtaala commented Sep 10, 2024

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
Copy link
Author

eljamm commented Sep 10, 2024

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
Copy link
Author

eljamm commented Sep 23, 2024

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
Copy link
Author

eljamm commented Sep 23, 2024

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
Copy link

I tried reaching out to Kitty's developer with no luck: kovidgoyal/kitty#7992 (comment)

@luisbc92
Copy link

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.

@KETHERCORTEX
Copy link

I've encountered this behaviour in KDE's Clock (org.kde.kclock). I worked around it by launching it in X11 mode (XWayland). Just restricted the access to Wayland in Flatpak settings and now the timer doesn't stop showing actual time left after switching to another monitor.

@kabessao
Copy link

kabessao commented Dec 26, 2024

I'm having the same problem. I'm ignoring it for now, but it's still pretty annoying. In my case it seems to only happen on some qt applications, like Chatterino and Kitty in my case (not sure if Kitty uses qt or not). Also, in my case they don't stop immediately, it take a couple of seconds for them to stop.

I've been dealing with this when I was using Nobara, but now I migrated to NixOS and I'm still getting the same behaviour.

Aditionally, in my case anyways, setting the window as "scratch" the window never freezes.

I'm on a Dual GPU laptop (Optimus prime I think the name is) with Intel and Nvidia.
When on Nobara I was on Gnome 45 and now on NixOS I'm on Gnome 47.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
anyone-else-seeing-this? bug Undesirable behavior help wanted Don't hesitate to participate!
Projects
None yet
Development

No branches or pull requests

5 participants