There is an updated pull request by Logarithmus against master on the void-packages repository

https://github.com/Logarithmus/void-packages libpipewire02
https://github.com/void-linux/void-packages/pull/26144

chromium: enable WebRTC screen sharing via PipeWire
- [x] libpipewire0.2
- [x] patch chromium's template
- [ ] test building for all archs:
    - [ ] x86_64 - 🚧
    - [ ] i686 - 🚧
    - [x] aarch64 - ignoring because `nocross=yes`
    - [x] armv7l - ignoring because `nocross=yes`
    - [x] x86_64-musl - works with some issues (tested on my laptop: https://youtu.be/HnD5mgPn8gk):
    * have to kill `xdg-desktop-portal*` processes sometimes, probably caused by some sort of race condition;
    * also you may need to start/restart screensharing for it to work.
        ✔️ https://www.webrtc-experiment.com/Pluginfree-Screen-Sharing
        ✔️ https://zoom.us (in-browser version)
        ✔️ https://discord.com (in-browser version)
        ❓ https://web.skype.com - not tested yet
        ❓ https://meet.google.com - not tested yet
    - [x] aarch64-musl - ignoring because `nocross=yes`

Currently I'm investigating these stability issues with `pipewire`. It seems that `pipewire` is trying to use `rtkit` to make audio/video processing run in real time. Unfortunately, it fails to do so:
```
2020-11-16T03:49:59.73350 daemon.err: Nov 16 03:49:59 rtkit-daemon[3165]: Failed to make ourselves RT: Function not implemented
2020-11-16T03:49:59.73602 daemon.warn: Nov 16 03:49:59 rtkit-daemon[3165]: Warning: failed to read scheduler policy: Function not implemented
2020-11-16T03:49:59.73620 daemon.debug: Nov 16 03:49:59 rtkit-daemon[3165]: Supervising 0 threads of 0 processes of 1 users.
2020-11-16T03:49:59.73645 daemon.debug: Nov 16 03:49:59 rtkit-daemon[3165]: Supervising 0 threads of 0 processes of 1 users.
2020-11-16T03:49:59.74118 daemon.err: Nov 16 03:49:59 rtkit-daemon[3165]: Failed to make ourselves RT: Function not implemented
```
After a bit of searching, I've found these bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1229700
https://bugs.gentoo.org/show_bug.cgi?id=569546

So now I'm building `linux5.9` for `x86_64` with `CONFIG_RT_GROUP_SCHED` disabled.
I hope it will help, but honestly chances are fairly low.

Right now I have `chromium` for `x86_64` & `i386` and `linux5.9` builds running inside my Void Linux DigitalOcean droplet.
They will take a few hours to finish I think.

A patch file from https://github.com/void-linux/void-packages/pull/26144.patch is attached