Announcing Pegasus Frontend

fastpop72

@fluffypillow said in Announcing Pegasus Frontend:

@fastpop72 oh looks like there was a number rounding issue, will fix it in a sec. This will fix the buttons staying on screen, but if you'd like to make your setup extra nice, you could also add a colored rectangle to hide the parts sticking out during the animation.

Thank you for the fix.

I tried to make an extra nice setup inserting a rectangle in this way between the last PrimaryMenuItem and the RollableMenuItem:

    Rectangle {
        width: parent.width
        height: 100
        color: "#eee"
    }

Anyway, during closing animation, the rectangle doesn't slide together with the primary Text and let the lower Text visible for some microseconds.... Am i missing some further arguments to add to Rectangle item?

fluffypillow

@fastpop72 Looks like the new rectangle is below the buttons; you could increase it's Z value to raise it above the others.

fastpop72

@fluffypillow said in Announcing Pegasus Frontend:

@fastpop72 Looks like the new rectangle is below the buttons; you could increase it's Z value to raise it above the others.

Solved!! Thanks!!

PS: Are you interested in a Pull Request? Launching the exe with the "kiosk" argument disable some menus (Settings, Help & Exit Pegasus) and the version text in the lower-left corner.

fluffypillow

@fastpop72 Thank you, actually I plan to make it so all quit buttons could be enabled/disabled individually, probably together with some settings file entries to also make it work on eg. Android. I'm not sure about the settings and help screen yet (I might need some license texts to be accessible), and also perhaps a full menu disable option could be possible too in the future.

fluffypillow

Weekly update! Well, sort of, as mentioned haven't had time the last week, but I should have some in this one.

At the moment I'm still struggling with the Pi 4 support. I have an idea of where do things go wrong, but couldn't confirm it yet and as it's quite deep in some low level code, it takes significant time to try out any changes. Hopefully I can do it without sacrificing too much sanity.

Other than that I'm writing documentation and might also do some cleanup/redesign on the home page.

Darksavior

@fluffypillow I'm here to test out builds if you wish.

fluffypillow

@Darksavior Thanks, unfortunately this time it's creating the builds that takes time, and figuring out what exactly happens near the driver. Will report as soon as I find something out.

fluffypillow

@Darksavior just to make sure, does game launching work in EmulationStation from the fkms branch?

hooperre

@fluffypillow Does for me. Yes.

fluffypillow

@hooperre thanks; I've actually managed to do some good progress today, if I'm lucky I might be able to fix this soon.

Darksavior

@fluffypillow yes. I do need to test the steamlink app but all emulators load with no issues.

PlayingKarrde

I finally managed to get RetroArch running on the Shield. For anyone else that wants to get it up and running this should be universal:

collection: Super Nintendo Entertainment System
shortname: snes
extensions: sfc, smc, zip
launch: am start --user 0
  -n com.retroarch.aarch64/com.retroarch.browser.retroactivity.RetroActivityFuture
  -e ROM "{file.path}"
  -e LIBRETRO /data/user/0/com.retroarch.aarch64/cores/bsnes_performance_libretro_android.so
  -e CONFIGFILE /storage/emulated/0/RetroArch/config/retroarch.cfg
  -e IME com.android.inputmethod.latin/.LatinIME
  -e DATADIR /data/data/com.retroarch.aarch64
  -e APK /data/app/com.retroarch.aarch64-1/base.apk
  --activity-clear-top

Just change for your specific collections (make sure to change the core file to one that is specific to your collection though of course).

This is also specifically for the aarch64 build of RetroArch. If for some reason you don't want to use the 64 version I believe you can just remove the .aarch64 parts from any of this. YMMV though.

@fluffypillow since this took me a while to figure out, and since the Shield is a good platform for this FE and RA the most useful emulator, I wonder if it would be worth adding this info to the docs as well?

fluffypillow

@PlayingKarrde sure, it can be added, and I'll also mention the 64bit version. Compared to the example from the docs, the difference (other than aarch64) seems to be

  -e LIBRETRO /data/user/0/com.retroarch.aarch64/cores/bsnes_performance_libretro_android.so
  -e CONFIGFILE /storage/emulated/0/RetroArch/config/retroarch.cfg

ie. the Shield uses /data/user/0 instead of /data/data and the config is stored directly on the storage (instead of under Android/data/com.retroarch/files). Is that correct? I wonder if that's something device- or Android version specific thing, or perhaps a setting in RA?

PlayingKarrde

Yes that's correct. I feel like it is platform specific because the shield seems to have a lot of it's settings split into storage for easy access. The other location is not directly accessible without root access.

fluffypillow

@PlayingKarrde turns out /data/user/0 is actually a symlink to /data/data, so both should work in theory. Could it be the config location then?

Edit: Indeed it seem that when you create a "New Configuration" it is created in a new RetroArch directory under the storage. By default both 32 and 64 bit releases seem to use Android/data/com.reatroarch. This could be pointed out in the docs.

fluffypillow

@Darksavior Progress! I've managed to launch both console and 3D programs with this build. Before running, you might need to

export QT_QPA_EGLFS_KMS_ATOMIC=1

An issue I've noticed is that after returning to Pegasus the keyboard presses seem to be duplicated. Will take a look into it. Also I couldn't test how it works with multiple screens or under X11. Haven't tried gamepads and actual emulators or ports yet either.

PlayingKarrde

@fluffypillow said in Announcing Pegasus Frontend:

@PlayingKarrde turns out /data/user/0 is actually a symlink to /data/data, so both should work in theory. Could it be the config location then?

Edit: Indeed it seem that when you create a "New Configuration" it is created in a new RetroArch directory under the storage. By default both 32 and 64 bit releases seem to use Android/data/com.reatroarch. This could be pointed out in the docs.

Interesting. Hmm then maybe it was purely the fact I was always using the aarch64 version and didn't have correct references. Although the com.retroarch.aarch64/com.retroarch.browser.retroactivity.RetroActivityFuture is also different but I'm unsure what that is a reference to tbh so I can't say what it should be looking for.

Darksavior

@fluffypillow Success! It seems to work without that command, though I do get the message Setting framebuffer size is only available with DRM atomic APIwhen not using it. If I do use it, I get the error framebuffer size format is invalid. I also get QObject::connect(QObject, FrontendLayer): invalid null parameterand [w] QCoreApplication::postEvent: Unexpected null receiverwhen loading games, though that's without using your command and I've messed around altering the stock theme too.

So I'm finally starting to get higher res box art, and the art is very blurry when displayed in pegasus. Any ideas? The current ones I'm testing with are nothing fancy..850x850 jpegs. I use 1080p output, but I also tried 4k output and there's no change in quality.

Original
Astal (USA) (DW0722)-image.jpg

Pegasus

Emulationstation

PlayingKarrde

@Darksavior That's most likely due to the sourceSize attribute for the image. It's imported at whatever resolution is specified there and then scaled.

fluffypillow

@Darksavior yes, the images are reduced to 256x256, which might be indeed a bit small on 4K :)

The atomic mode setting should be turned on, it allows to use a more modern way to handle the video driver, according to the docs, which the Pi 4 happens to support. Don't worry about the warning, apparently there's a way to provide some framebuffer settings to override, and the warning is produced when it's not set (ie. invalid).