Kitty terminal emulator very very slow (sometimes)

Since I started using Fedora I am having this weird problem with kitty emulator.

It can be very, very slow to do anything. For example if you hit one key it takes several seconds to display on the screen. Commands, once typed, take even longer to execute, like >10s to ls any directory.

Sometimes it will be like this immediately upon opening but other times it will be OK then become this way. It never seems to solve itself, if I leave a slowed down window open and try to use it again hours later it will still be slow.

All panes and tabs in the affected session are affected.

If you open a new kitty session, it is no more likely to be affected than by chance.

It has no obvious correlation to other applications which are open or what they are doing, what shell is being used, what’s being done in the terminal, general system resource usage. My cpu and RAM monitors aren’t doing anything unusual during these times. The rest of the computer behaves normally with no slowdown.

I have not had this problem when using xfce terminal.

Not sure how to begin troubleshooting this. It is very annoying.

Problem was present from first boot.

I am running fedora 39 xfce spin recently installed on on thinkpad x260. I have an SSD and lots of RAM. I don’t think I have installed any drivers except the default.

Let me know if any other info is required. I don’t have any idea where to start troubleshooting this.

1 Like

Since things are OK in other terminal emulators I would guess it is something to do with Kitty’s rendering. Kitty ties into the video buffer in a way that allows high-res graphics to be displayed within the terminal. I would suggest experimenting with the video driver to see if that makes any difference. For example, does Kitty exhibit the problem if you boot the system with nomodeset on the kernel command line?

I never tried that or heard about it. The internet tells me the method is to edit the file /etc/default/grub. Add nomodeset to the line GRUB_CMDLINE_LINUX. So in my case that would be:

GRUB_CMDLINE_LINUX="rd.luks.uuid=luks-74e90ffa-a855-4465-9021-e710f5fda7e2 rhgb quiet nomodeset"

then run sudo update-grub and reboot.

Do I understand correctly what you are suggesting? Then I guess, to reverse it, remove the option, re-update and reboot again?

In the arch wiki I read:

Along with the nomodeset kernel parameter, for an Intel graphics card, you need to add i915.modeset=0

I have an integrated intel GPU. Does this apply? Or would it only be the case for a separate card?

Should I expect the computer to otherwise work normally?

That’s news to me. If it says that you need it, then I’d go ahead and try it.

Yes, almost. A few video processing intensive tasks such a 3D rendering (used in games) may run slower or not work at all. You probably wouldn’t want to run your PC with that option set permanently. I’m just suggesting that you try it as a way of testing to see if something about the video driver might be causing Kitty to render things slowly.

It turns out that update-grub is a debian thing. I gather it is a sort of wrapper around some other tool(s).

Everything I am finding about how to transfer the procedure to fedora is a little too complex for me at the moment… I don’t want to risk hosing my system right now just for performance troubleshooting.

I also did wonder if there was some sort of GPU issue. If this method did solve it, where would I go from there? I’ve been using the same computer for a couple of years, with debian-based and arch-based distros. So I know that linux can handle it. Should I try different drivers? And are those installed via dnf just like other software?

you can use grubby to modify kernel arguments:
sudo grubby --args="kernel args" --update-kernel="kernel to be updated or ALL"
sudo grubby --remove-args="kernel args" --update-kernel="kernel to be updated or ALL"

man grubby provides more info

1 Like

You do not need to update anything for testing.

When booting you can press and hold the shift key and it should display the grub menu. Once there, pressing e for edit will allow altering the linux command line that is displayed then you can continue to boot.

Changes made this way are temporary and only take effect for that one boot.

This is an effective way to test ideas that may or may not work without making permanent changes.

Once you know what changes may be necessary it would be time to edit the /etc/default/grub file to add the changes you wish then run grub2-mkconfig -o /boot/grub2/grub.cfg to make those changes permanent.

Using grubby is another way to make changes permanent.

1 Like

Ah this is simpler for troubleshooting. I tried 2 variations. I don’t find any clues here but here’s what happened.

#1: nomodeset i915.modeset=0:

  • very low rez lightdm at login
  • xfce4 opens with 640x480p + 1x scale (usually 1366x768p + 2x scale)
  • tried to change using xfce4-display-settings no other resolutions available
  • tried to increase to 2x scaling which was available; screen went blank and I couldn’t get x back
  • was able to use console (also low rez) to reset display settings then rebooted

