Fedora is pretty aggressive with updating KDE. They push major new versions during a Fedora release.

HDR is new ground on Linux, so it’s understandable it’s taking a while. It requires involvement from all over the graphics stack: graphics drivers, mesa, Wayland protocol, protocol needs to be implemented in compositor, apps need to implement the protocol.

It’s hidden away on Gnome. You need to hit a keyboard shortcut that brings up a special console window then run a command to enable the HDR.

For better or worse, Plasma has the option prominently displayed in settings.

You can right now. If you are using KDE, it should work with mpv, though you might need to launch it from terminal with a few flags to tell mpv to use HDR.

If you’re not using KDE, you can launch gamescope with the hdr flag in the tty and have it launch mpv.

Though I’m not sure any browsers have working HDR. I think Chromium may have some stuff in progress. Gnome Web may get it since WebKit supports HDR and HDR is being worked on for GTK.

They as in Wayland? Xorg doesn’t have HDR either and never will.

you can’t go and install apt packages without updating your system first

You can use apt without updating first. You’ll just be installing potentially outdated versions if the cached repository information is old. Though you may run into issues if you do partial upgrades (updating the cached repository, but not running an upgrade, then installing something new). Though this is less of an issue on Ubuntu since they try not to do big updates.

you also can’t use a GUI apt frontend as well as apt via the command line

The error message should tell you that you can’t have multiple commands running at once. The error message is a bit too technical, citing the lock files.

I would like to remind everyone that while this extension does not include display response measuring and calibration, they will come later.

No calibration yet.

This is the protocol for HDR content. KDE already ships an experimental version of it.

Shame, it seems an apt issue caused him multiple problems.

It prevented him from setting up Davinci Resolve, though honestly that probably wouldn’t have worked out well anyways.

He also wasn’t able to install the deb of kdenlive, but at least the snap version worked for him.

Cinnamon’s accent color support works by changing the GTK theme, which Firefox would follow.

The Firefox 133 update changes the accent color without changing the GTK theme, I believe it’s following the accent color portal.

I’ve had two XFX cards, an RX 480 and 6700 XT. Didn’t have issues with either one, no coil whine with the fans.

Bizarrely enough, I think KDE apps also read that info from ~/.config/gtk-3.0/gtk.css. So use Flatseal, KDE’s settings, or the CLI to give all apps access to that file.

True, although not in the same way. KDE is using its own GTK theme and uses ~/.config/gtk-3.0/gtk.css to override colors to the accent color. But this method is broken for sandboxed versions of Firefox since they can’t access ~/.config/gtk-3.0/gtk.css (though with flatpak you could create an override to allow it).

I believe (and hope) Firefox is now following the standardized accent color portal for determining the accent color. If so, then this accent color change should work on Gnome, KDE, Pantheon, and other desktops that support the accent color portal. If true, then even sandboxed apps should follow the accent color without messing with the sandbox.

You’re up to date. Staging refers to the updates they release every 2 weeks.

That’s in contrast to the stable releases they release once a year, which incorporates all the development that happened in the past year of staging updates.

Fixed the title.

Good for those who want Wayland native windows.

But as with new code and features, it may have bugs. I wouldn’t be surprised if some distros make it default back to Xwayland instead.

The big thing it has going for it is that they set up btrfs snapshots out of the box so you can rollback if necessary.

They also do more automated testing than Arch so theoretically it should be more stable.

No, you are never specifying to actually upgrade the package with the ‘u’ flag. Running pacman -Sy archinstall would upgrade the package, since it would first refresh the package cache then reinstall the latest version.

Also, there’s not really a benefit to using 2 'y’s but it does add some extra stress to the package mirrors, so I would avoid doing that.

Current Arch ISO is from November 1, so you likely used the old version (unless you used pacman -Syu before you used in the installer).

Flatpak firefox stores that stuff in ~/.var/app/org.mozilla.firefox