alacritty: Redraw randomly hangs until a keypress

Note that (as of today) an arch package alacritty-git is out of date (v 0.3.3). This version still suffers from this issue. What’s more (as it has been already said) 729eef0 solved an issue. So it should be closed

I immediately updated now that I saw #2438 was merged. This seems to have solved all of the issues I had relating to this (and so much more) 😍

It’s happening on my i3-gaps + compton machine too. It seems that switching compton backend from glx to xrender helps.

This is still happening for my on 0.12.2 on pop-os 22.04 as well.

$ alacritty --version
alacritty 0.12.2
$ uname -a
Linux eos 6.5.4-76060504-generic #202309191142~1695998943~22.04~070916d SMP PREEMPT_DYNAMIC Fri S x86_64 x86_64 x86_64 GNU/Linux
$ cat /etc/os-release
NAME="Pop!_OS"
VERSION="22.04 LTS"
ID=pop
ID_LIKE="ubuntu debian"
PRETTY_NAME="Pop!_OS 22.04 LTS"
VERSION_ID="22.04"
HOME_URL="https://pop.system76.com"
SUPPORT_URL="https://support.system76.com"
BUG_REPORT_URL="https://github.com/pop-os/pop/issues"
PRIVACY_POLICY_URL="https://system76.com/privacy"
VERSION_CODENAME=jammy
UBUNTU_CODENAME=jammy
LOGO=distributor-logo-pop-os

Still happens to me with 0.12.2 , on pop-os (based on Ubuntu) 22.04 LTS. I haven’t seen it except with tmux as the shell, though I haven’t tried very hard. With tmux, every couple of minutes 😦

@kchibisov, I’m running X11 with tmux and experience the issue mentioned here and in https://github.com/alacritty/alacritty/issues/4362. Have not experienced the issue since switching over to https://github.com/alacritty/alacritty/pull/6175 (been running it for ~3 days)

@Dzordzu the package is not outdated. In fact, there’s no package, there is a PKGBUILD (package build script). The PKGBUILD will fetch and build the last commit. There’s nothing outdated.

I’ve tested https://github.com/jwilm/alacritty/commit/729eef0c933831bccfeac6a355bdb410787fbe5f as well, seems like the issue was solved in it’s entirety, no bell issues too.

Thanks for the amazing support!!! 💯

As of 729eef0c, on my system (Arch Linux, X11, awesome WM ), a visual bell stays “on” until some interaction with the window is performed (such as moving the mouse): $ sleep 1; echo '\a'

I think I can reproduce this issue with the evlp2 branch. So this needs more investigation.

I’m looking forward to glutin eventloop 2.0 which is actively worked on and will eventually fix the issue. But until then it drives me nuts. It happens a lot and I constantly press random keys, because I’m afraid the terminal isn’t updating.

Is there a workaround to avoid having to switch to a different terminal emulator? E.g firing events constantly, disable optimization or to use an older version of alacritty or https://github.com/chrisduerr/alacritty/commit/1e8e9046cec57b7f08748cacbbed17ae9170ae66?

Happens to me too. Usually I blamed ssh connection for that, but today it happened twice when running something locally. I don’t use tmux or any other terminal multiplexer.

Happens much more frequently on my laptop, where I have ubuntu 14.04.6 LTS with Alacritty v0.2.9, but also happens at my workstation/desktop, where I run arch linux and have 0.3.3-2 installed.

Always happens when long (but not extremely long) output happening and scrolling the screen (like building something or pacman -Syyuu), but maybe it’s just because I happen not to press keys while it’s happening. (when I type, maybe it would happen too, but it’s easy to be unnoticed).

UPD: This indeed seems to be i3 specific, I also run i3wm. On the laptop where it happens the most, I believe I don’t use any composition manager.

That’s completely irrelevant whether they worked or not. The issue is that one frame on X11 is not being presented to the display for whatever reason when we draw and submit it, so for now the only viable solution would be to draw e.g. 3 times last redraw just to ensure that the frame goes to display.

X11 is just not great when it comes to hardware acceleration, because it was never designed with it in mind, so things break like that is not surprising. Keep in mind that contiguous redraw generally works, because it’s contiguous. For now only nvidia and llvmpipe seems to be broken, and intel using legacy xf86-video-intel(shouldn’t be used anyway).

We’re aware of issue with nvidia/llvmpipe on X11, which is likely not our issue, but just how x11 works. there’s #7251.

It seems like the maintainers aren’t looking at this thread, it might be time to create a new issue and just link to this one.

I just found something that might actually help to uncover the underlying issue here. Hear me out, its a bit of a long story:

I have an i7-1065G7 CPU with Iris graphics inside a Dell XPS 13 7390 2-in-1.

I had a bunch of problems with anything that uses gpu acceleration over the last couple of weeks but a combination of:

• Not sufficiently annoying, just puts extra load on my CPU
• Not getting anywhere with the usual tricks

… prevented me from resolving it.