#2: nomodeset:

  • same low rez lightdm
  • when I login screen goes blank
  • again still able to access console so rebooted

Computer is not usable at that resolution, can only see a few lines of text so didn’t do any more testing since I don’t know how to trigger the intermittence problem with kitty. is there some other investigation to do with these boot options?

Not sure what that was but I don’t think it’s the way forward.

Is there a way to find out what are the correct drivers for my computer? I understand there are different ones but don’t know how to find out about them. I have a backup of my previous system drive from other distros that didn’t have this problem. can I look somewhere to find out what drivers were installed before?

I guess it’s a bit speculative but what else could be causing this issue?

The nomodeset parameter should not limit the display resolution to 640x480. It sounds like there is something unusual about your video configuration. If you are using scaling, that might well have an impact on Kitty’s rendering performance. Again, you shouldn’t need to, but you could add something like video=DP-1:1920x1080 to the list of parameters along with nomodeset. You will likely need to change DP-1 to the name of the connection your display is connected to. You can find the name(s) of your connection(s) with ls -d /sys/class/drm/card?-* | cut -d '-' -f 2-.

lspci -k will list the hardware present in your system and what drivers are compatible as well as which driver is currently being used.

It looks like Kitty has a --debug-rendering option. Since you said other terminal emulators work OK, you could open one of them and then launch Kitty with kitty --debug-rendering. Then use your Kitty terminal until it starts running slowly and see if anything interesting is logged in the original terminal window when Kitty is running slow.

I really aoppreciate all the input. :slight_smile: I am saving the thread so I can refer to it later because I’m sure all of them will be useful.

@glb Thanks for the detailed instructions re setting modes, I will try them out.

hmmm interesting. Not sure what to make of the information. The man page doesn’t say much.

lspci -k
00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Host Bridge/DRAM Registers (rev 08)
	Subsystem: Lenovo Device 504a
	Kernel driver in use: skl_uncore
00:02.0 VGA compatible controller: Intel Corporation Skylake GT2 [HD Graphics 520] (rev 07)
	Subsystem: Lenovo Device 504a
	Kernel driver in use: i915
	Kernel modules: i915
00:14.0 USB controller: Intel Corporation Sunrise Point-LP USB 3.0 xHCI Controller (rev 21)
	Subsystem: Lenovo Device 504a
	Kernel driver in use: xhci_hcd
00:14.2 Signal processing controller: Intel Corporation Sunrise Point-LP Thermal subsystem (rev 21)
	Subsystem: Lenovo Device 504a
	Kernel driver in use: intel_pch_thermal
	Kernel modules: intel_pch_thermal
00:16.0 Communication controller: Intel Corporation Sunrise Point-LP CSME HECI #1 (rev 21)
	Subsystem: Lenovo Device 504a
	Kernel driver in use: mei_me
	Kernel modules: mei_me
00:17.0 SATA controller: Intel Corporation Sunrise Point-LP SATA Controller [AHCI mode] (rev 21)
	Subsystem: Lenovo Device 504a
	Kernel driver in use: ahci
00:1c.0 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #1 (rev f1)
	Subsystem: Lenovo Device 504a
	Kernel driver in use: pcieport
00:1c.2 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #3 (rev f1)
	Subsystem: Lenovo Device 504a
	Kernel driver in use: pcieport
00:1f.0 ISA bridge: Intel Corporation Sunrise Point-LP LPC Controller (rev 21)
	Subsystem: Lenovo Device 504a
00:1f.2 Memory controller: Intel Corporation Sunrise Point-LP PMC (rev 21)
	Subsystem: Lenovo Device 504a
00:1f.3 Audio device: Intel Corporation Sunrise Point-LP HD Audio (rev 21)
	Subsystem: Lenovo Device 504a
	Kernel driver in use: snd_hda_intel
	Kernel modules: snd_hda_intel, snd_soc_skl, snd_soc_avs, snd_sof_pci_intel_skl
00:1f.4 SMBus: Intel Corporation Sunrise Point-LP SMBus (rev 21)
	Subsystem: Lenovo Device 504a
	Kernel driver in use: i801_smbus
	Kernel modules: i2c_i801
00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection I219-LM (rev 21)
	Subsystem: Lenovo Device 2233
	Kernel driver in use: e1000e
	Kernel modules: e1000e
02:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS522A PCI Express Card Reader (rev 01)
	Subsystem: Lenovo Device 504a
	Kernel driver in use: rtsx_pci
	Kernel modules: rtsx_pci
