PCSX2 Emulator Disables Wayland Support By Default

[RedEyed]

After decades to be a Linux user, I came to conclusion, that Linux Desktop is broken by design, everyone blaming everything and no one taking responsibility to make their code compatible.

Unix philosophy is to make programs to do one thing well, but when we use Linux Desktop, we are wrongly expecting that all things are done well.

[ssokolow]

Do you program GUI applications? I do. Docorations are simply areas where you paint to and handle events. There is nothing special about them.

That's the problem. They don't obey user customizations, they can't be trusted to indicate any kind of security context information, and they don't respond to attempts to manage the window if the application gets wedged in a way that prevents the compositor from detecting it and taking over direct processing of input events.

[ssokolow]

After decades to be a Linux user, I came to conclusion, that Linux Desktop is broken by design, everyone blaming everything and no one taking responsibility to make their code compatible.

Unix philosophy is to make programs to do one thing well, but when we use Linux Desktop, we are wrongly expecting that all things are done well.

No, it's just this diagram all over again. Remember Alan Cox's "my views on esd are mostly unprintable" quote from the XMMS home page? We're back to the situation where Hardware audio mixing (X11) is going away and people are fighting over whether ALSA dmix, aRTs, or esd is the proper way to share access to that resource.

Meanwhile, a bunch of abrasive people are convinced that Wayland will never be ready and are getting very concerned that use-cases like X11-on-FreeBSD will become untenable before someone steps up to write the true X12 (i.e. PulseAudio).

As Brodie Robertson frustratedly noted in his video about this, Wayland is plagued by insane levels of bickering and bikeshedding. He then proceeded to urge application developers to find relevant issues and lay out their use-cases rather than just ignoring Wayland and waiting for things to work out the slow way. (i.e. what LibrePCB did when they weighed in on the request for support for setting window icons without requiring an installed .desktop file for each sub-application and said they'd locked LibrePCB to "XWayland || die" semantics for lack of support for it because their primary concern is delivering a good user experience by any means possible.)

[Sonadow]

After decades to be a Linux user, I came to conclusion, that Linux Desktop is broken by design, everyone blaming everything and no one taking responsibility to make their code compatible.

Unix philosophy is to make programs to do one thing well, but when we use Linux Desktop, we are wrongly expecting that all things are done well.

If you want to use a proper Linux that is successful and coherent, buy a Chromebook and use ChromeOS.

[patrick1946]

Though it fizzled out, KDE proposed the sane idea which preserves user choice, as usual, while GNOME just tried to gaslight everyone into believing that the limitations imposed by bad architectural decisions in Mutter were actually universal truths.

KDE has a really bad idea record. I looked into this and it is simply complicated. The decoration space shouldn't be spend on a few design elements like modern UIs shows.

[patrick1946]

That's the problem. They don't obey user customizations, they can't be trusted to indicate any kind of security context information, and they don't respond to attempts to manage the window if the application gets wedged in a way that prevents the compositor from detecting it and taking over direct processing of input events.

SSD can't be trusted too because you can always disable them. Client side decorations are a proofen concept and the only problem now is that some frameworks like Qt do not support them well.

[DooMMasteR]

All the NVIDIA workarounds are really bad, the window decoration stuff can and will be fixed, but with NVIDIA there is little hope and while some people still ride the ship that Linux should try to improve compatibility with NVIDIA's proprietary approach it becomes more and more clear that it is just a bad thing.
Wayland without NVIDIA would simply be better.
Even Chrome, when rendering on Wayland+VK has issues, that are mostly related to NVIDIA workarounds, and while Google has the manpower to make their own workarounds I can totally see how a smaller OSS project cannot spend the manpower on such BS.

[piotrj3]

SSD can't be trusted too because you can always disable them. Client side decorations are a proofen concept and the only problem now is that some frameworks like Qt do not support them well.

Disabling is not a problem in grand scheme of things. Only program that i am aware uses such things is WINE stuff that you can set in wine config. And that is quite special case.

There are a lot of problems with CSDs like you can crash aplication in a way that window of it can't be moved away because responsibility of decorations is inside aplication. Another is providing sensible CSD for each possible DE with each possible colors and so on. When SSD might be not as polished here, at least i am fully aware that decoration will respect dark mode, and color scheme of my DE.

CSD can work on apple when essentially every single program in the world uses one toolkit, one enviroment, and limited design options from users.

CSD will not work when you have Qt, GTK (hundreds of possible smaller GUIs, some of them are legacy or written for just one project), Gnome, KDE and a lot more DEs, each with own design choices and so on. Heck even if you had just KDE, making CSD good with all possible ways to configure KDE (You can make KDE look like windows 7, 10, 11, Mac OS and waaaay more) is unlikely.

[piotrj3]

All the NVIDIA workarounds are really bad, the window decoration stuff can and will be fixed, but with NVIDIA there is little hope and while some people still ride the ship that Linux should try to improve compatibility with NVIDIA's proprietary approach it becomes more and more clear that it is just a bad thing.
Wayland without NVIDIA would simply be better.
Even Chrome, when rendering on Wayland+VK has issues, that are mostly related to NVIDIA workarounds, and while Google has the manpower to make their own workarounds I can totally see how a smaller OSS project cannot spend the manpower on such BS.

When Nvidia holds some responsibility, a lot of responsibility are on opensource devs as well. For example we wait forever for some community developers to agree how explicit sync is done. Stuff like DMA-BUF being GPL only was pure malicious action done against typical linux user who simply got some machine and might think "let's try linux" to only get dissappointed and never try again.

[DooMMasteR]

What? the GPL enforcements where taken because NVIDIA used APIs in their closed code they should not use.
The authors had long discussions about it but decided enforcement would be the best since then using drivers would become transparent and you could at least start debugging API interfacing issues in a proper way.
So far, whatever shenanigans NVIDIA does on the APIs is mostly a black box, which is the opposite of the idea of using GPL code to interface your own code.

And now NVIDIA seems to, again, not do the right thing... so the issue persists...

Also most of the issues are completely unrelated to the DRM-API changes :-)