Closed user7518275128 closed 2 years ago
Pobega
commented
2 years ago Unless I'm mistaken this isn't an XWayland issue, it seems like nothing is handling the fcade:// URL.
The Fightcade Flatpak was developed and is tested on Wayland pretty regularly
user7518275128
commented
2 years ago Thank you for replying so fast. Yes the title for the issue is probably incorrect. Do you want me to change it? This is more a xdg problem but surprisingly works fine with X11 native with the same setup.
Pobega
commented
2 years ago Does xdg-open work? Could you try something like xdg-open fcade://play/fbneo/ssf2xjr1 on the command line and post any output here (including errors)
user7518275128
commented
2 years ago Same error.
I also tried going into the sandbox using
$ flatpak run --command=bash com.fightcade.Fightcade
and running
xdg-open fcade://play/fbneo/ssf2xjr1
Got the same error from the first post.
xdg-utils package is version 1.1.3
Pobega
commented
2 years ago What's your desktop environment?
user7518275128
commented
2 years ago Currently using swaywm and launching it with dbus-run-session sway from TTY
This is using Alpine Linux
Pobega
commented
2 years ago I believe that is your issue. The way that Fightcade works is that it uses URLs to communicate with the emulators, there is a .desktop file shipped in the Flatpak that facilitates launching the emulators.
Your desktop environment is responsible for interpreting those .desktop files and you likely need to have one run as part of your sway session. It's something that comes for free with full desktop environments.
I don't believe this to be a bug with the Flatpak but rather a configuration issue.
Pobega
commented
2 years ago https://github.com/swaywm/sway/issues/5777 seems maybe related?
user7518275128
commented
2 years ago swaywm/sway#5777 seems maybe related?
This seems to be the exact same problem. I'll see if I can get any more logs at least to fix this temporarily.
Pobega
commented
2 years ago I'm going to close this issue since the problem doesn't seem to be related to the Flatpak, feel free to reply if you have more information in case others run into this issue.
Let me know if there's anything actionable on my end to help with Sway integration, but from what I've read this seems like an issue on Sway's end. Keep in mind Fightcade is distributed as a binary so I'm limited in how much I can realistically change.
Dagumi
commented
2 years ago The Arch AUR package for fightcade2 manages to handle the URLS on my i3 Xorg setup (but has another set of issues which makes your flatpak version preferable), however this flatpak version gives the error mentioned in OP. I believe from looking over that package's PKGBUILD that it doesn't really add functionality for handling URLS that's not in the official fightcade2 linux release.
I compared the handling between the official Fightcade2.sh, fcade.sh, and your fcade-quark.sh and can't really see how it could be any different, it seems like they all just pass the URL directly to emulator/fcade.
There must be some difference in handling if one works OOTB and the other doesn't, so it seems like there should be a way to generalize to systems without a desktop environment. If you decide to look into this issue again, please let me know if there's anything you'd like me to test or log.
Pobega
commented
2 years ago I'm definitely open to discussion/PRs/patches if you're willing to take a look at it, but realistically I am unlikely to attempt to debug this myself. But please feel free to poke around and share your findings!
It should be pretty simple to build the Flatpak yourself using flatpak-builder, and you could just modify fcade-quark.sh and add some logging to see if you can get more information out of it (or run it directly from within the sandbox using a fake fcade:// URL, like the one in the comments.)
Another way to 'force' a launch is to run xdg-open as mentioned earlier in the thread from within the sandbox. This should kick off your modified fcade-quark.sh.
Pobega
commented
2 years ago Now that I think about it there's a big difference here; you're using i3 on Xorg right?
The sway issue seems to be related to Wayland, but you're having a similar issue on X. Are you seeing the exact same dbus complaint?
Would be useful if @user7518275128 could update us on whether or not the tips in the linked bug worked for them on Sway.
Pobega
commented
2 years ago I can't see the comment in Github (did you delete it?) but it contained useful information so I'm going to repost it.
Right, it's definitely not a Wayland issue. Further, I'm pretty sure I figured out what I overlooked when comparing the official launcher script and yours. Line 13 of fcade-quark
IFS='/' read -r -a fcadecmd <<< "$PARAM"
I commented this out (along with the entire conditional below it except line 21), opened a bash env in the sandbox, ran fcade-quark fcade://play/fbneo/sfiii3 and successfully got a missing rom error (which is accurate, I don't have the rom set up). However, in my normal environment, running flatpak run com.fightcade.Fightcade and trying to use the "test game" button in the same game's lobby was still giving me the dbus error.
In this case it's definitely an issue on my end so I'd like to resolve it. My experience using this is that the read command breaks things up properly; I'm using it to figure out if Fightcade is attempting to do a checkrom (so I can manually handle that since it doesn't work automatically) and if not to just continue launching as usual.
I'm a bit confused how this could be broken; the read command is essentially the equivalent of splitting the $PARAM arg by / to find the command. If you run that same fcade-quark command without modifying the script and it doesn't work could you try to diagnose exactly what is going wrong?
Unless the read is either getting checkrom or failing (perhaps the read is failing and not setting the $fcadecmd var?) the conditional should always fall into launching the emulator normally.
Dagumi
commented
2 years ago I can't see the comment in Github (did you delete it?) but it contained useful information so I'm going to repost it.
I did delete it, after testing it again I realized that it was unrelated, passing a URL to fcade-quark in sandbox works regardless of that line, passing it to xdg-open in sandbox doesn't work regardless of that line (gives the OP's error). I accidentally conflated which commands I tested.
Pobega
commented
2 years ago That makes sense, sorry for necroing your deleted comment. So it's as I thought, it's something specific to opening with a URL handler which makes it harder to debug. I appreciate you looking into this, hopefully it's something I can fix in my package (though my gut tells me it's likely a bigger issue with Flatpaks and URL handling in window managers and may be more suited for a bug in https://github.com/flatpak/flatpak)
Dagumi
commented
2 years ago (though my gut tells me it's likely a bigger issue with Flatpaks and URL handling in window managers)
I agree, given all of that, the issue still seems to be that the URLS are not being handled by xdg-open correctly. I think it might be an issue with setting the MIME type or having an unset DE in the sandbox. If I can't figure out a solution I'll open a bug with flatpak. Thanks for the support regardless.
Pobega
commented
2 years ago On second thought the bug may be more relevant to https://github.com/flatpak/xdg-desktop-portal rather than the Flatpak issue tracker.
I did come across this thread on Reddit with some more i3 specific information - seems like there could be some pipewire goodies interfering, and there's a mention of putting dbus-update-activation-environment --systemd DBUS_SESSION_BUS_ADDRESS DISPLAY XAUTHORITY into your .xprofile. Do either of these solutions have any effect on your system?
Edit for futureproofing: The Reddit thread links to https://github.com/flatpak/xdg-desktop-portal-gtk/issues/107#issuecomment-777344071
Dagumi
commented
2 years ago I didn't have the relevant updated pipewire config and I happened to try the dbus-update[...] fix while troubleshooting the issue, so no avail for those. I'm going to try testing different implementations of xdg-desktop-portal backends.
Pobega
commented
2 years ago I got an email from the original creator of this issue with an update, but I guess they lost access to their Github account so I'll share it here in case anyone comes across this via Google.
Hi! 👋 I created a issue ticket months ago in the fightcade github, regarding Fightcade flatpak not responding to sway/labwc/whatever wayland Been trying to find out for weeks what is going on with the package. Fightcade on fedora + plasma + wayland + systemd works perfectly because Dbus finds the fcade-quark call instantly On the other hand... in setups without org.freedesktop.systemd1 (openrc/runit) looks like Dbus cannot get the call. Sorry for the wall of text 😅😅
In flatpak + wayland + openrc + plasma = I get prompts to choose an application for x-scheme-handler/fcade and with user interaction I cannot choose for fcade-quark (Emu never opens) In flatpak + wayland + systemd + plasma = I don't get prompts and everything is set well without user interaction (I assume systemd fixes the association automatically; emulators works
found the fix: enabling "support.dbus = enable" in wireplumber fixes it; or replacing wireplumber with pipewire-media-session 😅
Using Wayland (passthrough via xwayland) it's not possible to play games when clicking on TEST GAME or challenging a player.
$ flatpak run com.fightcade.FightcadeI'm currently using sway 1.7 with these xdg packages installed: