[BUG] scrcpy won't start in AppImage build of guiscrcpy on Fedora Silverblue

[ghost]

Describe the bug

scrcpy won't start on Fedora Silverblue using AppImage build of guiscrcpy.

To Reproduce

1. Download AppImage build from GitHub
2. Make it executable
3. Execute it from terminal:

   ./guiscrcpy-v4.10.0-37-gd7a36da.dev.r.glibc2.31-x86_64_826cfa4beda90b5bd590e0d6ada04eb8.AppImage

4. Click START SCRCPY
5. scrcpy won't show up, instead the following error appears in terminal output

/tmp/.mount_guiscrM56PUz/scrcpy/usr/bin/scrcpy: /tmp/.mount_guiscrM56PUz/scrcpy/usr/lib/libselinux.so.1: no version information available (required by /lib64/libgio-2.0.so.0)
/tmp/.mount_guiscrM56PUz/scrcpy/usr/bin/scrcpy: symbol lookup error: /lib64/libgio-2.0.so.0: undefined symbol: g_module_open_full

Expected behavior

scrcpy window should appear.

Screenshots

Desktop (please complete the following information):

Linux

Distribution: Fedora Silverblue 35.1.2
Desktop Environment: Gnome 41.0
Architecture: Intel 64-bit

Additional context

No additional context

[srevinsaju]

Try using the COPR for scrcpy
https://copr.fedorainfracloud.org/coprs/zeno/scrcpy/

[ghost]

It can be done, it's just rather recommended against this type of setup by Fedora project teams.

Fedora Silverblue can be very unfriendly in terms of COPR repositories, since it's designed with immutable base OS (read-only root filesystem) in mind. Only essential system applications and hardware drivers should be installed on the host with RPM (layered), everything else should be delivered through Flatpak or container.

If running within toolbox, this is the error output:

INFO: scrcpy 1.19 <https://github.com/Genymobile/scrcpy>
/usr/share/scrcpy/scrcpy-server: 1 fil...ed. 165.4 MB/s (37330 bytes in 0.000s)
libGL error: MESA-LOADER: failed to open swrast: /usr/lib64/dri/swrast_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib64/dri, suffix _dri)
libGL error: failed to load driver: swrast
X Error of failed request:  BadValue (integer parameter out of range for operation)

Title can be misleading, since this issue is more specific to Fedora Silverblue or AppImage, changing it.

[srevinsaju]

Ah, I see, what you say makes sense. I think having guiscrcpy as a flatpak would be the best. What do you think? Related: #232

[ghost]

Yeah, distributing as Flatpak would be the most preferable option for Fedora Silverblue / Endless OS users, or you may fix the AppImage build issue and call it a day since AppImage should work as well if done right (I use many other AppImage applications on Fedora Silverblue).

[srevinsaju]

@thjderjktyrjkt if you are interested in testing the prerelease flatpak, can you check out this PR and let me know how it works?

flathub/flathub#2652 (comment)

[ghost]

It worked perfectly. Finally a working scrcpy on Silverblue.

[srevinsaju]

Thank you for testing!

[ghost]

Audio doesn't seem to work. Even by manually selecting sndcpy there is still no sound. On Android sndcpy stuck at Waiting for connection...

[srevinsaju]

Yea, neither sndcpy or usbaudio is bundled with guiscrcpy, maybe I should work on it as a separate flatpak plugin 🤔

[ghost]

As sndcpy requirements says:

VLC must be installed on the computer.

Perhaps Flathub version of VLC can be used for this ?

[srevinsaju]

We will also need to add sndcpy's binaries which will then need to communicate with VLC. But I am not sure if sndcpy plugin should bundle the entire flatpak, or should I spawn commands from within the flatpak using flatpak-spawn? The latter looks like a security issue and makes the plugin harder to get accepted on Flathub. 🤔 , but bundling VLC itself might increase the flatpak size by a huge margin.

[ghost]

Yeah that's an old school issue with Flatpak, the lack of cross-application integration. In their theory, applications should register their own URI scheme for others to send requests to them, Just like mobile operating system. But in reality most existing desktop applications don't work that way, and porting to Flatpak while maintaining existing functionality can be a hit or miss.

flatpak-spawn can be used I guess, because it allows newly executed program to run under tighter permissions.

Edit: Or not. looking at the documentation, I realized flatpak-spawn can either spawn a new sandbox that's tighter than existing sandbox, or a completely un-sandboxed program with arbitrary access to anything. It's impossible to "spawn a program within VLC flatpak" unless arbitrary execution permission is given, but then the point of sandboxing renders pointless.

[srevinsaju]

Agreed, I was thinking about the same.

btw, guiscrcpy Flatpak has been released to FlatHub:

https://flathub.org/apps/details/in.srev.guiscrcpy

[poiNt3D]

Any luck getting audio to work on Silverblue?