How to enable scrollback even when a workspace loses focus

[brianredbeard]

My apologies if this isn't the correct forum. I spent quite a while searching through issues & the Kitty website but wasn't able to find the appropriate configuration option or command sequence. Additionally, I wasn't able to identify the correct forum for "support" (e.g. IRC, a mailing list, Slack/Discord channel, discussion forum, etc).

I am trying to figure how how to enable scrollback on a tab/window, even when it has lost focus and the mouse has moved to a different workspace (on Linux that is). Either enabling this globally or for a single tab/window is sufficient.

In my setup I have 3 monitors running Gnome3/X11. What is happening is an instance of Kitty is running in "Workspace 1" with a constantly scrolling application (imagine tail -f). When I move the mouse/cursor to "Workspace 2" (running on a different monitor) all activity from Kitty stops. I appreciate the savings that this provides on system resources, but when interacting with a number of remote systems concurrently (e.g. watching scroll back from 10 hosts in a cluster for an event to occur) it defeats the purpose of having multiple workspaces.

I have (seemingly) confirmed that this is not (at least directly) an issue with the window manager or desktop environment by running gnome-terminal with the following for loop on a workspace and then moving to another workspace:

for x in `seq 1 100`; do
  echo ${x}
  sleep 1
done

In this situation the cursor in gnome-terminal correctly transitions to an outlined cursor (denoting a loss of focus) but still continues displaying scrollback within the window.

[kovidgoyal]

That's not expected behavior. kitty windows process input from child processes even when backgrounded. On some platforms (Cocoa, Wayland) kitty windows request what's called a render frame from the compositor and only draw when such a frame is received. On Wayland compositors use this mechanism to throttle rendering, saving resources for hidden windows.

What version of kitty are you on and what display backend? X11/Wayland? Can you replicate the issue with kitty --config NONE and the current version 0.19.1

[kovidgoyal]

no followup

[mawkler]

I'm having this exact issue. When switching to another window on the same workspace Kitty keeps updating, but if I switch to a workspace on another screen Kitty stops updating after ~4 seconds.

Alacritty, Terminator and Console don't have this issue.

I'm on EndeavourOS on GNOME Shell 46.4 and I'm using the PaperWM GNOME extension to manage windows. The issue doesn't appear if I disable PaperWM.

[kovidgoyal]

then alacritty, terminator and console presumably arent respecting render frames, you can have kitty do the same by setting sync_to_monitor no in kitty.conf.

[mawkler]

I tried setting sync_to_monitor no but I'm still seeing the same behaviour

[kovidgoyal]

Run with --debug-rendering

[mawkler]

Here's the output of kitty --debug-rendering:

Click to expand

``` ❯ kitty --debug-rendering [0,072] Compositor missing capabilities: layer_shell [0,107] Creating window 1 at size: 930x1368 and scale 1 [0,133] GL version string: '4.6 (Core Profile) Mesa 24.1.5-arch1.1' Detected version: 4.6 [0,143] Fractional scale requested: 120/120 = 1,00 for window 1 [0,143] Resizing framebuffer of window: 1 to: 930x1368 window size: 930x1368 at scale: 1,000 [0,143] Waiting for swap to commit Wayland surface for window: 1 [0,143] Preferred integer buffer scale changed to: 1 for window 1 [0,143] Compositor set top-level bounds of: 2560x1408 for window 1 [0,143] Compositor top-level capabilities: maximize=1 minimize=1 window_menu=1 fullscreen=1 [0,143] XDG top-level configure event for window 1: size: 0x0 states: [0,143] XDG surface configure event received and acknowledged for window 1 [0,143] Waiting for swap to commit Wayland surface for window: 1 [0,143] Final window 1 content size: 930x1368 resized: 0 [0,143] Setting window 1 "visible area" geometry in configure event: x=0 y=0 930x1368 viewport: 930x1368 [0,178] OS Window created [0.197] Child launched [0,198] Window 1 swapped committing surface [0,232] Calling wl_pointer_set_cursor in setCursorImage with surface: 0x5ac4397d53d0 and serial: 0 [0,233] Compositor set top-level bounds of: 2560x1408 for window 1 [0,233] XDG top-level configure event for window 1: size: 930x1368 states: TOPLEVEL_STATE_ACTIVATED [0,233] XDG surface configure event received and acknowledged for window 1 [0,233] Final window 1 content size: 930x1368 resized: 0 [0,233] Setting window 1 "visible area" geometry in configure event: x=0 y=0 930x1368 viewport: 930x1368 [0,500] Calling wl_pointer_set_cursor in setCursorImage with surface: 0x5ac4397d53d0 and serial: 30075 [0,550] Calling wl_pointer_set_cursor in setCursorImage with surface: 0x5ac4397d53d0 and serial: 30075 [3,507] Calling wl_pointer_set_cursor in _glfwPlatformSetCursor with surface: (nil) and serial: 30075 [19,575] Compositor set top-level bounds of: 2560x1408 for window 1 [19,575] XDG top-level configure event for window 1: size: 930x1368 states: TOPLEVEL_STATE_ACTIVATED TOPLEVEL_STATE_SUSPENDED [19,575] XDG surface configure event received and acknowledged for window 1 [19,576] Final window 1 content size: 930x1368 resized: 0 [19,576] Setting window 1 "visible area" geometry in configure event: x=0 y=0 930x1368 viewport: 930x1368 [19,576] OSWindow 1 occlusion state changed, occluded: 1 [22,869] Calling wl_pointer_set_cursor in setCursorImage with surface: 0x5ac4397d53d0 and serial: 30110 [22,878] Compositor set top-level bounds of: 2560x1408 for window 1 [22,878] XDG top-level configure event for window 1: size: 930x1368 states: TOPLEVEL_STATE_ACTIVATED [22,878] XDG surface configure event received and acknowledged for window 1 [22,878] Calling wl_pointer_set_cursor in setCursorImage with surface: 0x5ac4397d53d0 and serial: 30110 [22,878] Final window 1 content size: 930x1368 resized: 0 [22,878] Setting window 1 "visible area" geometry in configure event: x=0 y=0 930x1368 viewport: 930x1368 [22,878] OSWindow 1 occlusion state changed, occluded: 0 [22,928] Calling wl_pointer_set_cursor in setCursorImage with surface: 0x5ac4397d53d0 and serial: 30110 [24,239] Calling wl_pointer_set_cursor in setCursorImage with surface: 0x5ac4397d53d0 and serial: 30120 [24,289] Calling wl_pointer_set_cursor in setCursorImage with surface: 0x5ac4397d53d0 and serial: 30120 [27,240] Calling wl_pointer_set_cursor in _glfwPlatformSetCursor with surface: (nil) and serial: 30120 ```

