-
-
Notifications
You must be signed in to change notification settings - Fork 786
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hanging after recent update on Arch #5197
Comments
Same here, updated my hyprland version and wezterm won't create a window. This issue seems to indicate theres an issue with how wezterm implements the wl protocol hyprwm/Hyprland#4806 (comment) |
You can add The xorg-xwayland is needed. |
That (Hyprland link) is a completely different issue. If wezterm is printing anything then it's #5103, which should only appear on Hyprland 0.37.0 (technically 2 commits after 0.36.0) |
Also having this issue on Void Linux under Wayland. I'm not running it under xwayland so I'll use the Foot terminal while this is being fixed. I can provide logs if that helps. |
Also have this issue since last update on two Arch Hyprland machines. Here's the log for |
Well, I think I just found a workaround. |
While this worked for me too, it should be noted that this seems to be equivalent to |
+1, exact same situation (Arch/hyprland). I'm downgrading to the previous version of Hyprland meanwhile. |
same |
disable wayland?so why dont use kitty? |
I have the same setup (archlinux, wayland + hyprland) and problem. But to make things weirder, when I call |
Are you sure both aren't running on xwayland? |
Here's what's happening: In Wayland, for an application to show up, it has to receive what's called a "configure event" from the compositor. (the configure event is also used for example to resize the application) Hyprland v0.36 (and most other compositors probably) will send 2 configure events when an application starts. The first one has mostly-empty fields (including the size, which is set to 0 0) and the second one has a bit more data (with a proper size). Apps should open (display their window) as soon as they receive their first configure event. But sending 2 configure events like that cause some issues on slower computers. Most apps (like foot and firefox) will open with a random size (or a very small size) when they're told to open with a size of 0. They will then resize themselves again (second configure event) a few (possibly hundred or thousands) milliseconds later, which will cause tiny visual artifacts. To fix this, vaxry made it so that Hyprland v0.37 (technically 2 commits after 0.36) will properly predict the size of new apps before they open and send them a single configure event with the right size. But for some reason, wezterm will only open if it receives a configure event with size 0 0. If you send it a configure event with any other size (e.g. the size it's supposed to open with), it will not display its window. However, if you open a floating window in the same workspace, you actually "bypass" Hyprland's size predictions for any other new windows (including tiled). Causing Hyprland to send 2 configure events (just like on v0.36); one with size 0 0, and another with the proper size. This makes wezterm show its window again. Launching wezterm with the floating windowrule will also bypass Hyprland's size predictions. hy3 (Hyprland plugin for manual tiling) has not implemented size predictions yet, so wezterm also work there. I'm not very familiar with wezterm's codebase so I am unable to find out how wezterm is expecting an empty configure event, so I just completely removed it as a temporary workaround ( |
duplicate of #5067 |
Will this be fixed? The terminal looks really ugly for me under XWayland (I use fractional scaling). |
Same here, and set Reset |
Is this a duplicate of #5103 ? |
What Operating System(s) are you seeing this problem on?
Linux Wayland
Which Wayland compositor or X11 Window manager(s) are you using?
Hyprland
WezTerm version
20240316-074238-889f8a9c
Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?
Yes, and I updated the version box above to show the version of the nightly that I tried
Describe the bug
After running wezterm it's just hanging.
To Reproduce
No response
Configuration
The same behavior with running
wezterm -n
Expected Behavior
Make it works again!
Logs
Anything else?
strace (not full):
The text was updated successfully, but these errors were encountered: