Reassessing Wayland
-
[email protected]replied to [email protected] last edited by
I sincerely hope it works for you! That
--no-config
flag tellslocalectl
not to change the layout for the TTY consoles, and it might be important to include for systems with encryption (I don't understand why, just something I saw when reading on the Arch wiki). -
[email protected]replied to [email protected] last edited by
I knew dudemanguy would eventually make a post like this. I use the distro(Artix Linux) he's a maintainer on Artix, and he's a solid dude that is always willing to help and gives solid help.
I have both riverwm and bspwm along with Wayland and X on my system and honestly have stuck on X because getting my workflow exactly the same on Wayland has been a technical hurdle of learning Zig (riverwm is written in Zig), and so far, with the exception of the occasional race condition, X just works.
I want to convert to Wayland, and will probably get around to making my own custom scripts in zig for working with riverwm. But until then, X/bspwm is where I live.
-
[email protected]replied to [email protected] last edited by
Yeah, same boat.
Tried river few months ago but couldn't fit my Awm workflow into it, river seems to think about tags as just tags for where you want windows (even on multiple of them) but I just want workspaces, where each ws also has its own tiling mode. Also, seems there is no standard on how to read/view the current tiling mode by something like waybar, also essential for me when toggling through them.
Also I don't understand Xwayland - I've searched hours for ways to tell the compositor to "tell" Xwayland to not scale the content dpi or something along these lines - there seems to be no standard and every compositor handles xwayland in their own way?
-
[email protected]replied to [email protected] last edited by
-
[email protected]replied to [email protected] last edited by
What X11-only apps/programs did you need xwayland for?
I actually always disabled xwayland whenever I experimented with wayland (weston and sway), because everything I use is supported natively, and I wanted to make sure the native support was forced.
-
[email protected]replied to [email protected] last edited by
I'll look into those, thank you!
(I currently set up my APL keymap via .Xmodmap with xmodmap, and setxkbmap for X11 terms, and with 'loadkeys' for console.)
-
[email protected]replied to [email protected] last edited by
I finally got an "upgrade" going from a super slow 25 year old system to a kinda slow 10 year old system. Went with wayland to try it out and it works well enough so far.
The only thing I'm missing, and I haven't had a need since the upgrade is to be able to run remote X applications locally. Relied on a netbook with X client and had my desktop downstairs. Now my new laptop can run all I meed so no remote X tunnels over SSH.
-
[email protected]replied to [email protected] last edited by
For example, the recently publicized about mouse latency differences is true and something I've noticed but the difference doesn't particularly bother me. Something like that is just one of those inevitable consequences of the design of Wayland being so fundamentally different.
It would be interesting if someone explained the relationship between Wayland design and mouse latency
-
[email protected]replied to [email protected] last edited by
Have you explore hyprland, niri (scrollable, not dynamic, but it's sort of dynamic then) or sway (static tiling though, but offering tabbed layout and dynamic stacking/floating, plus hugely customizable)? Did you discard them because not close enough to bspwm? Just curious, not to judge your decision or anything like that.
Being an artix user, are you using logind (the official default), or just seatd, or the new logind alternative turnstile (not supported by all init systems, looks like only dinit which I use and openrc, tough void has it working with runit I believe)? I'm wondering what's really required on wayland. I like the approach of just seatd, but I don't know what one would lose and what are the wins, but if not seat alone then turnstile which actually require seatd. Also I would like to drop calling d-bus, but I'm not sure if that would prevent the compositor to work, but further if screen sharing with webrtc, electron apps like slack or teams-for-linux would stop working. I guess not using d-bus would not affect mako. But any ways, I'm curious of what you're using on your wayland experience. The official and default way is just logind plus d-bus plus polkit. For such sharing xdg-desktop-portal is required, which fundamentally seems to be plumbing of d-bus, but I'm not sure...
BTW, for blog post referenced, dudemanguy is also the mpv developer, so that requires quite a lot of effort (mpv specially on the support side of things, besides the developing effort, particularly to support wayland, and mpv does for some time now). I'm glad he's back writing,
-
[email protected]replied to [email protected] last edited by
It is kinda simple. X.org and older Wayland compositors use the legacy KMS API, while modern compositors use the atomic API.
The atomic API lets a compositor update everything for all planes in one go, this is a good thing because either all changes apply or none at all.
The legacy API only lets things be updated individually.Now why does atomic have more latency when it comes to mousing around? It's because in a single atomic commit all properties have to be set, including cursor X & Y positions. Once an atomic commit has been sent to the kernel, it is locked and can't be changed until the next monitor vblank. This means the cursor position is ever so slightly outdated. The legacy API does not have this limit, compositors can immediately move the cursor no problem, so less perceived latency.
There were proposed changes to address this years ago, but those seem to have fizzled out.
-
[email protected]replied to [email protected] last edited by
Thanks for the detailed answers. So we can say that Wayland sacrifices lower latency in exchange for higher accuracy.
According to this post Gnome allows you to change this behavior through an environment variable (
MUTTER_DEBUG_ENABLE_ATOMIC_KMS=0
on Ubuntu 22.04). It should be a configurable option, considering the amount of people complaining about this mouse behavior.Oh and this is also why the cursor movement might visibly start stuttering during heavy GPU load. This is a problem that was solved back in the 80s but here we are…
Sad, but does this problem only affect Wayland or also Xorg?