Quoting: const

Quoting: pleasereadthemanual

Quoting: constFor a few years, we were able to welcome more and more people switching from windows. Now we are finally back to telling people "Yeah, your still perfectly capable hardware is not supported, you should buy other hardware"
I personally think this is utterly stupid. I recognize wayland is the future, but compatibility is still favoring Xorg, especially for Nvidia users (~70%) with multi-screen setups. I can't believe people here are celebrating this cutting of workarounds.

Despite my complaints about Wayland compositors, I think it has actually been an overall better experience. Games play smoother and it's generally smoother. Krita and Steam have the worst flickering in the world, but Bitwarden and Freetube's flickering I can live with.

Multi-monitor setup with my Wacom tablet flat-out doesn't work properly on Xorg. It will only work properly on KDE Wayland. Proper color accuracy is desirable, and while Xorg kind of implements it, the Wayland protocol looks to be close to completion and doing a much better job with all the input from all these important stakeholders.

Once explicit sync is implemented (it looks very close), I think that's the last thing Wayland needs for it to be a consistently good experience for me. It's already a consistently better experience than Xorg even with the flickering. Neither has been problem-free.

I don't argue that some people have a better experience with Wayland. That's a given. But just because it works for you it doesn't mean it works for everyone. Explicit sync may be close, but if that solves issues for many people, shouldn't distros wait for it before they drop Xorg sessions as a fallback?
I have a wacom tablet on my 3 screen setup, btw. It just works on Xorg.
I tried wayland nearly every year for a while. Have gotten a session to run once, it was misbehaving in every way I can imagine. Mouse offset, crazy colors, graphic elements moving randomly added to constant flickering seemed like the experience those warning banners in movies and videogames warn you of. That's the one time I got it to run at all. Every other time, selecting the wayland session would drop me back to the login manager. My 980TI might be old, but it's still pretty fine for a lot of games and I fear that entire generation can have comparable issues. So yeah, make it the default, pressure Nvidia to fix their driver. But until we are sure everyone has an equally good or better time with wayland, distros should keep the fallback.

Edit: ok, I'm now on wayland. Had to set a kernel option for it to work. It's not a nightmare for now, it actually seems pretty neat and a lot of KDE bugs that were bugging me lately have gone. That's great. Still, the fact I had to set a kernel option is kind of a sign this is not ready for prime time.

Linux Mint is where you want to be if you want the best experience. They aren't going to transition to Wayland until it's deemed well and truly ready.

Fedora is not, and has never been about the best experience. It's about embracing the new as quickly as possible. I don't know what Ubuntu's doing but I can't imagine they're going to take the Xorg option away any time in the next 5 years.

Yes, it was hard for me to enable it on Arch. Though I think you've touched upon the reason Plasma has set it as the default: they've stopped fixing bugs for Xorg and are only focusing on Wayland, so it's probably going to be a better experience for more people. And bugs might be easier to fix, too.

I hope that Noveau + Zink + NVK is set as the default drivers for NVIDIA sometime soon and we won't need to worry about those particular issues sometime in the near future.

I do think you're right that it's an awful time to be a newcomer, because you're stuck with two not-very-great options right now. There's cool and fundamental stuff on Wayland you won't see on Xorg, but there are definite issues with Wayland too. I hope that the pain now will result in a great experience in 2025, which is just around the time some people might be considering their options.

And out of genuine curiosity, what is missing on Wayland? I wanted to compile a list so I can keep tabs on the issues, but so far I've got:

* Explicit Sync to fix flickering (recently got 3 ACKs and is nearly ready to merge, awaiting implementations in compositors + drivers)
* Color Management Protocol (seems like some early implementations have recently been done and Plasma 6 has limited HDR support)
* Better IME protocol, maybe? It works for me on GNOME and KDE, but the implementation was a little broken on wlroots

View this comment - View article - View full comments

QuoteAround two days is not a bad turnaround time, although a shame that EA / Respawn aren't testing to ensure they don't break it, but we likely still need a fair bit bigger user share before such huge publishers will do that.

Who is to say the reason Valve fixed it so quickly isn't because EA / Respawn tested it and reported it, and couldn't wait any longer to push it out?

View this comment - View article - View full comments

