BC-250 kernels — stable 7.3.0, RC 7.3.rc6, BORE 7.3.0

BC-250 CachyOS kernels + Mesa repository

Kernels

Stable: linux-cachyos-bc250

• Upstream source: linux-cachyos
• Version: 7.3.0-4.341
• Patch set: linux-cachyos
• The Cyan Skillfish DP-audio spread-spectrum fix is omitted: it has been upstream since Linux 7.2.
• Now built on Linux 7.3 (cachyos-7.3.0-2), so this kernel carries the same twenty-two patches as the RC one -- including the ch7218-vrr-allowlist and pcon-vrr-hf-vsdb carries described under the RC section below. CachyOS's 7.2/hdmi branch used to provide that behaviour on the stable side and 7.3 does not, so VRR through a CH7218 needs the patches here now.

Release candidate: linux-cachyos-rc-bc250

• Upstream source: linux-cachyos-rc
• Version: 7.3.rc6-2.317
• Patch set: linux-cachyos-rc
• Built from the patches/linux-cachyos-rc set, which since Linux 7.3 became stable is an identical copy of the stable set; the two directories stay separate because each is regenerated against its own CachyOS tag.
• The hdmi21-vtem-on-tmds.patch carry ("Emit VTEM for HF-VSDB VRR on TMDS links", upstream 640fd039dc8b) has been dropped. It is queued for Linux 7.4 -- it landed in drm-next on 2026-09-02, one day after 7.3-rc1 was tagged -- so it arrives on its own with the next series. It also only ever applied through a passive DP++ adapter; through an active DP->HDMI converter the GPU speaks DisplayPort and the code never ran. The other seven patches of the original backport arrived in cachyos-7.3-rc2-1 via CachyOS's 7.3/hdmi merge and were dropped earlier.
• ch7218-vrr-allowlist.patch (both sets) -- FreeSync passthrough on a Chrontel CH7218 DP-to-HDMI 2.1 adapter (DPCD branch OUI 2B:02:F0, UGREEN DP134 and most compact "8K" plugs). CachyOS's 7.2 kernel listed this converter in the FreeSync PCON allowlist; its 7.3 line was rebuilt on a different VRR series and does not -- checked against cachyos-7.3.0-2 on 2026-10-21 -- so on 7.3 the same adapter fails the allowlist and VRR is silently absent, identical hardware. One static table entry, unconditional (it cannot be gated and only states the chip may carry VRR, which it does). Unrelated to the opt-in CH7218 quirk above.
• pcon-vrr-hf-vsdb.patch (both sets) -- the allowlist entry above was necessary but not sufficient. On 7.3 a DP-to-HDMI PCON gets its VRR range only from the AMD FreeSync EDID block, parsed by DMUB/DMCU firmware that DCN201 does not have, so the parse always fails on a BC-250 and the range stays 0/0 even when every DPCD gate passes. This adds what 7.2/hdmi already did: fall back to the HDMI Forum VRR range the DRM core parses in software. Covers TVs without an AMD block too. drm.debug=0x2 logs the decision as VRR: PCON HF-VSDB fallback.

BORE: linux-cachyos-bore-bc250

• Upstream source: linux-cachyos-bore
• Version: 7.3.0-4.341
• Patch set: linux-cachyos
• Uses the same BC-250 patch set as the stable kernel (patches/linux-cachyos).

All three kernels use:

• ISA baseline: x86-64-v3 (CachyOS generic_v3)
• CPU tuning: Zen 2 (KCFLAGS=-mtune=znver2)
• BC-250 telemetry/GPU-activity fixes, with 8-core SMU metrics decoding matched to the patched SMU firmware in the current community BIOS. 8-core boards must run patched SMU firmware -- there is no supported fallback for stock/unpatched SMU firmware on 8 cores. Patch it via https://github.com/Forbidden-Darkness/AMD-BC-250-UEFI-v2.2-Firmware-Menu-Script/releases (prebuilt flashable UEFI) or https://github.com/rw-r-r-0644/bc250-smu-unlock (userspace patcher)
• GFX1013 PASID TLB invalidation fix and compute GFXOFF guard
• Opt-in KFD/HWS runlist TLB workaround (amdgpu.bc250_flush_by_runlist=1)
• AMDGPU TTM NULL-page cleanup guard for partially populated BOs
• Widened Cyan Skillfish SMU SCLK range (350-2230 MHz) for userspace SMU governors
• 4K120 at 4:4:4 over HDMI 2.1, on by default: HDMI 2.1 PCON negotiation (dcn201-hdmi21-pcon.patch) and the two on-die DCN201 DSC engines (dcn201-enable-dsc.patch) through an active DP 1.4 -> HDMI 2.1 FRL adapter. Verified on a BC-250 into an LG G5 via a UGREEN 8K adapter: FRL PCON negotiated, DSC at 12 bpp, 3840x2160@120 RGB with HDR. A native DisplayPort monitor or a passive adapter is untouched either way. amdgpu.bc250_hdmi21=0 switches it off and gives an unpatched kernel back. Not upstream -- the work of TeleBooth (https://gist.github.com/TeleBooth/d88ef745895d444a401d0e621de9818e).
• Opt-in: CH7218 adapter quirk for a black screen at 4K120 (found, diagnosed and originally written by @dejan_994). Some DP-to-HDMI 2.1 adapters built on a Chrontel CH7218 -- UGREEN units among them, DPCD branch OUI 2B:02:F0, branch name CH7218 -- ship firmware that reports no HDMI downstream port, or reports it as DisplayPort, when the adapter is in fact a DP-to-HDMI 2.1 converter. The driver believes it, never negotiates FRL, and sends 4K90/4K120 as plain DisplayPort video the adapter cannot emit over TMDS: black screen, while 4K60 keeps working. ch7218-pcon-quirk.patch forces the converter identity and restores the 12 bpc / FRL 48 Gbps / YCbCr 4:2:2 and 4:2:0 ceilings. Off by default -- enable with amdgpu.bc250_ch7218_quirk=1 alongside the default amdgpu.bc250_hdmi21=1, then confirm with cat /sys/module/amdgpu/parameters/bc250_ch7218_quirk (the CH7218 quirk dmesg lines appear only in a detection where the firmware actually misreported; a correctly-reporting adapter is left untouched and silent, and since this build the final ceiling re-assert is also limited to those detections). It stays opt-in because plenty of CH7218 adapters work correctly and nothing in the DPCD tells a broken unit from a healthy one, so enabling it for everyone would override correct information from working hardware. With the parameter unset the kernel behaves exactly as it would without the patch: every part of this workaround checks the switch before touching anything. If 4K120 is still absent afterwards, check the sink EDID for CTA VIC 118 -- that is a display limitation, not a kernel one. Details in docs/PATCHES.md.
• Experimental, opt-in: pcon-force-dsc.patch -- for DP-to-HDMI 2.1 adapters that advertise no DSC decoder although the chip has one. A Cable Matters 102101 (Synaptics VMM7100, fw 7.02.120) reports no DSC and no FEC on this board, so 4K120 is built as YCbCr 4:2:2 10-bit instead of RGB 12-bit with DSC. amdgpu.bc250_pcon_force_dsc=1 advertises a DSC 1.2a decoder and FEC on behalf of an adapter whose DSC block is entirely zero (the block a known-good CH7218 reports is used as the template) and drives it accordingly. It is a probe of the adapter's firmware, not a fix: if it really cannot decode, 4K120 comes up black or corrupted and the parameter must be removed. Adapters that advertise any DSC capability are never touched. Logs what it overrode at warning level. Off by default; with the parameter unset the helper returns before touching anything.
• Always on: a CH7218 that denies its own DSC decoder is corrected. Split out of the opt-in quirk above into ch7218-dsc-restore.patch, and deliberately not behind a parameter. Some CH7218 firmware clears DP_DSC_SUPPORT while still reporting the decoder's revision, slice capabilities and maximum bits per pixel -- a combination that cannot describe real hardware. DC believed the bit, and since a DP 1.4 HBR3 x4 link cannot carry 4K120 RGB uncompressed, the stream came back as YCbCr 4:2:2 10-bit instead: picture unaffected, colour detail quietly worse, nothing logged. Seen on an adapter that reports everything else correctly, after the display returned from standby. Unlike the identity quirk this cannot override a correct report -- if the bit is set there is nothing to do, and if the capability block is empty the adapter really has no decoder -- so it needs no opt-in. amdgpu.bc250_hdmi21=0 switches it off with the rest of the PCON path; dmesg | grep 'restored cleared DSC_SUPPORT' shows when it stepped in.
• Fixed: the display going dark on a mode change. The BC-250 reaches HDMI through a DP-to-HDMI 2.1 converter; when the display stream stays off longer than a few seconds -- a slow session handover -- the converter drops its HDMI side, and the driver brings the picture back from cached link state without re-detecting, reporting success into a dead link. cs-relink-after-long-blank.patch now times the blank and forces a full re-detect (the same thing a cable re-plug does) when the stream returns after more than amdgpu.cs_relink_ms milliseconds, default 3000, a quarter second after the mode is set. Short switches are untouched: a normal handover blanks for about 0.1 s. Runtime-writable knobs: cs_relink_ms (3000; 0 disables), cs_relink_delay_ms (250), cs_relink_cooldown_ms (10000, a hard loop breaker), cs_relink_at_boot (0), cs_relink_debug (on; dmesg | grep 'bc250 relink'). cs_relink_at_boot is new and OFF by default: the blank timer only sees blanks that happen while the driver is running, so a machine that boots with the adapter already stuck gets no help -- reported surviving several reboots before clearing on its own. Set amdgpu.cs_relink_at_boot=1 to also re-detect once on the first screen of a boot, then read dmesg | grep 'bc250 relink' to see what it decided. It stays off because the benefit is unproven -- the driver already runs a full detect about three seconds earlier, and nothing can tell a stuck adapter from a healthy one -- while the cost is a real mode change and hotplug event rather than a quiet probe. Bounded to the first 60 s of uptime, and it does not start the cooldown timer, so it cannot swallow the first genuine long blank of the boot. Not a DSC problem -- reproduced with amdgpu.bc250_hdmi21=0 on an uncompressed 4-lane HBR2 link. A GPU governor is not the cause but makes it far more likely, because it lengthens session handovers (0.09 s without, 4.4 s with, same switch); temp-read = \"sysfs\" avoids that. Ver...

BC-250 FSR4 payload mirror

Pinned, checksum-verified mirror of the third-party payload used by the BC-250 FSR4 Proton packages (proton-cachyos-native-bc250, protonge-latest-bc250).

These are mirrors, not our work. They exist because the upstream sources are not durable:

• OptiScaler nightlies are pruned — the nightly repository retains roughly a month (33 releases at the time of writing), so a pinned nightly URL 404s within weeks and would break the build.
• The FSR4 provider is served from a GitHub Pages site, which can change without notice or versioning.

nightly-20260904 is the known-good OptiScaler build: it is the one the upstream BC-250 FSR4 work was measured and validated against, and every key of the shipped OptiScaler preset is present in its OptiScaler.ini. The build normally tracks the latest nightly and validates the preset against it, falling back to this mirror when a key is missing.

All three files match the upstream project's own manifest checksums:

730d5057338cf68adc3bf38a358985a04629ad00fae305bd717694a392216a53  OptiScaler_v10.0.0-pre1_20260904.7z
fb12735bfcc0d47f534f2206d57ec34129dc3d22b6405a1c2ef86745ab48b2eb  OptiPatcher_v0.41.asi
5de9b6d9f5475a0f2622e4cbce88cde46c68929d9bd0bbc353c70056997bb771  amdxcffx64_v4.1.1.xz

Provenance:

• OptiScaler — https://github.com/optiscaler/OptiScaler-nightly/releases/tag/nightly-20260904
• OptiPatcher — https://github.com/optiscaler/OptiPatcher/releases/tag/v0.41
• FSR4 provider (amdxcffx64 4.1.1) — https://loathingKernel.github.io/proton-upscalers/

The FidelityFX SDK is MIT licensed; its notice ships in the packages.