Slight correction, it’s available in Linux 6.7, and has to be enabled with the kernel parameter nouveau.config=NvGspRm=1. It may be enabled by default soon though (latest news I could find about that here).

NVK itself is not dependent on anything proprietary, but it’s practically required to enable NVIDIA’s GSP firmware blob if you want to see actual performance since it’s what enables re-clocking (older post by Collabora here which touches on it).

Cheers, glad to hear you got it working. I don’t think there’s any problem on your end; all my flatpaks are user-installed as a Guix System user, so it didn’t cross my mind that a habitually-placed --user flag would not work if something was installed system-wide!

Thanks for posting about this! I never thought to try this as an Akregator user, but it’s a great idea… I spent the past day getting this to work since I also use the Flatpaks; hope it helps.

As suggested by @[email protected], one solution is to define a custom protocol where the URL gets passed to a script that opens Firefox Reader with the URL; here’s what I’ve done:

1. Decide on a protocol name, which the URL will be prefixed with and passed to xdg-open since that should be available to the Flatpak. I used firefox-reader as the protocol, so I put xdg-open firefox-reader://%u as the custom command (so a command Akregator would run might look like xdg-open firefox-reader://https://example.com).
2. Define a desktop entry to support the custom protocol (you can see mine below). ~/.local/share/applications is the standard place to put these, as far as I’m aware. Since the custom protocol needs to be removed from the URL, I wrote a script (also below) to do this and then call Firefox with about:reader?url= prefixed. The script can be anywhere in $PATH.
3. Add the desktop entry as a “default application” for opening URLs using this custom protocol. In my case, I ran xdg-mime default org.mozilla.firefox.reader.desktop x-scheme-handler/firefox-reader (org.mozilla.firefox.reader.desktop is the name of my desktop entry file).
4. You also might have to update some mime/xdg database stuff. I had to run update-desktop-database ~/.local/share/applications so xdg-open would find the “Firefox Reader” desktop entry.

[Desktop Entry]
Type=Application
Name=Firefox Reader
Exec=open-firefox-reader.sh %u
StartupNotify=false
MimeType=x-scheme-handler/firefox-reader;

#!/usr/bin/env bash

flatpak run --user org.mozilla.firefox about:reader?url="${1#firefox-reader://}"

If you have any other trouble or want to find more information about this since the desktop entry could probably be tweaked, here are the sources of note I used to figure this out (If I forgot a step or two writing this, they should also be present somewhere in there):

• https://unix.stackexchange.com/questions/497146/create-a-custom-url-protocol-handler
• https://wiki.archlinux.org/title/XDG_MIME_Applications
• https://wiki.archlinux.org/title/Desktop_entries#Update_database_of_desktop_entries

I haven’t gotten around to trying the stable release out, but there’s one ProtonDB report - presumably for 6.0 given the post date - so far that says it works flawlessly.

I’m guessing the situation is the same as pre-6.0, though. I participated in some of the playtests, where I got the same performance issues that I got before with the game slowing to a crawl after some time. The user on ProtonDB also has pretty beefy specs, so I couldn’t say if the performance issues were fixed, either. I’m not sure if you’re asking if it’s playable or has gotten better, so I will say that (at least for pre-6.0) it technically works regardless as long as your computer is beefy enough.

The Proton GitHub issue for Squad might be nice to bookmark to make or check up on every once in a while; usually any issues, fixes, and updates end up there.