Quoting: constFor a few years, we were able to welcome more and more people switching from windows. Now we are finally back to telling people "Yeah, your still perfectly capable hardware is not supported, you should buy other hardware"
I personally think this is utterly stupid. I recognize wayland is the future, but compatibility is still favoring Xorg, especially for Nvidia users (~70%) with multi-screen setups. I can't believe people here are celebrating this cutting of workarounds.

Despite my complaints about Wayland compositors, I think it has actually been an overall better experience. Games play smoother and it's generally smoother. Krita and Steam have the worst flickering in the world, but Bitwarden and Freetube's flickering I can live with.

Multi-monitor setup with my Wacom tablet flat-out doesn't work properly on Xorg. It will only work properly on KDE Wayland. Proper color accuracy is desirable, and while Xorg kind of implements it, the Wayland protocol looks to be close to completion and doing a much better job with all the input from all these important stakeholders.

Once explicit sync is implemented (it looks very close), I think that's the last thing Wayland needs for it to be a consistently good experience for me. It's already a consistently better experience than Xorg even with the flickering. Neither has been problem-free.

View this comment - View article - View full comments

Quoting: jens

Quoting: pleasereadthemanualMy experience is that Krita is terrible on GNOME, Wayland or X11, with a NVIDIA GPU. My Wacom tablet works properly on KDE Wayland and only KDE Wayland.

Of course, Krita's toolbar flickers black every 5 seconds so it's a little distracting.

Have I mentioned how tired I am of NVIDIA's proprietary drivers before?

Cool to hear that the KDE folks got their tablet support right. I'm using my Wacom tablet solemnly as a mouse replacement, not for actual drawing. So slightly different use case I guess. Lots of Wacom related PR's got merged for the upcoming Gnome version, so I have hopes that the normal interaction works better, but things like https://gitlab.gnome.org/GNOME/mutter/-/issues/2983 are still open and probably no that easy to address :(

Yeah, the flickering might be related to the implicit/explicit sync issues. I sincerely hope that https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/90 gets merged soon and all related PR's land in compositors, xwayland etc. From my understanding, that should solve all flickering (asuming what you are seeing is related to that). Side note, reading through the discussion of that PR, NVIDIA engineers are pushing for this and contributed heavily, so it is not NVIDIA that is holding back.

The strange thing is, Krita was not flickering in the 535 series of NVIDIA drivers. It was only in the 545 series that the flickering was introduced. Fortunately, my entire monitor no longer flickers, so I guess I'll take it...

My understanding is that AMD and Intel's drivers implement implicit sync but NVIDIA doesn't want to implement that; they want explicit sync because implicit sync is imperfect, but I'd take imperfection over the flickerfest. I haven't looked into it at all; that's just what I've heard. Some cursory reading suggests this is accurate.

I don't know what the experience is like on AMD, but I've never gotten any flickering on my Intel iGPU. I hope this is fixed sometime soon, because it's a pain in several of my programs, including Steam. The end of that merge request is looking good...they all seem pretty happy with it. Implementations to follow in a few months?!

View this comment - View article - View full comments

Quoting: jensI'm using an NVIDIA GPU and a Wacom tablet instead of a mouse. Both are currently not really usable on Gnome Wayland. That said, I still very welcome this switch to reduce landscape and have manpower available for getting Wayland into shape.

I'm not worried of NVIDIA, the explicit sync stuff is shaping up nicely and I guess by the end of year we have a perfect Wayland experience on NVIDIA. There is also NVK coming with an astonishing speed. The Wacom support on Gnome Wayland is getting better too, but there are still some hurdles. Fortunately there is also `labwc` which works perfectly with regard to tablet support.

My experience is that Krita is terrible on GNOME, Wayland or X11, with a NVIDIA GPU. My Wacom tablet works properly on KDE Wayland and only KDE Wayland.

Of course, Krita's toolbar flickers black every 5 seconds so it's a little distracting.

Have I mentioned how tired I am of NVIDIA's proprietary drivers before?

View this comment - View article - View full comments

Quoting: PyreticWait, he's removing the emulator from Google Play? Does that mean he's not supporting the Android version anymore?

There are plenty of ways to install apps on Android. He could just distribute an .apk file. Maybe get it listed on F-Droid when it's open source.

