I have yet to read this, but. But the first part is like the internals of systemd, you won’t immediately need it.
If you want to make use of systemd, you can skip directly to where it explains unit files. You’ll soon see just how much it can do for you
Have you tried gnome connections? It’s more on the “quick and easy” rather than “professional” side, but maybe it does the job.
Tho I wonder whether it’s more of a windows-side issue… maybe windows 11 requires some kind of online authentication that cannot be implemented by other clients, and maybe this authentication can be turned off. I’m merely speculating here, but I know that remmina works for windows 10 so it’s suspicious.
AMD has an nvdec/nvenc equivalent called AMF, on Linux it’s going to be deprecated in months in favour of va-api.
To my knowledge, it does not have an nvfbc equivalent. Which anyway, Nvidia has deprecated on windows in favour of a windows-native screen capture with a name I don’t remember.
For what is worth, va-api encoding + kmsgrab works pretty well for me, it does have some latency, but nothing too unacceptable. Probably less than the one caused by the Bluetooth controller. And none of this is vendor specific, you can get it working on Intel, AMD and Nvidia (Nvidia needs a compatibility layer, but it works). Also, it works on Wayland, but sunshine needs some privileges to work.
Sunshine supposedly supports nvfbc with patched Nvidia drivers, even on Linux, I haven’t tried it, so I don’t know if it works on Wayland. I don’t see why it shouldn’t, as long as you give sunshine privileged permissions (like you need for kmsgrab). Even without nvfbc you can use nvenc, so you don’t need the va-api compatibility layer.
Supposedly, since this Nvidia driver release nvfbc is used as backend for pipewire screen capture, so it should just work for apps like OBS, I don’t know if sunshine has intention to move to it.
In general, screen capture on Linux pretty much works, even on Wayland. The general sentiment that it’s broken is actually old news.
There’s a caveat though. Proprietary apps tend to use outdated stuff (e.g. electron builds from 5 years ago) and thus don’t support screen sharing on Wayland.
Gambling society and its future
Did you solve this in the end?
Try checking the sampling rate in your pipewire config. It should be 48000. I don’t remember exactly how to set it, check on the arch wiki.
Last time I had issues with digital audio that was it.
Hmmmm
Do you actually need a full fake edid for your usecase? I think you are looking for the video= kernel parameter, which forces a port to be active, and adds a mode (resolution and refreshrate) to it’s list of supported modes
Performance Is about on par with windows for everything dx9 to dx12. Dx8 and earlier I think are not supported by wine.
In general you will be able to play almost all games, as long as they don’t require kernel level anti cheat, but some online games do block Linux users. In the case of tarkov I can’t help, you should read online.
Older games should be fine, personally I played Max Payne 1 an 2 a couple month ago, and the original Hitman series runs better than on windows.
Expect to do some tinkering on some more advanced games. E.g.: Shadow of the Tomb Raider and Alan Wake 2 require the experimental version of proton, God of War Ragnarok requires to enable SteamDeckMode on a config file to disable PlayStationSDK, usually you will find suggestions on protondb.
Some Nvidia proprietary things will not work in games on wine, e.g.: GPU accelerated physix will not work, also on some games dlss will require editing wine’s registry.
Is this supposed to replace bluez?
Celluloid does much less than vlc, why not just using mpv (which celluloid uses as backend) so you have a full player
Lenovo might have intentionally reduced the performance in Windows by default to enhance battery life, because it is a gaming laptop they probably have a lot of performance options in the vendor’s control center to sacrifice battery life for performance, are you sure you activated every performance option?
Also mesa drivers often have better performance than Radeon official drivers, but they are less consistent (more stuttering).
Probably, if everything else is correct. GPU passthrough hands over an entire GPU to the virtual machine, so the only way of getting the output of that vm is plugging a monitor in that GPU
I haven’t looked into how to configure this but it should be possible, and you would use the motherboard HDMI port for the VM, and the ports on the dGPU for the host. As usual, the arch wiki is your friend, even if you are not using arch
But… If you don’t care about VM performance (seeing as you are passing the iGPU to it) you should look into other options like virtio or sr-iov, so you don’t need to fiddle with the HDMI ports. Please notice that virtio is paravirtualized and only works well for Linux guests, and sr-iov is real hardware virtualization and requires hardware support. Both these methods require only one GPU. Once again, look at the arch wiki and the qemu wiki.
Also, if you are using Linux guests, you should really look into “GPU native context” which is a paravirtualization method that works similarly to Hyper-V’s GPU paravirtualization (which is currently the best) and would allow almost native performance for the VM, without requiring multiple GPUs. It is not available for amdgpu yet, but you can follow development here.
P.s. if you are using windows hosts, paravirtualization methods will not be satisfactory for the foreseeable future. You will need either passthrough (like you suggested) or full virtualization (with sr-iov). I can give you more details if you like.
GNOME tries to set a high standard of polishedness, look-and-feel, and simplicity of design. This is not wrong and makes GNOME good looking and easy to use for a less savvy user. But this has some drawbacks.
For a more savvy user that knows what he wants to do, the simplistic interface gets in the way and wastes time. In contrast KDE Will hold your hand less, and get less in your way. Though, when you drop these requirements GNOME becomes very pleasant to use, especially on laptops, which is why I use it on my laptop.
Another drawback is that GNOME developers will not ship something that doesn’t fig their standards of usability. This adds to the polishing, but it means you will miss out on features, for reasons like “the options in the settings would be confusing for the users” until they are satisfied. E.G.: fractional scaling and vrr. On the other hand, KDE Will ship things that are less polished, but at least you have it.
Also some applications will work suboptimally on GNOME with Wayland, because of client side decorations.
Hi, I’m hijacking this thread to answer your other questions. Xpadneo is the correct answer, it will work with any desktop environment (xorg or Wayland) and all reasonable distros. It’s also the driver used by the steam deck, so go with that. But I suggest you read the troubleshooting section for two things: fixing input latency (if you experience it) and secure boot (more on that later).
I use both KDE and GNOME (on different computers, for different reasons), but in general I suggest you use KDE.
Now I will explain secure boot:
You can use third party drivers with secure boot on any distro that supports secure boot. Here’s how it works. Secure boot means that the bios checks that the kernel and requires that the kernel checks that all kernel drivers are signed with a key that it recognizes.
Now, either using a second bootloader (like redhat’s shim) signed by Microsoft, or either directly getting Microsoft’s signature, you get secure boot support on distros like Fedora or Ubuntu. So your kernel and all your included drivers are signed by Fedora with a key they got from Microsoft.
Other drivers (like Nvidia’s and this) aren’t signed, so secure boot will not accept those. But, secure but supports MOKs (machine owner keys), which are keys for signing drivers that you manage yourself and you installed on your bios, and secure boot will accept drivers signed with those.
Now, external drivers can be installed using two systems: akmod (used mostly by Fedora and redhat derivatives) and dkms (used by anyone else). These two are not in conflict and will work on the same system at the same time, it’s just preference. The Nvidia drivers you installed used akmod, xpadneo uses dkms.
Both these systems support setting up a key for signing, you should then register that key on your bios. When you installed your Nvidia drivers a little interface made by Fedora for those drivers helped you to set up your key for akmods, and now you can use any akmod driver with secure boot. You could always do it manually and you can do it on any distro, Fedora just adds the graphical interface.
To use xpadneo you need to do basically the same thing but for dkms, and you need to do it manually, it’s very easy, the troubleshooting section should direct you here for instructions, you will recognize some of the steps of registering the key.
If you feel a little adventurous, you can find which key akmod uses, and set dkms to use the same, so you don’t need to register another one.
Also, I strongly discourage this, but you can technically remove Microsoft’s key and sign everything with your own key if you really hate Microsoft. Please please please don’t do it, you will screw up and break your system badly, and it’s also a lot of work. Places like datacenters and such do this. Because they want total control on what goes on those machines. Also they don’t sign stuff on the machine themselves, but they sign on a more secure one and then deploy the signed stuff.
I would say:
But you could also go for any more up to date debian-based distro, like Pop_OS or even Ubuntu, they might be easier for a newbie user. Fedora and OpenSUSE will be more up to date though.
If you do use Ubuntu, don’t stick to just LTS versions, use the last version available (which right now happens to be an LTS version). The “extra support” it offers is not something desktop users care about, it’s outweighted by the benefits of more updated software.
Just use some HP calculator emulator. That way you don’t have just an RPN calculator, but a full fat graphing calculator.
TL;DR depends on your gpu.
Some monitors below HDMI 2.1 support the early version of freesync made by AMD, while others support a fragment of what became 2.1’s VRR. The former is supported only by AMD, while the latter by both AMD and Nvidia (Pascal and upper with latest drivers). If you have the former, the monitor is probably not compatible with DP’s official adaptive sync, so Nvidia won’t work even on DP.
But… Even if you have AMD, due to a bug in the driver, if you have a Polaris GPU it might not detect the vrr capability over HDMI (but will over DP). I know for sure that RDNA 2.5 cards support it, in theory it should work even for all Vega and Navi GPUs, but I haven’t tested it.
Well in the worst case you can always enter a tty or ssh and try to fix from there. But you can be sure the system will be recoverable.
I took a simplistic approach on some of the things I talked about, but you can use it as a pointer for a deeper dive. Also I realized now that I wrote the comment in really bad English, apologies.
I really do believe the future of the Linux desktop will be exciting, and that’s also thanks to Wayland.
It’s digital audio, not analog, I doubt the GPU could ever be an issue. I suspect either there was a bug in the interaction between pipewire and the drivers (on one side or the other), or an update changed the default sampling rate of pipewire