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).
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:
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
).~/.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
.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).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):
I’ve been having my own fun trying out NVK on Guix System so I can’t give you specific instructions (assuming you’re not using Guix), but I can tell you what you need and maybe someone else can chip in on how/if you need to do anything else on your distro:
nouveau.config=NvGspRm=1
-Dvulkan-drivers=nouveau-experimental
flag.A few notes:
FLATPAK_GL_DRIVERS=host
); however, there’s a bug that causes the Steam Flatpak to not work when doing this. The mesa-git-extension Flatpak exists which can also be used to replace Mesa runtimes, but it had issues building with NVK so it’s currently disabled.The only package I’m aware of at the moment (other than my hacked-together Guix package) is available in the AUR.
It’s my pleasure :)
Just a note if you plan on installing Guix on top though, since I didn’t realize you might be running NixOS: according to this discussion, you’d need to take a different route to get Guix working.
I do!
For starters, you’re not required to install Guix System in order to use the Guix package manager itself; the manual provides instructions for installing it on top of your existing system here if you want to use it but not fully commit (you can do this with Nix too).
Guix allows for adding new sources to pull packages from using channels. The nonguix channel provides the Linux kernel - blobs and all - as well as other stuff that won’t be upstreamed, like Steam and NVIDIA drivers.
I recommend this helpful series by System Crafters, which includes a few guides on installing Guix and Guix System with the full Linux kernel.
You might find The Full-Source Bootstrap: Building from source all the way down by some of the GNU Guix maintainers of interest to read, which discusses how Guix is attempting to solve the “trusting trust” attack some have mentioned here.
Although I haven’t used it myself yet, Guix actually has a feature that lets you “challenge” the build servers to see if your builds match the pre-built binaries (the command being aptly named guix challenge
).
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).