> But Wayland is just broken, and everyone would rather sit around arguing with each other instead of actually addressing the design flaws.
> It's not the first time such a proposal has been put forward. Something that developers need for their applications to work properly on WL (particularly multi-window applications), and it gets vetoed. Every other OS manages this fine. But apparently we're in the wrong for not conforming to some warped view of how applications should be, despite our applications working fine on every other platform.
This is so damn true. Wayland lacks a Linus-style BDFL saying that the kern... the compositor is for applications, and not the other way around. We won't have nice things until Wayland maintainers stop thinking about what their end users must or must not do, and start closing feature gaps with X and compositors/window managers on other OSes. Right now they're reinventing the wheel while making it square.
Wayland already works, and is great for a lot of use cases; it's the default on distributions like Fedora, and has been for a while. It has nice things. For 90% of users, it's better than X in most ways that matter.
Similar, but much less catastrophic, to how Android isn't great for blind users, or people who want to do low-latency audio production, Wayland is actually great for most users, despite not appealing to extremely niche use cases. It's objectively better for most real-time use cases.
I exclusively use X11 because of an extremely niche use case, and I can admit that Wayland is perfectly fine for 99% of things anyone wants to do with a computer. It's not a square wheel at all.
> For 90% of users, it's better than X in most ways that matter.
I sincerely doubt this. The project hasn't organised much in the way of receiving user reports, and anyone with a negative one has experienced various levels of hostility: you are usually suspected of user error.
The distro's that have switched also target devs/enthusiasts, who tend to have a particular subset of all possible hardware which leads to biased impressions.
I think many don't quite understand that much of the hairyness in Xorg is necessary: it's the hardware that dictates the requirement of those 1001 little workaround. A clean slate doesn't mean the slate can stay clean: you either choose to support all of those unperfect devices, device-combos, user requests, or, and that seems to be what happened, you focus on a narrow happy path (for the kind of people the devs themselves see) and leave it at that. I don't mins that, but I do mind anyone arguing Wayland should be or is going to replace anything; look at the negative user reports. It's nowhere near there.
> Wayland already works, and is great for a lot of use cases;
> I exclusively use X11 because of an extremely niche use case, and I can admit that Wayland is perfectly fine for 99% of things anyone wants to do with a computer. It's not a square wheel at all.
This had me thinking about digital NIMBYism. Suggest others do one thing, while you do the opposite, because your reasons make sense.
You still haven't addressed PCSX2's, or anyone else's, concrete reasons.
I use X11 because I wrote a terrible usermode hack a decade ago for a niche (<2000 units) piece of hardware that gives incorrect EDID information and needs a handshake to turn itself on, and haven't tried to port my hack to the post-kms world yet. It is the definition of a legacy hack, and one I'm hoping to rid my systems of the second I get a decent vacation.
I've used Wayland before; it's great. Most people aren't gamers; everything PCSX2 wants to do is something that 99% of people do not care about; for the majority non-gamer software, allowing a window to manage absolute position is pointless, or even bad. Apps shouldn't be able to force CSD if the user doesn't want it; GNOME is respecting user preference (and that's not a Wayland thing). Even so, it still works with XWayland. For Wayland users, there is no service disruption. Aside from people who dislike XWayland, anyway.
Proprietary NVIDIA drivers being broken is an NVIDIA thing. Swapchains causing segfaults happened any time you used direct rendering from like 470 to 525, even on X11. They don't make great Linux drivers.
It's the 1% that makes Wayland awful. If it's such a small part, then why not support it anyways? If it's a security issue, let kde/gnome break it in their own ways.
> Wayland already works, and is great for a lot of use cases; it's the default on distributions like Fedora, and has been for a while. It has nice things. For 90% of users, it's better than X in most ways that matter.
> I exclusively use X11 because of an extremely niche use case, and I can admit that Wayland is perfectly fine for 99%
I am also married with a nice girl, but the girl next door, looks much better. /s
Honestly at this stage, this stuff starts to feel like FUD. Every computer I use -- work laptop, personal desktop, personal laptop -- uses Wayland at this stage. Two are on Sway, one's on KDE. I cannot think of any show-stopping bugs I've encountered for... years.
It was a lot more rough 3 years ago when I first switched over (because the laptop I had then was HiDPI, but the screen I attached it to was standard, and X was _horrible_ across these two screens) -- but these days, it all just goes.
I'm sure the process of hashing things out with the various committees is slow and laborious, but for a relatively normal set of desktop needs -- browser, IDEs, games, some photography work (albeit without having done any colour profile management, I know that's missing -- but my gear/monitors aren't up to that really anyway), it's fine.
It can be simultaneously true that Wayland can be viable, and that Wayland's foundation is still broken and lacking. Same as X11. I think the frustration for devs is having to support _both_ broken platforms; at least X11's failures and shortcomings are known and mostly unchanging. Wayland keeps breaking new things downstream in the process of adding features or resolving problems.
But this:
> for a relatively normal set of desktop needs
The problem is that there's no such thing on desktop. There are _commonalities_ between many users, but even in just the web browser space there are app-side hacks and workarounds just to get about 90% of the functionality that browsers expect on other platforms.
Even in your list, most desktop users don't need an IDE or do photography work. Many don't need "games", and "games" itself is such a broad category of things, each of which presents new and exciting Wayland wrinkles and limitations to ram face-first into.
Hell, I can't run KDE on F39 without a constantly running XWayland recording bridge for desktop commonalities that use or require screen sharing (Zoom, Discord, etc.).
And most of the issues might start with the Wayland project, but they're exacerbated by Qt and GNOME problems, whether it's doing little to nothing and holding back every dependent app (Qt) or constantly coming up with new and exciting ways to break or deviate from the protocol (GNOME). Those bottlenecks aren't new, but they're magnified by Wayland's slow-moving chaos, and drawn into relief by X11 Just Working because the hacks and garbage workarounds are damn near 40 years old.
It's been mostly fine for me as well, but that has only been the case because of things like Xwayland; there are a large number of styles of program that are either really difficult reimplement or simply can't work without it.
Multi-window programs, for example, are difficult to get working directly on Wayland. The issue has been brought up several times [1][2]. And it's not a particularly uncommon UI-style.
For example, most video production software I've worked with allows you to popout certain components into separate windows so that you can, for example, have your timeline, which may have many tracks taking up lots of vertical space, on a separate monitor from the preview viewport. This is a really nice feature. And the lack of its presence is one of the things I really dislike about DaVinci Resolve, despite it being an otherwise great tool with some of the best, if not the best, colorgrading utilities.
This isn't something unique and niche to video production either, though; lots of photo editing, audio production, 3D modelling, CAD software, and other scientific/engineering applications have similar UI. Wayland makes it difficult, though, because there isn't a good way to request or suggest the kind of positioning these programs need [1].
Anyway, that said, I, too, have lived with a mostly Wayland desktop for a few years without too many issues, even as someone who doesn't have the most "typical" workflows or needs. So, to an extent, I think you're not wrong; the idea that Wayland is *entirely* unusable is, obviously, not true.
But again, key point, *mostly* Wayland; without Xwayland or similar, I think it'd be genuinely unusable for me and likely many others.
While the compatibility layers genenerally work well, and in many ways, still provide many of the benefits of Wayland, like security, I don't think it's unreasonable to want a better, native way to deal with some of these issues so that people can drop the additional legacy abstraction.
I think it's also worth noting that just because /our/ Wayland experiences haven't been too bad doesn't mean that its the case for everyone.
As I, and several others, mentioned in other comments, there are several implementations of Wayland compositors, for example. Our particular choice of components/desktop environments might be fine, but others may be more broken or intentionally lacking support for useful/semi-necessary "optional" extensions to the protocol.
It'd be one thing to intentionally pick a bad implementation as a user and then complain about it. But sometimes, people aren't aware they're using Wayland in the first place, let alone which compositor they're using.
As a developer, even if you don't care for a particular implementation, unless you do as PCSX2 did, you'll still likely need to think about everyone elses' quirks as well, because too many of your users will also be users of whatever is most problematic -- e.g., GNOME is very popular and also has/had been one of the more annoying ones.
> Honestly at this stage, this stuff starts to feel like FUD.
I understand how you feel, now that I use Wayland everywhere myself. But I still remember when some things I used has issues and I have a whole list of a dozen of them.
Even now, using Wayland involves a LOT of compromise on my part. I'd have to stop my anger at CSD and issues with Global Menu a lot out of tiredness (still annoying - I have to run OBS in xwayland temporarily to access its remux menu). I have to contend with not having unattended remote desktop for my Linux devices. And I have to manually change how I set up fcitx5 instead of just setting it up in three lines in Home-Manager.
It's full of annoyances, but I'm tolerating it. Others... probably just don't have the patience, especially the devs who are supposed to fix these things for their app when they just want to focus on other things (especially multiplatform devs).
One post summarizes it pretty well. Jehan says:
> As GIMP maintainer, do you want me to open a separate report so that we explain our use case on multiple windows, as well as future planned use cases?
I find it fascinating. There is this supposed successor to X11, but it breaks a lot of existing applications, telling them that they are wrong. Because layout shall be done by the compositor, not by the application.
True, traditional desktop systems make a lot of invalid assumptions like Windows with a global physical pixel grid that makes it pretty tough to display windows which span multiple monitors with different DPIs correctly.
Yet still, they get one thing right: Positioning is a job shared between the application and window system. Because only the application knows the semantics in detail. Completely ignoring that and insisting on the application to only express these semantics via a previously-agreed upon protocol sounds pretty arrogant to me. This means that details will be lost. It's not up to the protocol designers to decide which semantic details are important. That's up to the application designer.
Oh, that's just one of many such cases. There's also the history of how it took years of requests, and pressure from Valve, for Wayland devs to consider letting the user disable VSync. Or the disaster around the UI scale, which until recently would be rounded up to the nearest integer, passed to the client, and the client's rendered bitmap would then be downscaled by the compositor to match the actual scale set by the user. Because who needs performance, accurate display of images, or subpixel antialiasing of fonts? Fortunately, they have relented on this too and a fractional scaling protocol got merged. Unfortunately, it basically obsoletes a core protocol field.
It's a whole repeating pattern: Wayland starts out with a weird and inflexible design -> Wayland devs try to make the whole Linux ecosystem conform -> they start backtracking after years of pressure, but now they have to add cruft/workarounds to the protocol. Happened to forced VSync, integer-only UI scaling, the compositor-driven render loop with no visibility hints, client-side decorations only... At this rate, Wayland will be full of obsolete cruft before it even overtakes X11 in popularity.
It is fascinating. And the answer he was given was "Yes"!
And then given the rate at which protocol changes happen, it will take YEARS to do anything.
Sebastian Wick said this:
> If we add a protocol like this, there is no going back. We will be stuck with it forever and have to live with this pain for the next 30 years when someone finally manages to write a successor to wayland that's willing to break backwards compatibility again like wayland did.
They're looking for "perfection for the next 100 years" instead of "good enough for now".
The concept of "window position on screen" makes no sense, since a compositor is allowed to display windows arbitrarily, and doesn't necessarily display them as 2D rectangles (for instance, they could be displayed in a VR environment at arbitrary 3D positions, or they could be warped arbitrarily, etc.).
Also, the window layout belongs to the user and compositor and it would be a security hole to let applications affect it.
If you want to position subwindows, you need to draw the subwindows yourself inside a main window like e.g. VSCode does with its various panes.
> The concept of "window position on screen" makes no sense, since a compositor is allowed to display windows arbitrarily, and doesn't necessarily display them as 2D rectangles (for instance, they could be displayed in a VR environment at arbitrary 3D positions, or they could be warped arbitrarily, etc.).
> No problem! For window managers like this, it is perfectly legitimate to just ignore the client’s positioning requests. The API specifically mentions that clients should not rely on absolute placement to happen. It is merely advice to the compositor to choose a sensible initial spot to put a window. Same goes for weird form factor displays or specialized compositors, of course (but those may not even implement xdg-shell at all).
Seems like the main reason to let apps know the absolute positions of their windows is for running Windows apps in WINE, and legacy proprietary Linux apps that were meant to work on X11. Wayland devs want a perfect, elegant solution, but they're just sticking their heads in the sand and hoping that reality will go away.
Yes exactly, tiling window managers frequently ignore applications trying to set window geometry. It need be no different for exotic VR wayland compositors or whatever else anybody has in mind. The existence of a protocol for setting window geometry and positions obviously does not mean every compositor must respect those requests.
I don’t know, deciding not to support multi-window mode seems ok to me. It’s a relic of the past and dragging around all that baggage often isn’t worth it.
...Now, I haven't used Linux regularly in a long time, so I may be misunderstanding, but unless "multi-window mode" means something very different than what it sounds like, it seems ludicrously arrogant to be declaring it a "relic of the past". Do you think every application should use no more than a single window, and fit its content inside that? Rather than being able to have a window for the main content, a tool palette, an information window, etc?
Just because that's the only kind of application you can imagine wanting to use or make doesn't mean that should be the only thing allowed.
Tell that to the people who like replicating their Workspaces at home using a remote connection that works everywhere on every OS....unless you are using Wayland.
>... it is disabled on our release builds, because it's nothing but headaches for us, because of its broken by design nature causing issues for users. I listed a bunch of them in the OP as well.
>We're sick of getting blamed for bugs in wayland compositors, while the various committees sit around arguing with each other, finally decide on standard ways of doing things after half a decade, then GNOME ruins it all by refusing to implement it.
Think of the efforts wasted in duplicate/overlapping functionality between maintenance + development of distributions, package managers, shells, compilers, C libraries, desktop environments, etc.
Unfortunately that's not avoidable. The duplication exists because of disagreement regarding how things should be done. The alternative is not "my preferred project gets all the resources" but "my preferred project doesn't exist and all the resources go to some fundamentally flawed project that I don't want to use". See Windows or macOS for how that turns out.
More popular, yes. Usability is subjective. The lack of tiling window management or decent package management on either of the most popular two desktop operating systems renders them unusable to me, so I'm quite thankful that the ecosystem is fragmented enough to cater to my apparently niche tastes.
I would say that the popularity indicates the higher usability. People find Windows and MacOS easier to use, with less random problems. I also don't understand what you mean by lack of package management? Homebrew on MacOS is very decent, on Windows you have Scoop/WinGet which work very well. Either way both are much less fragmented than the Linux flatpak/snap/.deb/AppImage/.tar.gz nightmare which a regular user will never be able to figure out. I swear it's like Linux advocates have never even talked to a normal person, and are somehow under the illusion that Linux is a easy-to-use, user-friendly OS, which .. it's not. Any OS that requires you to know CLI basics to install regular apps is not a user-friendly OS (Chrome gives a .deb, but on some recent distros it cannot be installed by clicking on it! IntelliJ gives .tar.gz, which, well, good luck figuring that out, and others give AppImage, which needs chmod+x!).
Unfortunately the fragmentation can be felt quite strong. A thousand different Linux "flavours", none of them work even remotely as well as MacOS or Windows does. Most Linux distros have never heard of decent user experience design, or consistency in design, and with everybody and their mom making a new linux distro every week it just seems more like a toy than something to use professionally (other than as a server, I guess).
> The duplication exists because of disagreement regarding how things should be done.
Is there too high a level of this disagreement in open-source software? Should it be called out from the perspective of "please try to use your time more effectively instead of contributing to fragmentation because it's harmful to the ecosystem from a macro perspective"?
Yes, you can see it as wasted effort, but this is a key component of open source. Projects are built on the ideas and code of other projects. Sometimes this is a joint effort of a community, and sometimes it's done by a single developer who wants to try something different.
And this is great. There's growth in experimentation and failure, and trying new ideas. Not everything is going to succeed, and not every project will seem like it was worth the effort.
Ultimately, the user benefits by the overwhelming amount of choice of software, but it can also degrade the experience as projects might not be well maintained, unstable, and sometimes even abandoned.
This gives the opportunity for companies to step in and focus on supporting only a subset of software, which can lead to a better user experience, with the tradeoff of users having less choice, and being forced to use their computers in a specific way. These are two different approaches, and one is not inherently better than the other.
GNOME as a platform (and by extension, all of their associated projects which unfortunately includes the Wayland protocol) has such a bizarre worldview - it's like they think they can treat the Desktop OS, with all of its user expectations and existing working software, and remake it as a bigger iPadOS, to no one's actual benefit.
What do I get in return for having to give up all of these things that used to work? It's not faster, it doesn't do extra things I couldn't do before - it's _strictly_ downsides all the way down
It's cool if GNOME doesn't work well for you, but for me it's near-perfect. For sure it's rough around the edges, but what isn't? GNOME helps me get work done, stays out of my way until I need it, etc.
I see so much general hate towards GNOME on HN, and it's really annoying. If it doesn't work for you, great, I'd like to hear why. But saying it's "strictly downsides" simply isn't true, nor productive.
Issues with GNOME come down to three inter-related issues.
* Configurability - GNOME goes out of it's way to remove any configurability from their DE. First they move settings to obscure places, next they remove them entirely.
* Compatibility - GNOME devs don't provide solutions for common use cases like window positioning or screen capture (yes I know that screen capture is now supported, but it's a compositor specific implementation rather than actually standardized by Wayland), at the expense of end users with those requirements.
* Consistency - GNOME seems to go out of it's way to do things differently from other mainstream desktop platforms. Windows does typeahead search, macos does typeahead search, KDE does typeahead search, GNOME does their own weird recursive search instead.
On their own each of these isn't a dealbreaker (I can deal with weird defaults if I can change them, I don't need as many settings if the defaults are less weird and don't break my software). But all three together is too much - GNOME looks like they are sitting in an ivory tower trying to dictate their opinions on desktop design to the world while having sub 1% market share. People won't drop window positioning or screen capture just because GNOME devs say so - they'll just not support Wayland. I know at least one real world person who swore off desktop Linux as a whole after Wayland screen capture broke at a critical time.
> [screen capture is] a compositor specific implementation rather than actually standardized by Wayland
This isn't actually true anymore. The standard way to do screen capture on Wayland is to use the org.freedesktop.portal.ScreenCast portal. AFAIK that's supported on pretty much every compositor these days.
It's great that it works for you. It doesn't work great for a lot of other people.
The hate is because the "Gnome developers" (and that's an unfair generalization on my part, but let's run with it anyway) have a long history of saying This is the One True Way to do various things, and unlike most other Linux DEs, Gnome has positioned itself as a general-purpose system, and it has the most commercial backing of any other DE. There have even been cases where every other DE wants some Wayland thing one way but Gnome devs want it another way. Gnome developers go so far as to attempt to rationalize why other use cases or desires aren't even valid (which is offensive).
In other words, the hating on Gnome isn't necessarily that Gnome itself is inferior to other systems, it's that some Gnome developers (and many interactions when it comes to standardization and interoperability) are condescending, dismissive, and they insist on imposing their (technical) will on the whole Linux GUI ecosystem.
My criticism isn't of GNOME en masse, but of this Attitude of "The users must be protected from apps and also from themselves". Other posts have outlined some of the concrete issues related to these decisions - usually when developers choose to intentionally remove functionality and knowingly cause user pain, it is in the service of some greater benefit; "This sucks, but users will have a net gain in the end"
My point is, the "net gain" simply isn't there - it's unclear if there is any gain at all from these decisions that plainly cause user difficulty!
Aside from bugs and driver issues, Wayland has some unfortunate design limitations. For example, Dear ImGui multi-viewports don't work because "Wayland doesn't let application read or write windows positions."
This is a feature available on Windows, macOS, and of course X11. Making choices like this means desktop Linux becomes even more of a weird island that nobody wants to support.
Imagine a program that utilizes several separate windows for palettes. If the program has no way to specify where to place those palettes, the user is going to be presented with a ton of palettes piled on top of their document window and that they’ll have to sort that out themselves, rather than a neatly organized immediately usable workspace. That’s not really an acceptable user experience no matter how you slice it.
Multi-screen situations is another place where this comes up, which includes not just multi-monitor desktop setups but things like foldable devices, and it can be useful to have functionality that lets the user designate a screen for a particular function (for instance, putting sliders and knobs for audio production software on a touchscreen) and have it available regardless of the compositor the user is using.
>Imagine a program that utilizes several separate windows for palettes.
One way this can work is: When the program starts up on first install with a brand new config, all those palettes are part of the program window. Then as the user decides to undock them one by one, they are removed from the main program window and a new window is drawn containing that palette. So the user isn't presented with "a ton of palettes"; they get them one at a time and can move them as they wish.
The rest of that (maintaining their position next to the main window, restoring them when the application is restarted) would be solved by a protocol that allowed relative positioning, which was already suggested in the wayland-protocols MR discussion.
>it can be useful to have functionality that lets the user designate a screen for a particular function (for instance, putting sliders and knobs for audio production software on a touchscreen)
This can already work today if the compositor provides a way to do it, as long as the application tags such a window with some unique `app_id` or `title`. For example in sway the user can write config rules to match windows based on such criteria and run position etc commands on them. I assume KDE also has something like this because I remember it having a way to match windows using X properties in the KDE 4 days.
> One way this can work is: When the program starts up on first install with a brand new config, all those palettes are part of the program window.
What if the program doesn't want a single-window mode?
Or what if the work to support a single-window mode isn't considered to be worth it when the only people who care are the 0.01% of users who are on Linux and care that the program isn't Wayland-native?
Of course the order of operations here was to break everything first and then start addressing the issues they feel like addressing when and if they get around to it.
Kind of a real FU way of trying to move things forward...
Yes, normally when you make a new thing you start with a small base and then gradually make changes to it, instead of adding the whole kitchen sink from the start and defeating the purpose of making the new thing in the first place.
Well, that's how you go about relearning old lessons. It reminds one of Chesterton's fence, where the ignorant tear down the fence and after much suffering end up building the fence back up.
> That’s not really an acceptable user experience no matter how you slice it.
What you're describing is what happens in most desktop environments any time you open multiple document windows at once. Why is it so much more unacceptable for this to happen to tool palette windows? Yeah, it's obviously not good behavior, but it's prevalent enough that it's clearly a manageable problem for end users and generally preferable to refusing to support multiple windows at all.
macOS will actually cascade multiple document windows opened at once so long as the dev has taken a moment to flag the windows as document windows, which still isn’t amazing but at least ensures that all opened windows are visible.
How is the window manager going to handle the positioning in a scenario like multi-viewport? The user already conveyed their intent by dragging a window out of the application's viewport to create a new viewport, and Wayland is prohibiting the application from obeying the user.
I'm just trying to understand why ImGui needs to read and write window positions, because it's not immediately obvious from that paltry description. It sounds like you're describing a use case where it needs to be able to set the position of a new window relative to an existing window. So APIs to read the position of the current window and write the position of the new window are probably what they're looking for—though I can readily imagine narrower APIs to handle that use case. Does that sound to you like an accurate explanation of their complaint?
(None of the above explains why ImGui cannot in the interim accept a janky experience where newly created child windows pop up wherever the window manager puts them, as commonly happens for transient dialog boxes. This seems like a nice to have feature, but not a complete showstopper.)
AFAICT from looking at the imgui wiki page and the examples in the OP of the wayland-protocols MR, it seems to be entirely that either these libraries have existing API that allowed setting the window coordinates and thus they want to be able to continue providing them, or these applications (like gimp) want to be able to recreate those windows at their previous positions after the application is closed and restarted.
It's also worth noting that that imgui wiki link says the feature doesn't work well in X11 either, though I didn't read the linked issue for what exactly is broken there.
The position being wrong isn't the only issue - if you can't programmatically reposition a window, you have to break the user's drag gesture into two drag gestures, one to 'pop out' the window and then the user has to find it and grab it again to move it.
I get why GNOME devs don't wanna implement it (most of the times looks out of place for the app, or the app looks out of place to the system if it doesn't use the system toolkit, so it's just better for them to roll something that looks good for the app) and the XWayland implementation for SSDs are still a holdover that would need to be ported that they don't want to do. But then again to my knowledge QT has a way to make a header bar (I think even one in GTK style) and there is libdecor that handles headerbars.
> Inability to position windows
xdg-session-management is being worked to handle restoring of window positions. There are some contensious extensions being discussed about other window placements but they are still very much in flux. I personally am impartital for the actual use of the features and if they are really that necessary.
> Hacks in render-to-main because WL craps itself otherwise
This sounds more like a problem with the project itself than wayland considering the meriad of other things able to work, but then again its an emulator that might be doing some very weird stuff so I can't say much about it.
> Despite said hacks, game list still glitches after stopping emulation, happens more often in gnome
Probably a cascading problem from the previous
> NVIDIA just crashes in swap chain creation under Wayland
Not exactly too surprised, although my laptop with Intel/NV hybrid has been working mostly fine for my mostly basic usage.
> Broken global menus
Those are a thing anywhere other than OSX? How do they handle this on Windows?
Windows doesn't have global menus, it defines an API to get the workspace coordinates, which allows apps to know the area available to the window (i.e. not covered by the Start Menu)
If you mean wayland compositors in general, that's more like 15 years according to [1].
For gnome's Mutter, it's 12 years:
> Until they sort their s*t out, which is unlikely, since there's been very little progress over the last decade, just keep it disabled.
Begging the question if Wayland itself is already antiquated and if its maintenance perspective is any better than X.org's. When lack of developer motivation to work on X.org appears to be the sole point of leaving it behind since new apps haven't been created and (Nvidia) drivers for Wayland may still be problematic.
I can totally understand the desire to start with a clean architecture, but chances are we have to basically start over at square one, with the problem of how to attract younger devs now who want to invest their time into newer languages and/or graphics pipelines rather than maintaining Wayland.
Ignoring the exponential pace Wayland has improved for end users in the last 36 months (see for example Plasma/Wayland Showstoppers[0]), would staying on X11 not be more of a sunk cost fallacy? There aren't even any Wayland alternatives with meaningful momentum
It's entirely possible that both suffer from sunk cost fallacy, and from that analysis there isn't a "better" or "more" sunk cost. It's already sunk, anything you sink further into it is a waste.
Right. X11 is just old and widely used. Wayland is entrenched in its own bad decisions. It used to be one legacy and one new thing, but now it's one legacy and another dragging its own legacy.
So what's your suggestion start a 3rd initiative ?
It will suffer the same same problems that Wayland has. the problem is that X is flawed at the design and level and whatever you propose that fix those design issues will face the same type of push-back from the communities that don't like it because it's not the way their grandpa taught them to do things.
keep in mind the wayland devs are the xorg devs that gave up on that project because how hopeless it was to fix things around.
I think it's more interesting how Wayland has worked fine for me on AMD, Intel, and Nvidia for the last 4 years on my personal machines and work machines, and yet here we are still talking about if it works or not.
If you pay enough attention you'll start to notice the same users names across comments and threads. Hallmarked by ignoring any replies, repeating their pet peeve, repeating experiences from years ago as if they were recent re-tries, and ignoring the laundry list of features possible with Wayland that are impossible or declared as never happening with X11.
I made the mistake, I clicked the thread, and even replied. Meanwhile, I too have been using Wayland for years without issues. I'm on multiple video calls a day for work. I give screen share demos on Discord and Meet. Literally the only issue I've ever had was gamma ramp support, due to Nvidia, and they've even finally fixed that
Idk, see the Pipewire threads for more examples. And/or insert the link to the XKCD comic about the foot pedal. It's all so damn entitled too, from seeming OSS adjacent folks that apparently don't understand the first thing about OSS work. Those same people will never even acknowledge that "Wayland devs" ARE THE DAMN "X11 devs" and they've all declared X11 bankrupt. Buncha people here need to start ramping up on their non-XWayland X11 codebase knowledge if they think they're going to go the MATE route or something.
I too, have been using Wayland for quite some time.
I have some issues with it, but by no means they are deal-breaker, otherwise I'd have returned to Win10.
Most issues (that I've faced) are related to Hardware Acceleration, which, by my knowledge, is a common issue in Linux ecosystem; others are NVidia related, when playing games.
From my experience, overall: it's fine. (At least on KDE Plasma.)
Why should someone care about the laundry list of features that Wayland has if they don't need those features, and the feature that they do need doesn't work?
If I simply plug and unplug my laptop from the dock, my windows wind up randomly scattered between both laptop and monitor. Is that considered "works"?
Lots of people have lots of complaints. I, myself, have more than a few.
I'll go further. The fundamental problem is that Wayland CAN NOT be fixed. The underlying design architecture is simply not correct for modern hardware and its abstractions.
The problem is that a GUI is such an enormous pile of work that nobody can arise to compete with QT and GTK. Both of those toolkits are 20+ years old and desperately need to be redone from the ground up.
And, it's worse than that globally. Mobile/Web GUI and Desktop GUI have fundamentally different abstractions. Yet, because a GUI is such a huge pile of code, nobody wants to have separate GUIs for Desktop and Mobile/Web.
This is why something like Electron exists. No one wants any of the dumbass GUI toolkits--not Windows, not macOS and certainly not Gtk or Qt.
And, yes, I pile Mobile and Web together. Most people now interact with Web via their phone. This is painful to me, but it is simply reality.
> If I simply plug and unplug my laptop from the dock, my windows wind up randomly scattered between both laptop and monitor. Is that considered "works"?
1) that doesn't happen on my compositor
2) You can solve that yourself or pay someone to solve it for you. Unless you have a contract, you are not entitled to anyone elses time.
> The fundamental problem is that Wayland CAN NOT be fixed. The underlying design architecture is simply not correct for modern hardware and its abstractions.
I simply don't care. It works for me, better than anything else I've tried on any operating system. The fact that you disagree with Wayland abstractions has no impact on my real world use.
> [...] Both of those toolkits are 20+ years old and desperately need to be redone from the ground up.
Great idea, looking forward to your (contractors?) repo :-)
He can't, since the gfx part of Wayland is a thin, event-based abstraction over the modern hardware. It basically manages buffers between the hardware and clients.
The comparison to Qt, Gtk or Electron is also very wrong; it is an entirely different layer in the stack.
I'm using it full-time and the only issues I experience are with XWayland. But even those have been going away as native Wayland support lands in apps and nVidia slowly improves their drivers.
Scaling and overall performance it's night and day versus X11.
A way forward probably looks like a more feature-oriented fork of wayland than a do-over. The basic protocol is fine, it's just there's no sense of urgency to actually add important features to the standard, just a long design-by-comittee process which bogs down progress and frustrates developers and users.
There doesn't need to be any sense of urgency; see all the people complaining that there is no screen casting API? Well, it was implemented three years ago by all three major compositors, and they still didn't manage to notice.
It's been ready ready for a long time now. It's been on by default in Fedora for a long time now and I've not experienced issues. Or at least fewer issues than with X11.
Ready ready on what? Select hardware? I've thrown 4 regular off the shelf laptops at various DE's using Wayland and they all suck in various ways to the point that they're not even usable. Meanwhile I can throw Windows on all of them, and they work flawlessly. I'm quite tired of Linux guys saying their stuff works just fine, without mentioning how extremely limited is the hardware support to actually run any of those things, and judging from various forums, even if you have supported hardware, things break.
It's ready for me in that it works better than X11 on my hardware. No it's not flawless like MacOS and to some extent Windows, but it's certainly an improvement over what we had.
I don't understand what you're asking or why it's relevant to what I said. Did you mean to reply to someone else, or did you think that I was the same commenter as someone else?
I’ve used Linux for over 10 years and I don’t even know what an xorg config file is. I suspect most users don’t. I wouldn’t expect my desktop environment to require any config.
That stands to reason - the last time I had to edit xorg configs was probably over 15yrs ago getting multi monitor working before xrandr. Since 2005ish, xorg seemed to be able to happily autoconfigure itself.
I mean, of course that's the case? xorg.conf* applies to X (the process) which isn't running any longer. Also, most people haven't need d a xorg config in a long while, except for unique cases.
I would hesitate to call MacOS flawless. When I had to use it (m1 pro), it had more issues than Fedora with gnome (which has virtually no issues on the 4 systems I have running it). MacOS wouldn't work with thunderbolt dock, wouldn't work with some monitors / resolutions, requires a paid app to get middle click on touch pad (which is beyond laughable, but goes to show Apple users will pay for anything). The settings GUIs have more legacy than Windows. The updates are terrible... it will uninstall dev tools after an update, and looking at the size of them it's like it downloads and reinstalls the entire OS each time.
Curious, what sort of hardware issues? I don't have experience with Nvidia, but on Intel, my experience is equal on gnome (in fact, quite improved for the last couple of years - more fluid animations, less lag, etc). I've had this experience on thinkpads and most recently a framework laptop (though, vendor hardly makes a difference in this case).
Most of the issues are Linux auto-installing wrong graphic drivers, which then after a reboot results in a broken DE that doesn't work, and I don't want to spend my time manually verifying every update it tells me to install. I've had that in latest Ubuntu and Mint, to name a few. Other common issues I stumble upon is lack of audio driver support with either the audio not working at all, or working badly (no bass at all, very thin sound). Trackpad multi-touch support is bad in pretty much every distro (no decent gestures support, horrible inertia). Then of course what is now a running joke that Linux is unable to put my computer to sleep, so when I close the lid and open it again a few hours later, the battery is drained. So and so forth, and this is why I will not use Linux, because I don't find tinkering with any of this enjoyable at all, and want to get on with my work.
> Most of the issues are Linux auto-installing wrong graphic drivers,
What? Since when linux auto-install drivers?
You get those with your kernel and mesa (except nvidia). There is no installation.
> Then of course what is now a running joke that Linux is unable to put my computer to sleep, so when I close the lid and open it again a few hours later, the battery is drained.
Windows has exactly the same problem. You can thank "Connected standby" (pushed by Microsoft) for that -- neither Linux, nor Windows puts computer to sleep. They ask the firmware to put the computer to sleep. If the firmware is buggy, here's your problem.
It's about the GPU used in regular laptops, I'd imagine, for which Windows has drivers and support, and Linux does not. That's my point. X11 for those laptops works more reliably, but even then there's immense screen tearing, blurry texts, broken fractional scaling, etc. I just don't know why I would ever use software of this quality when even Windows XP had less issues like this in its hayday, and it released 20 years ago.
What a refreshingly honest commit message. The corporate over-professional dribble on work commit messages is so bland by comparison. That being said, I'm still left wondering if Wayland support on one of my projects is a problem.
I'm not sure if it's funnier to see popular projects shunning wayland because it sucks or Linus looking to move kernel development away from an email based workflow because "it really isn't working anymore". There is such an insane amount of coping about both of those topics online.
> NVIDIA just crashes in swap chain creation under Wayland
I'd say ignore Nvidia, their Wayland support is junk (until nouveau+nvk catches up). It's not a Wayland problem, it's Nvidia problem.
For dealing with CSD mess, there is libdecoration that SDL started using.
In general - just use SDL for for DE integration, instead of trying to reinvent the wheel.
Wayland is not broken. But if you are trying to reinvent the wheel of supporting it from scratch, you'll be hitting a lot of things that need to be implemented. So as above, don't do it. Others already did it for you.
Right, ignore it on Wayland because their drivers on Wayland are supported so poorly that's it's not worth wasting your time. It started getting a bit better lately, but it's still far from good.
I'd expect nouveau+nvk for it to catch up sooner than blob will become decent on Wayland.
Wayland is good until you hit the corner cases that the dev decided to abandon without leaving any alternatives. We can always have extra protocol that can be optionally enabled, but good luck with standardizing that. It feels as if Wayland people are abusing their committee to keep Wayland as-is, instead of extending it. The protocol dashboard[1] doesn't look exactly good.
>Hopefully, this doesn't mean weston developers can block essential protocols.
Of course it means that. Weston developers are core developers of the Wayland protocol, as are developers of other compositors. Also, not only weston but wlroots also NACK'd it (for the same reason). If compositors refuse to implement a protocol then there's no point to merging such a protocol.
Also to be clear, it was blocked from being added to xdg- namespace, and was thus moved to ext- namespace where it can still be worked on.
The internet is full of people that will inform you that all the stuff that stops working when switching to wayland is your own fault and you're a liar anyway.
I'm quite convinced these people just use windows and occasionally open linux in a vm for 10 minutes.
In my experience Wayland is pretty bad on Nvidia binary driver, has some annoyances on Gnome and works fabulous on AMD hardware with KDE or a wlroots based compositor.
Never tried it on AMD hardware, but I can confirm Nvidia drivers cause it to go haywire on all 4 of my machines. I try yearly or so, see everything's still a dumpster fire, and head back to X11
I have no problems with recent Ubuntu & Gnome & Wayland, unless I launch a game in Steam, and then it's a mixed bag (tho getting better).
And in fact multimonitor support esp with multiple DPIs & resolutions works much better with Wayland than with X. For that, X is just a terrible experience.
Due to the headline, it has dawned on me just now that the Steam Deck uses X11. Been using PCSX2 successfully on it for several months now. I never thought about whether it was using Wayland or X11 until reading this.
Ironically, the Wayland compositor used by the steam deck, gamescope, doesn't support native Wayland applications. Even weirder, it runs inside an X11 session.
To be fair, that includes a huge portion of the games available on a Steam Deck right now, given that Wine (and by extension Proton) currently only support running via XWayland. On the other hand, that's argument in favor of Wayland from my perspective; if something I want to run doesn't support Wayland, it doesn't actually stop me from using it.
Public service announcement: you might have switched from X to Wayland (as display server) without your having realized simply by upgrading your distro. To find out: printenv XDG_SESSION_TYPE
BTW, Linux/Wayland has been my daily driver for 3 years, and I'm happy with it though I don't have Nvidia graphics and don't need to record or share my screen.
> KDE isn't too buggy, GNOME is a complete disaster.
What did the author mean by this? Don't know much about Wayland other than it is window system, replacing x11.
KDE Plasma wiki[1] says, "KDE Plasma 5 is the fifth and current generation of the graphical workspaces environment created by KDE....KDE Plasma 5 uses the X Window System and Wayland."
KDE and GNOME roll their own wayland libs for their compositor.
These have varying levels of quality with their own unique quirks and bugs. The "gold standard" for wayland at the moment is wlroots which is what basically every other wayland compositor uses. PCSX2 apparently works perfectly fine on wlroots based compositors but has some quirks with KDE wayland and is nigh unusable with GNOME's super janky wayland implementation.
Funny, I've used a wlroots environment recently (hyprland), and noticed tearing in animations that I don't have in gnome. So, I guess I'll take "janky" :-)
Sorry, "tearing" isn't the correct word. I use the swipe gesture to "peak" at another workspace - if I have a video playing in that workspace, for example, it'll have artifacts in the playback while I'm mid-swipe. On gnome, the picture is perfect - I can swipe half-way, and the video is playing frame-perfect, as if the workspace was in focus.
There is no de-facto Wayland software like there is the X.org server. Wayland is just a protocol—KDE and GNOME (through Mutter) both implement it. The author is saying that KDE did so better than GNOME.
Briefly: it's a big lift for all the different desktop environments (DE) to move from X11 to Wayland. Lots of moving parts; re-implementing and re-factoring is needed.
Oh, I've got a Chromebook; didn't know it was all Wayland.
I'm thinking that it "just works" there because G has more resources to patch all the needed features. More resources than KDE or Gnome or others have available.
I assume its mostly because how you said they can do it and the impact is really only limited to their system AND chromebooks are to my knowledge way more focused of a UX than what Wayland needs to be able to support so they can be even more opinionated about what they support and how
As noted by other commenters, there are several compositors available for Wayland (essentially the bit that actually implements Wayland).
Some are developed independently of any particular desktop environment--like wlroots, labwc, hikari, etc--but some are part of a larger project, such as mutter and kwin (GNOME and KDE, respectively). Most of the time you install some sort of GNOME/KDE + Wayland distro, you'll usually also end up with their compositors, and thus potential quirks specific to their implementations.
GNOME's implementation in particular has historically caused a lot of drama relative to some of the others -- be it due to purely accidental, broken support for something, or sometimes intentional opposition to a particular concept that many applications rely/used to rely on, like server-side window decorations [1].
The accidental issues that come with fragmentation of the ecosystem and the intentional decisions by different compositors to not support particular extensions/whatever, like the aforementioned, can cause a fair bit of pain for developers of end-user programs.
Users who may be totally unaware of the inherent differences between Wayland and X, who may not know that different compositors exist, who may not even know they are running Wayland, etc, inevitably run into strange issues, and then, understandably, file bug reports.
This can get old quickly under normal circumstances. But I imagine it sucks even more when you're maintaining software that is relatively understaffed given its importance. Outside of PCSX2, mpv would be a good example:
- It's incredibly popular software on its own, being probably the most popular open-source, cross-platform mediaplayer after VLC.
- It's also embedded and used as a base for other applications on a wide variety of systems, ranging from other open-source players that try to integrate more tightly with a given platform--e.g., IINA (macOS), mpv.net (Windows), etc--to proprietary, commercial software, such as a variety of Android players and, importantly, Plex, which uses mpv as the default backend on at least tvOS/iOS/iPadOS.
- It's software that needs to deal with pretty low-level graphics and audio stuff, so it's inherently a bit complex, and the available pool of potential contributors shrinks.
- It tries to be as lightweight as possible and allow for easy embedding into other applications and porting to different systems, so it has several things working against it:
-- It's mostly written in C, making it very easy to build and embed anywhere, but not only is C not the sexiest language in 2023 to many, it's also a hard language for someone without a good grasp to write safe, quality code, particularly for something like mpv.
-- It doesn't try to enforce a particular rendering backend--e.g., OpenGL, DirectX, Vulkan, Metal, software, etc--nor a particular UI toolkit. Again, great for someone building on top of it. But it makes things like the change from server-side decorations to client-side significantly more annoying / potentially fundamentally incompatiblew ith the project goals.
mpv sits in that perfect anti-goldilocks zone:
It's important enough to be a problem if it were to disappear, yet unlike the Linux kernel, not quite important enough to have the funding and hoardes of patches despite the project complexity. It's also low-level enough to need to worry about every display server and platform on the planet, yet not low-level/general enough to have a say in the design decisions (e.g., Wayland membership, I believe, is pretty much limited to compositors and UI toolkits - like QT/GTK).
All of that, and probably more, adds up to maintaining a surprisingly important, difficult project with relatively few developers but likely many millions of users, many of whom may not even know you exist; it's thankless yet important work.
As a result, unsurprisingly, in addition to the infamous locale rant [2] (unrelated to Wayland), mpv used to have a pretty spicy wiki section entirely dedicated to GNOME's Wayland implementation:
This section still kind of exists, but it has been toned down a fair bit now that certian issues have been addressed [3]; it now mainly focuses on a couple of specific GNOME issues directly and more broadly addresses NVidia's poor Wayland support relative to some other vendors.
FWIW all the reasons seem like an aversion to complying with how Wayland works.
Yes, you can't position windows absolutely, but that's because you're not supposed to do that.
In any case I don't see how being able to position windows is relevant at all to PCXS2's functioning on Wayland? Just don't position windows if you can't?
It's an incredibly dumb reason not to support the protocol. Xorg is mostly unmaintained AFAIK.
> FWIW all the reasons seem like an aversion to complying with how Wayland works.
The absolute last thing you should want from a platform is to have to "comply" with its weird decisions and assumptions on what people will or won't want to do (especially when people clearly do want and already are doing said things).
> In any case I don't see how being able to position windows is relevant at all to PCXS2's functioning on Wayland? Just don't position windows if you can't?
From a user point-of-view Wayland is perhaps at a level of nitpicks of problems to some extent (haven't used it myself), but from a developer point-of-view it's, plain and simply, incomplete, with its refusal to support trivial things possible on X11 & Windows & macOS (i.e. everything else).
(not a PCSX2 user/dev, just searched for the issues; for reference, I've had the displeasure of writing code directly interfacing with X11 and so wish death to X11 as soon as possible, but wayland's still a horribly-opinionated mess)
40 years ago people did not care about malicous applications, nor did they care about jank, nor did they have the hindsights that we do know. Those API only still exist because of backwards compatibility.
Yeah, I find the creep of web app security mentality into the desktop to be a disaster. I want to be able to easily snoop on and control my GUI and I absolutely don’t want some display system to decide it knows better than me about this sort of thing.
> That don't mean that every random program needs to be able to. If a program is to be able to snoop, it needs to explicitly given the ability to do so.
I strongly disagree with this, this is how you get inconsistent, annoying computing experiences
I'd perhaps say that security can be a good idea, but it needs to be done well for it to be so. And not at all implementing a potentially-abusable feature, while counting as "secure", is absolutely not doing it well.
I think it's coming from developers with proprietary backgrounds who want to normalize the running of untrusted proprietary software on the Linux desktop, probably from some appstore with abysmal quality standards like Android and iOS. Contrast this mentality with sticking to Free software you downloaded from the official Debian repos.. why do I need to be protected against that software? I don't. These mobile-like desktop protection schemes are designed to facilitate mobile-like software consumption habits. Fuck all of that!
Even if you are someone who wrote their whole user space from scratch and don't use the internet or open any files made by others, you are not representative of the larger userbase. A lot of people download random software or libraries that could be malware or even just buggy (eg. The time Steam unintentionally deleted user files). These people want to gain utility from all of this software without having to worry about the software being able to do bad things.
In other words you want to facilitate the bad user habits of Windows, iOS, Android, etc on the Linux desktop. Why do you even want to use the Linux desktop in the first place if you prefer those systems? Stick to what suits you instead of trying to assimilate the niche holdout systems like some sort desktop borg.
>you want to facilitate the bad user habits of Windows, iOS, Android, etc on the Linux desktop
They are not bad user habits. They are only bad if the system is poorly designed. Unfortunately, the Linux desktop was poorly designed and the community is taking their sweet time to fix it.
>Why do you even want to use the Linux desktop in the first place if you prefer those systems?
It's just what I am used to using. I ackowledge the security of my computer sucks and I could be easily pwned at any time.
>trying to assimilate the niche holdout systems like some sort desktop borg.
I want the Linux desktop to be viable to use. Having competitive security compared to other operating systems is important. People shouldn't have to worry that using a Linux desktop will mean that a bad program can steal all of their accounts or delete all the files they have been working on. These type of things are preventable by the system and just blaming people that they should have known that what they downloaded was malware even if it is not at all obvious.
That all sounds like a better case for sandboxing our data rather than sandboxing our applications. The application-centrism is an iOS-ism (and now a Mac-ism, but I repeat myself) designed to facilitate Apple’s economic model where they are the sole gatekeeper of what a computer is allowed to do. People blindly copy that model into the Free Software world because Apple are Very Rich and so everything they do is automatically a good idea.
Maliciousness like wanting to open a window at a given location? That's seriously bad behavior and I hope the offenders will be stopped promptly and prosecuted. I didn't think evil like this existed in the world.
No, maliciousness like having a window move itself high enough that the close button is off screen or malicousness like the window dancing around, potentially causing other windows to also be noted around as the window manager responds. Yes, these can be somewhat mitigated by the window manager but the fact that every window manager will need to think carefully about the security of this hints that the design of the protocol is exposing a bad abstraction or interface.
> Yes, you can't position windows absolutely, but that's because you're not supposed to do that.
Why not? This seems like a pretty opinionated policy from something that's supposed to be a platform to enable applications. Why should some other developer dictate how an application should work? I'd expect "My way or the highway" from Apple, but not from a linux API.
It's more nuanced than "should be able to do it" and "shouldn't be able to do it". The problem is covered in the wayland-protocols MR that the PCSX2 PR author also linked to (and failed to appreciate): https://gitlab.freedesktop.org/wayland/wayland-protocols/-/m...
I don’t think anyone “failed to appreciate” that thread. The core reasoning on the part of the Wayland devs was absurd beyond belief.
“Applications and users decide what's actually optional - if 10 applications work on all the popular compositors but don't work in one with a novel approach to window management, then that compositor is considered broken, not the applications.”
So, the obvious solution to the problem is, apparently, to have no solution and have everything broken. Genius.
Thanks for the extra context. I don't have a dog in this particular race, but I think, as a developer, I'd look at that list of excuses and just say "Why bother, I'll just target X and get on with my life." The great thing about Linux is there's usually at least one other alternative for basically anything you want to do!
Wayland and systemd are two topics that I credit with showing me that I shouldn't give too much weight to the consensus on Hacker News and Reddit. Things turned out opposite to the prevailing sentiment at the time.
systemd faced an enormous torrent of criticism for replacing the simple sysvinit with something more complex. Yet, sysvinit was only simple if you focus on the init program only instead of taking a systemic view. Under sysvinit, if you wanted to turn a regular command-line program into a daemon, you had to code a whole dance of closing file descriptors, sanitizing environment variables, forking, calling setsid, forking again, resetting the umask, and so on [0]. You had to make sure that all code writing to the standard output and error streams was changed to use the syslog. You also had to manage a pidfile in a way that was free of race conditions. People would write the same logic over, and over, and over again in different projects and programming languages.
On the admin side, a server system with a sophisticated configuration that involved starting daemons when a connection arrives, automatic restarting, e-mailing on error, and so on, could easily turn into a complicated maze of interacting programs and shell scripts. To get the full picture of how a daemon is actually managed, you would need to check many config files with completely different syntaxes.
systemd has greatly reduced this pointless duplication of effort by centralizing the complexity into a single, well reviewed set of implementations. Now, you can take a small program that runs in the terminal and prints log messages to stdout and, with a single INI-like file of a dozen lines, turn it into a daemon whose process supervision is better than anything you could implement yourself. The ease of configuration encourages you to add features such as automatic restarts, resource limits, or dynamic users, which you probably wouldn't have done on sysvinit because it was a pain in the ass.
Wayland, until recently, almost universally praised, but it does the opposite. In order to keep the protocol pristine, it just pushes complexity onto everyone else and ends up making the situation terrible from a systemic perspective. Wayland can push video from a regular program (client) to a privileged one (compositor), but when asked about pushing video the other way to record the screen, they went "not my problem" so pipewire has to handle it. There is no longer even a set of standard command-line utilities you can expect everywhere. On X11, you can type a setxkbmap command to tweak your keyboard layout at runtime regardless of the desktop environment. You can get information about the connected monitors with an xrandr command. In Wayland, every compositor has its own way of handling these, and sometimes you can't even change a keyboard setting without restarting the compositor. What a regression and a blow to the community of tinkerers who like to share small utility scripts with one another.
These are just two examples, but I don't think that Wayland's approach of targeting specific use cases, instead of providing a set of general tools, can ever work well when combined with its bureaucratic approval process. It took years of asking before Wayland devs decided that maybe the user should be able to disable VSync after all. It also took years to backtrack from the bizarre choice of making the UI scale integer only instead of just exposing the real fraction set by the user.
As long as the option to keep it turned on exists, I have no issues with this. It's one thing to move forward with a new stack, but it's a different thing to have it as default when it doesn't fully work
Actions like this will just hurt Wayland in the long run. It needs more users, and for that more applications that support it by default. No one will bring X11 to the level of Wayland, but someone might fix the existing Wayland problems.
X11 today works better for more users than Wayland. No user will want to switch to something that provides a worse experience.
Until these issues are ironed out, it's delusional to think that making Wayland the default will make users happy. Keep it as an experimental feature, and once it provides an objectively better experience for everyone, make it the default.
These technical discussions by folks in the trenches often miss the forest for the trees. Users don't care that X11 is difficult to support, develop and maintain. They just want a working system. By the looks of it from this GH issue, Wayland is also a pain for developers. What a sad state of affairs for Linux.
I guess I'm just hoping for some user that will be bugged enough by problems in Wayland that they decide to fix them. The chance of that increases with user count.
I understand that the bulk "forest" of Linux users don't care about their window manager / desktop environment, but it's a higher number than in other operating systems. This approach wouldn't work in Windows or MacOS, in Linux it might.
Why learn about wayland and figure out how to fix things (and then probably have gnome developers never ever accept your fix) when you can just switch to Xorg in 3 seconds?
Because nobody maintains Xorg anymore. Wayland was started because the Xorg developers thought Xorg had come to the end of the road and was unfixable. You can think of Wayland as X12, except without copyright/trademark concerns.
Sure, X11 "better", as long as you don't have high or mixed DPI screens, appreciate variable refresh rates, arbitrary scale factors, don't mind inconsistent tearing, aren't bothered by using a openly unmaintained, abandoned critical piece of desktop infra, etc.
Otoh, if you're willing to buy a GPU from a vendor that doesn't snub Linux, or maybe god forbid change screenshot programs (doubt you even need to nowadays), you get plenty of benefits with Wayland.
Edit: athe kind of person that downvotes comments like this are some of the least respectable, laughable, on the planet. Shove your fingers in your ears harder and make that tantrum louder. I'm sure it will convince X11 devs to abandon Wayland and return to the project they declared on life support, yup. That's how these things work.
The “oh, just don’t buy a GPU from NVidia” point is one I see made a lot when discussing Wayland’s failures, but it completely misses the fact that CUDA is currently the only viable option for GPU compute in many situations. If any significant part of your desktop usage involves such compute, that’s not a solution - or rather it’s a solution that renders your system less capable than it was before.
Though in a sense that’s consistent with Wayland’s general “you’re holding it wrong” approach of shifting blame for any problems onto the person reporting them and concluding that anything that doesn’t work well isn’t a valid use-case anyway.
> Sure, X11 "better", as long as you don't have high or mixed DPI screens, appreciate variable refresh rates ...
Tell that to the PCSX2 users who experience issues on Wayland, but not on Xorg.
This is what I mean by missing the forest for the trees. There's no doubt that Wayland is technically superior to Xorg in many ways. But technical superiority means squat if applications are misbehaving and crashing. While developers are arguing about who should be in charge of window placement (FFS, how is _this_ still a discussion after *15 years*!?), the only thing users get is a poor experience.
> Shove your fingers in your ears harder and make that tantrum louder.
I didn't downvote you, but maybe you should follow your own advice and realize that Wayland does not work great for everyone. Your type of dismissals are the equivalent of "works on my machine".
Not sure it will do anything to hurt Wayland. The app will just run in XWayland which is mostly impossible to tell between a native Wayland app for users.
I might not be up to date on this, but does fractional scaling work at all on Linux under any setup? Last I checked GTK just flat out didn't support it or something.
KDE supports fractional scaling. GTK doesn't and as a result neither does GNOME. There's hacks in gnome to work around this by faking it with downscaled integer scaling (render at 2x, squash into 1.5x) but it never provided a good experience for me.
> But Wayland is just broken, and everyone would rather sit around arguing with each other instead of actually addressing the design flaws.
> It's not the first time such a proposal has been put forward. Something that developers need for their applications to work properly on WL (particularly multi-window applications), and it gets vetoed. Every other OS manages this fine. But apparently we're in the wrong for not conforming to some warped view of how applications should be, despite our applications working fine on every other platform.
This is so damn true. Wayland lacks a Linus-style BDFL saying that the kern... the compositor is for applications, and not the other way around. We won't have nice things until Wayland maintainers stop thinking about what their end users must or must not do, and start closing feature gaps with X and compositors/window managers on other OSes. Right now they're reinventing the wheel while making it square.