Kitty: Linux: Kitty freezes when reloading i3 config while window is hidden in tabbed mode and compton is running

[Gordin]

Kitty seems to be frozen sometimes after I switch back to a workspace. I started using kitty just a couple of days ago, so I've only tried version 0.14.1 and latest git master so far, both have this bug. This is how it looks like When I switch to a workspace with frozen kitty terminals from Firefox (The Graphics in the terminal just carry over from whatever was in the previous workspace).

This happens with and without running a compositor (compton). I can't consistently reproduce this, it feels very random. I left my laptop on overnight, but nothing was frozen afterwards. Also is seems to only freeze windows on a particular workspace. Right now I have 2 frozen kitty instances on workspace 2, and a hand full of not-frozen ones on other workspaces.
One of the frozen instances had a vim running and the process is still there, kitty just does not update any more and does not seem to process keypresses. I looked at the other kitty freeze issues with mesa 19, but stuff like this #1515 is supposed to be fixed in 0.14.1, isn't it?

I'm running an updated archlinux with i3 on Xorg with xf86-video-intel on 1:2.99.917 and mesa 19.0.5-1.

I tried to get a log with --debug-keyboard and --debug-gl but the only output that isn't just keypresses is the GL version string at the start

head kitty-log

GL version string: '4.5 (Core Profile) Mesa 19.0.5' Detected version: 4.5
Press scancode: 0x85 clean_sym: Super_L composed_sym: Super_L mods: none glfw_key: 343 (LEFT SUPER) xkb_key: 65515 (Super_L)
on_key_input: glfw key: 343 native_code: 0xffeb action: PRESS mods: 0x0 text: '' state: 0 sent key to child
on_key_input: glfw key: 343 native_code: 0xffeb action: RELEASE mods: 0x0 text: '' state: 0 ignoring as keyboard mode does not allow release events
Release scancode: 0x85 clean_sym: Super_L mods: super glfw_key: 343 (LEFT SUPER) xkb_key: 65515 (Super_L)
Press scancode: 0x21 clean_sym: l composed_sym: l text: l mods: none glfw_key: 76 (L) xkb_key: 108 (l)
on_key_input: glfw key: 76 native_code: 0x6c action: PRESS mods: 0x0 text: 'l' state: 0 sent text to child
Release scancode: 0x21 clean_sym: l mods: none glfw_key: 76 (L) xkb_key: 108 (l)
on_key_input: glfw key: 76 native_code: 0x6c action: RELEASE mods: 0x0 text: '' state: 0 ignoring as keyboard mode does not allow release events
Press scancode: 0x24 clean_sym: Return composed_sym: Return mods: none glfw_key: 257 (ENTER) xkb_key: 65293 (Return)

tail kitty-log

Release scancode: 0x36 clean_sym: j mods: none glfw_key: 74 (J) xkb_key: 106 (j)
on_key_input: glfw key: 74 native_code: 0x6a action: RELEASE mods: 0x0 text: '' state: 0 ignoring as keyboard mode does not allow release events
Press scancode: 0x26 clean_sym: a composed_sym: a text: a mods: none glfw_key: 65 (A) xkb_key: 97 (a)
on_key_input: glfw key: 65 native_code: 0x61 action: PRESS mods: 0x0 text: 'a' state: 0 sent text to child
Release scancode: 0x26 clean_sym: a mods: none glfw_key: 65 (A) xkb_key: 97 (a)
on_key_input: glfw key: 65 native_code: 0x61 action: RELEASE mods: 0x0 text: '' state: 0 ignoring as keyboard mode does not allow release events
Press scancode: 0x16 clean_sym: BackSpace composed_sym: BackSpace mods: none glfw_key: 259 (BACKSPACE) xkb_key: 65288 (BackSpace)
on_key_input: glfw key: 259 native_code: 0xff08 action: PRESS mods: 0x0 text: '' state: 0 sent key to child
Release scancode: 0x16 clean_sym: BackSpace mods: none glfw_key: 259 (BACKSPACE) xkb_key: 65288 (BackSpace)
on_key_inpu

