Flatpak support

[Doomsdayrs]

Flatpak will allow cemu to be used on all linux distributions.

Would be nice:

• #20

[Doomsdayrs]

Alright, why does Cemu need SEPol?

[JakobDev]

You should maybe wait until Cemu is ready. There are a few major Issues like that it needs a case-insensitive filesystem. Iaslo have 2 PRs (#12 and #10) open for the data files, so you don't need to create your own.

[Doomsdayrs]

You should maybe wait until Cemu is ready.

Precisely why it is a draft pr :D

There are a few major Issues like that it needs a case-insensitive filesystem.

CEMO is not case sensitive ready?

Iaslo have 2 PRs (#12 and #10) open for the data files, so you don't need to create your own.

I will look at them, and see how to get them imported into the flatpak on compilation time (of the flatpak)

[JakobDev]

CEMO is not case sensitive ready?

See #1

I will look at them, and see how to get them imported into the flatpak on compilation time (of the flatpak)

You just need to wait until they got merged

[Eonfge]

As mentioned in #1,

I did some quick work for a Flatpak but the first problem that has to be tackle VCPKG. It's not very suitable for the reproducible and isolated build standard of Flatpaks: The VCPKG-package fails because it tries to connect with the network within the build process which is running in an isolated environment.

https://github.com/Eonfge/flathub/tree/info.cemu.Cemu

This should first be resolved before we can continue with a Flatpak

[Crementif]

vcpkg is no longer required since #75 was merged, so if anyone that has more flatpak experience could help with this issue that'd be nice!

EDIT: I meant vcpkg instead of flatpak!

[Tachi107]

I did some quick work for a Flatpak but the first problem that has to be tackle VCPKG. It's not very suitable for the reproducible and isolated build standard of Flatpaks: The VCPKG-package fails because it tries to connect with the network within the build process which is running in an isolated environment.

https://github.com/Eonfge/flathub/tree/info.cemu.Cemu

This should first be resolved before we can continue with a Flatpak

This has been fixed in #75; the build can be now completed without using vcpkg (only system dependencies)

[Doomsdayrs]

Had to disable vcpkg for the flatpak build, as flatpak does not allow network access during build time.

      - -DENABLE_VCPKG=false

[Doomsdayrs]

Alright, so I have reached the point of handling dependencies.

imgui is a dependency that the project uses, but it does not have a cmake, I have tried to create one, but this is not my expertise, anyone think they can help?

[Tachi107]

Cemu's Findimgui.cmake file already checks for both a pkg-config file and a CMake Config file, usually provided by distros. What issue are you facing?

[Doomsdayrs]

Cemu's Findimgui.cmake file already checks for both a pkg-config file and a CMake Config file, usually provided by distros. What issue are you facing?

I cannot use vcpkg for flatpak, the dependencies have to be specified explicitly.

Thus, imgui has to be built. And imgui does not have a cmake file on its repo.

[Tachi107]

I know you cannot use vcpkg. What I meant is that the Findimgui.cmake file can find imgui if it is installed on the host system (for example, when installing the libimgui-dev package on Debian).

What environment do you have to use to build Flatpaks?

[Eonfge]

I've been keeping up to date, and this should be the next step in getting a working Flatpak Cemu. Latest version has -DENABLE_VCPKG=false, full llvm12 (clang-12) and so forth.

https://github.com/Eonfge/flathub/tree/info.cemu.Cemu

[istori1]

Had to disable vcpkg for the flatpak build, as flatpak does not allow network access during build time.

      - -DENABLE_VCPKG=false

Something like this will enable the use of network for vcpkg

modules:
  - name: vcpkg
    build-options:
      build-args:
         --share=network

[JakobDev]

This will allow network in flatpak-builder, but the Flathub buildserver still blocks it, so you can only build locally and publish on a custom repo. If you want to publish on Flathub, you need to build without network.

[Doomsdayrs]

@SSimco Since I lacked the time to contribute for this enough, can you make the PR to flathub?

[JakobDev]

It would make sense to upstream the patches.

[j8r]

Hello, good news: I got a fully flathub-compliant Flatpak built. However, the application quickly returns an error after startup stating that some directory are not writable. It can be fixed by complying with the XDG directory standard.

Now remains to contribute to Cemu to make application run properly inside Flatpak, be free to work on it :slightly_smiling_face: . Here is the Flatpak source code along with the build instructions for those wanting to work on it.

Here are the AUR files along with their patches, which can be helpful - all credits to them: https://aur.archlinux.org/cgit/aur.git/tree/?h=cemu

Thanks to @Anuskuss, @Doomsdayrs and @Eonfge for their work, which helped me to make the package.

Some questions:

• Why https://github.com/cemu-project/Cemu/blob/main/src/resource/logo_1.png is 241x241, not 256x256? Also the naming scheme can be more robust, for example by suffixing the px numbers. More image resolutions will be also welcome: 16, 32, 48, 64, 128 and 512, plus a svg if you can.
• Only the filesystem,nowide,program_options,system boost libraries have been necessary. Others defined in https://github.com/cemu-project/Cemu/blob/main/vcpkg.json could potentially be removed (to be tested)

[Exzap]

Oh good work! I started to look into flatpak myself recently because this PR seemed stale. While working on it I also fixed some issues with our build system so that we don't require as many patches and workarounds for building the flatpak. (Ideally none at all)

Since I got pretty far already I think the best course of action is to merge our work and then I can submit it to flathub under the name of our organization (cemu-project). Assuming you don't mind?

However, the application quickly returns an error after startup stating that some directory are not writable. It can be fixed by complying with the XDG directory standard.

There have been some PRs for this already. A recent one was pretty promising but the author closed it without comment. I'll look into this.

Why https://github.com/cemu-project/Cemu/blob/main/src/resource/logo_1.png is 241x241, not 256x256? Also the naming scheme can be more robust, for example by suffixing the px numbers. More image resolutions will be also welcome: 16, 32, 48, 64, 128 and 512, plus a svg if you can.

No particular reason other than we don't have the logo in a higher resolution and the original artist has long disappeared. Someone would have to remake it if we wanted it as SVG or in much higher resolution since upscaling can only get us so far.

Only the filesystem,nowide,program_options,system boost libraries have been necessary. Others defined in https://github.com/cemu-project/Cemu/blob/main/vcpkg.json could potentially be removed (to be tested)

We definitively use more than that. Keep in mind that boost modules often have dependencies on other boost modules and you indirectly get more modules than you ask for. When I wrote the list for vcpkg.json I went through all the included boost modules in our source so there shouldn't be any unnecessary ones.

[j8r]

Thanks for the quick reply! Great, awesome if you can work on that! For the name, it is a reverse domain name. The Cemu project owns the cemu.info domain, so the app name will start with info.cemu. I suspect it can be info.cemu.cemu-project.Cemu instead of info.cemu.Cemu if you prefer. It can also be com.github.cemu-project.Cemu.

I don't know if you know how the flathub submission work? It doesn't matter much at the end who submit. I can let you fork my repository and make any modification deemed necessary. You'll have admin rights to the future flathub repository of course anyways.

[j8r]

No particular reason other than we don't have the logo in a higher resolution and the original artist has long disappeared. Someone would have to remake it if we wanted it as SVG or in much higher resolution since upscaling can only get us so far.

I guess it is the perfect time for a new logo contest 😄

[JakobDev]

The Cemu project owns the cemu.info domain, so the app name will start with info.cemu. I suspect it can be info.cemu.cemu-project.Cemu instead of info.cemu.Cemu if you prefer. It can also be com.github.cemu-project.Cemu.

The App ID is already set: It's info.cemu.Cemu, like the name of the Linux dist files. It was discussed back then. btw: ID's that start with com.github are no longer allowe3d on Flathub.

There have been some PRs for this already. A recent one was pretty promising but the author closed it without comment. I'll look into this.

Sounds good. I hope that we will get a Flatpak soon.

[j8r]

Oh ok so @Exzap meant submitting the PR from https://github.com/cemu-project/flathub/tree/info.cemu.Cemu, my bad. No problem!

[cobalt2727]

No particular reason other than we don't have the logo in a higher resolution and the original artist has long disappeared. Someone would have to remake it if we wanted it as SVG or in much higher resolution since upscaling can only get us so far.

@Exzap Wikipedia seems to have a 512x512 version, no idea if this is official or not: https://en.m.wikipedia.org/wiki/File:Cemu_Emulator_icon.png

[ludgie]

No particular reason other than we don't have the logo in a higher resolution and the original artist has long disappeared. Someone would have to remake it if we wanted it as SVG or in much higher resolution since upscaling can only get us so far.

@Exzap Wikipedia seems to have a 512x512 version, no idea if this is official or not: https://en.m.wikipedia.org/wiki/File:Cemu_Emulator_icon.png

Seems to be a recreation from a guy, here's his DevianArt page: https://www.deviantart.com/we4ponx

Although maybe a new logo contest would be better

[j8r]

Let's use that then, if the Cemu authors agree. It seems not copyrightable, thus free for any use.

[j8r]

I noticed the icon is not the same as the original icons. The best is to have a consistent one, the only way is to all the existing *.ico and *.png, and perhaps the already different cemu.icns. Either we derive those from the Wikipedia/DeviantArt one, which is in 512px, or maybe better create a new one in SVG.

[jibsaram]

However, the application quickly returns an error after startup stating that some directory are not writable. It can be fixed by complying with the XDG directory standard.

@j8r I was able to avoid this problem and successfully run Cemu within the flatpak build by compiling Cemu with PORTABLE set to OFF (this defaults to ON). With it off, it will actually already use XDG standard directories. It also seems like more recent commits of Cemu remove the need for the included glslang-spriv.patch.

Here's a diff of your repo's work, in case it helps. It has a few other changes to get things to compile locally, as it was referencing some specific commit branch combinations that have since become outdated/desynced. I also enabled --filesystem=home so that Cemu would actually have access to the home directory, and I also switched to the Release build type, though I don't think that part was strictly necessary to get things to build.

diff --git a/info.cemu.Cemu.yml b/info.cemu.Cemu.yml
index 754b7fa..b326128 100644
--- a/info.cemu.Cemu.yml
+++ b/info.cemu.Cemu.yml
@@ -3,7 +3,7 @@ runtime: org.gnome.Platform
 runtime-version: '43'
 sdk: org.gnome.Sdk
 
-command: Cemu
+command: cemu
 
 finish-args:
   - --socket=x11
@@ -11,6 +11,7 @@ finish-args:
   - --device=all
   - --socket=pulseaudio
   - --share=network
+  - --filesystem=home
 
 modules:
   - name: boost
@@ -35,7 +36,7 @@ modules:
     cleanup:
       - /lib/*.a
     config-opts:
-      - -DCMAKE_BUILD_TYPE=RelWithDebInfo
+      - -DCMAKE_BUILD_TYPE=Release
     sources:
       - type: archive
         url: https://github.com/fmtlib/fmt/archive/refs/tags/9.1.0.tar.gz
@@ -48,19 +49,19 @@ modules:
   - name: glm
     buildsystem: cmake-ninja
     config-opts:
-      - -DCMAKE_BUILD_TYPE=RelWithDebInfo
+      - -DCMAKE_BUILD_TYPE=Release
     sources:
       - type: git
         url: https://github.com/g-truc/glm.git
         branch: master
-        commit: cc98465e3508535ba8c7f6208df934c156a018dc
+        #commit: 0a6d3334ea747b0023d232572d3aff61dc6b48e6
 
   - name: glslang
     buildsystem: cmake-ninja
     cleanup:
       - /lib/*.a
     config-opts:
-      - -DCMAKE_BUILD_TYPE=RelWithDebInfo
+      - -DCMAKE_BUILD_TYPE=Release
       - -DBUILD_EXTERNAL=OFF
       - -DBUILD_SHARED_LIBS=ON
       - -DSKIP_GLSLANG_INSTALL=OFF
@@ -77,14 +78,13 @@ modules:
   - name: imgui
     buildsystem: cmake-ninja
     config-opts:
-      - -DCMAKE_BUILD_TYPE=RelWithDebInfo
+      - -DCMAKE_BUILD_TYPE=Release
     cleanup:
       - /lib/*.a
     sources:
       - type: git
         url: https://github.com/ocornut/imgui.git
         tag: v1.88
-        commit: 9aae45eb4a05a5a1f96be1ef37eb503a12ceb889
         x-checker-data:
           type: json
           url: https://api.github.com/repos/ocornut/imgui/releases/latest
@@ -101,7 +101,7 @@ modules:
   - name: libzip
     buildsystem: cmake-ninja
     config-opts:
-      - -DCMAKE_BUILD_TYPE=RelWithDebInfo
+      - -DCMAKE_BUILD_TYPE=Release
       - -DBUILD_DOC=OFF
     cleanup:
       - /bin
@@ -118,7 +118,7 @@ modules:
   - name: pugixml
     buildsystem: cmake-ninja
     config-opts:
-      - -DCMAKE_BUILD_TYPE=RelWithDebInfo
+      - -DCMAKE_BUILD_TYPE=Release
       - -DBUILD_SHARED_LIBS=ON
     sources:
       - type: archive
@@ -132,7 +132,7 @@ modules:
   - name: rapidjson
     buildsystem: cmake-ninja
     config-opts:
-      - -DCMAKE_BUILD_TYPE=RelWithDebInfo
+      - -DCMAKE_BUILD_TYPE=Release
       - -DRAPIDJSON_BUILD_DOC=OFF
       - -DRAPIDJSON_BUILD_EXAMPLES=OFF
       - -DRAPIDJSON_BUILD_TESTS=OFF
@@ -148,7 +148,7 @@ modules:
   - name: wxwidgets
     buildsystem: cmake-ninja
     config-opts:
-      - -DCMAKE_BUILD_TYPE=RelWithDebInfo
+      - -DCMAKE_BUILD_TYPE=Release
     cleanup:
       - /bin
       - /include
@@ -157,7 +157,6 @@ modules:
       - type: git
         url: https://github.com/wxWidgets/wxWidgets
         tag: v3.2.1
-        commit: 97e99707c5d2271a70cb686720b48dbf34ced496
         x-checker-data:
           type: anitya
           project-id: 5150
@@ -170,17 +169,15 @@ modules:
     buildsystem: cmake-ninja
     builddir: true
     config-opts:
-      - -DCMAKE_BUILD_TYPE=RelWithDebInfo
+      - -DCMAKE_BUILD_TYPE=Release
       - -DENABLE_VCPKG=OFF
+      - -DPORTABLE=OFF
     post-install:
-      - install -m755 ../bin/Cemu_relwithdebinfo $FLATPAK_DEST/bin/Cemu
-      - install -Dm644 ../src/resource/logo_icon.png $FLATPAK_DEST/share/icons/hicolor/128x128/apps/info.cemu.Cemu.png
-      - install -Dm644 ../dist/linux/info.cemu.Cemu.desktop $FLATPAK_DEST/share/applications/info.cemu.Cemu.desktop
-      - install -Dm644 ../dist/linux/info.cemu.Cemu.metainfo.xml $FLATPAK_DEST/share/metainfo/info.cemu.Cemu.metainfo.xml
+      - install -m755 ../bin/Cemu_release /app/bin/cemu
+      - install -Dm644 ../src/resource/logo_icon.png /app/share/icons/hicolor/128x128/apps/info.cemu.Cemu.png
+      - install -Dm644 ../dist/linux/info.cemu.Cemu.desktop /app/share/applications/info.cemu.Cemu.desktop
+      - install -Dm644 ../dist/linux/info.cemu.Cemu.metainfo.xml /app/share/metainfo/info.cemu.Cemu.metainfo.xml
     sources:
       - type: git
         url: https://github.com/cemu-project/Cemu.git
-        # branch: master
-        commit: b724a657e6b33e011808dbc4a398a344c4f7593d
-      - type: patch
-        path: glslang-spriv.patch
+        tag: v2.0-8

Edit: Updated above patch to include a fix for Cemu not correctly launching from the .desktop shortcut. The binary was copied over in a different directory and was called Cemu, whereas the official included .desktop file from the Cemu repo that's actually being used by the Flatpak build too is looking for a binary called cemu (lowercase). So your Flatpak repo's info.cemu.Cemu.desktop file is not actually used, and as mentioned before, glslang-spriv.patch is no longer needed.

Hope this helps :).

[j8r]

Thanks to have tried it out! Being able to write to the home is not a solution, it defeats the whole purpose of the sandbox, plus is not necessary if the application is designed properly. I'll add host:ro to access the roms.

RelWithDebInfo should also be kept, can be useful for debugging, and otherwise the flatpak linter will flag those.

The remaining change is PORTABLE=ON then, the executable name and removing the patch. Thanks to have pointed me to that!

[Doomsdayrs]

Thanks to have tried it out! Being able to write to the home is not a solution, it defeats the whole purpose of the sandbox, plus is not necessary if the application is designed properly. I'll add host:ro to access the roms.

I think its better to just upstream using xdg portals.