04:00.0 Network controller: Intel Corporation Wireless 8260 (rev 3a)
	Subsystem: Intel Corporation Device 1130
	Kernel driver in use: iwlwifi
	Kernel modules: iwlwifi

I guess I am also curious about drivers which may not be available on the system but would be better.

rpm fusion seems to be the main place for this kind of thing in fedora world. It suggests:

Intel (recent)
Using the rpmfusion-nonfree section
sudo dnf install intel-media-driver
Intel (older)
Using the rpmfusion-free section
sudo dnf install libva-intel-driver

What is meant by “recent” and “older” is anybody’s guess. It depends when it was written and material conditions of the author. Usually I assume my hardware is “older” in general. I would prefer to try free first before resorting to no free.

intel-media-driver - somewhat elusive. Maybe it doesn’t exist in the repo?

libva-intel-driver: intel/intel-vaapi-driver: VA-API user mode driver for Intel GEN Graphics family

In one of the above repos I came across intel_gpu_top (repo) which is available via igt-gpu-tools package in fedora. It might be useful here but a person with better technical understanding would have better luck.

hardware specs + details for cpu/gpu

I look at these but was unable to discern anything of value to my low level of comprehension.

That’s a good idea. I don’t know why I didn’t find and try it already. I definitely looked for something but sometimes I get a bit lost in the kitty documentation due to being so expansive.

thanks again to anyone who took the time to even read this

1 Like

So I tried this. When you open kitty it outputs prompt_marking lines, I think about 3 lines per command entered. Outputs like this:

kitty --debug-rendering
GL version string: '4.6 (Core Profile) Mesa 23.3.6' Detected version: 4.6
prompt_marking: x=0 y=13 op='A'
prompt_marking: x=0 y=14 op='C'
prompt_marking: x=0 y=19 op='D;0'
prompt_marking: x=0 y=19 op='A'
prompt_marking: x=0 y=19 op='D'
prompt_marking: x=0 y=19 op='A'
prompt_marking: x=0 y=19 op='D'
prompt_marking: x=0 y=19 op='A'
prompt_marking: x=0 y=19 op='D'
prompt_marking: x=0 y=19 op='A'
prompt_marking: x=0 y=19 op='D'
prompt_marking: x=0 y=19 op='A'
prompt_marking: x=0 y=19 op='D'
prompt_marking: x=0 y=19 op='A'
prompt_marking: x=0 y=19 op='A'
prompt_marking: x=0 y=20 op='C'

On the occasion for the above output the terminal was immediately slow when opened.

also sometimes get y=21 op='D;130' which I thought had to do with entering an invalid command but then sometimes it comes up even for a valid command.

How to discern any meaning from this?

Also ran sudo intel_gpu_top (can’t be run as normal user) in case there was anything there. Nothing I do in kitty makes anything happen in that. When I move my mouse around really fast I can make the Render/3D graph and some of the other numbers go up a bit but other than that not sure how to test it. Here is how both of them look:

I don’t get those repeating “prompt_marking” messages when I run Kitty on my system, so that might well be related to the problem you are seeing.

I haven’t found anything about exactly what that “prompt_marking” message means though, so I’m not sure I’ll be able to help with that error (if it is an error).

For what it’s worth, there appears to be an issue tracker for Kitty here. Someone might be able to help you if you report that output from running kitty --debug-rendering on their issue tracker.

Found this in the kitty tracker: Raspberry Pi [Debian 12] – blank window · Issue #6916. A completely different problem with similar debug output. Suggested solution (no feedback to find if it helped):

this will be a driver issue. You can try software rendering via the MESA
env var the exact name of which escapes me at the moment.

Web search to figure out what was he talking about led me here: Environment Variables — The Mesa 3D Graphics Library latest documentation.

Eventually I find that if I launch kitty this way there is no issue:


So I will mark as solved since that is technically the case. It seems as though there is something else amiss though. I don’t really understand the meaning of it.


That’s a neat work around. I didn’t realize you could override Kitty’s environment so it will use the software rendering (your PC’s CPUs) instead of hardware rendering (your PC’s GPU) if there is a bug in your video driver. Hopefully the problem with your video driver will get fixed soon so that this work around is no longer necessary.

Thanks for reporting the work around so others will be able to find it if they hit a similar bug. :slightly_smiling_face:

1 Like