Yes, it does matter, it’s a feature of your monitor that you just cannot use on gnome. Wayland DOES support VRR, it’s had a protocol for it for a while now. GNOME doesn’t support it yet. VRR works perfectly fine on KDE Plasma Wayland and Hyprland (standalone wayland compositor).
Not necessarily true, you can switch say Kwin for Mutter or something else for example. People have successfully done it in the past.
It’s just not at all straight forward, nor supported, nor recommend, likely very unstable especially under Wayland, amongst losing out on features that rely on integration between the DE & compositor.
It’s possible to do, but; why even bother? it’s not really worth it.
Someone smarter than me can probably explain this way better...
As far as Wayland goes, If I remember correctly, it's mainly just a protocol, and Gnome/KDE do all the actual work of making stuff happen, so both need to support it to have it work correctly. Like if Wayland was a language like French, Gnome and KDE need to know the French words for something before they can have conversations about it, and Gnome hasn't been as studious with it's dictionary in regards to VRR. X11 just has an ancient code-base, and adding support for anything involves a lot of effort to make sure something else isn't broken by the addition.
Gnome hasn't officially merged support for VRR yet, but there is a merge request to add support, and a patched version built on that code available if you want to try it (mutter-vrr, gnome-control-center-vrr) at least on Arch Linux's AUR.
The stupid thing is mutter-vrr works far better than Plasma’s implementation in my experience. Plasma locks refresh rate to max if your cursor is moving, causing games that use the cursor to stutter badly while the mutter implementation refreshes the cursor at the game’s rate as expected.
Tried it. Everything was good until it returned a couple of errors.
First:
CMake Error at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:230 (message):``Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE)``Call Stack (most recent call first):``/usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:600 (_FPHSA_FAILURE_MESSAGE)``/usr/share/cmake/Modules/FindPkgConfig.cmake:99 (find_package_handle_standard_args)``thirdparty/fluidsynth/src/CMakeLists.txt:157 (find_package)
– Configuring incomplete, errors occurred!``==> ERROR: A failure occurred in build().`` Aborting…``-> Failed to install layer, rolling up to next layer.error:error making: zmusic - exit status 4
Second: Same as the first one
Third:
==> ERROR: Could not resolve all dependencies. -> error making: gzdoom-exit status 8 -> Failed to install the following packages. Manual intervention is required: zmusic - exit status 4 gzdoom - exit status
Wayland and X11 are protocols, they are essentially just documentation. You need an implementation to be able to actually run programs on it, called a compositor. People tend to think of X11 as a single software because historically Xorg became dominant as the main implementation of the specification, so most of us have only ever used Xorg (but Xorg is not the only implementation of X11, there are many others). Wayland, as a newer protocol, hasn’t undergone such consolidation yet, there are many competing compositors implementing the protocol in their own way. GNOME has one such compositor, and KDE has their own, and there are many others. So it’s not about “Desktop Environments” all running over the same compositor, as it was on Linux in the Xorg days. Instead, the Wayland features you get are the ones your choice of compositor has already implemented, and can vary between different compositors.
So it’s less the Gnome doesn’t support VRR and more that “the wayland compatible desktop compositor that the Gnome project prefers doesn’t support VRR”?
Which is basically the same thing. Gnome uses Mutter, which is a part of the Gnome project as a whole.
Wayland changes things a fair bit compared to Xorg. There’s no standard Wayland server, each DE implements their own to suit their needs. Some libraries have emerged to help with that, it’s relatively easy to get going with wlroots which Sway/Hyprland/Gamescope uses. But Gnome makes their own and so does KDE so it can integrate more deeply with the DE.
There’s non-desktop compositors too, like for VR for example where you can manage your windows in 3D space all around you. That’s where Wayland shines, that gets super complicated to do in Xorg but a breeze with Wayland.
One thing to keep in mind if you’re gonna try Deus Ex out with Surreal Engine is that it currently does not have the input system working, due to it being completely different than UT’s lol. Lots of functions aren’t implemented yet also, so we’re pretty much stuck with the intro flyby now :V
In 2291, in an attempt to control violence among deep-space miners, the New Earth Government legalized no-holds-barred fighting. Liandri Mining Corporation, working with the NEG, established a series of leagues and bloody public exhibitions. The fight's popularity grew with their brutality.
Soon, Liandri discovered that the public matches were their most profitable enterprise. The professional league was formed: a cabal of the most violent and skilled warriors in known space, selected to fight in a Grand Tournament.
Now it is 2341. Fifty years have passed since the founding of Deathmatch. Profits from the tournament number in the hundreds of billions. You have been selected to fight in the professional league by the Liandri Rules Board. Your strength and brutality are legendary.
The time has come to prove you are the best, to crush your enemies, to win the Tournament.
I was there for the fan wars. I was in the Tribes camp, but Quake and UT ate up plenty of time. The map mods for Duke Nukem were a big deal for a while making ridiculous stuff with inescapable pits that were only fun to play a few times.
Its basically bugfixes for specific games through proton. Different fames need different fixes, so you cant just make a general fix for some bugs if they only exist in one game. The new launcher promises to make one database for those fixes where all the launchers can fetch their data from instead of everyone having to do their own thing and having to fix each game separately.
Wine attempts to translate Windows calls into Linux, its developed by Codeweavers whose focus is/was application compatibility.
Valve took Wine and modify it to best support games, the result is called Proton. For example:
Someone built a library to convert DirectX 9-11 calls and turn them into Vulkan ones, it was written in C++ and is called DxVK.
Wine has strict rules on only C code and their directx library handles odd behaviour from old CAD applications.
Valve doesn't care about that, they care that the Wine DirectX library is slow and buggy and DxVK isn't. So they pull out Wines and use DxVK.
There are lots of smaller changes, these are 'Proton Fixes', sometimes Proton Fixes are passed on to Wine. Sometimes they can't but discussion happens and a Wine fix is developed.
linux_gaming
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.