The core of Wayland does seem to be pretty good, but I think adoption has been hurt by a tendency to push things out of the core protocol and the lack of a unified implementation between major desktop environments. Screenshots and screen capture got pushed out to dbus protocols and are quite limited in some ways compared to what you could do with X (good for sandboxing, but I think rather unfortunate for the non-sandboxed case). Window decorations are a huge mess because GNOME/Mutter don't support server side decorations at all, but non-GTK apps don't necessarily know how to draw their own. Even VRR support is kind of a mess because it's up to the individual compositors to implement it and one of the most commonly used ones (Mutter, used in GNOME) doesn't support it.
One of the big issues with Wayland is the (intentional) fragmentation. Each "Wayland compositor" is really its own window system, with its own peculiarities. This forces applications that would have been trivial to implement on X to either limit support to only a single "compositor", or suffer explosion of compositor-interfacing code.
Apart from that, Wayland is very opinionated, it's basically intended to cater to 70% of users, while flipping off the rest.
the dumbest decision was to push keyboard layout handling to compositor, and if you happen to be multilingual, you're locked into mainstream DEs. while all the cool stuff like newm, cardboard, hikari is destined to avoid any meaningful adoption unless authors reinvent a monstrous wheel that is keyboard layouts
I've been using Wayland (on Fedora) for a while, and it's been fine. No crashes, no weird performance problems. I wouldn't even know it's not X...
... EXCEPT THAT it doesn't support color management (or at least, Chrome doesn't support it under Wayland, I'm never clear where exactly the problem lies), so my wide color gamut monitor goes fluorescent in Wayland, while staying properly subdued in X.
There, I've now fulfilled the contractual obligation to gripe about Wayland in every post about it.
Are you certain that you're running Chrome under Wayland, and not XWayland?
I couldn't figure out for the longest time why I couldn't drag a file from the Gnome file manager to Google Drive in Chrome. Turns out it's because Chrome wants to run under XWayland by default - at least on my machines.
I switched "Preferred Ozone platform" to Wayland under chrome://flags and now drag+drop works. Not sure about color management, though.
Every time I want to try it I see complaints about color management, and it raises all red flags I have with me. Is it really true? How can something so basic and vital be neglected?
Well, for some people that’s apparently fine—an image asset format (QOI) that’s been received fairly well by this forum had its author strongly opposed for the longest time to even specifying a colorspace, let alone allowing more than one. Those people are not me and I’ve cursed them out a few times, but they are not rare.
The {Gamma,Color}FAQ pair[1] are the traditional entries in that category, although my own experience implementing colorspace transformations is that they may be making the subject appear more complicated than it needs to be.
At the same time, I’m not sure if the “falsehoods” path is the simplest here, or if an explanatory “what is” approach would be better. There’s no end to mistaken things people get confused into believing, but the fundamentals of emissive colour are just not that hard—a (mostly) linear system can only be so complicated. In that respect I think I found the introductory part of the Matplotlib colormap talk[2] to be the most helpful source on the basics.
(There are difficult things about color, of course. But perceptual similarity does not in my opinion count as part of the fundamentals. And while the science of paint and light-matter interaction in general is basically endless, unless you’re doing print design or photorealistic rendering it’s probably not an immediate concern for you.)
Well, X is definitely showing its age and some week-spots. I think we need something. And given how huge X is - in both features and users - it's gonna be really hard. And, it seems only Wayland is making any progress - even if slow. The other options are slower or non-existent.
The people who wrote and worked on X for many years decided to write and work on Wayland instead. No-one's forcing you to switch, but conversely no-one's forcing the folk who used to work on X development to keep doing that.
I did see one of the long-standing developers wondering whether it would have been better-received if they'd called it X12 :P.
X is color-managed to the same degree that it is in Wayland. That is, all buffers are sRGB, and the application needs to convert output buffers in sRGB format. Chrome certainly takes great care to do color management of the content displayed in the window, but again, it is limited to sRGB output. This is the same in Wayland and X.
Color management needs improvement across the kernel & drivers, the compositors, and the applications. For more details on implementing color management, see Henry Wentland's 2022 XDC talk about implementing HDR (a feature that requires robust color management up and down the stack). You might notice that it primarily focuses on Wayland.
There's a lot of talk about HDR and Chrome here. I'm interested in neither but me and other professionals (in photography and graphic design) that do color critical work need to be able to create color profiles with spectrophotometer hardware and https://displaycal.net/ and use those profiles. It's a well known fact that this is currently impossible with Wayland but possible in X. Developers of darktable, Rawtherapee, Krita and other open source applications hang out out on pixls.us. Here's a thread:
Okay, my situation is that I have a monitor that displays a larger than RGB color gamut. When I set an ICC profile for my monitor in GNOME, and go to a page that should be in an sRGB color gamut in Chrome in X, it displays it as it should look. In Wayland, it displays it in my monitor's native (wider than sRGB) gamut.
I'm guessing you're using GNOME? Gnome doesn't support proper fractional scaling currently because GTK's current API only supports an integer scaling factor. There's an experimental feature that fakes it with 2x scale to GTK and downscales in the compositor.
I use 1.5x on my Framework 13 laptop (2256x1504) and it works perfectly :) Way better than Xorg, especially when using multiple displays with different scales or fractional scales.
For the mouse cursor, I had the same issue with Xwayland windows until I explicitly setup a cursor theme. Now that works too... and I suspect it was also because of that display scale thing.
Are you using any electron based apps? I find them to be much blurrier when using fractional scaling versus Xorg so I'm running my monitors at native rather than my preferred scale of 125% (2K 16" and 4K 27" displays).
IIRC, vs code supported some extra arguments (--enable-features=UseOzonePlatform,WaylandWindowDecorations --ozone-platform=wayland) but this didn't work universally across electron applications and caused very noticeable input lag in others such as Discord.
Yes xwayland just renders the application in the original size and scales it leading to a very blurry experience. Using only native apps avoids it so I find it a little hard to knock wayland instead of say electron or X. This is the issue: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1318
Gnome (or rather GTK) is currently lagging on fractional scaling support, KDE Plasma seems to get it correct.
For mouse cursors changing size, I fixed that on my system by ensuring the XDG desktop portal for KDE was enabled. Not sure that was the real fix, but it seemed to let KDE handle cursor rendering even over GTK windows.
Wayland is supposed to have fractional scaling now. I think wdisplays lets you configure it.
#1 was was never solved by X11 properly, and I'm forced either have large fonts on 27" 2K and ok fonts on 4K 32" or ok fonts on 27" and small on 32", because I'm limited by one Xft.dpi
I found fractional scaling to be way better handled under X11. If you fractional scale under wayland you get terrible blurriness everywhere as if they're upscaling instead of downscaling.
This will still result in bluriness, since it is scaling the already rasterised image, instead of informing the application to render at a different pixel resolution.
X11/Xorg has long supported proper per-display fractional scaling, since the usual resolution in 96 DPI, which can easily be multiplied by 1/0.6 and set per-display using `xrandr --dpi 160/DP-2`. It is still however up to frameworks (Gtk, Qt) to detect and implement this. I've seen Qt applications handle this automatically, but not Gtk.
My last Wayland-related post on HN [0] was about how it handled this worse than X11 due to lack of proper fractional scaling. AAIU, this has since been added to the protocol, but based on sibling posts, it sounds like framework support is still in the same state as in X11 (ie, works in Qt, not in Gtk).
Last time I tried wayland, only a month or two ago, i ran into multiple bugs that led me to switch back to xserver.
Discord screen share did not work at all. I guess the official app doesn’t support wayland. The workarounds are “use a web browser instead” or “risk a ban with an alternate discord client”.
Which led me to problem 2: screen share did not work in Firefox either. Tried a whole bunch of workarounds but couldn’t get it to work. Either wouldn’t see a display, or Firefox would crash. Nothing worked.
I think I recently saw something in the Firefox patch notes about wayland screenshare, so maybe I’ll give it another go in another few months.
I had the same problem with screen share not working in Firefox. It simply gave an empty list of things to pick from to share.
After, idk, half a year or so, I gave it a fifth(?) try, it still didn't work, and I googled the problem once more. Lo' and behold: you have to install xdg-desktop-portal to get screen share functionality. I installed it, and it worked.
Now there's 2 problems with this:
1. the UX is F'ing punching out the bottom of the barrel. There is no hint, no error message, no breadcrumb to tell you what's going on. You just get an empty list of sharing choices and are left completely befuddled. Cool.
2. xdg-desktop-portal, first hit when you look it up, starts its description with "A portal frontend service for Flatpak and possibly other desktop containment frameworks." What the F does that have to do with screen sharing? (Apparent answer: …sandboxing/access control?) If you dig more, you do get told that it does screen sharing, but with a first hit noodling on about "Flatpak" … "desktop containment" why would you even be inclined to dig deeper?
The irony of an UI project being this oblivious about dealing with users is… well.
xdg-desktop-* just goes 100% cpu. It's the first process I kill after booting Fedora. I'd appreciate if xorg folks implemented whatever hippie nonsense millennials want so that we can go back to 20 years ago when everything worked fine.
Hmmm 2003 was pretty good for me. (or was it 2002?) I was one of the first people who did a wget on the Fedora 1.0 iso download link on freenode/#fedora
Hippie nonsense like an npm install not installing any keylogger with arbitrary internet access without even trying? Or multiple screens with different resolutions?
I've had multiple screens with different resolutions in xorg since 2008 (one laptop, one monitor setup). How is npm even related? Are you just generating responses?
What kind of security does your typical linux desktop has? I help you, basically none.
Something as “benign” as an npm install could do basically anything on your computer, besides installing a video card driver (as per the old xkcd, but nothing improved since). At least wayland took a new approach that is not as naive as the previous millenium’s stance on security.
I'm really not understanding how npm security is related to wayland security. Do you mean sending everything through dbus in plain text format? Yes, wayland wet the bed on that one.
If npm is the only thing you know and want to talk about, and you have no idea what the security weaknesses introduced by wayland or xorg are, maybe do it in another thread?
Npm is a random executable that happens to be common. It can run arbitrary code and linux userspace is basically beyond useless in securing anything meaningful about itself. That Documents/FamilyPhotos album? Completely read-writable, I can just send the whole content to any IP address. One might say that you can run it in firejail or so, but noone does it.
But here comes the graphics-related problem: even with firejail, any X program has basically unrestricted access to your whole screen and every key event without any form of security. This is basically unsolvable without nesting x sessions, or.. throwing away the whole of X and starting afresh with better primitives, a la wayland.
Yes that's all well and good, but What "security primitives" in wayland are you even typing about? The main author basically admits in every forum and discussion that there is nothing to do if your system is compromised.
> Discord screen share did not work at all. I guess the official app doesn’t support wayland.
This will probably get fixed somewhat soon. We have a branch with some work to improve screenshare on Linux, including xdg-desktop-portal support (via the implementation in webrtc), but it needs some more work before it's ready to merge and deploy. Unfortunately, the Wayland experience will still be worse than X11 when this lands because this branch also brings audio share to X11. We wanted to do the same for Wayland, but xdg-desktop-portal has no audio support and doesn't provide enough information to find the right audio source via pulse/pipewire manually.
Search with Google for "NVidia 525 driver not installing Ubuntu" for the sorry tale of NVidia 525 vs. Ubuntu and Mint. There's a dependency problem and the install fails. There is much discussion of workarounds. If you try this using the "additional drivers" GUI program, you get a dialog box with a big X and an "OK" button, but no message.
If you want to run Wayland on NVidia hardware, you need to be heavily into Linux system administration.
We do support for a commercial Linux desktop program that gets primarily run on Windows clients. We use VcXsrv (a X-Server for Windows) for that.
I'm wondering, is it/will it be possible to forward a Wayland program like you can a X11 program? Or will we have to go back to NX/X2Go/VNC/RDP solutions and login to a whole desktop environment?
You aren't going to get better than streaming compressed video with any modern toolkit, since the rendering happens in the app and it's just about moving pixels going over the network.
Nobody uses just one computer anymore, and software rendering plus a codec is a poor use of shared datacenter hardware. We’re going to end up with Javascript or Wasm as the accelerated remote rendering API unless someone delivers something more appropriate.
X11 is mostly stable though. With Wayland on Fedora/GNOME or KDE a crash or two once in a while is still pretty much something you expect. Hopefully it gets better in less than 20 years :)
It's nice that it works for the two of you. But without actual crash statistics this isn't particularly useful. (To be fair: neither is the top-level post.)
Gnome 3 also didn’t crash on me for years. But as always these flamewary threads that dare mention the few forbidden words (wayland, systemd, etc) are always full of anecdotal evidences and emotions post-rationalized into some “argument”.
Touchpad gestures on X11 suck, though. There are hacky workarounds (background software that send special key combos after recognizing a gesture) but there's nothing like a three or four finger drag in X11.
After trying Wayland on my laptop once, I never wanted to go back to X11. Sadly, I made the mistake of buying Nvidia hardware, but I look forward to using Wayland without bugs.
I find touchpad gestures to be a mess on both X11 and Wayland. This is one of the main reasons I don't use Linux on my laptop. Gestures aren't recognized reliably or frequently they just stop working at all. Plus there isn't consistent support for gestures across applications which although not a X11 or Wayland issue is still irritating. Everytime there is a new round of major distro releases I try them. Everytime I go back to Windows because of the gestures issue and poor battery life. The battery life being the main issue. I'll probably not try anymore because neither seems to get better.
I don't know what DE you're using, but on Gnome multitouch support worked out of the box the moment I logged in with Wayland enabled. Pinch to zoom worked in most apps (in my browser, in the picture viewer, and in the Maps app, which are the only places I ever bothered to look for it) and horizontal/vertical scrolling worked a lot smoother than on X11 across the board.
Your trackpad does need to be supported, though. Trackpads without Linux driver support will report to the kernel as if they're PS/2 mice with weird side effects, and those will never work well. If your trackpad has decent driver support (many Synaptic models, for example, though not all) then every single touch is being forwarded to the OS and gestures should work like they do on Windows.
Funnily enough, Windows battery life is a lot worse on my laptop than Linux battery life. I don't know what intern Lenovo had design the fan curves and power settings for this laptop, but I have the choice between "30fps desktop" and "sounds like a fan taking off" whenever I use Windows. I have my suspicions that Linux doesn't boost the CPU as much as Windows does, but honestly I don't need it to stick to its max boost all that often anyway.
My laptop is also a Thinkpad. My experience is the opposite of yours. A plain install of either Fedora or Ubuntu leaves me with about 40% of the battery life on Windows and a much busier fan. Tweaking gets me up to about 50% of the Windows battery.
The synaptics trackpad in my laptop has driver support. Gnome gestures are enabled at install but the trackpad multi-finger swipe gestures are detected erratically and then often stop working until I logout and back in. I assume this is a software issue since rebooting the device is not required. The linux version of my browser doesn't have any gesture support.
I crash constantly on Wayland and I can't talk about it or get help to fix it, because like all Linux problems, it all comes back to somehow being my fault, as all Linux issues are the fault of the user.
As long as desktop Linux's problems keep getting blamed on the user, it will never achieve wider adoption.
Wayland can't crash, it's a protocol. That's like saying "http" crashed. Chrome or Firefox can crash, but not http. Gnome and KDE are Wayland implementations. I'm using SwayWM which uses wlroots as its Wayland implementation and it's solid as a rock.
You either understood the point and purposely ignored it or just missed it completely. The parent reply clearly means support for wayland, not the protocol.
Being pendantic about the definition doesn't help the discussion at all. It is the type of response you would get on the red website
I read it again and it does not seem obvious that they were talking about apps rather than the WM itself. Please explain to me where that's made clear.
I agree, but I'm curious what the "red website" is? I thought maybe reddit or lobste.rs, but they seem more blue to me. Unless because their logos/favicons are red? Seriously not trying to be annoying, generally curious.
I meant the literal color, too! I guess the new website does have some reddish elements. The old one was entirely blue [1], and I'm pretty sure "reddit" is just a play on "read it".
Ah, full circle, back to being uselessly pedantic. :) But I was really curious, didn't know "red website" was slang for it (well familiar with "orange website").
I guess that raises an interesting point. The implementations are so divergent that there are probably a lot of very different crashing bugs in all the various pieces that can make a Wayland desktop. As opposed to Xorg, where bugs can be fixed in a single tree.
I'd just like to interject for a moment. What you're referring to as Linux, is in fact, GNU/Linux, or as I've recently taken to calling it, GNU plus Linux...
I used to find this funny but having had the misfortune of having to hyper define stuff to Stallman on multiple occasions... the joke starts to feel like remembering a lite trauma
I mean RMS is cool and totally awesome but dang it... there are just some things. This goes for everyone I guess.
I agree. Switching from glibc + coreutils to musl + busybox is much more like "switching operating system" than switching from Linux + systemd + GNOME to HURD + SysVInit + KDE.
Obviously not. GNU hasn't been "the operating system" in at least several decades.
Dude the "OS API", in the Linux world, is the syscall interface. Some programs use the wrappers provided by GNU libc, others use the wrappers provided by musl, others yet (such as Go programs) issue syscalls directly.
Hopefully they will one day use my zero-overhead syscall wrappers with sum type niche-value-optimized error handling
https://github.com/Cons-Cat/libCat
I used sway for a bit back in 2019 on a dated laptop with Nvidia card, I was actually impressed how performant it was compared to Gnome. I remember tiling browser windows + complex apps, some terminals and DotA2 while waiting for matchmaking so IMO I was throwing a lot at it, but things kept working and running smoothly, it would react instantly to any tiling hotkeys, fullscreen toggle, no matter how much I was messing with it. On Windows programs would become unresponsive after 1/10 of such treatment.
There was one dealbreaker though; random rare crashes which would reset my workspace that I couldn't narrow down to anything. This + not being in the mood to write my own DE from scratch (configs) made me ditch it. But it is tempting to go back to it once in a while given how much time had passed - if it was available for Mac, I would very very likely reconsider, otherwise it just adds more fragmentation between Mac/Linux.
Sway supports anything the kernel supports. The kernel supports any video card that implements their APIs. Nvidia doesn’t do the latter, so blame them.
Problem is always with software having good support for these "newer" protocols. Most just seem to test and develop against X11.
In general, it would be great to have more first-class support for Linux from many major software developers (in my opinion, Valve is a pretty good leader in this area). Linux always feels like second class citizen that you need go in manually tweak and fix something to make it work (thankfully, there is plenty of info to do it but it is still a hassle).
> Primarily, what I’ve learned is that Wayland is actually really well-designed. The writing is on the wall for X, and Wayland really is the future.
Hmm. The first sentence does not imply the second is true. I wonder what it would take to see widespread adoption of a new windowing system. Quite a lot, I would imagine.
I certainly have some complaints with Wayland's design, but I'm curious what you would remark as dealbreakers here. As someone intimately familiar with both X11 and Wayland (and used to maintain stacks for both), Wayland is a real improvement along many axes.
to Wayland, when executed from a non-ARM machine running a X server (respectively Wayland server) with a unknown compositor[2], without `my-wayland-c-program` loading any compositor-specific code or resources (and preferably being statically linked[1], although statically linking xlib is admittedly also a pain in the ass[3]).
Things that are the responsibilty of the window manager, such as the title bar, close window button, and alt-space menu, need to work correctly on any compositor that supports them, without the application running any code related to those things.
If it was just having to run everything on the same machine, wayland would have to have conspicuously significant advantages (of which it has roughly none) to be worth the loss in functionality. Adding on per-compositor special-casing - especially when the suggested 'fix' is apparently for me to link per-compositor shitware into my applications to allegedly abstract away that special casing - means Wayland needs to die in a fire.
0: Regarding ssh -Y: yes, the lack of security-distrust between two pieces of hardware right in front of me, that I nominally trust and control, is intentional.
1: ie `file my-wayland-c-program` prints (emphasis added):
2: "unknown" as in the application doesn't know, and isn't going to find out, because it doesn't matter unless the application is `wl-print-compositor-name` or similar.
The second the steam client drops its 32bit legacy code and finally has a wayland backend, I start to code my wayland compositor (probably based on the drm/vulkan one from valve deck).
That said, be careful, one of the big mistakes from x11 was those bazillions of libs with their quite not stable ABI/API to deal with, the wlroots lib from this article _must_ stay private/static for a wayland program!
Does it have hardware cursor support yet? My last experience was unusable for mouse-centric use, like treacle compared to Windows or X11. Windows has proven you can have all these nice things in a low latency environment
Each implementation of Wayland is its own beast (called a "compositor"). Sure there is a libwayland they all share, but all the implementation details are up to the compositor. The idea of a cursor being hardware or software is not a fundamental part of Wayland as far as I can tell. Hardware cursors are supported in wlroots.
You've just started me down a rabbit hole of reading, I'm so confused now that there is even the idea of a 'hardware cursor' of an idea so clearly implemented in software.
It popped up first some time in the 90s (or at least that's when I first became aware of it), long before any "3D accelerators" or similar became available.
Telling a graphics card "here's a bitmap, please render it at these coordinates, over the framebuffer content" is so much easier and more efficient than, in the earlier days, rendering a cursor into the framebuffer (and then undoing that for the next frame), at the rate where this needs to happen (pretty much every frame) to boot.
I don't know if in modern times, this could be reasonably achieved through compositing, but I suspect "here's the bitmap, render it here" is still easier, conceptually at least.
> of an idea so clearly implemented in software.
As an aside, many hardware things are ideas that could be clearly implemented in software.
Yeah, it's the "reasonably" part that I wasn't sure of. At the end of the day, just updating the coordinates in some hardware registers to effectively move the cursor still sounds much simpler (and with more potential for efficiency, as the graphics card can decide how to do it) to me, yeah.
The cursor has to be rendered outside the normal graphics pipeline to feel responsive. To match it you would need to render the desktop at 2x or so the mouse polling rate (like 2000 fps or so for a good mouse)
1: Mouse polling rate needs to be higher than rendering rate and and NOT the other way around. The higher the better because it guarantees that there is less of a delay between the latest sample from the mouse and the time the mouse cursor is rendered. (There are plenty of articles about how to minimize latency for fighting games by going from triple to double buffering and sampling just at the start of the "double" rendering phase)
2: Hardware cursors of old were akin to sprite hardware on consoles, here the hardware did compositing (or pre-compositing) operations on a per-line basis just before sending the frame contents to the display.
On platforms like the C64 you only had 8 sprites in hardware but if you tuned your code to race the display processor you could have more by updating the sprite positions to lines below (so still limited to 8 per line but non-overlapped it was possible to have more).
3: Looking at WDDM there seems to be 2 ways cursors could be handled, either Windows uses overlays under the hood for the cursor (if overlays support operations like alpha-blending automatically) or the compositor pre-empts the GPU when it's time for an display update, modern GPU's are fast enough that compositing operations should be able to finish quickly enough to meet frame-times but if done off-screen for safety it could be producing an extra frame of latency. Regardless the GPUs should be fast enough today to make it happen whenever needed even if not using the classic ways.
Right but say the mouse is a constant 1000hz. To get the most recent sample on the screen as quickly as possible you either need the entire rendering pipeline to run ridiculously fast (the 2000 fps example), render just in time before vsync with impossible accuracy, or bypass as many clocks and buffers as possible and blit the cursor with hardware magic. There’s a reason it’s still done this way after so many years of advancement
I don’t think it’s true. I have written a toy compositor where I didn’t bother with a separate hardware plane for the cursor and it was snappy as hell at 60fps.
The frame could be generated several ms after the mouse movement occurred
You can sort of solve it by ensuring the frame is generated (or at least the cursor added to it) just in time for vsync (ie as late as possible) but it won’t be as good as a traditional hardware cursor
Well, your cursor would otherwise constantly damage every buffer underneath it, demanding constant redraws just from moving the mouse across. If you have 2 hardware planes and simply composite one over the other at the hardware level, this won’t happen.
If you ever had the “fortune” to get a kernel that is brokenly busy, you might have seen a completely irresponsive static image, but the cursor might still move. This is also due to this.
Last time I tried Wayland I still had these issues:
- Windows can't position themselves, this is seriously annoying for apps with lots of utility windows.
- Apps can't change the display refresh rate, which means I can't watch movies on my TV without stutter.
- GNOME sometimes crashes for me on Wayland, taking the whole session with it. I also can't restart Mutter to reload extensions, which makes developing them (to work around Wayland shortcomings, ironically) a pain in the butt.
I use it but screen sharing is still a bear. I can't get it to work with Slack at all - (this is on the flatpak release of Slack 4.32.127)
It's good enough though that I'm just kind of working around it - always hoping that some update to Sway or Flatpak or some tweak with Flatseal will fix the issue. Hasn't yet though.
But I would strongly urge anyone from switching to it unless you have nostalgia about the bug-ridden nature of the 2010-era Linux Desktop.
I’m still using it, by the way, with Hyprland, but I think I’ll be switching back to X11/i3 soon. Here’s a taste of my experience thus far.
Electron apps are a mess. This isn’t (all) wayland’s fault but for issue lists like https://github.com/electron/electron/issues?q=is%3Aissue+is%... to exist, proponents of wayland would find it in their best interest to tackle the problems given the large number of applications that use electron.
Screen sharing doesn’t work. All the old fixes are to be ignored - it has regressed. Again. Font sizes are screwy. VSCode simply doesn’t work. The handy slack shortcuts like ctrl+shift+space for mute that work anywhere only work when slack is focused on Wayland.
If you have multiple monitors of different scaling factors, moving a window from one to the other results in it becoming unbearably blurry.
wl-clipboard and vim with clipboard=unnamedplus (the only reasonable clipboard) simply don’t work well together, and have a history of bugs going back for FOUR YEARS. At the moment, holding down x or d for repeated deletes is INSANELY slow. As in, I’m used to it working at my repeat rate of ~60 deletes per second and it barely does 3.
Every now and then, my cursor becomes huge. Every now and then, it becomes tiny. No idea why, and I’m afraid to ask.
There’s a subtlety here. Something can still have a few bugs without being bug ridden. It’s the difference between a puddle and a flood.
X11 with i3, the setup I’ve used for years, is not bug ridden. There are quirks, but nothing fundamental, nothing that makes it a bad user experience.
Wayland, on the other hand, has been a dreadful experience. Some of the most fundamental things, like cursor rendering, window rendering, multiple monitors, clipboard, all have problems doing the basics.
To be clear, this is what I actually expected. My disappointment is that people have been preaching about Wayland for years, pushing a stronger and stronger line that it is fantastic, has great support, and is ready to switch to now. That just isn’t the case.
> Wayland, on the other hand, has been a dreadful experience
That sentence is literally meaningless. What wayland? It is still a protocol. Is “the web” bug ridden? Or http? No. A browser can be. So let’s talk about sway or gnome or whatever specifics, otherwise we will just continue to type into the air.
Hyprland, which I believe is based on Sway but I’m not sure.
Either way, most of the problems I’ve been having do not seem to be implementation specific, and instead stem from buggy usage of the protocol. It’s no secret that Electron’s wayland support is an ongoing problem, for instance.
That’s an ultra niche compositor, so I don’t think it’s fair to conclude anything about the wider protocol. Also, there is a difference between higher level things not working, and something as basic as cursor/window rendering not working - the latter is absolutely stable and working fine since forever.
Electron apps seems to generally work pretty well now with correct arguments, but somehow got glitchy when I attempt to snap them to left/right grid in gnome. I have a wide monitor so this drives me nut.
Recently, games performance on wayland seems to regress, either framerates get cut in half, or previously working games suddenly full of graphical issues. Probably nvidia's fault again. I'll see if nvidia 535 driver fixed that.
Unfortunately the whole Linux display thing has rather confounded searches about the town. Any open source contributors who live here are probably mildly annoyed.
Why don't then name projects the way Amazon sellers name products, with a semi-random agglomeration of letters instead of taking a perfectly sensible name that is already in use. Would you call your display driver brooklyn?
I propose a committee that allocates sets of random letters on a first-come-first-serve basis. That way, we will not suffer the undue burden of having multiple names for things.
The name of this committee shall be 'mvphjguq'. Not only is the name unlikely to collide with any existing place names, it is nigh unpronounceable! And because it is only 8 letters long, it is easy to remember, while also having a 1 in 26^8 chance of having a collision with another randomly generated value (although we can check for collisions before dispensing new names).
It was literally named that way because the guy who created it had the enlightening idea for the protocol on that very road.
We only have so many easily pronounceable, short syllable-combinations, if all we do is moan about that, that’s not really useful.. there are bad names, like completely unsearchable, or copying the name of an alternative project in a very similar niche.
We used to have cool names like gaim or something. Then stupid trademarks started going after names whose substrings matched the trademark and no-one wanting to avoid a heartattack chose again original names.
