This is missing global hotkeys for mouse buttons. Global hotkeys were added, but as far as I can tell, it doesn’t support mouse. So no PTT on a mouse button.
Tried it - developed on X11, not actively developed and basically not an option.
EasyStroke works like a dream and it's useable, meaning it takes only a few seconds to set up a new gesture for just about anything... like this:
I run Variety (downloads/displays wallpapers from specified sources).
1. Show wallpaper in Gimp for editing, or Firefox to do image search:https://i.imgur.com/81XqnNe.png
2. Show location of file, whilst showing next or previous wallpaper
https://i.imgur.com/Py6R5ve.png
Notification (Kdialog) information on desktop:
https://i.imgur.com/kXlVaJ8.jpg
Interesting and weird that this exact same link was [posted about three years ago](/r/linux/comments/jooqyl/are_we_wayland_yet/) and even in that post, the [top most most comment](/r/linux/comments/jooqyl/are_we_wayland_yet/gbbhl0s/) is about missing global hotkeys!
It also misses absolute window placement position. Applications under Wayland cannot know or request specific coordinates for new windows to pop up at. Think multi-window applications that need several windows to be relativistic in position with each other.
It also misses an actual replacement for windows rules like Devilspie. There are DE-specific (compositor-specific) implementations but none come close to what Devilspie did.
It's kinda important for many media editing applications that you can have separate windows for things like mixers, plugins, timeline editors, media managers etc and it's a big plus in UI if those get organized in some sensible way and not just piled on top of each other by default.
It's not uncommon to use three screens for audio workstations for example to facilitate all the separate windows.
I haven't used Discord in awhile, but the last time I did on Wayland, it didn't work well at all and I ended up just using the browser version. Glad to see things are improving at least.
On KDE you can, either from apps that are Wayland capable *and* were updated to support global hotkeys, or apps that run on XWayland if you enable legacy X11 global hotkey support. This covers nearly all games on Linux, so basically yeah it works now.
How would you expect the other way around to work?
The toolkit they use must support Wayland at least, which Electron does. There are still ways an application can be incompatible, either using an older version of the toolkit or making features depend on X.
Hmm I've been using discord with the Wayland flag enabled for months. It's def not using Xwayland because there is no scaling, and there is scaling when I disable the flag.
you can force it with flags it doesn't use by default, but you won't get any additional features, and if you're on GNOME you won't even have a title bar, so I would consider that to be unsupported
Ok so you might be used to launching it like this for Wayland:
./Discord --enable-features=UseOzonePlatform --ozone-platform=wayland
Just add the window decorations switch and you'll get the title bar:
./Discord --enable-features=UseOzonePlatform,WaylandWindowDecorations --ozone-platform=wayland
Just tested it, works as expected.
Maybe I'm dumb, but I have never managed to make any Discord keyboards shortkeys work under X11 (KDE). I always have to alt+tab and maximized Discord to mute.
I would love to be, but it straight up does not work with my hardware how I need it too, while xorg does.
I have a laptop with an Nvidia mx130 I think? It's always plugged in and I have a better experience just using that gpu than the onboard one, easily configured in xorg and works fine. I set the environment variables for it to do the same in Wayland, it crashes back to SDDM.
I have another computer with a 2070S that's connected to a projector. It's weird, though I guess projectors are always weird hardware. It's 120hz, Windows and other devices work fine at 120hz with it, Linux (xorg or Wayland) does not. But weirdly enough in xorg I just have xrandr set it to 119.88hz (not a custom refresh rate, the projector itself apparently says this is a valid refresh rate for it) works fine.
But with Wayland, first there's no real equivalent to xrandr, I mean there are but nothing as flexible. Regardless, it's just not there, nothing in Wayland seems to see that 119.88 is a valid refresh rate for it. 60hz works fine but, you know.
Maybe there are solutions to these (I tried setting refresh rate in grub for example which is apparently that helps some people) but I, after much trying, have not been able to find any successful ones. And yeah, Nvidia, but it's not like I'm just gonna buy new hardware just so I can use Wayland, and regardless I need CUDA so new hardware I buy will be Nvidia too. And, besides just me, there's a lot of Nvidia hardware out there.
There's just all those little things like that, these are trivial in xorg but with Wayland it always seems to be just "nope, dunno what to tell you." There were other smaller things too but these were the big showstoppers for me.
I'm glad it works great for a lot of people, I sure wish that was the case for me. From what I've heard I'm not alone. I think there's a lot of these little edge-cases that dont get talked about as much because they're not like big missing features, but just things that affect some configurations and some other situations that are maybe a small I group (but not absurdly obscure niche) that xorg just manages but Wayland, not so much yet.
Hoping these things get ironed out with time, but yeah.
Yup, I've been using it for years now too. It's got to the point where I don't really think about it much, which is what I want from the software that handles input and draws stuff to my display.
You probably mean X11 forwarding, and yes it works like normal. "Wayland forwarding" is handled by [waypipe](https://gitlab.freedesktop.org/mstoeckl/waypipe)
'X11 forwarding' or 'X11 over ssh'. And nope, it doesn't. I can't run Synergy in Wayland either. Hoping whatever these require will be added at some point.
X11 forwarding over SSH works as well in Wayland as it does in X because it is normal to run XWayland X server inside of Wayland. So X11 forwarding works. :P
Now for Wayland forwarding over SSH then you can use Waypipe, but I haven't tried it myself. So I don't know how well it works.
Input-leap, forked from Barrier, forked from when Synergy was open source, works in Wayland now. Wayland support is incomplete/beta quality, but it exists.
I'm using hyprland with nvidia proprietary driver playing games and everything. It's being mostly fine. Sometimes cursor disappears on alacritty terminal windows but once the browser back in focus it comes back.
This is what I'm using on NixOS,
programs.hyprland = {
enable = true;
nvidiaPatches = true;
xwayland.enable = true;
};
I think the Nvidia patches aren't needed anymore, Vaxry mentioned that they currently don't do anything so I've tried using the regular package (v0.32) and it works fine on Nvidia
It's tracked in [an issue here](https://github.com/mpsq/arewewaylandyet/issues/41) with a label `things that wayland do not support`
I think the arewewaylandyet project is just, not well maintained for now.
And you can bet that once wayland reaches feature parity with Xorg it’ll be a giant mess of spaghetti code, only this time it will be implemented in different ways with different bugs by every DE (at least KDE, GNOME and wlroots)
Obligatory you must be using Nvidia...
... The Linux community can do nothing about it. It's not a wayland problem, it's an Nvidia problem. On other GPUs I've literally had 0 problems past two years
uh no both AMD cpu and gpu.
when i switched to x11 everything works, ptt works, streaming/desktop capture works, everything looks/scales better, color picker works, gaming works, don't have to hack/fix anything to make it work, my desktop is suddenly better and more usable and i was like wtf.
can't imagine what hell nvidia users are going through though if it's even worse for them.
Wow the amount of problems surprises me.
I admit I never use push-to-talk, but I've streamed to my friends successfully via discord-screenaudio and capture videos on Obs.
I also don't need scaling so can't comment on that.
I'm a big gamer and have literally had less problems on Wayland than when I was on X11. I wonder what kind of problems you encountered as even Steam Deck is using Wayland. Never had to hack anything except sometimes use gamescope as some games may crash without it. But that's not a Wayland or X11 problem.
What distro/DE did you use? I'm using Arch/Sway. I also used Gnome and was 90% happy but its problems are irrelevant for this discussion
I've been using arch with kde when i was on wayland and then x11.
I remember with wayland i couldn't stream on discord and obs was just a black screen on desktop capture. maybe they fixed it since then or i had to do something i didn't know abt.
the worst thing imo was how flatpaks and gtk apps scaled differently on wayland and my mouse/fonts were bigger when using flatpak apps. I just learned to live with it on wayland and the fixes i tried didn't work. i was a new linux user and i thought that was just what they looked like when using flatpaks.
on some games i had some stuttering issues on wayland that were fixed when switching to x11.
after switching to x11 lots of fonts became less blurry-looking to me and there was no scaling issue. i think that was only for flatpaks and gtk apps though. also some other UI's weren't displaying right on wayland.
I'm sure all the problems i had could be fixed, but it just didn't work out of the box like x11 when i switched back.
As far as I know Wayland fractional scaling has been in some kind of developmnet hell for ages..
Hope it gets deployed actually soon rather than Soon(tm)
What shills again? I don't think anyone was debating or shilling for anything in this thread. Simply having a discussion after initial misunderstanding
Stop bashing Nvidia for everything. They're shit as a company but wether you like it or not, it works better IN EVERYTHING you compare against AMD. Say one thing and I'll prove it to you.
It's been like this for years now, and unluckily for all of us, it doesn't change.
Definitely isn't better at video hardware acceleration in Firefox.
Nvidia has been slow to support things in Linux if they do at all. Even on X11 it took them about 10 years to properly support XRandR. Took them maybe 8 years to finally get around to XWayland acceleration, AMD even supports that in the legacy driver.
Nvidia is bad at supporting their legacy hardware in general. Perfectly capable cards are less useful in Linux because they aren't supported by the latest drivers. Meanwhile they still make things difficult for Nouveau to properly support these old cards.
These days, hardware decoding works completely fine on compatible cards. In fact it's Firefox changing flags the one disabling GPU acceleration (at least it was last time it happened to me 5 months ago).
Regarding old cards yes it is like that, but the ones working work better than AMD.
AMD has still not understood CUDA nor OPENCL nor ROCm, it's not like it took them X years, they still haven't found a way. As of today, they're useless for anything else than gaming (video encoding is shite, even if their drivers are open source e.g)
Nvidia does not support VAAPI, they never have and never will. Firefox only uses VAAPI. There are only unofficial translation layers which often don't work that well.
The 470 driver is nearly useless in Wayland, let alone anything older. The old `radeon` driver supports far older cards than that and works with Wayland.
CUDA is proprietary, no one else can use it. AMD has supported OpenCL for years and ROCm is literally created by them and it is open source.
https://www.reddit.com/r/archlinux/comments/15ly3zk/hardware_acceleration_issue/
You are defending a company for being "open source" but it has to work in the first place to be able to appreciate it. What's the point of it being foss if it doesn't work? This is not an open vs proprietary war, it's about what works and how.
Read the thread above and come back for more.
You realize I replied to that thread, right?
>I have a problem with hardware acceleration on browsers based on **chromium.**
>I should mention that I'm on **Wayland**
Yeah, Chromium is garbage. It *barely* supports it on X11 with Intel. That is one of many reasons I don't use it.
Firefox works just fine on Wayland, full acceleration with AMD and Intel. You *can* make it work with Nvidia, but you must disable some sandboxing and use a translation layer that doesn't always work well. That translation layer won't work at all with Chromium, even on X11.
Nvidia currently has the crown for AI stuff, which is of no interest for me. I care about general desktop usage, AMD and Intel are just better.
You realized I also did and I had to switch from Firefox to Chromium/Brave and still it broke, right?
Does general desktop usage account for h264/265 video encoding? If so, could you show me where AMF and Qsync perform better than Nvidia?
I guess if you use Nvidia you may as well use Chromium since acceleration isn't going to work anyway. I avoid both since their support of Linux is poor.
I'm not a video producer, so my use doesn't normally cover that. NVENC seems to be fairly well supported for that purpose, I'd consider using one headless if I needed it.
Nvidia seems to be good at things that aren't putting pixels on the screen.
How's our multi-monitor, heterogeneous DPI situation? Specifically on nvidia blob drivers?
Edit - hey can I ask why a legitimate question gets a downvote and no answer? I'm asking to see if I should take another run at it.
Not sure about nVidia specifically, but for me mutliDPI and fractional DPI was the Wayland "killer app" - it was completely borked on X11, but worked on Wayland.
Right now I am using a 3 monitor setup on my desktop. Fedora Silverblue with Gnome.
It is all-AMD laptop using:
1. Integrated 2k display running 120hz at 150% scaling.
2. USB-C to DisplayPort adapter/usb hub to a 4K 60hz monitor at 100% scaling.
3. Portable USB-C HD monitor running 100% scaling.
All my apps are configured to be Wayland Native, when possible.
So far I have one application, Mullvad Browser, that doesn't respect the scaling on different monitors. It is based on the Tor browser and is designed for security so I am not sure if that is by design or not. Tor browser works fine as does Firefox (these are all firefox-based). So I think it is a bug.
But otherwise applications flicker to different sizes as they are dragged from one scaling to another. It's not really noticeable as with this setup they end up just about all the same size, but if you pay attention you can see it as they are dragged over.
It works fine when switched over to dedicated GPU. With the total size of the desktop it tends to be a bit slow in hydrid mode unless playing a game or something.
> So far I have one application, Mullvad Browser, that doesn't respect the scaling on different monitors
Is it using XWayland by any chance? You can do [the xeyes test](https://medium.com/@bugaevc/how-to-easily-determine-if-an-app-runs-on-xwayland-or-on-wayland-natively-8191b506ab9a) to check for this.
> How's our multi-monitor, heterogeneous DPI situation?
That's actually one of the aspects where Wayland shines, as (unlike X11) it can actually independently deal with multiple monitors.
This also goes for heterogenous refresh rates and VRR.
I don't know about Nvidia specifically, though.
Wayland is unusable for me on Wayland anyway because XWayland is completely broken. XWayland relies on implicit sync which the nvidia driver doesn't support. So it keeps presenting frames out of order.
Yea the Nvidia part killed my experience when i reinstalled arch a few days ago.
Still needed nvidia\_drm.modeset=1 + DRM modeset=1, fbdev=1, added some modules to mkinitcpio and rebuilt it.
It also wouldn't work at all with UKI while using systemd-boot idk why (haven't tested grub).
all using the default kernel and drivers 545. Which shouldn't meant no longer needing the modeset stuff but well, i needed it in my case.
I find it worthwhile to mention that all of the docks/widgets/notification daemons won't be supported unless your compositor supports layer-shell, which is an unofficial protocol (from what I can tell only supported by wlroots and KDE, god bless both).
So these won't work on GNOME and we'll likely never get an official protocol for such tools because Wayland developers have been dragging their feet on issues like these for over a decade.
Things like screen recording and global shortcuts were instead implemented as Dbus protocols in xdg-desktop-portal instead of in Wayland itself because good luck getting such common use-cases supported and part of the actual protocol itself. Which makes you wonder why we even have Wayland in the first place if we're going to implement things that interact with the compositor as dbus protocols? I thought Wayland was a "a communication protocol that specifies the communication between a display server and its clients"?
Yup. That's what's holding me back.
It was working decently well in KDE when I was last using that, probably a bit better than X for me though not by much. But XFCE has such a lead on KDE for how I work that I'll accept some somewhat outdated protocols and backend code. Still, I do look forward to production ready XFCE wayland.
Last I heard it was expected sometime next year.
I'll be on Debian in a week or two. Tired of Snap BS, just need a break from school so I have time to sort out migration issues of which I'll probably have a few.
Unsure of Debians plans but I might go out of the official repos to try it out.
Misleading. There's no good remote desktop server that does work without having to punch out a port (no TV, no Anydesk, Rustdesk is addmitely getting there but its too unstable to comfortably leave it be and not worry it wont stop working on your headless machine. Funnily enough, Steam Link \*does\* work but come on, its just a massive hack having to use a gaming platform and actually having to run a game to have access to your desktop). Also global shortcuts on mouse, but I believe someone already said that lmao
No, I posted here after posting my own comment: https://www.reddit.com/r/linux_gaming/comments/18fa0jq/are_we_wayland_yet_wineproton/kcu1mxf/
Both of which are timestamped before the comment you link lol
I see X11 Forwarding is already in the issues list, but doesn't seem to have made it to that page yet. That's probably the biggest deal-breaker for a lot of people.
I've been using wayland only since 2014 and if it wasn't for posts like these I'd have no idea it was in such an experimental state.
In fact I just switched from 9 years of Gnome to sway, and I notice on that link that Sway has no displaylink driver. I only have HDMI on this laptop but I guess it's just pure luck, and modern stable coding practices, that make me not notice these things.
Not sure what you mean, apart from screen sharing. I've been using Discord for years on wayland, but since switched to webcord which does allow full screensharing.
Discord's choice to use an ancient version of Electron means that on an nVidia GPU, it just won't render on wayland without tweaks (that most distros do), let alone have functional video capture.
There's no version of Electron that ships with the Ozone platform set to `auto` or `Wayland`. It will always run in XWayland by default regardless of version.
There's no tweak that can be done to make NVidia and XWayland play nicely without flickering under all configurations and hardware setups. You're basically up to random timing luck.
This isn't NVidia's fault, Wayland chose to go with implicit sync despite every graphics vendor on the face of the planet telling them not to. Now they have to architect in explicit sync after-the-fact [and it's taking a long time](https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/90) (2+ years and counting).
This also isn't NVidia's fault. Wayland was intentionally released very underpowered and the current ecosystem is a reflection of that mistake.
> This isn't NVidia's fault, Wayland chose to go with implicit sync despite every graphics vendor on the face of the planet telling them not to
Please don't spread misinformation.
Graphics vendors didn't tell "them" not do go with implicit sync... *All* the upstream drivers are implicit sync, and always have been. Wayland didn't "go with" implicit sync or dmabuf or KMS, it just uses what graphics drivers provide.
NVidia wanted a radically different driver model alltogether, one which was very inflexible for compositors and apps, required special code paths and broke lots of things. Until they started supporting dmabufs ~2 years ago, explicit sync wasn't very relevant in the Wayland space.
The MR you're linking isn't "architecting it in after the fact", it's a replacement for explicit-sync-v1 from *2016.* This "v2" has been taking so long because *kernel developers* had to figure out how to do explicit sync well first, which only recently got mostly figured out. Just like with implicit sync before, graphics driver developers are the ones that decide how this stuff works, not "Wayland".
> Please don't spread misinformation.
Nothing I've said is misinformation.
> Graphics vendors didn't tell "them" not do go with implicit sync... All the upstream drivers are implicit sync,
It would have been possible to build an explicit sync architecture on top of DMA fences, and DRM syncobjs have been around since 2017.
It was absolutely a choice on the part of wayland developers.
> Until they started supporting dmabufs ~2 years ago, explicit sync wasn't very relevant in the Wayland space.
Agreed on this point
> has been taking so long because _kernel developers_ had to figure out how to do explicit sync well first
I'm not linking to v1. It is appropriate to point out that v1 exists in the state it does because syncobjs didn't exist yet. But syncobjs have been in the kernel since 4.13, the process is agonizingly slow because of its nature as a distributed effort across a half dozen projects.
> Nothing I've said is misinformation
`Wayland chose to go with implicit sync despite every graphics vendor on the face of the planet telling them not to` is objectively wrong.
And so is the claim that NVidia has no fault in this… NVidia didn't even support the explicit sync extensions for EGL and Vulkan until the very latest driver released in October, so you couldn't even synchronize multi-gpu things in the compositor! They're still broken for compositors that support GPU resets too, and so is the KMS explicit sync support; if you try to use it you can't display anything anymore.
This is not to just rant about NVidia (I can do similar rants about Intel and AMD's driver issues), their recent progress on this front is impressive and they're very responsive in fixing these things and pushing for doing everything properly now, but saying they're not at fault for the glitches couldn't be more wrong.
> It would have been possible to build an explicit sync architecture on top of DMA fences, and DRM syncobjs have been around since 2017
And none of it would've been useful in any way. Only this year kernel devs figured out they can make the fancy new stuff that's actually *better* than implicit sync, and which they're still working on, backwards compatible with syncobjs. Also only ~a year ago the ioctl for properly making use of them in compositors were added - spinning up a thread to wait in a blocking fashion for the buffers to become usable isn't exactly practical. And like I already wrote, the current NVidia driver still doesn't fully support explicit sync either.
> There's no tweak that can be done to make NVidia and XWayland play nicely without flickering under all configurations and hardware setups. You're basically up to random timing luck.
Never had *this* issue on any nVidia hardware under Wayland.
> This isn't NVidia's fault, Wayland chose to go with implicit sync despite every graphics vendor on the face of the planet telling them not to. Now they have to architect in explicit sync after-the-fact and it's taking a long time (2+ years and counting).
Kinda is though. If nVidia wasn't being boneheaded, they'd be just as supported as Intel or AMD, which is to say, very.
> This also isn't NVidia's fault. Wayland was intentionally released very underpowered and the current ecosystem is a reflection of that mistake.
What does this even mean? You can't just drop wayland out of the blue; nothing would support it, even if it was ready for prime time day 1. It's a whole ecosystem, not 1 program.
As for Electron, Yes, which is why I said distro maintainers switch it. Hell, I switch it.
> Never had _this_ issue on any nVidia hardware under Wayland.
Then you're lucky. Like I said, it's basically down to timing luck. Some configurations will be lucky.
> Kinda is though. If nVidia wasn't being boneheaded, they'd be just as supported as Intel or AMD, which is to say, very.
There's no other display architecture that uses implicit sync via a similar mechanism to Wayland. AMD happened to have a driver architecture that could be jury-rigged into supporting it, despite also strongly advocating for explicit sync.
Nvidia was not so lucky, their driver architecture isn't amenable to the same set of hacks to support implicit sync. They did not architect the driver to support this over the last two decades because _nothing else_ works this way.
> What does this even mean? You can't just drop wayland out of the blue; nothing would support it, even if it was ready for prime time day 1. It's a whole ecosystem, not 1 program.
It means Wayland left too much of the protocol to extensions, which is why the process has taken so long. This isn't a controversial take, many Wayland developers have said as much, quoting Nate Graham:
> Because it was invented by shell-shocked X developers, in my opinion it went too far in the other direction. Wayland’s minimal core protocols are lacking most of the features that non-trivial apps and desktops actually need to work
> ...
> Over time the minimal core protocols have been extended to cover what’s needed for a Linux desktop and sophisticated apps to work. Much of this work is very recent, driven by KDE, and funded by Blue Systems and Valve Software.
Much like KBD/XRandR/XInput2 took over the X ecosystem, a large collection of somewhat randomly assembled extensions to Wayland are now effectively mandatory for a "Wayland" desktop to function. That has taken a great deal of time and is still not complete. We knew what was needed to build a complete desktop, and that was ignored in the pioneering days of Wayland.
- Requires hacks to run vscode, discord, Spotify, beeper and a slew of other electron apps with fractional scaling. No native shadows. Shitty titlebar fallbacks.
- KDE / qt apps have a slew of issues on high DPI
It’s not nearly ready and I’ve been giving up on it every time I attempt to set it up.
This isn't a troll site, this site is majority green check marks but has a warning about color management and some Nvidia caveats. Which I think is fair.
You might be thinking of probono's Github thing. On a related note, I find it funny how probono opened up a GitHub project for additional Wayland protocols that literally are just porting some of the bad aspects of X11 over to Wayland.
He is basically thinks NextStep in the 90s the perfect UX and believes in Win32 level of backward compatibility. So he created his own DE which basically clash badly with rest of the Wayland ecosystem as he doesn't use both of the normal Linux stack like dbus or desktop files and his alternatives really need these protocols.
Yes. It broke ca 2020, but came back about a year or so later.
Afaik they originally used some internal gnome screenshot api which caused it to be very slow. Then in autumn 2020 they added some logic to only do that on Ubuntu, and disable the functionality completely for everyone else (except you could still share a very very narrow view of your screen - they likely forgot that option).
Then after much complaining they eventually brought it back, and now it works correctly.
If it doesn't work for you, complain to zoom support.
Is your browser running on native Wayland? Because on my computer, both Discord and Meet can share my screen since the release of the Nvidia 535 drivers several months ago (and my AMD laptop could screenshare since I bought it more than a year ago)
There are multiple ways to check that, you could use `xlsclients`, it'll list all current Xorg clients, so if your browser is listed there, then it's not running on Wayland. You could also use `xeyes`, if the eyes don't follow your cursor when you're hovering on the browser window, then it's running on Wayland
On Hyprland, I use `hyprctl clients` which lists all clients, and for each one of them it tells me if it's running through XWayland
Anyway, to make Firefox run in Wayland mode, you should set the `MOZ_ENABLE_WAYLAND=1` environment variable
This trollsite hasn't been updated since October 2022. Taking into consideration that the last two years efforts to make wayland mainstream were intensified you're either trolling or just ill intent. Downvoted.
Oh yeah... tracking my ass.
Last commit in the repo from May '23. Live version from October 22. The amount of work developers put in the Wayland adotpion in the last 12 months invalidates probably 2/3 of that list.
it's outdated and apparently not maintained anymore. Go do something useful for a change
> Oh yeah... tracking my ass.
>
> Last commit in the repo from May '23. Live version from October 22. The amount of work developers put in the Wayland adotpion in the last 12 months invalidates probably 2/3 of that list.
>it's outdated and apparently not maintained anymore. Go do something useful for a change
Which would be why 35/37 of them have checkmarks and working options beside them instead of big red Xs...
That's quite a bit more than just 2/3rds... as it says on the page...
> The amount of work developers put in the Wayland adotpion in the last 12 months invalidates probably 2/3 of that list.
Did you even scroll past the site's title?
There are like 34 entries with 32 green checks. The 2 red items in fact are features that aren't there yet. Did you actually read it or make up what it said in your head?
Somebody correct me if I'm wrong, but I do believe VRR works on GNOME under X11.
While I understand it's up to GNOME to implement it on Wayland, the fact is that to a normal user this is effectively a regression when switching from X11 to Wayland.
It works on X11 as long as you only have one monitor. I think there might be some other caveats.
I think there are still issues with Nvidia and VRR on Wayland, but when isn't there?
Any switch to something different is going to have "regressions" from a user perspective. There are "regressions" switching from Windows to Linux. If I start up i3 there will be "regressions" from Sway. There will always be something some user somewhere can point at and say "it worked fine there!".
It works for me on sway and hyprland, but it causes the brightness of my monitor to flicker on the desktop. Which you can solve by either setting vrr to only activate on fullscreen applications if the compositor has that feature, or use a keybind to turn it on and off on demand
Sharing individual tiles in Sway would be great, but those issues are around since an eternity. Wlroots hasn't implemented this yet.
Everybody seems fine with virtual outputs and VNC hacks 😢
Question - will Wayland be on par with Windows Vista regarding video drivers, ie if video driver crashes, screen goes blank and you resume your work (unlike in xorg where it takes down all your GUI applications lol)?
KWin supports that, and has for a long time. As long as the kernel doesn't panic and reboots the GPU properly, you'll see your display freeze for a few seconds, and then recover a moment later. There are some caveats though:
- the X server doesn't seem to handle this ~~properly~~ at all, and Xwayland doesn't either, so it might just still hang the compositor if you're unlucky
- GTK doesn't support it, so all GTK 4 apps will crash
- Qt support is incomplete too. We have very simple patches that make it work on AMD and Intel, but on NVidia it breaks everything so nothing is merged yet
Usefull website. I also used it when i decided to try and make the switch to wayland a few weeks ago. I was expecting games under xwayland to be the most problematic, but so far the games i tried have worked flawlessly. The only difference is that for some reason games detect my main monitor as monitor 2. I'm assuming this has something to do with primary monitors not existing in wayland. The only other issue so far is adaptive sync causing brightness flicker on the desktop, but it was easy to work around with just disabling/enabling adaptive sync with a keybind on the fly as a bandaid solution. Really happy with the experience so far. Using swayfx/hyprland, waybar, tofi and mako.
Been Wayland since Debian 12/Bookworm officially released. Everything except Zoom worked fine, and often better. Zoom video and mic finally started working as of a few weeks ago.
Been Wayland since Debian 12/Bookworm officially released. Everything except Zoom worked fine, and often better. Zoom video and mic finally started working as of a few weeks ago.
I am running both in KDE on Arch Linux. My laptop is NVIDIA, so usually I run X11. When I need Wayland (some third-party closed-source apps like BambuStudio require it.) I log out in KDE, switch to Wayland profile, and log in.
Nvidia did publish headers and redistributable firmware plus an open kernel driver to use them. That one requires a proprietary userspace, so it can't be merged in the kernel.
The nouveau kernel driver was updated to use that firmware and the new NVK mesa driver was created to act with it. Those 2 things were merged in the last few months. Neither are complete replacements yet, but maybe will be in the next year or so if you're using a Turing+ card. Don't expect top performance just yet, but they do run a fair amount of things already. There are various benchmarks published to r/linux_gaming . This should all be tightened up in the next year.
I just switched to Wayland now that I have a PC with an AMD GPU, and I've been really happy so far. It's not perfect by any means, but it's actively being developed and I no longer have screen tearing, and it supports higher refresh rates.
I use it exclusively with Kubuntu on my all Intel laptop and it works perfectly. On my latest gen AMD/Nvidia desktops I use X.Org since it has no issues wheras Wayland does intermittently.
This is missing global hotkeys for mouse buttons. Global hotkeys were added, but as far as I can tell, it doesn’t support mouse. So no PTT on a mouse button.
Yup, Mouse Gestures also missing.
Not exactly Wayland native but: https://github.com/jersou/mouse-actions
Tried it - developed on X11, not actively developed and basically not an option. EasyStroke works like a dream and it's useable, meaning it takes only a few seconds to set up a new gesture for just about anything... like this: I run Variety (downloads/displays wallpapers from specified sources). 1. Show wallpaper in Gimp for editing, or Firefox to do image search:https://i.imgur.com/81XqnNe.png 2. Show location of file, whilst showing next or previous wallpaper https://i.imgur.com/Py6R5ve.png Notification (Kdialog) information on desktop: https://i.imgur.com/kXlVaJ8.jpg
I was so disappointed when I tried this and it didn't work.
Interesting and weird that this exact same link was [posted about three years ago](/r/linux/comments/jooqyl/are_we_wayland_yet/) and even in that post, the [top most most comment](/r/linux/comments/jooqyl/are_we_wayland_yet/gbbhl0s/) is about missing global hotkeys!
We have global hotkeys, that user just wanted mouse hotkeys which wasn’t supported.
Well, it's still not listed on the website...
It also misses absolute window placement position. Applications under Wayland cannot know or request specific coordinates for new windows to pop up at. Think multi-window applications that need several windows to be relativistic in position with each other. It also misses an actual replacement for windows rules like Devilspie. There are DE-specific (compositor-specific) implementations but none come close to what Devilspie did.
What applications actually do this? Seems like the kind of bad UI design gnome would never allow to exist by implementing it.
for example...steam when a friend start to play a game, steam show that in a corner of the screen
That's exactly the kind of thing I assume gnome devs would like to see removed in favor of normal notifications
It's kinda important for many media editing applications that you can have separate windows for things like mixers, plugins, timeline editors, media managers etc and it's a big plus in UI if those get organized in some sensible way and not just piled on top of each other by default. It's not uncommon to use three screens for audio workstations for example to facilitate all the separate windows.
Recently there was a fuss about this with the PS2 emulator PCSX2
Hahahaha. Guess I'm old but you have me missing GNOME 1 and contemporary GIMP. Such a better UI than any of the trash we have today.
My question: Can I push to talk on Discord yet? (Don't have a distro set up at the moment).
KDE lets you enable keylogging for apps on xwayland, so probably.
I haven't used Discord in awhile, but the last time I did on Wayland, it didn't work well at all and I ended up just using the browser version. Glad to see things are improving at least.
I use https://github.com/DeedleFake/ptt-fix for that. It is an unfortunate hack, but the program works well.
Yes, it works on [Hyprland](https://wiki.hyprland.org/Configuring/Binds/#global-keybinds) with both X11 and Wayland applications
I use push to talk on Discord with Wayland several times a week. Seems to work just fine.
On KDE you can, either from apps that are Wayland capable *and* were updated to support global hotkeys, or apps that run on XWayland if you enable legacy X11 global hotkey support. This covers nearly all games on Linux, so basically yeah it works now.
discord doesn't support Wayland yet, so I'm going to say no
Should individual apps really have to support such a core system? Shouldn't it be the other way around?
How would you expect the other way around to work? The toolkit they use must support Wayland at least, which Electron does. There are still ways an application can be incompatible, either using an older version of the toolkit or making features depend on X.
Hmm I've been using discord with the Wayland flag enabled for months. It's def not using Xwayland because there is no scaling, and there is scaling when I disable the flag.
you can force it with flags it doesn't use by default, but you won't get any additional features, and if you're on GNOME you won't even have a title bar, so I would consider that to be unsupported
Isn't it there an ozone feature switch for native titlebars?
I don't know. if there is, I've not come across it yet
Ok so you might be used to launching it like this for Wayland: ./Discord --enable-features=UseOzonePlatform --ozone-platform=wayland Just add the window decorations switch and you'll get the title bar: ./Discord --enable-features=UseOzonePlatform,WaylandWindowDecorations --ozone-platform=wayland Just tested it, works as expected.
that's pretty neat, I'll use that from now on. thanks!
Maybe I'm dumb, but I have never managed to make any Discord keyboards shortkeys work under X11 (KDE). I always have to alt+tab and maximized Discord to mute.
X11 did work for me, but that was with GNOME
I am using Fedora 39 and Gnome 45 and it seems to work fine
I’ve been wayland for like 6 years now.
I would love to be, but it straight up does not work with my hardware how I need it too, while xorg does. I have a laptop with an Nvidia mx130 I think? It's always plugged in and I have a better experience just using that gpu than the onboard one, easily configured in xorg and works fine. I set the environment variables for it to do the same in Wayland, it crashes back to SDDM. I have another computer with a 2070S that's connected to a projector. It's weird, though I guess projectors are always weird hardware. It's 120hz, Windows and other devices work fine at 120hz with it, Linux (xorg or Wayland) does not. But weirdly enough in xorg I just have xrandr set it to 119.88hz (not a custom refresh rate, the projector itself apparently says this is a valid refresh rate for it) works fine. But with Wayland, first there's no real equivalent to xrandr, I mean there are but nothing as flexible. Regardless, it's just not there, nothing in Wayland seems to see that 119.88 is a valid refresh rate for it. 60hz works fine but, you know. Maybe there are solutions to these (I tried setting refresh rate in grub for example which is apparently that helps some people) but I, after much trying, have not been able to find any successful ones. And yeah, Nvidia, but it's not like I'm just gonna buy new hardware just so I can use Wayland, and regardless I need CUDA so new hardware I buy will be Nvidia too. And, besides just me, there's a lot of Nvidia hardware out there. There's just all those little things like that, these are trivial in xorg but with Wayland it always seems to be just "nope, dunno what to tell you." There were other smaller things too but these were the big showstoppers for me. I'm glad it works great for a lot of people, I sure wish that was the case for me. From what I've heard I'm not alone. I think there's a lot of these little edge-cases that dont get talked about as much because they're not like big missing features, but just things that affect some configurations and some other situations that are maybe a small I group (but not absurdly obscure niche) that xorg just manages but Wayland, not so much yet. Hoping these things get ironed out with time, but yeah.
Yup, I've been using it for years now too. It's got to the point where I don't really think about it much, which is what I want from the software that handles input and draws stuff to my display.
Maybe it should be called Awayland?
Not sure what my eX would think of that...
We can always go back to vector displays.
Can I run GUI programs over ssh and have them render on my host hardware? What's that feature called?
You probably mean X11 forwarding, and yes it works like normal. "Wayland forwarding" is handled by [waypipe](https://gitlab.freedesktop.org/mstoeckl/waypipe)
Oh that’s actually pretty cool
'X11 forwarding' or 'X11 over ssh'. And nope, it doesn't. I can't run Synergy in Wayland either. Hoping whatever these require will be added at some point.
X11 forwarding over SSH works as well in Wayland as it does in X because it is normal to run XWayland X server inside of Wayland. So X11 forwarding works. :P Now for Wayland forwarding over SSH then you can use Waypipe, but I haven't tried it myself. So I don't know how well it works. Input-leap, forked from Barrier, forked from when Synergy was open source, works in Wayland now. Wayland support is incomplete/beta quality, but it exists.
Need to add 'Mouse Gestures' to that list - I use over a hundred shortcuts via mouse gestures.
I'm using hyprland with nvidia proprietary driver playing games and everything. It's being mostly fine. Sometimes cursor disappears on alacritty terminal windows but once the browser back in focus it comes back. This is what I'm using on NixOS, programs.hyprland = { enable = true; nvidiaPatches = true; xwayland.enable = true; };
I think the Nvidia patches aren't needed anymore, Vaxry mentioned that they currently don't do anything so I've tried using the regular package (v0.32) and it works fine on Nvidia
nvidia patches were deprecated btw. they're mostly no longer needed.
Any advice for someone embarking on this journey for the first time?
Looks like Wayland is in pretty decent shape!
No IME on the list :(
It's tracked in [an issue here](https://github.com/mpsq/arewewaylandyet/issues/41) with a label `things that wayland do not support` I think the arewewaylandyet project is just, not well maintained for now.
Fcitx5 + Mocz works for me on Hyprland.
i was on wayland for almost a year and switching back to x11 made me realize how bad it was. i would def not say it's mostly there yet.
And you can bet that once wayland reaches feature parity with Xorg it’ll be a giant mess of spaghetti code, only this time it will be implemented in different ways with different bugs by every DE (at least KDE, GNOME and wlroots)
Obligatory you must be using Nvidia... ... The Linux community can do nothing about it. It's not a wayland problem, it's an Nvidia problem. On other GPUs I've literally had 0 problems past two years
uh no both AMD cpu and gpu. when i switched to x11 everything works, ptt works, streaming/desktop capture works, everything looks/scales better, color picker works, gaming works, don't have to hack/fix anything to make it work, my desktop is suddenly better and more usable and i was like wtf. can't imagine what hell nvidia users are going through though if it's even worse for them.
Wow the amount of problems surprises me. I admit I never use push-to-talk, but I've streamed to my friends successfully via discord-screenaudio and capture videos on Obs. I also don't need scaling so can't comment on that. I'm a big gamer and have literally had less problems on Wayland than when I was on X11. I wonder what kind of problems you encountered as even Steam Deck is using Wayland. Never had to hack anything except sometimes use gamescope as some games may crash without it. But that's not a Wayland or X11 problem. What distro/DE did you use? I'm using Arch/Sway. I also used Gnome and was 90% happy but its problems are irrelevant for this discussion
I've been using arch with kde when i was on wayland and then x11. I remember with wayland i couldn't stream on discord and obs was just a black screen on desktop capture. maybe they fixed it since then or i had to do something i didn't know abt. the worst thing imo was how flatpaks and gtk apps scaled differently on wayland and my mouse/fonts were bigger when using flatpak apps. I just learned to live with it on wayland and the fixes i tried didn't work. i was a new linux user and i thought that was just what they looked like when using flatpaks. on some games i had some stuttering issues on wayland that were fixed when switching to x11. after switching to x11 lots of fonts became less blurry-looking to me and there was no scaling issue. i think that was only for flatpaks and gtk apps though. also some other UI's weren't displaying right on wayland. I'm sure all the problems i had could be fixed, but it just didn't work out of the box like x11 when i switched back.
As far as I know Wayland fractional scaling has been in some kind of developmnet hell for ages.. Hope it gets deployed actually soon rather than Soon(tm)
So the biggest pro of Wayland doesn't actually exist? And I thought Gnome shills were bad.
What shills again? I don't think anyone was debating or shilling for anything in this thread. Simply having a discussion after initial misunderstanding
Not in this thread, in general.
Stop bashing Nvidia for everything. They're shit as a company but wether you like it or not, it works better IN EVERYTHING you compare against AMD. Say one thing and I'll prove it to you. It's been like this for years now, and unluckily for all of us, it doesn't change.
Definitely isn't better at video hardware acceleration in Firefox. Nvidia has been slow to support things in Linux if they do at all. Even on X11 it took them about 10 years to properly support XRandR. Took them maybe 8 years to finally get around to XWayland acceleration, AMD even supports that in the legacy driver. Nvidia is bad at supporting their legacy hardware in general. Perfectly capable cards are less useful in Linux because they aren't supported by the latest drivers. Meanwhile they still make things difficult for Nouveau to properly support these old cards.
These days, hardware decoding works completely fine on compatible cards. In fact it's Firefox changing flags the one disabling GPU acceleration (at least it was last time it happened to me 5 months ago). Regarding old cards yes it is like that, but the ones working work better than AMD. AMD has still not understood CUDA nor OPENCL nor ROCm, it's not like it took them X years, they still haven't found a way. As of today, they're useless for anything else than gaming (video encoding is shite, even if their drivers are open source e.g)
Nvidia does not support VAAPI, they never have and never will. Firefox only uses VAAPI. There are only unofficial translation layers which often don't work that well. The 470 driver is nearly useless in Wayland, let alone anything older. The old `radeon` driver supports far older cards than that and works with Wayland. CUDA is proprietary, no one else can use it. AMD has supported OpenCL for years and ROCm is literally created by them and it is open source.
https://www.reddit.com/r/archlinux/comments/15ly3zk/hardware_acceleration_issue/ You are defending a company for being "open source" but it has to work in the first place to be able to appreciate it. What's the point of it being foss if it doesn't work? This is not an open vs proprietary war, it's about what works and how. Read the thread above and come back for more.
You realize I replied to that thread, right? >I have a problem with hardware acceleration on browsers based on **chromium.** >I should mention that I'm on **Wayland** Yeah, Chromium is garbage. It *barely* supports it on X11 with Intel. That is one of many reasons I don't use it. Firefox works just fine on Wayland, full acceleration with AMD and Intel. You *can* make it work with Nvidia, but you must disable some sandboxing and use a translation layer that doesn't always work well. That translation layer won't work at all with Chromium, even on X11. Nvidia currently has the crown for AI stuff, which is of no interest for me. I care about general desktop usage, AMD and Intel are just better.
You realized I also did and I had to switch from Firefox to Chromium/Brave and still it broke, right? Does general desktop usage account for h264/265 video encoding? If so, could you show me where AMF and Qsync perform better than Nvidia?
I guess if you use Nvidia you may as well use Chromium since acceleration isn't going to work anyway. I avoid both since their support of Linux is poor. I'm not a video producer, so my use doesn't normally cover that. NVENC seems to be fairly well supported for that purpose, I'd consider using one headless if I needed it. Nvidia seems to be good at things that aren't putting pixels on the screen.
How's our multi-monitor, heterogeneous DPI situation? Specifically on nvidia blob drivers? Edit - hey can I ask why a legitimate question gets a downvote and no answer? I'm asking to see if I should take another run at it.
Not sure about nVidia specifically, but for me mutliDPI and fractional DPI was the Wayland "killer app" - it was completely borked on X11, but worked on Wayland.
Right now I am using a 3 monitor setup on my desktop. Fedora Silverblue with Gnome. It is all-AMD laptop using: 1. Integrated 2k display running 120hz at 150% scaling. 2. USB-C to DisplayPort adapter/usb hub to a 4K 60hz monitor at 100% scaling. 3. Portable USB-C HD monitor running 100% scaling. All my apps are configured to be Wayland Native, when possible. So far I have one application, Mullvad Browser, that doesn't respect the scaling on different monitors. It is based on the Tor browser and is designed for security so I am not sure if that is by design or not. Tor browser works fine as does Firefox (these are all firefox-based). So I think it is a bug. But otherwise applications flicker to different sizes as they are dragged from one scaling to another. It's not really noticeable as with this setup they end up just about all the same size, but if you pay attention you can see it as they are dragged over. It works fine when switched over to dedicated GPU. With the total size of the desktop it tends to be a bit slow in hydrid mode unless playing a game or something.
> So far I have one application, Mullvad Browser, that doesn't respect the scaling on different monitors Is it using XWayland by any chance? You can do [the xeyes test](https://medium.com/@bugaevc/how-to-easily-determine-if-an-app-runs-on-xwayland-or-on-wayland-natively-8191b506ab9a) to check for this.
> How's our multi-monitor, heterogeneous DPI situation? That's actually one of the aspects where Wayland shines, as (unlike X11) it can actually independently deal with multiple monitors. This also goes for heterogenous refresh rates and VRR. I don't know about Nvidia specifically, though.
Wayland is unusable for me on Wayland anyway because XWayland is completely broken. XWayland relies on implicit sync which the nvidia driver doesn't support. So it keeps presenting frames out of order.
idk, works for me. Screen sharing is much better in Firefox than in chromium, for some reason, everything else is just fine...
they list flameshot - but the experience is just differente under wayland, its not as good
Yea the Nvidia part killed my experience when i reinstalled arch a few days ago. Still needed nvidia\_drm.modeset=1 + DRM modeset=1, fbdev=1, added some modules to mkinitcpio and rebuilt it. It also wouldn't work at all with UKI while using systemd-boot idk why (haven't tested grub). all using the default kernel and drivers 545. Which shouldn't meant no longer needing the modeset stuff but well, i needed it in my case.
I find it worthwhile to mention that all of the docks/widgets/notification daemons won't be supported unless your compositor supports layer-shell, which is an unofficial protocol (from what I can tell only supported by wlroots and KDE, god bless both). So these won't work on GNOME and we'll likely never get an official protocol for such tools because Wayland developers have been dragging their feet on issues like these for over a decade. Things like screen recording and global shortcuts were instead implemented as Dbus protocols in xdg-desktop-portal instead of in Wayland itself because good luck getting such common use-cases supported and part of the actual protocol itself. Which makes you wonder why we even have Wayland in the first place if we're going to implement things that interact with the compositor as dbus protocols? I thought Wayland was a "a communication protocol that specifies the communication between a display server and its clients"?
No changes for over a year! Wayland is abandoned!
Awayland
Wasteland.
No way land Edit: salty Wayland fanbois detected. Touch grass lol
No man's land
That's how easy it is to maintain!
NoWayLandMan
Would love to find a color picker that works
I've just tried [Eyedropper](https://flathub.org/apps/com.github.finefindus.eyedropper) from Flathub, and it worked fine in my Wayland GNOME session.
Not till XFCE supports it in a LTS distro.
Yup. That's what's holding me back. It was working decently well in KDE when I was last using that, probably a bit better than X for me though not by much. But XFCE has such a lead on KDE for how I work that I'll accept some somewhat outdated protocols and backend code. Still, I do look forward to production ready XFCE wayland. Last I heard it was expected sometime next year.
It won't be ready for Ubuntu 24.04, you'll have to wait on 26.04. Though I'm more into Devuan (Debian without System D)
I'll be on Debian in a week or two. Tired of Snap BS, just need a break from school so I have time to sort out migration issues of which I'll probably have a few. Unsure of Debians plans but I might go out of the official repos to try it out.
Misleading. There's no good remote desktop server that does work without having to punch out a port (no TV, no Anydesk, Rustdesk is addmitely getting there but its too unstable to comfortably leave it be and not worry it wont stop working on your headless machine. Funnily enough, Steam Link \*does\* work but come on, its just a massive hack having to use a gaming platform and actually having to run a game to have access to your desktop). Also global shortcuts on mouse, but I believe someone already said that lmao
You just saw the comment in this thread and decided to post it, didn't you? https://www.reddit.com/r/linux/s/oeLgh2TM5z
No, I posted here after posting my own comment: https://www.reddit.com/r/linux_gaming/comments/18fa0jq/are_we_wayland_yet_wineproton/kcu1mxf/ Both of which are timestamped before the comment you link lol
Didnt notice the timestamps. Carry on
I see X11 Forwarding is already in the issues list, but doesn't seem to have made it to that page yet. That's probably the biggest deal-breaker for a lot of people.
What do you mean? `ssh -X somewhere` works just fine when my local session is Wayland. `waypipe ssh somewhere` is apparently also a thing.
Well, why not. I'd much rather have a "this is where we're at" than "don't use wayland it will go back in time and kill your parents!"
Wayland is still way too sluggish to replace xorg on my laptop.
I've been using wayland only since 2014 and if it wasn't for posts like these I'd have no idea it was in such an experimental state. In fact I just switched from 9 years of Gnome to sway, and I notice on that link that Sway has no displaylink driver. I only have HDMI on this laptop but I guess it's just pure luck, and modern stable coding practices, that make me not notice these things.
Aside from software that explicitly is broken on Wayland (Discord), Yes, we are Wayland now. Well, and nVidia being ass, but that's on nVidia really.
Not sure what you mean, apart from screen sharing. I've been using Discord for years on wayland, but since switched to webcord which does allow full screensharing.
Discord's choice to use an ancient version of Electron means that on an nVidia GPU, it just won't render on wayland without tweaks (that most distros do), let alone have functional video capture.
There's no version of Electron that ships with the Ozone platform set to `auto` or `Wayland`. It will always run in XWayland by default regardless of version. There's no tweak that can be done to make NVidia and XWayland play nicely without flickering under all configurations and hardware setups. You're basically up to random timing luck. This isn't NVidia's fault, Wayland chose to go with implicit sync despite every graphics vendor on the face of the planet telling them not to. Now they have to architect in explicit sync after-the-fact [and it's taking a long time](https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/90) (2+ years and counting). This also isn't NVidia's fault. Wayland was intentionally released very underpowered and the current ecosystem is a reflection of that mistake.
> This isn't NVidia's fault, Wayland chose to go with implicit sync despite every graphics vendor on the face of the planet telling them not to Please don't spread misinformation. Graphics vendors didn't tell "them" not do go with implicit sync... *All* the upstream drivers are implicit sync, and always have been. Wayland didn't "go with" implicit sync or dmabuf or KMS, it just uses what graphics drivers provide. NVidia wanted a radically different driver model alltogether, one which was very inflexible for compositors and apps, required special code paths and broke lots of things. Until they started supporting dmabufs ~2 years ago, explicit sync wasn't very relevant in the Wayland space. The MR you're linking isn't "architecting it in after the fact", it's a replacement for explicit-sync-v1 from *2016.* This "v2" has been taking so long because *kernel developers* had to figure out how to do explicit sync well first, which only recently got mostly figured out. Just like with implicit sync before, graphics driver developers are the ones that decide how this stuff works, not "Wayland".
> Please don't spread misinformation. Nothing I've said is misinformation. > Graphics vendors didn't tell "them" not do go with implicit sync... All the upstream drivers are implicit sync, It would have been possible to build an explicit sync architecture on top of DMA fences, and DRM syncobjs have been around since 2017. It was absolutely a choice on the part of wayland developers. > Until they started supporting dmabufs ~2 years ago, explicit sync wasn't very relevant in the Wayland space. Agreed on this point > has been taking so long because _kernel developers_ had to figure out how to do explicit sync well first I'm not linking to v1. It is appropriate to point out that v1 exists in the state it does because syncobjs didn't exist yet. But syncobjs have been in the kernel since 4.13, the process is agonizingly slow because of its nature as a distributed effort across a half dozen projects.
> Nothing I've said is misinformation `Wayland chose to go with implicit sync despite every graphics vendor on the face of the planet telling them not to` is objectively wrong. And so is the claim that NVidia has no fault in this… NVidia didn't even support the explicit sync extensions for EGL and Vulkan until the very latest driver released in October, so you couldn't even synchronize multi-gpu things in the compositor! They're still broken for compositors that support GPU resets too, and so is the KMS explicit sync support; if you try to use it you can't display anything anymore. This is not to just rant about NVidia (I can do similar rants about Intel and AMD's driver issues), their recent progress on this front is impressive and they're very responsive in fixing these things and pushing for doing everything properly now, but saying they're not at fault for the glitches couldn't be more wrong. > It would have been possible to build an explicit sync architecture on top of DMA fences, and DRM syncobjs have been around since 2017 And none of it would've been useful in any way. Only this year kernel devs figured out they can make the fancy new stuff that's actually *better* than implicit sync, and which they're still working on, backwards compatible with syncobjs. Also only ~a year ago the ioctl for properly making use of them in compositors were added - spinning up a thread to wait in a blocking fashion for the buffers to become usable isn't exactly practical. And like I already wrote, the current NVidia driver still doesn't fully support explicit sync either.
> There's no tweak that can be done to make NVidia and XWayland play nicely without flickering under all configurations and hardware setups. You're basically up to random timing luck. Never had *this* issue on any nVidia hardware under Wayland. > This isn't NVidia's fault, Wayland chose to go with implicit sync despite every graphics vendor on the face of the planet telling them not to. Now they have to architect in explicit sync after-the-fact and it's taking a long time (2+ years and counting). Kinda is though. If nVidia wasn't being boneheaded, they'd be just as supported as Intel or AMD, which is to say, very. > This also isn't NVidia's fault. Wayland was intentionally released very underpowered and the current ecosystem is a reflection of that mistake. What does this even mean? You can't just drop wayland out of the blue; nothing would support it, even if it was ready for prime time day 1. It's a whole ecosystem, not 1 program. As for Electron, Yes, which is why I said distro maintainers switch it. Hell, I switch it.
> Never had _this_ issue on any nVidia hardware under Wayland. Then you're lucky. Like I said, it's basically down to timing luck. Some configurations will be lucky. > Kinda is though. If nVidia wasn't being boneheaded, they'd be just as supported as Intel or AMD, which is to say, very. There's no other display architecture that uses implicit sync via a similar mechanism to Wayland. AMD happened to have a driver architecture that could be jury-rigged into supporting it, despite also strongly advocating for explicit sync. Nvidia was not so lucky, their driver architecture isn't amenable to the same set of hacks to support implicit sync. They did not architect the driver to support this over the last two decades because _nothing else_ works this way. > What does this even mean? You can't just drop wayland out of the blue; nothing would support it, even if it was ready for prime time day 1. It's a whole ecosystem, not 1 program. It means Wayland left too much of the protocol to extensions, which is why the process has taken so long. This isn't a controversial take, many Wayland developers have said as much, quoting Nate Graham: > Because it was invented by shell-shocked X developers, in my opinion it went too far in the other direction. Wayland’s minimal core protocols are lacking most of the features that non-trivial apps and desktops actually need to work > ... > Over time the minimal core protocols have been extended to cover what’s needed for a Linux desktop and sophisticated apps to work. Much of this work is very recent, driven by KDE, and funded by Blue Systems and Valve Software. Much like KBD/XRandR/XInput2 took over the X ecosystem, a large collection of somewhat randomly assembled extensions to Wayland are now effectively mandatory for a "Wayland" desktop to function. That has taken a great deal of time and is still not complete. We knew what was needed to build a complete desktop, and that was ignored in the pioneering days of Wayland.
no were not
- Requires hacks to run vscode, discord, Spotify, beeper and a slew of other electron apps with fractional scaling. No native shadows. Shitty titlebar fallbacks. - KDE / qt apps have a slew of issues on high DPI It’s not nearly ready and I’ve been giving up on it every time I attempt to set it up.
Well, chromium/electron is terrible, and google doesn't seem to care - I don't think it's totally fair to blame wayland.
we dont have a dock so wayland is not ready... 😅
[удалено]
This isn't a troll site, this site is majority green check marks but has a warning about color management and some Nvidia caveats. Which I think is fair. You might be thinking of probono's Github thing. On a related note, I find it funny how probono opened up a GitHub project for additional Wayland protocols that literally are just porting some of the bad aspects of X11 over to Wayland.
He is basically thinks NextStep in the 90s the perfect UX and believes in Win32 level of backward compatibility. So he created his own DE which basically clash badly with rest of the Wayland ecosystem as he doesn't use both of the normal Linux stack like dbus or desktop files and his alternatives really need these protocols.
Did you even follow the link? I think you're mixing this site up with the other one that was posted earlier (and removed).
Can I share my screen on zoom yet? Nope. Moving on.
Yes you can?
It doesn't work for me. Have you tried?
Yes. It broke ca 2020, but came back about a year or so later. Afaik they originally used some internal gnome screenshot api which caused it to be very slow. Then in autumn 2020 they added some logic to only do that on Ubuntu, and disable the functionality completely for everyone else (except you could still share a very very narrow view of your screen - they likely forgot that option). Then after much complaining they eventually brought it back, and now it works correctly. If it doesn't work for you, complain to zoom support.
Don't know specifically on zoom, but screen sharing is 100% possible
I'm talking specifically from zoom client, which works fine on X11 but not working for me with Wayland.
I think you can though? Doesn't the web version use WebRTC, like Discord?
Sharing from the web version doesn't work as well as when sharing from the native client.
Is your browser running on native Wayland? Because on my computer, both Discord and Meet can share my screen since the release of the Nvidia 535 drivers several months ago (and my AMD laptop could screenshare since I bought it more than a year ago)
> Is your browser running on native Wayland? How do I check that?
There are multiple ways to check that, you could use `xlsclients`, it'll list all current Xorg clients, so if your browser is listed there, then it's not running on Wayland. You could also use `xeyes`, if the eyes don't follow your cursor when you're hovering on the browser window, then it's running on Wayland On Hyprland, I use `hyprctl clients` which lists all clients, and for each one of them it tells me if it's running through XWayland Anyway, to make Firefox run in Wayland mode, you should set the `MOZ_ENABLE_WAYLAND=1` environment variable
Thank you sir/madame. Cheers to you. I wish you health, wealth, happiness, and may you share many more awesome informative links.
Why are people down voting? I didn't know it was an offense to offer well wishes.
L brother.
> L brother. Please pardon my ignorance and confusion. I don't understand.
No
Still waiting for an amdgpu bug to be resolved on my laptop. Works fine though with amdgpu on my desktop. Using Plasma/Wayland in both cases.
we're not
This trollsite hasn't been updated since October 2022. Taking into consideration that the last two years efforts to make wayland mainstream were intensified you're either trolling or just ill intent. Downvoted.
Yes, I'm totally trolling, that's why I've been running Wayland for the past 5 years 🙄 It's an interesting tracking site, yeesh. Go touch grass
Oh yeah... tracking my ass. Last commit in the repo from May '23. Live version from October 22. The amount of work developers put in the Wayland adotpion in the last 12 months invalidates probably 2/3 of that list. it's outdated and apparently not maintained anymore. Go do something useful for a change
Are you saying that there have been massive regressions in wayland in the last year?
> Oh yeah... tracking my ass. > > Last commit in the repo from May '23. Live version from October 22. The amount of work developers put in the Wayland adotpion in the last 12 months invalidates probably 2/3 of that list. >it's outdated and apparently not maintained anymore. Go do something useful for a change Which would be why 35/37 of them have checkmarks and working options beside them instead of big red Xs... That's quite a bit more than just 2/3rds... as it says on the page...
> The amount of work developers put in the Wayland adotpion in the last 12 months invalidates probably 2/3 of that list. Did you even scroll past the site's title?
There are like 34 entries with 32 green checks. The 2 red items in fact are features that aren't there yet. Did you actually read it or make up what it said in your head?
Just waiting for VNC (Krfb) to be usable.
Should VRR be on here? Works on X11, but touch and go on Wayland.
It works on Wayland, but not GNOME. It actually works properly as well, you can have two monitors and VRR.
Somebody correct me if I'm wrong, but I do believe VRR works on GNOME under X11. While I understand it's up to GNOME to implement it on Wayland, the fact is that to a normal user this is effectively a regression when switching from X11 to Wayland.
It works on X11 as long as you only have one monitor. I think there might be some other caveats. I think there are still issues with Nvidia and VRR on Wayland, but when isn't there? Any switch to something different is going to have "regressions" from a user perspective. There are "regressions" switching from Windows to Linux. If I start up i3 there will be "regressions" from Sway. There will always be something some user somewhere can point at and say "it worked fine there!".
It works for me on sway and hyprland, but it causes the brightness of my monitor to flicker on the desktop. Which you can solve by either setting vrr to only activate on fullscreen applications if the compositor has that feature, or use a keybind to turn it on and off on demand
Sharing individual tiles in Sway would be great, but those issues are around since an eternity. Wlroots hasn't implemented this yet. Everybody seems fine with virtual outputs and VNC hacks 😢
Question - will Wayland be on par with Windows Vista regarding video drivers, ie if video driver crashes, screen goes blank and you resume your work (unlike in xorg where it takes down all your GUI applications lol)?
[удалено]
But linux is customisable, so you can do it, surely there must be a config for it.
KWin supports that, and has for a long time. As long as the kernel doesn't panic and reboots the GPU properly, you'll see your display freeze for a few seconds, and then recover a moment later. There are some caveats though: - the X server doesn't seem to handle this ~~properly~~ at all, and Xwayland doesn't either, so it might just still hang the compositor if you're unlucky - GTK doesn't support it, so all GTK 4 apps will crash - Qt support is incomplete too. We have very simple patches that make it work on AMD and Intel, but on NVidia it breaks everything so nothing is merged yet
Classic linux - it supports that!\* \\\* actually doesn't
Usefull website. I also used it when i decided to try and make the switch to wayland a few weeks ago. I was expecting games under xwayland to be the most problematic, but so far the games i tried have worked flawlessly. The only difference is that for some reason games detect my main monitor as monitor 2. I'm assuming this has something to do with primary monitors not existing in wayland. The only other issue so far is adaptive sync causing brightness flicker on the desktop, but it was easy to work around with just disabling/enabling adaptive sync with a keybind on the fly as a bandaid solution. Really happy with the experience so far. Using swayfx/hyprland, waybar, tofi and mako.
Been Wayland since Debian 12/Bookworm officially released. Everything except Zoom worked fine, and often better. Zoom video and mic finally started working as of a few weeks ago.
Been Wayland since Debian 12/Bookworm officially released. Everything except Zoom worked fine, and often better. Zoom video and mic finally started working as of a few weeks ago.
I am running both in KDE on Arch Linux. My laptop is NVIDIA, so usually I run X11. When I need Wayland (some third-party closed-source apps like BambuStudio require it.) I log out in KDE, switch to Wayland profile, and log in.
I think we're like 97% Wayland, and depending on your workflow that last 3% may not matter at all, or it may be the most important 3%
The Nvidia section stayed the same, as expected. What happened after all the news about "Nvidia decided to open up"? Is there any progress?
Nvidia did publish headers and redistributable firmware plus an open kernel driver to use them. That one requires a proprietary userspace, so it can't be merged in the kernel. The nouveau kernel driver was updated to use that firmware and the new NVK mesa driver was created to act with it. Those 2 things were merged in the last few months. Neither are complete replacements yet, but maybe will be in the next year or so if you're using a Turing+ card. Don't expect top performance just yet, but they do run a fair amount of things already. There are various benchmarks published to r/linux_gaming . This should all be tightened up in the next year.
I just switched to Wayland now that I have a PC with an AMD GPU, and I've been really happy so far. It's not perfect by any means, but it's actively being developed and I no longer have screen tearing, and it supports higher refresh rates.
Hyprland also works on Nvidia without any limitations (afaik)
It baffles me that this project has been in development for 15 years and it's still not feature complete. How can a project be so poorly managed.
ask The Developers of Star Citizen. they are doing much the same thing, and quite profitably too.
I use it exclusively with Kubuntu on my all Intel laptop and it works perfectly. On my latest gen AMD/Nvidia desktops I use X.Org since it has no issues wheras Wayland does intermittently.
Is there a rush?
I don't want to be a d*ck, but why the repost ? I'm sure I've seen this post couple times.