PCSX2 Disables Wayland Support
github.com
github.com
> 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.
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.
What ways specifically?
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.
> 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'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.
> 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
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.
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.
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.
---
[1]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/m...
[2]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/i...
Related:
- https://github.com/PCSX2/pcsx2/issues/10065
- https://github.com/mpv-player/mpv/issues/8692
---
EDIT:
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.
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.
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.
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.
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.
This is a poorly thought out objection (sounds more like a rationalization), neatly addressed here: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/m...
> 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).
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".
>... 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.
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.
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
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.
2) They completely removed the keyboard shortcuts css mechanism, so I can't have emacs-like text navigation everywhere
3) They even removed local shortcut customization capabilities and replaced corresponding dialogs with useless shortcut reference window
4) There is no working systray implementation
5) their community is extremely hostile, seemingly they sadistically enjoy telling users to "fuck off, we kno better"
I was a happy gnome user since 2005 until ~2017 but this shitshow is not bearable anymore.
* 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.
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.
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 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!
https://github.com/ocornut/imgui/wiki/Multi-Viewports
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.
(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.)
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.
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.
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.
Kind of a real FU way of trying to move things forward...
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?
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.
> 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 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?
[0] https://community.kde.org/index.php?title=Plasma/Wayland_Sho...
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.
Are we sure _this_ isn't the problem?
Distros that "work" have to pin and lock your X11 and kernels to get the magic combination.
Nvidia has been terrible for a while, and this is not Wayland specific.
My Intel and AMD laptops have worked great.
My SteamDeck is awesome.
Eu escrevo 5 línguas adequadamente.
J'écris cinq langues bien.
Escribo 5 idiomas correctamente.
Scrivo correttamente 5 lingue.
The last you setup in your DE and the first you use xkb as before. (Or at least that’s how I did it before)
But I personally speak 5 languages (with very different levels) and writing gets a bit complicated.
For example I can write ∀ x ∈ ℕ: x > 1 → x² > 1, but not in wayland.
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.
Scaling and overall performance it's night and day versus X11.
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.
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 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.)
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.
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 :-)
Could you elaborate on this?
The comparison to Qt, Gtk or Electron is also very wrong; it is an entirely different layer in the stack.
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.
I'd expect nouveau+nvk for it to catch up sooner than blob will become decent on Wayland.
I believe this one of the features pcsx2 wants to see merged. 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.
Edit: See details in https://gitlab.freedesktop.org/wayland/wayland-protocols/-/b...
I'm quite convinced these people just use windows and occasionally open linux in a vm for 10 minutes.
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.
But I'm on AMD. Thinkpad Z16 AMD Gen1.
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.
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."
Disclaimer: I run ChromeOS and Wayland just works.
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.
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.
That said, the rest of the functionality is now an exercise for desktop environments, and they can (and do) things differently.
And anything that people used to do on X11, they are told by zealots that they are wrong and aren't supposed to do that.
For example:
Not losing all the work every time your windows manager crashes
remapping keys
Use xinput to change parameters of their input devices (libinput dropped most configuration options present with evdev)
Global shortcuts
tunnelling over ssh
https://news.ycombinator.com/item?id=37509703
>remapping keys
>Use xinput to change parameters of their input devices (libinput dropped most configuration options present with evdev)
Up to the compositor.
>Global shortcuts
Also up to the compositor. Was added to xdp in https://github.com/flatpak/xdg-desktop-portal/blob/main/data... so it's up to the compositor's xdp impl to provide it. It was created by a KDE dev so I assume KDE implements it at least.
>tunnelling over ssh
> Also up to the compositor.
Exactly my point! Right there. Thanks.
Before you said that your point was that people tell you you aren’t supposed to do those things. But you are able to remap your keys.
Remapping keys has been possible in Wayland for quite a while in any compositor I used. (KDE, Gnome, Sway)
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...
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.
See https://gitlab.freedesktop.org/wayland/wayland-protocols/-/m... for the discussion on this
I think about 40 years of GUI APIs disagree with this.
Having good security is essential to having a good app platform. You can see a real disaster in how malware operated on Windows a couple decades ago.
>I want to be able to easily snoop on and control my GUI
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
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.
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.
“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.
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?
Cause users expect it to happen and complain when it doesn't anyway: https://github.com/PCSX2/pcsx2/issues/9064, https://github.com/PCSX2/pcsx2/issues/10065
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)
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.
[0] For details, see https://www.freedesktop.org/software/systemd/man/latest/daem...
Linux will never conquer the desktop with this shit.
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 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.
Of course no one has to use / switch to anything, but reaching a critical mass of users would be helpful in the long term.
Latest release in June… https://www.x.org/wiki/Releases/
Doesn't seem extremely abandoned.
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.
I know in theory it might happen… but it's a non-issue since it doesn't happen.
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".
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.