This is my kitty config: kitty.conf

[kovidgoyal]

weird, does the freeze mean you cant do anything, or does it fix itself after some key presses/mouse motion etc? Your system is basically identical to mine, and I have never seen this, with the exception of using xf86-video-intel. Try un-installing that and just use the modesetting driver.

[Gordin]

After the freeze I can't do anything with that window any more, I tried click, keys, moving, resizing, fullscreen, etc. nothing unfreezes it. It also doesn't even listen to SIGTERM any more.

I'll try with modesetting driver

[kovidgoyal]

You can also try strace -f to see what it is doing when it freezes, my
guess would be something in the driver.

[Gordin]

Hm, I guess I'll have to run strace on a couple instances and let them running then I guess. When I strace the frozen instance it only outputs this

strace: Process 31778 attached with 3 threads
[pid 31781] restart_syscall(<... resuming interrupted restart_syscall ...> <unfinished ...>
[pid 31779] futex(0x5602e037ea08, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
[pid 31778] restart_syscall(<... resuming interrupted poll ...>

And this when I click or press anything (outside and inside kitty)

[pid 31778] poll([{fd=5, events=POLLIN}], 1, -1) = 1 ([{fd=5, revents=POLLIN}])
[pid 31778] recvmsg(5, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\n\3\t\217\16\0\200\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 64
[pid 31778] poll([{fd=5, events=POLLIN}], 1, -1) = 1 ([{fd=5, revents=POLLIN}])
[pid 31778] recvmsg(5, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\34\0\t\217\16\0\200\2R\1\0\0X\325\215\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 32

[Gordin]

@kovidgoyal I've been using modesetting driver for the last couple hours and a window just froze. Freezing with modesetting driver is a little different though... Instead of keeping the pixels from another workspace the window is just black now. When I set the window to floating it seems to disappear, like is has 0 width and height or isn't placed on screen? I can also interact with the terminal normally, I started and exited vim on the terminal and it also responds to SIGTERM correctly. (I had htop open in another terminal to see the vim process spawn from kitty, the kitty instance stayed black the whole time). Also nothing seems to unfreeze kitty.

So at least it probably doesn't seem to have anything to do with xf86-video-intel, assuming this is the same bug...

[Gordin]

I can reproduce it now, seems to be a problem with compton coupled with i3 after all...
Steps to reproduce:

• ~/.config/compton.conf with

# transparancy settings for i3
opacity-rule = [
  "0:_NET_WM_STATE@:32a *= '_NET_WM_STATE_HIDDEN'"
];

• start compton
• Open 2 Instances of kitty
• Switch to Tabbed mode in i3, so that one of the kitty instances is hidden
• Trigger an i3 config reload (bindsym $win+Shift+c reload)
• The kitty instance that was hidden is now frozen (black display, but accepts inputs, I didn't test this with the xf86-video-intel driver yet)

Workaround: Remove that line from compton.conf...

I've attached an strace of the frozen kitty instance. I've scrolled through it and I think there might be something interesting in there, but it's 9000 lines for just a couple seconds, so I hope you have a good idea of what you would be searching for...: kitty.log

[Gordin]

I noticed I have a compton.conf... This line seems to trigger the bug (the line with _NET_WM_STATE_HIDDEN specifically) :

# transparancy settings for i3
opacity-rule = [
  "95:class_g = 'kitty' && !_NET_WM_STATE@:32a",
  "0:_NET_WM_STATE@:32a *= '_NET_WM_STATE_HIDDEN'"
];

This snippet is from the arch wiki on compton: Compton - Tabbed windows

(I edited my previous comment)

[kovidgoyal]

wow that's a pretty specific scenario :) I'll investigate it someday when I have time, although maybe it would be better to just switch to wayland with sway or similar as it has transparency builtin and so should not require such hacks for tabbed windows.

[akupila]

I'm seeing something that's quite similar, on Wayland with Sway and Kitty 0.14.1. I can't reliably reproduce, but this commonly happens if i let the display go to sleep. Sometimes i can see a _tiny_ kitty window, not sure if this helps (screenshot 1:1 size):

I'm happy to provide any additional info, if you tell me what can be useful (i'm not sure where to look). I'm pretty sure this started happening in 0.14.0.

[kovidgoyal]

@akupila I highly doubt this has anything to do with the original issue. Open a separate bug report for it, mentioning your system config details. Also ry setting sync_to_monitor=no in kitty.conf and see if it fixes the issue.

[joshuarubin]

I'd just like to add that I'm using wayland/sway and seem to be having the same issue as the OP. Most of the time kitty works fine, but sometimes when going to its workspace (even if just switching from a different monitor, meaning kitty wasn't hidden) it freezes. This has nothing to do with tabbed layout or compton. I don't have any transparency enabled on any level. This does not only occur after a sway reload. Maybe the OP found a specific way to reproduce the issue, but it is not the _only_ way. I don't have a reliable way to reproduce the issue myself though. kitty works most of the time until suddenly it's useless.

It happens frequently enough that I've had to pin my package manager to v0.13.3 as this is a very significant issue that greatly impedes my work.

Both v0.14.0 and v0.14.1 exhibit this behavior.

Clearly the scenario isn't so specific as now multiple people are reporting it.

I really hope @kovidgoyal can make this a higher priority than "someday when I have time", but I realize beggars can't be choosers.

Thanks so much for kitty, it's really great and a critical tool that I use _constantly_.

[kovidgoyal]

Umm the wayland specific bug has nothing to do with this issue and is
already fixed.

[joshuarubin]

If you're talking about #1696 I don't think it's the same

[kovidgoyal]

Regardless, it has nothing to do with this issue. And if you wish to claim it is not the same as #1696 then run from master and see.

[joshuarubin]

will do

[xaltsc]

I have the same problem with and without compton, but with xmonad on VoidLinux (kernels 5.0.21 and 5.1.7); however, I also have the problem with other apps, namely, Spotify. I wonder if it's not more a Firefox issue than a kitty one..

[xaltsc]

Well, the bug also happens when using Chromium, so not Firefox specific...

Also, the bug seems to be solved when fadeWindowsEventHooks (which makes xmonad communicate with compton) are not added to handleEventHook.

[MarsCapone]

I also have this issue. Running Xorg on Arch. AwesomeWM. I don't have a compositor or even a compton config.

The windows don't respond to any attempt to close using window manager controls. Instead I either xkill or send SIGTERM.

[xaltsc]

So, I recently tried to re-uninstall xf86-video-intel and retried to only use the modesetting driver, and so far, I haven't had any freeze, even with compton running all the time.

Perhaps we are experiencing different bugs here ?

[pyr]

I also have this issue. Running Xorg on Arch. AwesomeWM. I don't have a compositor or even a compton config.

The windows don't respond to any attempt to close using window manager controls. Instead I either xkill or send SIGTERM.

I am in this situation as well. Xorg + Arch + AwesomeWM. xkill is my only option when the bug exhibits. It tends to happen much faster when using a regularly updated window (such as a window running irssi).

I should add this is running with 0.15.1-1 from arch, I'll try from master and report findings

[pyr]

Running master yields the same issue, as does the recently released 0.16.0-1

[wakatara]

@xaltsc @pyr @MarsCapone @j-james

Hey guys,

Since I ran across this myself with kitty and several electron7 based apps (and Chromium) in i3 and awesome on Mnajaro and then latest Arch (August), I should let you know this is intel video driver related. I fixed it in my config by changing my X11 settings if you have a intel graphics chip (say an Iris or UHD or similar onboard.).

In my i3 system, I fixed it by setting DRI to 2 instead of 3 in the /etc/X11/xorg.conf.d/20-intel.conf file

Section "Device"
    Identifier "Intel Graphics"
    Driver "intel"
    Option "DRI" "2"
EndSection

Note: DRI was set to 3 originally. This fixed everything in Majaro i3 20.03. In Arch with i3 setting this corrected logged into i3 window freezing (and ghost space whjen they crashed) but did weird things to the lightdm screen.

I'm using a heavily modified version of POPOS right now, and have not had these issues with kitty.

Daryl.

// @kovidgoyal

[Gordin]

Just wanted to confirm what @wakatara said. I was also using intel graphics with DRI set to "3" and "fixed" this issue by setting the DRI to the older version "2". I also experienced this with a couple other electron based Apps (Slack and Spotify) and the DRI Settings also fixes this problem for those electron Apps.

@wakatara in POPOS, are you still using the intel driver, and if so, with DRI set to 2 or 3? Is this an Archlinux issue (I'm also running Arch), or is this a problem for all distributions with DRI 3?

[kovidgoyal]

Sounds like a driver bug to me. Sadly, there are rather a lot of bugs in
the intel drivers on Linux. Feel free to continue the discussion but am
closing as not a bug in kitty.

[wakatara]

@kovidgoyal Definitely not a bug in kitty (though much like these people, I thought it was at first too. I just happened to have VS Code go the same way that made me google around for it more.

@Gordin POPOS seems to not use the intel driver and the X11 directory structure does not mirror the structure that both Arch and Manjaro share. I do believe this bug has to do with AUR based distros and possibly the intel drivers though also believe that since I imagine everyone of us was running Compton/Picom with our base systems, that might also somehow be in the mix.

in Manjaro i3 I had the DRI set to 2 which corrected everything. In a hand rolled version of the latest Arch (August, I believe), setting DRI 2 corrected logged in window freezing issues, but the lightdm login was showing tearing and jagging when logging into the system (that was only about the second time I'd evr installed Arch and it did not solve the problem I was originally trying to correct with it - encrypted disk and hibernation working), so punted and went to POPOS.

POPOS seems to either not be using separate Intel drivers or using what comes with the 5.4 kernel that the 20.04 Ubuntu core comes with.

lshw -c video gives the following on POP OS which seems like it is running the i915 Intel drivers which is probably underpowering the new Iris graphic chip I've got.

  *-display                 
       description: VGA compatible controller
       product: Iris Plus Graphics G7
       vendor: Intel Corporation
       physical id: 2
       bus info: pci@0000:00:02.0
       logical name: /dev/fb0
       version: 07
       width: 64 bits
       clock: 33MHz
       capabilities: pciexpress msi pm vga_controller bus_master cap_list rom fb
       configuration: depth=32 driver=i915 latency=0 mode=1920x1080 visual=truecolor xres=1920 yres=1080
       resources: iomemory:600-5ff iomemory:400-3ff irq:143 memory:601c000000-601cffffff memory:4000000000-400fffffff ioport:2000(size=64) memory:c0000-dffff

[j-james]

Hey @wakatara ,

Thanks for CCing us. What you describe lines up with my experiences - the two other applications I've experienced similar (but much less frequent) freezes with were VS Code and Chromium (although never Spotify 🤷).

I don't currently have a Linux machine set up (sent in for repairs!) but once it's back I'll try the fix you suggested and report into this thread. It was running Manjaro with bspwm, but has never had Compton / Picom running (or even installed).

// @dharmab @daygr

(now that my computer's back, I can confirm - the fix works perfectly)

[daygr]

@wakatara @j-james looks like the archlinux wiki points towards this problem

I'm currently not specifying a DRI version in my xorg.conf so it is defaulting to 3. Will try using 2 and report back, as this issue is still on/off for me. (edit: I also do not consistently use picom, I found enabling the "TearFree" option on the intel driver sufficient)