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.

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.

I still use virtual desktops, just a lot less because I can just minimize windows instead of banishing them to a different desktop, and that’s how you quickly end up using too many desktops, the problem is that then you need to remember where every window is when you need it back. With regular wm you can just press the icon to go back to the window regardless of where it is.

Splitting the thread here. I personally used i3wm for more than a year and became white fast with it, then I had to use windows for a month and when I went back to i3 it was a pain, I couldn’t do shit. It was at that moment I decided “why can’t I just stop forcing myself to this PITA and just use the mouse faster?” And I never used a tiling VM again, personally I use kde on desktop and gnome on laptop.

But, I can see the appeal of automatic tiling, so I raise you this: scrollable compositors. You get both the benefits of automatic positioning and oc moving things in and out of the way, without keeping track and managing 10 virtual desktops

A couple years ago it could never have worked properly, Nvidia drivers didn’t support Wayland. Because Nvidia refused to implement drivers that followed the Linux semantic (which admittedly was outdated). About a year ago, after many years of work, they published a new semantic that Nvidia was willing to implement. Alongside that, a new Wayland protocol was added so that compositors could opt-in the new semantic when the driver supports it. So, to use Wayland with Nvidia you need both a recent enough Nvidia driver (I think anything after last July) and a compositor that implement the linux_drm_syncobj_v1 protocol. I’m not even sure hyperland supports it, so you should also look into that before continuing.

P.s.: gnome’s mutter, and kde’s kwin (which are the name of their compositors) both supported that protocol since the very day after it was released, so those are guaranteed to work if they are recent enough, unless if you are on Ubuntu lts which stripped it out for a pet peeve about adding features to lts releases.

I don’t have such a laptop, so I can’t really speak for experience, but I can tell you what I know.

You definitely can use prime to render a program on the dgpu and display it on the igpu, this requires basically no configuration at all on wayland, I even did it on my desktop computer when Wayland didn’t run on Nvidia. But I don’t know if you can or why you would use the dgpu for everything instead of only selected programs (games).

What you really need is a compositor that properly uses both GPUs and can use the ports of both at the same time, hyperlaneld might just be bad at that. Gnome should be in a better position so you can start from here and see if gnome behaves better.

Also, are you sure you want to use a tiling compositor on a gaming laptop? Wouldn’t it be a better experiment to just go with gnome? It’s visually polished and goes well with trackpads.

Is this supposed to replace bluez?

I think Hellwig understands everything very well, he just wants things done his way, for whatever (possibly valid) reason he might have.

Literaly from your quotation: “I assume that we’re good with maintaining the DMA Rust abstractions separately […] No, I’m not” He understands the abstractions would not be in his domain and maintained by someone else, he does not want abstraction at all.

Maybe you are not familiar with the proposal but these “separate rust abstractions” would be a separate module that depends on DMA mapping as a client and deals with cross-language issues, rust drivers would then be clients of this module, it would not be part of the DMA mapping module, it would not be mixed with the DMA code. But Hellwig doesn’t want an abstraction module at all, Instead he want’s you to “do that [the abstraction] in your driver so that you have to do it [maintain a cross-language codebase]”.

Please notice that the abstraction module would not add any more burden on him than the drivers themselves would, because as of now C code is allowed to break Rust code. It would only remove burden from maintainers of Rust drivers, and even if it weren’t it would be easier to fix just the abstraction instead of every driver.

He also refuses to have other people maintain the abstraction, this too for whatever reason, which accredits his request to not add abstraction he would have to maintain. If the abstraction were part of the core dma mapping code, I think it would be a reasonable request, but it wouldn’t be.

Now, we do not know the reason why he opposes it so much. From his words it looks like he doesn’t want Linux to be a cross-language codebase, which would be a valid reason in itself, but dealing with abstractions in drivers instead of a module doesn’t make it any less cross-language, unless the drivers are out of tree, which they wouldn’t be. Some people (e.g. Hector Martin) think that he’s hoping the Rust for Linux project to fail altogether, and fore rust code to be removed from the kernel, and this obstruction would partake in that. I do not think it is that drastic, I think he just fears that those abstraction would eventually become part of what he has to maintain, and no amount of reassurance or new maintainers would change his mind.

I also don’t think Martin’s brigading is anything productive, and I hope that doesn’t become the reason that rust code gets obstructed from being merged into the kernel, but it sure does focus the attention on these matters.

What they are asking is not to change the c code to suit rust, but to leave the C code as is, and have a single Rust-written wrapper that links into the C DMA code so that other Rust drivers can link into the wrapper. Additionally, said wrapper is not to be maintained by Hellwig, but by the maintainers of the drivers that will use the wrapper, so without overhead for Hellwig.

He is not asking to not make his work harder, he’s explicitly asking to make it harder to write rust drivers that use DMA.

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.

What kinda question is that? Mobbing the developers out of switch emulation.

The only two options where you and ryujinx and they are both taken out, all the forks are jokes because the developers that had real abilities worked on the main projects.

I would say:

• Fedora if you like a point release, which means that every 6 months you do a big update of core stuff like the desktop environment, and on Fedora everything else is always generally up to date.
• OpenSUSE Thumbleweed if you like a rolling release, which means that you don’t do big updates, everything is kept to the last version that the software repository has, this is how arch works except in Thumbleweed the repositories are updated slower than in arch and less likely to break.

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.