View this comment - View article - View full comments

I'm really surprised to see it so quickly. It usually takes months for the new GNOME release to land in Arch. It's been what, a little over a week?

Chromium is now really buggy for some reason. It flickers all the time. And the Qt theme is broken. I was already using the Wayland session, so it's strange to see regressions like this. I use Firefox 95% of the time anyway and it works fine, so it's no big deal.

The Steam client was already a flickering mess before the upgrade, but now the icons are in completely the wrong place on the Downloads page.

My single-click to open files in Dolphin was changed to double-click for some reason, so I changed it back.

There's now a bug in the Overview effect where if you have two rows of virtual desktops, it won't display the row of virtual desktops at the top. It worked fine in Plasma 5. I've set it back to one row of virtual desktops for now. The overview effect is an improvement otherwise.

Signal Desktop now takes a long time to load up or doesn't load up at all unless started from the terminal. On the other hand, Thunderbird now starts up when launched and I no longer need to launch it from the terminal!

I hope the annoying bug where resuming from suspend would shuffle my primary monitor to my second monitor is fixed now.

Overall, not too disruptive.

Quoting: sobinsirilDoes anyone else have issues with qbittorrent working on Plasma 6, Arch Linux?

It doesn't open for me unless I open it from a magnet link or a torrent file.

Works for me.

View this comment - View article - View full comments

They are separate projects, but technically VKD3D-Proton is a fork of VKD3D with massive changes, and is better in every way for almost everything, including general software. That last part I've heard from GloriousEggroll and other members of the Lutris team, by the way. But it's true that VKD3D is supposed to be better for general software as opposed to being focused on games. It's just that VKD3D has implemented so few of the Direct3D12 API compared to VKD3D-Proton that the fork ends up being better overall right now.

DXVK, on the other hand, is a completely separate project from Wine for D3D9-11 and duplicates parts of the Wine project. It can even be used directly on Windows or by itself without Wine. Wine has an OpenGL translation layer for all other D3D versions except 12, called "WineD3D". However, Wine has a very experimental Vulkan translation layer hidden behind a registry key for Direct3D versions before 12.

You can enable it by reading the instructions here: https://wiki.winehq.org/Useful_Registry_Keys

Quote| +->renderer
| | [Select what backend to use for wined3d. Valid options are:

| | gdi
| | gl
| | vulkan

| | The "gdi" option (and its alias "no3d") mostly exists for legacy or test reasons.
| | As of Wine 5.1, gl is the default and vulkan is still work in progress,
| | so don't expect great results with it yet.]

...but you should just use DXVK.

DXVK is better than WineD3D's OpenGL backend for most APIs, but the OpenGL backend can be better in some cases for D3D9. That might not be the case anymore, but it was a few months ago.

There's also a WIP Vulkan translation layer for D3D8 for some reason.

View this comment - View article - View full comments

Quoting: F.UltraAnd the emulator would be completely useless without that guide and that key extraction tool, and any site hosting the tool and/or such a guide would violate the DMCA.

That is Nintendo's argument, but the emulator could still be used for Homebrew Switch games. For example, some indie game developers make games for the Gameboy, distributing the emulator and all (e.g. npckc distributing Marron's Day via Sameboy sometime in the next few months).

Yuzu would not be entirely useless without the keys, but Nintendo's argument is that this is not a significant use case and should be discounted. So you're completely correct in your analysis.

View this comment - View article - View full comments

Quoting: melkemindNone of the things you mentioned are what needs to be "cleaned." It's the technology that allows the software to circumvent Nintendo's copy protection. I assume it's encryption of some sort..

The initial public filing by Nintendo mentions that they have "three layers of encryption" which are Technological Protection Measures that need to be circumvented in order for Yuzu to play Switch games. The first is the encryption on the console itself, and IIRC the games have two layers of encryption. When you dump the game using other tools, Yuzu still needs to make use of the decryption keys the user provides to decrypt the dumped game file in real-time. So it is technically circumventing the technological protection measure but only if the user provides the decryption keys.

That is Nintendo's argument, anyway. Whether a judge would interpret it that way is 50-50; the legal theory has not been tested in court.

View this comment - View article - View full comments