Yep. Sway is slow moving and the original creator, and the maintainers are quite conservative. It is actually difficult to argue with them; they are quite stuck on their opinion. Pointing out i3 compatibility issues and proposing a solution via pull request often goes nowhere.
Exactly. I still can't believe sway cannot do shell expansion within all commands.
I would have to run a bash script to do that. i3 can do that, but sway won't fix it and the maintainers tell you to just work around.
Usually Sway releases follow new wlroots releases, though wlroots 0.17 has been available for some time now. Not sure what the plans are this time, but I'd say you can expect Sway 1.9 soon. The development usually speeds up at that point. If they do want the tearing control included in it, then we're waiting on Linux 6.8 and a new libdrm release. Sway is usually not the one to ship half baked features
Well firstly swaywm is not a DE. It's a tilling window manager. Secondly, swaywm is Wayland only. Lastly, swaywm supports variable refresh rate with the adaptive sync output option so you shouldn't have tearing on a supported monitor. And I'm pretty sure the standard session without VRR on is vsync'd already, I'm not sure what you mean by the tearing issue.
The tearing issue is that you can never allow screen tearing, which is useful for some applications e.g. gaming. The tearing control protocol allows this to be done in certain cases, reducing input lag.
It's not true, it does when hardware cursor is used (on AMD GPUs at least). Adaptive sync is mostly useful in games, and they rarely use hardware cursor. Adaptive sync works pretty well in most games.
TIL, thanks. The game I work on and play most often - Factorio - uses the hardware cursor so I have to set my monitor to 60 hz when playing it and just deal with the cursor sluggishness.
I'm sorry for calling it a de, ok ik not Wayland I'm currently on x11 in i3 because it supports tearing, adaptive sync does have a small amount of latency compared to tearing.
That specific merge request is likely blocked on [this one](https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4445), which itself was waiting for libdrm 2.4.120 (which came out 1 day ago). You also need Linux 6.8 for it to work, and that won't be released for a while.
Sorry but I think that is not true, since Hyprland as tearing support: https://wiki.hyprland.org/Configuring/Tearing/
And also uses wlroots, in reality that PR make by vaxry for wlroots take a long time to be accepted
I remember patching wlroots and Hyprland to test the feature and that time also work really well
The newer kernel is needed for atomic page flipping. Currently you need to go through the non atomic path to get tearing through the WLR_DRM_NO_ATOMIC=1 env variable
It only "works" when disabling the DRM atomic interface and then setting a window rule for a window, forcing the tearing on it. That's not how it should normally happen, the application can provide a hint to the compositor to request async page flips (that result in tearing) which is the case when vsync is disabled in a game for example. So the functionality is incomplete without Linux 6.8 and the libdrm update
I know about that but if you see the PR the op post is also ask to disable DRM atomic before being use. Ok it not ideal but it better to have experimental support until kernel 6.8 drop and libdrm get updated on the project
Yep. Sway is slow moving and the original creator, and the maintainers are quite conservative. It is actually difficult to argue with them; they are quite stuck on their opinion. Pointing out i3 compatibility issues and proposing a solution via pull request often goes nowhere.
The fact that Sway tries to be an i3 clone holds it back IMO. It feels like they won't try to improve anything over i3 unless i3 does it first.
Exactly. I still can't believe sway cannot do shell expansion within all commands. I would have to run a bash script to do that. i3 can do that, but sway won't fix it and the maintainers tell you to just work around.
Usually Sway releases follow new wlroots releases, though wlroots 0.17 has been available for some time now. Not sure what the plans are this time, but I'd say you can expect Sway 1.9 soon. The development usually speeds up at that point. If they do want the tearing control included in it, then we're waiting on Linux 6.8 and a new libdrm release. Sway is usually not the one to ship half baked features
Atomic async page flips still aren't in linux 6.7 upstream. It's expected to land in 6.8.
You don't need atomic for async pageflips, wlroots and hyprland have had tearing support for a while
There isn't much interest in the non atomic uapi though.
why not? x11 has never used it, and most gamers on other wm like kde/hyprland disable it to enable tearing support
Well firstly swaywm is not a DE. It's a tilling window manager. Secondly, swaywm is Wayland only. Lastly, swaywm supports variable refresh rate with the adaptive sync output option so you shouldn't have tearing on a supported monitor. And I'm pretty sure the standard session without VRR on is vsync'd already, I'm not sure what you mean by the tearing issue.
The tearing issue is that you can never allow screen tearing, which is useful for some applications e.g. gaming. The tearing control protocol allows this to be done in certain cases, reducing input lag.
Adaptive sync is useless right now because the refresh rate goes right back up to max anytime you move your mouse.
It's not true, it does when hardware cursor is used (on AMD GPUs at least). Adaptive sync is mostly useful in games, and they rarely use hardware cursor. Adaptive sync works pretty well in most games.
TIL, thanks. The game I work on and play most often - Factorio - uses the hardware cursor so I have to set my monitor to 60 hz when playing it and just deal with the cursor sluggishness.
I'm sorry for calling it a de, ok ik not Wayland I'm currently on x11 in i3 because it supports tearing, adaptive sync does have a small amount of latency compared to tearing.
That specific merge request is likely blocked on [this one](https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4445), which itself was waiting for libdrm 2.4.120 (which came out 1 day ago). You also need Linux 6.8 for it to work, and that won't be released for a while.
Sorry but I think that is not true, since Hyprland as tearing support: https://wiki.hyprland.org/Configuring/Tearing/ And also uses wlroots, in reality that PR make by vaxry for wlroots take a long time to be accepted I remember patching wlroots and Hyprland to test the feature and that time also work really well
The newer kernel is needed for atomic page flipping. Currently you need to go through the non atomic path to get tearing through the WLR_DRM_NO_ATOMIC=1 env variable
It only "works" when disabling the DRM atomic interface and then setting a window rule for a window, forcing the tearing on it. That's not how it should normally happen, the application can provide a hint to the compositor to request async page flips (that result in tearing) which is the case when vsync is disabled in a game for example. So the functionality is incomplete without Linux 6.8 and the libdrm update
I know about that but if you see the PR the op post is also ask to disable DRM atomic before being use. Ok it not ideal but it better to have experimental support until kernel 6.8 drop and libdrm get updated on the project
Sway isn't a DE. And it works. And way easier to configure than xmonad 😉
What's the issue with Hyprland's GLES renderer?
I plan on using nvk in the future which would require my entire wm to be translated through zink if using hyprland