- cross-posted to:
- linux_gaming@lemmy.ml
- cross-posted to:
- linux_gaming@lemmy.ml
A set of merge requests were opened that would effectively drop X.Org (X11) session support for the GNOME desktop and once that code is removed making it a Wayland-only desktop environment.
Going along with Fedora 40 looking to disable the GNOME X11 session support (and also making KDE Plasma 6 Wayland-only for Fedora), upstream GNOME is evaluating the prospect of disabling and then removing their X11 session support.
Some concerns were raised already how this could impact downstream desktops like Budgie and Pantheon that haven’t yet fully transitioned over to Wayland. In any event we’ll see where the discussions lead but it’s sure looking like 2024 will be the year that GNOME goes Wayland-only.
Time for Nvidia to step up their driver game… shrugs
I think they already have. I held off on Wayland on my main machine for a long time due to Nvidia issues. For example, I was getting rendering issues where some windows/popups would be totally invisible until I moused over them. Those issues are now gone, and I’ve been running Wayland for the last few months with no problems at all.
yeah, it got better, but still not good enough
i still have issues here and there, i hope they step up.
NVidia won’t do shit until they’re forced to, which is probably why it’s come to this “force everyone over even if its not 100% ready” changeover
They still haven’t solved the problem of a Gnome Shell crash taking down my entire session with it. I need to be able to restart the shell independently of the Wayland compositor for me to switch.
KDE Plasma will get this feature soon, I hope GNOME Shell will follow their approach.
pretty sure the KDE work will be at least partially compatible with other desktops. one of the demos shown was specifically using the feature to swap between Wayland desktops without losing app state
I feel like if Gnome Shell is crashing enough for this to be a problem then it crashing is the actual problem.
ubuntu already compile gnome with the fix(edit: i confused it with triple-buffering, that ubuntu compile gnome with, idk if ubuntu compile gnome with the fix to don’t take down the entire session), but the merge request is there, and it work, idk with gnome didn’t merged it still, maybe other priorities?Do you have a link to this?
Here is an alternative Piped link(s):
https://piped.video/jlDhpFjBWiw?si=lviB5_L85msDVbEH
Piped is a privacy-respecting open-source alternative frontend to YouTube.
I’m open-source; check me out at GitHub.
Yep. I’m not even using Wayland. Every other day its “Oops, there was a fucky wucky!” And I have to log out. I’m on Cinnamon for now.
Well let’s hope that massively improves the Wayland experience then. I tried it last week and still had flickering screens, laggy windows, and crashing games. In the current state it would be unacceptable for me to switch
depends if nvidia care about improving wayland, they don’t really have any reason to care today. Maybe if people start purchasing hardware from their competition enough.
I’m having a perfect time on intel at least. Though I have no video game requirements.
My problem is that I’m kinda tied to CUDA and thus Nvidia. If AMD’s ROCm would’ve been a bit better and supported on consumer GPUs I would’ve went for that.
But having a non-NVIDIA card in order to use the latest GNOME doesn’t seem reasonable to me. Then again, maybe the pressure will finally make NVIDIA get their shit together
considering how willing they were to throw vendors like EVGA under the bus, trying to figure out what pressure Nvidia listens too might be a challenge in of of itself …
I’m gonna assume you can use Cuda, without driving the display with nvidia. You just need a motherboard with onboard Intel
That seems like a rather extreme work-around for Wayland proponent delusions. Buying an nvidia card and then not using it for graphics at all.
That’s gonna make gaming a lot harder though. And I’m on an AMD CPU. I’m not sure whether it has an internal GPU even. My point is that they’ll lose a lot of users by forcing Wayland. I’m not dure Nvidia will care for such pressure
I had the same problems until I switched to an AMD card. Since then it’s been smooth sailing in Wayland.
I had those issues with an old nvdia driver version, bun on the recent ones it works better.
What’s everyone’s Wayland showstopper?
I’m holding out for better autoclickers/macro recorders before I go to Wayland
Nvidia
Better Wine support. It’s coming soon, but I prefer xorg until Wine properly supports Wayland.
is XWayland not good enough for that?
I would say Xwayland is good ENOUGH, but it’s not great, my clipboard with xwayland is awful on sway, for example. It works, but not the best.
ah, on Gnome it’s relatively seamless
I recently stopped switching to x11 for gaming. With most games, the performance is 5-10fps better on Wayland
Honestly, Wayland just doesn’t give the impression of working well enough with everything to replace my window manager and all kinds of utilities that grew around it (or X11 in general) for a decade or two just to only notice after using it for a few weeks that it won’t work with some things. It demands a huge time investment up front for questionable gain basically.
As a multimonitor user with mixed properties, and an AMD user, Wayland has been nothing but a massive gain for me and continues to get better in equally massive strides on KDE (been using kwin-wayland for almost a full year as a daily driver now). It even improved the user experience on my surface pro that I’m running the surface-linux kernel on.
I am not using a Desktop Environment and if switching to Wayland means I will have to give up tiling window managers for DEs I will never switch to Wayland.
The Arch wiki lists more options to choose from: https://wiki.archlinux.org/title/wayland
Considering how many things Wayland apparently still lacks that need to be implemented in each compositor separately a last release in February sounds like a half-dead project.
Sway is based on wlroots and therefore does not need to implement the complete Wayland specification itself. Many other Wayland window managers are also based on wlroots and therefore share a common base (compositor).
Furthermore Sway’s git repo has activity up to a couple of days ago: https://github.com/swaywm/sway/commits/master
Dude, why are you so annoying about this topic? sway is a very good tiling window manager that IIRC two years ago was able to do things X11 based window managers will never be able to (different VRR on multiple monitors) and its basically the reference manager for wlroots, a library implementing the Wayland functionality. I’ve been using Wayland exclusively since about 2021 and I can say all my stuff now works better than under X11. Does it mean everything under the sun works better or is possible? Probably not, but at the same time, the people putting in the work have decided that the old concept was no longer maintainable for them and no one else is willing to pick it up.
Dude, why are you so annoying about this topic?
Because Wayland proponents have been at it for over a decade now pointing at their broken mess saying “look, everything works” and yet somehow the longer these posts stick around the more comments accumulate about things that do not work, and not minor edge cases either but major features like screen recording, games, one of two major graphics cards vendors, remote desktop, significant applications not working,… I am sick and tired of this broken project pretending it is ready to replace X11 over and over and over again.
If they had acknowledged that it was 20% done, 40% done, 60% done (that is maybe where it is now) it would be different but Wayland developers seem to live in their own bubble where “works on my machine sometimes, with half of all applications” is considered done.
Today I can install any game, any application on Linux and know it works with X11, no ifs, no “only on that vendor”, no “only on the latest unreleased bleeding edge version”. Why should I give that up for years of Wayland pain just to get back to where I started minus the things Wayland will never implement like network transparency.
The project you’re looking for is called wlroots, everything will be based on it eventually, the only compositors that aren’t are gnome and kde and that’s because they made their compositors BEFORE wlroots existed.
deleted by creator
Remind me in 2 years /s
The time-investment is short-term pain, long-term profit. That’s kinda our thing as Linux guys
But where it the long-term profit? Every time Wayland comes up in the last 15 or so years since it was first mentioned somewhere it is an endless list of comments about things that don’t work and “will work soon” ™. Meanwhile in all that time there hasn’t been a single exploit for the security issues Wayland claims to fix. X11 has worked just fine for all this time.
I am not opposed to replacing things in general (e.g. I do like systemd and never want init scripts back) but Wayland just seems like a bad design with bad goals and bad implementations.
That talks about typical implementation vulnerabilities. I am talking about the kind of vulnerabilities the Wayland design supposedly protects us from by design.
You do realize you’re comparing wayland to a protocol that doesn’t even make an attempt at stopping keylogging, screengrabbing, or really implements any form of security whatsoever, right? I could make a list but it’d be effort, you should really research this stuff before you spread FUD on accident.
I’m just going to point out that there’s a reason EVERY SINGLE PERSON who worked on X11 has moved onto wayland. Imagine how hard of a sell it’d be for most people to move on from a project that has THIRTY YEARS of work, to redoing everything from scratch, how many people in any other situation would ALL choose rewriting from scratch.
They learned from their mistakes, and that’s why they restarted from scratch.
I have to research more thoroughly what the promised advantages of Wayland are, but from what I’ve heard is that the capability system is much more secure and the architecture is more decentralized, not a single server which takes everything down with it when it breaks.
Anyways, Wayland has a LOT more growth behind it. X is in the process of being deprecated. So I’m pretty sure Wayland must be better in some general way, otherwise it couldn’t have gotten this momentum.
I play Heroes of the Storm through Lutris.
I have a superultrawide 32:9 monitor.
In X11, I can get HotS to scale past its normal limits just like I could in windows and take up a full 5120x1440 resolution.
In Wayland, I can’t.
I will die on this hill.thy gamescope(that run on steam deck) i think it can scale, if yes, so it’s an implementation issue, that need to be fixed by the compositor
need to be fixed by the compositor
It is a Wayland issue that things like this need to be fixed per compositor. Honestly, what were the designers thinking?
there is a base implementation basically all compositors are based on
the compositor need to implement the option to change resolution, how could wayland(the protocol) dictate it?, it don’t have a feasible way to do it, what could help is less fragmentation, like using wlroot, but again wayland(protocol) don’t habe a way to dictate it
If they had kept the window manager concept, separating mechanism and policy they would have only needed one implementation for all the mechanisms.
yes, they could have made the implementation from the start, and that is a valid criticism to wayland(i also agree), but we have wlroots now, and they are working very close with KDE(in one of the devs blog they even said about KDE being ported to wlroots in the future), except for gnome, every DE are working together
Why should it not be fixed by the compositor, exactly?
As far as I see it, that’s a smart design choice, the issue is just that we needed a universal implementation, an x.org equivalent, and we now have that with wlroots, now that that exists, there’s no downsides to that approach, as far as i’m aware.
In what way exactly does that make it a smart design choice. It sounds like compositor implementers essentially have to work around the bad design choice by including a library and even then each compositor will have to update the dependency version for wlroots each time something needs to be fixed that breaks the wlroots ABI (or for containers, static linking,… just each time).
No, it sounds like compositors will use a library so that they don’t have to do a shitload of work that they’d have to do otherwise.
…this is already how x.org works. You have to implement the x.org server, or create your own implementation of X11.
The only reason you think your criticism doesn’t apply to X.org is because nobody updates X.org anymore… There’s no more breaking changes to be made because it’s a fundamentally broken, shitty protocol.
[This comment has been deleted by an automated system]
Mine’s mostly just bad electron app support for native Wayland. In theory Electron now offers full Wayland support but hooooo boy is it going to be a while until all of the electron garbage I use finally updates to a new enough version for proper support.
The other gotcha is just general client side decorations support for apps in general. I’m shocked that no one has built a small libadwaita wrapper library that implements client side decorations for apps. It’s going to be ages until app developers all implement their own (crummy) CSD that doesn’t match system themes at all.
You can still use XWayland though, it’s not going anywhere. They are only removing the ability to run a X11-only session.
Yeah, fair - they’re not so much showstoppers as persistent irritations.