Live data from Hacker News

PCSX2 Disables Wayland Support

github.com

41–50 of 208 posts

Re: PCSX2 Disables Wayland Support

#41
post #20

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 AF…

> Yes, you can't position windows absolutely, but that's because you're not supposed to do that.

I think about 40 years of GUI APIs disagree with this.

Re: PCSX2 Disables Wayland Support

#42
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

Re: PCSX2 Disables Wayland Support

#43

> 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." [1] https://en.wikipedia.org/wiki/KDE_Plasma_5

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:

- https://github.com/mpv-player/mpv/wiki/FAQ/ddcbe1b88a99d2568... (2020)

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.

-----

[1]: https://gitlab.gnome.org/GNOME/mutter/-/issues/217

[2]: https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f02...

[3]: https://github.com/mpv-player/mpv/wiki/FAQ/a70c96040ad4fa374...

Re: PCSX2 Disables Wayland Support

#44

Earlier quoted context omitted.

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.

Xwayland is instantly recognizable as shitty due to fractional scaling. Which almost everyone with a modern laptop uses.

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.

Re: PCSX2 Disables Wayland Support

#45

My opinion on a few of the points they have: > Stupid obsession with CSD in Gnome 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…

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)

Re: PCSX2 Disables Wayland Support

#46
post #20

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 AF…

> 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.

Re: PCSX2 Disables Wayland Support

#47
post #20

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 AF…

Even if X11 goes away XWayland will be around.

Re: PCSX2 Disables Wayland Support

#48

Earlier quoted context omitted.

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…

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.

Works flawlessly if you've never edited a Xorg config file… if you did, there is no way to keep using the same configuration

Re: PCSX2 Disables Wayland Support

#49
post #20

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 AF…

That thread is a fantastic reason to never run wayland.

Re: PCSX2 Disables Wayland Support

#50
post #34

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…

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.

Post reply on HN