com.skype.Client VS libvirt

Screen sharing seems to be a difficult problem to resolve. Zoom only just resolved this recently[1], Webex has been promising a fix for a while[2], and Skype still hasn't done anything[3].

[1] https://support.zoom.us/hc/en-us/articles/6634039380877-Zoom...

[2] https://help.webex.com/en-us/article/9vstcdb/Webex-App-for-L...

[3] https://github.com/flathub/com.skype.Client/issues/142

If the device still works in the os and just not in skype. I would try the flatpak package. https://flathub.org/apps/details/com.skype.Client

https://snapcraft.io/skype or Flatpak https://flathub.org/apps/details/com.skype.Client

I also found some old issue on Github Latest version of Skype won't run #70

Alternatively one can use the Flatpak packaged Skype.

I have no idea if that is true or not, I haven't used Skype for more than a decade. But, an app running as a Flatpak can't directly create files in /etc/ even if that directory was exposed in the sandbox (which it isn't in the Skype flatpak, as you can see here), just like any other process running as a non-root user can't create files in /etc/ (unless your permissions on /etc/ are severely messed up). So if what you claim is true, it has nothing to do with Flatpak's sandbox or with portals. And since in the default configuration the pulseaudio daemon (which is running outside the sandbox) does not run as root either, I severly doubt that what you claim here is true at all.

Only in trivial cases. The problem is when another part of the program holds a function pointer (eg callback) into the library which has been unloaded.

libvirt has long been linked with -Wl,nodelete to avoid this:

https://gitlab.com/libvirt/libvirt/-/commit/8e44e5593eb9b89f...

So, next I setup cockpit and cockpit-machines, which works to create VMs (via cockpit-machines) but they use tcg/qemu i.e. emulation and no KVM based h/w acceleration - my test VMs were very slow! I figured out while qemu+KVM works on command line, it doesn't work and the culprit was libvirt! After discussing with the good folks on #asahi channel and with tobhe (Ubuntu-Asahi creator), I gathered enough evidence to conclude libvirtd doesn't know the "right" qemu commands to exec and logged my findings to the libvirt project https://gitlab.com/libvirt/libvirt/-/issues/365 (which can probably use some of the community noise, to expedite the fix).

Nvidia 510 introduced a regression you can see the relevant issues here and here

The work to split into multiple daemons started a few years ago.

https://gitlab.com/libvirt/libvirt/-/blob/9b8bb536ff999fa61e...

There have been a few complaints online in the Arch and Gitlab forums regarding this issue. https://gitlab.com/libvirt/libvirt/-/issues/410

The issue stems from a change in libvirt. Libvirt is responsible for parsing all your VM's XML and turning it into a QEMU command. Somewhere between libvirt version 6.6 and version 6.9, there was a slight change in the way USB devices are passed to QEMU, and obviously libvirt followed suit. As a result, some USB passthrough configurations, such as the MacOS one in the thread, as well as the onboard bluetooth for windows suffered errors.

It's a bug, fix is upstream: https://gitlab.com/libvirt/libvirt/-/commit/04736179b283f55f62616a20a1ec95c665aab8ca