Desktop Texture support under Linux

[Frooxius]

Currently the desktop uses the uDesktopDuplication library. This is a Windows-only library and does not work under Proton (it will just cause a crash), so under Linux (running nuder Wine), this is disabled.

I have not looked into how feasible it would be to get a solution running under Linux, considering it still has to run under Proton, but if anyone want to poke at this, feel free!

We'd likely accept and merge this feature.

It would also likely need to implement some of the desktop interactions too - the key presses and mouse.

[Mhowser]

Is this the correct repo for the library? https://github.com/hecomi/uDesktopDuplication

[Frooxius]

Yes

[Redd56]

So on xorg iirc you just ask the xorg server and it just hands it to you. Easy and it just works. But that means mouse and keyboard is a bit anoying.
And on wayland you need to use the xdg desktop portal or an equivilent which requires actual desktop authentication to select which desktop is which.
Also wayvr exists already and is honestly really good so like i have zero use for a reso desktop tab on linux, but steamvr is ass so thats a concideration

[Redd56]

https://github.com/wayvr-org/wayvr heres the wayvr repo. It kight be worth it to look into their implimentation as imo its pretty good

[Mhowser]

Keep in mind the renderer is stuck in proton land, so until we get a native renderer, there will need to be something that proton can use.

[kitlith]

@Mhowser There is already precedent for Resonite using internal wine mechanisms to be able to call out to non-Windows code in the form of shmbridge, so in theory something similar could be done here.

[jvyden]

So I was about to post a whole rough plan in regards to using WayVR's wlx-capture abstraction they have, but I looked last-minute and found out that code is GPLv3 so it can't be used here, this being an MIT project. Oof.

Either way, that might have been a bit too complicated anyways since it's a Rust ABI and we'd have to write our own C interface for it and then make a new wine bridge for that C interface. It's likely easier to just write our own C library anyways that does it all in one project so we don't have to juggle two binaries for one feature.