[Fedora 39, Wayland, Gnome 45.3, Alacritty 0.13.1, default config] Alacritty indefinitely displays the block cursor until its window is resized, maximized or hidden-then-restored #7620
Comments
|
It's a gnome bug. |
|
Could you post me |
|
See #7465 |
Sure: |
|
Could you post |
|
|
FWIW:
|
|
yeah, it's a gnome bug, they should fix it. |
|
Thanks for looking into it @kchibisov! I understand that it's technically some other project's bug. But practically, in the software production it's pretty common to go an extra mile to make sure the software would actually work properly on some specific target platforms with extra testing and sometimes tweaking it to address the target platform's quirks and even bugs. No one's interested in the software that doesn't work, even if it's stopped working because of some external causes. Alacritty is amazing (when it works), and with all due respect to your hard job (I know, maintaining is hard and not always grateful), running an upgrade and finding out that it stops working, to me is unacceptable for such a critical piece of software as the terminal emulator. That makes me interested in exploring the alternatives further (foot, kitty, etc.) none of which happen to have such an issue under the apparently buggy Mutter. |
I tested on gnome 44.2 and it worked, they released 45.2 and it doesn't anymore, they even provided a fix upstream but not yet applied. They explicitly tell us to stop rendering right on start and never try to make it back. This all requires really recent protocol which probably only alacritty supports and handles the way protocol wanted, we can workaround and I physically can't test all compositors and their versions since I'd need to test 3 gnome releases, sway-git, sway, hyprland, smithay compositors, kde (with various versions).
Please, follow the upstream bug, no one except alacritty is likely handling this event(window state), so that's likely why this had lack of testing on compositor side since mutter is not the only one to had bugs (hyprland also had similar bug, they've fixed it). In general if compositor devs can't test something they shouldn't merge stuff like that, probably they just opted into testing on real clients and you just out-of-luck now, I've linked a workaround patch, but I'm not adding workarounds for not my bugs. I've pinged fedora package maintainer wrt that, maybe you'll get a workaround applied downstream. But that's all I want to do, otherwise no-one ever fix their bugs. |
|
@kchibisov Thanks for the extra details! Looks like things are indeed complicated with so many compositors and other Wayland abstractions, and things are moving too fast. I kinda miss times when Xorg and Rxvt just worked (at least for me) %) Thanks for not taking my rant personally. Appreciate your principles and all the hard work. |
On the second thought, the fact that Alacritty uses the 'recent' protocol that a very few apps (especially other terminal emulators) are currently using, and hence such a protocol can be assumed not very stable, means that Alacritty values performance number (I assume it was used for the 'better' performance metrics?) more than stability. Otherwise, imo, the right thing to do would be restrain from using it and hinding it behind some experimental flag until its support and awareness about it across Wayland software grows bigger. That's why I think without shifting the paradigm more to the 'stable' and less experimental side of things, Alacritty would be doomed to become unfunctional occasionally - not what I expected from the terminal emulator. |
|
it's a stable protocol that got a newer version adding one extra state, please complain to people not testing the code they write on compositor side. The last workaround for gnome I added 3 years ago is still present. There's nothing experimental in using the most recent version of the stable protocol. This protocol is how you get the window on screen on Wayland, used by all clients. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Even with no user config, after updating to Alacritty 0.13.1 on Fedora 39, it indefinitely displays the block cursor and nothing else until I perform maximize, resize or hide-and-restore operation on its window (i.e. somehow initiate the window redrawing). That happens only if there's no other window behind Alacritty. Contrarily, if I happen to have any other window open, and Alacritty gets opened above it, it becomes operational immediately.
Wasn't an issue with Alacritty 0.12.*.
System
OS: Linux, Fedora 39
Version: 0.13.1
Linux/BSD: Wayland, Gnome 45.3
Logs
The text was updated successfully, but these errors were encountered: