Hardware quirks database & implementation

I stumbled on this NixOS-hardware quirks database and configurations GitHub - NixOS/nixos-hardware: A collection of NixOS modules covering hardware quirks. · GitHub

Do we have some similar mechanisms in Fedora?

Concrete example: nixos-hardware/framework/13-inch/common/amd.nix at f8e82243fd601afb9f59ad230958bd073795cbfe · NixOS/nixos-hardware · GitHub

It applies the amdgpu.dcdebugmask=0x10 boot parameters to all AMD based framework laptops. The hangs caused by panel self-refresh seems to affect Framework users a lot, but also some users of other hardware vendors.

Should we implement a quirks database?

I think it is beneficial to end-users because they can get a working system out of the box after installing Fedora. The downside is it can mask upstream bugs (I still remove the amdgpu flag time to time to check if it’s fixed in the kernel), or become out of date.

Similar to downstream patches, we should try to upstream the quirk configurations to upstream so it benefits not just Fedora users.

How can it be implemented?

Unlike NixOS, it can be challenging to provide system-wide configuration overrides.

TuneD has a mechanism to set boot parameters but is using it for general purpose tuning a good idea?

Perhaps some commonly used configuration mechanisms like kernel boot params, kernel module params, gsettings and KDE equivalent, can be put in one place and applied via systemd units. This way it might even not be Fedora specific.

What do you think?