Wayland is pretty good
serebit.com
serebit.com
Apart from that, Wayland is very opinionated, it's basically intended to cater to 70% of users, while flipping off the rest.
... 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.
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.
And here is the relevant ongoing proposal https://gitlab.freedesktop.org/wayland/wayland-protocols/-/m...
In any case, track the spec progress here: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/m...
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.)
I did see one of the long-standing developers wondering whether it would have been better-received if they'd called it X12 :P.
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.
Similarly, if I go to this page: https://cameratico.com/tools/web-browser-color-management-te... in X, the ProPhoto and sRGB strips look different. In Wayland, they look exactly the same (in the monitor's native color gamut).
X is definitely more capable than Wayland is, at least with Chrome.
* Getting the display scale just right. I have a 3k by 2k laptop screen. 1x is too small and 2x is too big.
* Getting the mouse cursor to be drawn at a consistent size. Now the size varies when you move it across windows which is unacceptable.
Am I missing something? Both of these seem like basic issues that someone must have figured out a solution to.
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.
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.
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.
#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
xrandr --output DP-2 --scale 0.6x0.6X11/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).
`xrandr --dpi 160/DP-2` doesn't seem to do anything for me.
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.
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.
xmms worked fine after installing.
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.
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?
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.
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.
[1] https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1968929
[2] https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/2020249
[3] https://bugs.launchpad.net/ubuntu/+bugs?field.tag=nvidia-way...
Filed two bug reports. Back to Xorg.
Back to Xorg for now.
If you want to run Wayland on NVidia hardware, you need to be heavily into Linux system administration.
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?
Microsoft has some wayland stuff already for WSL, though I think internally there's RDP involved: https://github.com/microsoft/wslg
Yeah then I guess you're in the land of either waypipe or RDP/VNC/etc.
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.
The chance that I will use another WM any time soon is absolutely low.
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.
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.
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.
As long as desktop Linux's problems keep getting blamed on the user, it will never achieve wider adoption.
Surely you can’t expect some paid support level help for free from someone who works on it in his/her free time.
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
The orange website and the red website are popular slang that you hear around here from time to time
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").
A Google search for "the orange website" returns a lot of results about Hacker News, "the red website" doesn't return anything about Reddit.
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 mean RMS is cool and totally awesome but dang it... there are just some things. This goes for everyone I guess.
Obviously not. GNU hasn't been "the operating system" in at least several decades.
Alot of digging is needed to get nvidia accelerating / mouse cursor to work and performance is not comparable to X11 atm from my experience.
I haven't bought an nvidia powered device since 2007 and am using amd exclusively since 2011. No regrets. Open source drivers rock!
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.
And btw DotA2 had more FPS than on Windows :)
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).
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'm not sure how to properly and (edit: semi-)concisely explain the problem except by example:
How do I translate[0]:
$ ssh -Y raspberry-pi-on-null-model-cable ~/bin/my-x11-c-program
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):
ELF 32-bit LSB executable, ARM, version 1 (SYSV), [*]statically linked, stripped[*]
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!
sad to see another linux api design failure
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.
Evidently it can, as Wayland does it, but the result is pretty mediocre.
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.
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
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.
- 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.
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.
Basically, it’s not a comfortable experience.
So where is the non-bug-ridden version from any year? I would like to try.
While you are at it, I would also be interested in any GUI, other OS DE, whatever that is bug-free because I have yet to see one.
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.
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.
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.
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.
Only problem left is: no browser docks in obs due to cef upstream.
https://www.niche.com/places-to-live/wayland-middlesex-ma/ra...
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?
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).
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.
But otherwise, free game.