So a bit under 3 years ago, I made my infamous Wayland rant post that is likely the most read post on this blog by miles. I should really actually write about music again one of these days, but that’s a topic for another time. The language was perhaps a bit inflammatory, but I felt the criticisms I made at the time were fair. It was primarily born out some frustrations I had with the entire ecosystem, and it was not like I was the only sole voice. There are other people out there you can find that encountered their own unique Wayland problems and wrote about it.
With that post, I probably cast myself as some anti-Wayland guy which is my own doing, but I promise you that is not the case. You can check my mpv commits, and it’s businesses as usual. Lots of Wayland fixes, features, and all that good stuff. Quite some time has passed since then, and it is really overdue look at the situation again with all the new developments in mind. To be frank, my original post is very outdated and it is not fair to leave it up in its current state without acknowledging the work that has been done. So in comparison to 3 years ago, I have a much more positive outlook now.
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
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.
yeah, i had a couple of pain points on wayland a while back, even on amd. one single pesky piece of software still gives me grief sometimes but i think its mostly just that: software developers catching up at this point.
i notice general desktop responsiveness is better, cpu use is noticeably lower but it otherwise makes you forget it even exists, which is the point i wanted it to be in before i jumped ship.
I’m not abandoning my Awesome WM setup anytime soon personally. But I thought it’s worth sharing this perspective from someone who knows this stuff much better than me.
Yeah, same boat.
Tried riverwm 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/show 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?
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.
I used Awesome about 5 years ago, and was extremely happy with it, unfortunately an upgrade of Awesome broke my scripts so nothing worked, and I didn’t have the time to be distracted and fix it. So I switched to XFCE.
Pretty annoying to have many hours of work destroyed like that. If they have a promise now to not break compatibility with upgrades, I might consider trying it again. But I don’t care for a user environment that breaks completely because of changes in an upgrade.
As someone who hasn’t yet moved to Wayland, how good is support these days for alternate keyboard mappings? Is this something that each individual window manager needs to support, or does Wayland itself manage them?
Not just “international keyboard” support, but truly arbitrary keyboard/symbol mapping support. I muddle in programming with APL, which needs its own key mapping with Unicode symbols.
I recall KDE had its own mapping support which used some system APL layout but I’d rather not have key mappings tied to a specific window manager.
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.)
I use Wayland exclusively, but unfortunately I don’t think I have an answer for you since I’m not entirely familiar with this idea. Is your concern just for the configuration of a universal set of hotkeys configured within the compositor rather than a desktop environment?
I wasn’t aware that x11 facilitated this. I’d have figured keyboard mappings are abstracted from the compositor and left to the DE to handle, aside from core binds that allow dropping back to tty
I’m not sure I fully understood what you said, but I have messed around with changing layouts, as I use Colemak. It’s really annoying to have GDM or SDDM default to QWERTY.
The “correct” way to do it is to use
localectl [--no-convert] set-x11-keymap us,us "" colemak, grp:win_space_toggle, and that changes the relevant config files. So, Wayland is pulling from X11 configs (I think).Great info! I will try it when I decide to trial-run Wayland again, thank you!
(Some things I had read online suggested that Wayland did not use the x11 configs. If it does, that’s good news.)
I sincerely hope it works for you! That
--no-configflag tellslocalectlnot 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).
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.