[kovidgoyal]

I mean run it until it reproduces your issue and post the resulting log

[mawkler]

@kovidgoyal I did. In the new window I ran

for x in `seq 1 100`; do
  echo ${x}
  sleep 1
done

and then switched to another monitor. And after ~4 seconds the new Kitty window stopped updating

[kovidgoyal]

Your problem is the compositor is reporting the window as occluded, see

[19,576] OSWindow 1 occlusion state changed, occluded: 1

This corresponds to the wayland window suspended event (TOPLEVEL_STATE_SUSPENDED) which means the application needs to stop rendering the window. This is a bug in GNOME, most likely already fixed, update gnome and you should be fine, if not report it there.

[eljamm]

I'm experiencing this both on X11 and Wayland with PaperWM enabled. Could the issue be tied to how PaperWM is handling workspace focus or could it still be a GNOME bug?

For more debug information, you can see my comment in the linked issue.

Note: There doesn't seem to be anything useful from debug-rendering when reproducing this under X11:

$ kitty --debug-rendering
[0.229] GL version string: '4.6 (Core Profile) Mesa 24.1.5' Detected version: 4.6
[0.279] OS Window created
[0.300] Child launched
[0.336] Got notification server capabilities: frozenset({'body', 'actions', 'persistence', 'body-markup', 'sound', 'icon-static'})
[2.765] SIGWINCH sent to child in window: 1 with size: (46, 187, 1870, 1012)

[kovidgoyal]

If you are experiencing it on X11 it cant be this. This is wayland specific and indeed specific to compositors in wayland such as older versions of gnome that had buggy implemnetations of the iwndow occlusion wayland protocol.

[eljamm]

Bisecting my system, I was able to pin the issue to the update from from 0.34.1 to 0.35.0. specifically, I think this feature is the culprit:

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

This works great with normal Gnome since windows on the second monitor are considered on the same workspace and are only suspended when switching to another workspace. However, this doesn't work well with PaperWM since it uses one workspace per monitor, so switching monitors suspends the windows.

Would it be possible to make this feature configurable?

PS: The issue is still reproducible with PaperWM and kitty 0.34.1 using X11/XWayland, but it's probably unrelated to this, as you said.

[kovidgoyal]

kitty is following the wayland spec here, papaerwm is not. The point of this wayland protocol is that the compositor tells the application the window is occluded and the applicationt hen saves energy by not rendering it. If paperwm is incorrectly telling the application that a window is occluded when it shouldnt that needs to be fixed there. So either this should be fixed in paperwm or it needs an option to not do this.

[eljamm]

Well, Gnome is the one wrongly suspending the windows. PaperWM is already fighting tooth and nail to change how Gnome normally operates and separate-workspace per monitor is part of its design. That said, the developers have been notified, but I'm unsure if it's even possible to fix this from their side or how much time/effort it would take.

I'm okay with running an older version of kitty at the moment, although I wouldn't really consider that an optimal solution. I would much prefer if it worked on X11, so I'll have to see if I can figure that issue out later.

In all cases, thanks a lot for the amazing work you're doing. Kitty is hands down one of the best terminal emulators that I've tried.

[kovidgoyal]

I dont have an opinion on what is correct behavior or not in the compositor. The Wayland protocol says that wayland clients should suspend rendering when compositors tell them too. kitty is following that protocol.