However, this weekend I switched to GNOME because I just go too frustrated with certain problems (not related to this one) in KDE Plasma.

GNOME resolved my PLASMA-Problems but introduced two others:

• This alacritty problem (Only in Xorg)
• gnome-shell made my CPU go apeshit from just moving the mouse around in idle (30-60% usage) (Wayland and Xorg)

As described in my arch linux forum post: After two painfull afternoons of googling and poking around it turned out that gnome-shell fell back onto rendering on the CPU using llvmpipe because mesa was loading the wrong driver for my GPU!

I discovered this by checking journalctl -b /us/bin/gnome-shell and seeing warnings like these:

MESA-LOADER: failed to open i965: /usr/lib/dri/i965_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/dri, suffix _dri)
failed to load driver: i965
kmsro: driver missing
Failed to initialize accelerated iGPU/dGPU framebuffer sharing: Not hardware accelerated
libEGL warning: MESA-LOADER: failed to open i965: /usr/lib/dri/i965_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/dri, suffix _dri)
libEGL warning: MESA-LOADER: failed to open i965: /usr/lib/dri/i965_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/dri, suffix _dri)

MESA even attempting to load i965 is odd, since my GPU needs the iris driver! Not i965! So I decided to take a proper look at this, ended up setting: MESA_LOADER_DRIVER_OVERRIDE=iris in my /etc/environment and BOOM:

• CPU load Problems gone

AND:

• This alacritty on XORG problem also gone

And this might also be the reason while it randomly affects certain people but is unreproducible for the maintainers of alacritty. MESA loading the wrong GPU driver can go unnoticed for a loooong time (in my case: weeks) since most applications will just fall back to tormenting your CPU. My Plasma was probably running on the CPU for weeks without me noticing!

Alacritty master recently introduced a GLES2 renderer, I’d be curious if any of the people that can reproduce this want to test out opting into the slower renderer to see if that fixes it.

All you have to change is this line, which performs detection automatically: https://github.com/alacritty/alacritty/blob/master/alacritty/src/renderer/mod.rs#L92

I just tried forcing it both ways and it doesn’t make a difference.

@chrisduerr yes i am having the issue as described. The output updates after a few seconds of inactivity or with new input I’ll happily make a new issue though

See #5883. Our issue is different from this one since it’s severe lag as opposed to indefinite hanging.

@chrisduerr I’m also having an issue on macOS. Note that the output also updates if I wait several seconds.

I think you should report a separate issue. FYI I am running on macOS 12.1 with no issues. I only saw this issue on linux and what you describe doesn’t sound like the same thing (waiting for output doesn’t help). Also the fact that you have problems with firefox as well, could mean that your issue is not related to alacritty at all.

My bad. The problem with package versioning on my machine (that lasted for almost a half a year from now) was on my side. I’m sorry for interrupting.

This is great stuff! I would greatly appreciate a new release with this fix in it as I can finally recommend Alacritty for colleagues and projects!

It would be possible to use an older version of Alacritty until the issue is resolved.

There are also some patches in the archlinux repository which downgrade the glutin version, applying those might solve the issue though their focus seems to be on resolving transparency problems.

I would also expect the evenloop 2.0 pull request to be usable soon on Linux. My plan is to resolve the remaining issues in Alacritty within this week, however that does not mean that there won’t be any remaining issues upstream. However on macOS this won’t help at all.

So those are the main options for now. The next Alacritty will definitely release with this fixed, hopefully relatively soon once the upstream macOS issues are resolved.

The issue you’re looking for is https://github.com/jwilm/alacritty/issues/2217. Please don’t spam either of them with +1’s, since that will likely just burry useful information. If there’s additional information required, I’ll let you know, thanks.

I can also confirm that it happens during streaming console output (cat filename or git pull or make to build something), it’s not specific to being full-screen (like vim or tmux) or running multithread in some way.

@gbalke you’re observing this one #2217 .

Also seem to have this issue (I think anyways) I noticed long stretches of code like building a fork of aosp for Android or just playing music with mpd + ncmpcpp the terminal & visualizer will appear to hang but keyboard input or mouse movement will have it immediately redraw and catch up. This is on Arch Linux with Nvidia’s vulkan beta drivers 418.52.14 on xorg-server 1.20.5-1.

Hi @chrisduerr I tried #1518 with #1403 and I’m still seeing the issue (randomly). No idea what’s going on (is it related to the GPU?). This turns Alacritty a bit unusable 😦 (the only apparent way to force a redraw in my case by opening a new window and send the current (hanged) alacritty window to the back).

@dominik-zeglen the compton change fixes the issue for you?

This issue just started happening to me for the first time. I’ve been using alacritty as my main terminal for about 6 months and haven’t seen the problem before, until now.

I was able to narrow down the context in which the problem happen, at least for me. It only happens when using a compositor (happens with both mutter/gnome and compton for me), and when there are multiple Alacritty windows open. It does not happen with composition and just one window.

PS: Deleted my previous messages since they weren’t really accurate