[BUG] linux-cachyos 7.2.0-1: AMDGPU HDMI 4K50/60 RGB Full causes black crush; 4K30 and LTS 6.18.42 are correct

### Pre-flight checklist

- [x] I have searched existing issues and this is not a duplicate.
- [x] I have read the [Contributing Guidelines](https://github.com/CachyOS/linux-cachyos/blob/master/CONTRIBUTING.md).
- [x] I have verified the issue is reproducible with the latest available CachyOS kernel.
- [x] I have tried to reproduce the issue on Arch Linux's `linux` kernel.

### Upstream / vanilla kernel check

I have not tested with a vanilla/upstream kernel

### Kernel variant

linux-cachyos (EEVDF, Clang)

### System information (cachyos-bugreport.sh)

```text
I am currently filing this report from another machine and cannot run cachyos-bugreport.sh at this moment.

The relevant system and graphics information collected during the controlled testing is provided manually in the field below. I can provide the full cachyos-bugreport.sh output later if requested by the maintainers.
```

### Manual system information (if cachyos-bugreport.sh is unavailable)

```text
Kernel version: 7.2.0-1-cachyos
Kernel package: linux-cachyos 7.2.0-1 (EEVDF, Clang)

CPU: AMD Ryzen 5 7530U (Barcelo-R / Zen 3)

GPU: AMD integrated Radeon Graphics
GPU PCI ID: 1002:15e7
Driver: amdgpu

Architecture: x86-64-v3

Active SCX scheduler: none knowingly configured / not verified
```

### Bug description

After updating from linux-cachyos 7.1.8-1 to 7.2.0-1, the external HDMI display shows severe black crush when using RGB Full at 3840x2160 50 Hz or 60 Hz.

The internal eDP display is unaffected.

The issue is strongly mode/link-rate dependent:
- 3840x2160 @ 30 Hz, 8 bpc, RGB Full: correct
- 3840x2160 @ 50 Hz, 8 bpc, RGB Full: black crush
- 3840x2160 @ 60 Hz, 8 bpc, RGB Full: black crush

Using RGB Limited at 4K50/60 removes the black crush, while RGB Full at 4K30 works correctly.

A controlled comparison with linux-cachyos-lts 6.18.42-1 on the same hardware, userspace, TV, HDMI input and cable shows 3840x2160 @ 60 Hz RGB Full correctly.

This strongly suggests a kernel/AMDGPU HDMI regression in the high-TMDS path rather than a general Plasma/KWin/TV color configuration issue.

### Steps to reproduce

1. Boot linux-cachyos 7.2.0-1-cachyos.

2. Connect/use the external 4K TV via HDMI.

3. Set the HDMI output to:
- 3840x2160 @ 60 Hz
- 8 bpc
- RGB Range: Full

4. Display dark content with visible near-black/shadow detail.

Result:
The external HDMI display shows severe black crush. Near-black shades collapse into black, while the internal eDP display remains correct.

5. Change only RGB Range from Full to Limited.

Result:
The black crush disappears.

6. Change back to RGB Full and set 3840x2160 @ 30 Hz, 8 bpc.

Result:
The image is correct and near-black detail is preserved.

### Expected behavior

3840x2160 @ 50/60 Hz with 8 bpc and RGB Full should preserve the full near-black/shadow detail without black crush.

The output should look the same in terms of RGB range handling as:
- 3840x2160 @ 30 Hz, 8 bpc, RGB Full on linux-cachyos 7.2.0-1, and
- 3840x2160 @ 60 Hz, RGB Full on linux-cachyos-lts 6.18.42-1

The internal eDP display and the external HDMI display should both reproduce dark tones correctly.

### Actual behavior

On linux-cachyos 7.2.0-1:

- 3840x2160 @ 30 Hz, 8 bpc, RGB Full: correct
- 3840x2160 @ 50 Hz, 8 bpc, RGB Full: severe black crush
- 3840x2160 @ 60 Hz, 8 bpc, RGB Full: severe black crush

At 4K50/60, near-black shades collapse into black and visible shadow detail is lost on the external HDMI display.

Changing only the RGB range from Full to Limited removes the black crush.

The internal eDP display remains correct at all times.

A kernel A/B test with linux-cachyos-lts 6.18.42-1 shows 3840x2160 @ 60 Hz RGB Full correctly on the same hardware, TV, HDMI connection and userspace.

### Logs / stack traces

```text
No kernel oops, panic, pageflip timeout or obvious AMDGPU error is emitted when the issue occurs.

The following check was run on the affected linux-cachyos 7.2.0-1 boot:

journalctl -b -k --no-pager | grep -Ei 'pageflip|flip_done|commit wait|amdgpu.*(error|warn)|drm.*(error|warn)'

Output:

The same check on the working linux-cachyos-lts 6.18.42-1 boot also produced no relevant matches.

No classic AMDGPU pageflip timeout has been observed on this machine.

Relevant DRM connector state in the affected 7.2 mode:

Broadcast RGB:
Automatic=0
Full=1
Limited 16:235=2
value: 1

content type:
No Data=0
Graphics=1
Photo=2
Cinema=3
Game=4
value: 1

Colorspace:
Default=0
BT709_YCC=2
opRGB=7
BT2020_RGB=9
BT2020_YCC=10
value: 0

The working LTS state exposes the same relevant connector properties:
- Broadcast RGB = Full
- Colorspace = Default
- content type = Graphics

AMDGPU DTN debug logs were also captured in both states:

GOOD:
- linux-cachyos-lts 6.18.42-1
- 3840x2160 @ 60 Hz
- RGB Full
- no black crush

BAD:
- linux-cachyos 7.2.0-1
- 3840x2160 @ 60 Hz
- RGB Full
- black crush

The two amdgpu_dm_dtn_log dumps are functionally identical. After ignoring blank lines/trailing whitespace, no meaningful differences were found in:
- HUBP
- DLG
- TTU
- DPP
- DGAM / SHAPER / 3DLUT / RGAM
- gamut adjustment
- MPCC / OGAM
- OTG timing
- DSC
- stream/link encoder fields exposed by DTN
- calculated clocks

The DPP color pipeline is bypassed in both GOOD and BAD states.

This suggests the failing state may be in HDMI-specific programming not exposed by amdgpu_dm_dtn_log, e.g. SCDC/scrambling, TMDS clock-ratio/transmitter programming, or HDMI AVI InfoFrame / RGB quantization signalling.

Full GOOD/BAD DTN dumps can be provided if requested.
```

### Additional system information

RAM: 16 GB

Desktop environment: KDE Plasma 6.7.4
Window manager/compositor: KWin 6.7.4-7.1
Display server: Wayland
Init system: systemd

Qt: 6.11.2
qt6-base: 6.11.2-2.1
Mesa: 26.2.1

GPU:
AMD integrated Radeon Graphics
PCI ID: 1002:15e7
Driver: amdgpu

Display setup:
- Internal eDP panel
- External 4K TV via HDMI
- Desktop normally cloned/replicated between internal and external displays
- HDR disabled
- Wide Color Gamut disabled
- No ICC profile
- Color profile source: EDID

Relevant mode clocks reported by modetest:
- 3840x2160 @ 30 Hz: 297000 kHz
- 3840x2160 @ 50 Hz: 594000 kHz
- 3840x2160 @ 60 Hz: 594000 kHz

The regression correlates with the 594 MHz modes:
- 4K30 / 297 MHz / 8 bpc / RGB Full: correct
- 4K50 / 594 MHz / 8 bpc / RGB Full: black crush
- 4K60 / 594 MHz / 8 bpc / RGB Full: black crush

Additional controlled tests:
- RGB Automatic at 4K60: no improvement
- RGB Limited at 4K60: black crush disappears
- RGB Full with explicitly forced 8 bpc at 4K60: black crush remains
- Forced YCbCr 4:4:4 via amdgpu debugfs: black crush remains
- HDMI audio: works normally
- Suspend/resume: works normally
- Lid close/open transitions: work normally
- Internal + external to external-only transition: works normally
- Internal eDP image: always correct

The 4K30 Full/Limited test behaves normally:
- 4K30 RGB Full: correct shadow detail
- 4K30 RGB Limited: visibly washed out / too bright, as expected for a range mismatch

This indicates that RGB Full and the TV-side range handling work correctly on the same kernel in the lower-link-rate mode.

Kernel A/B comparison:
Same laptop, TV, HDMI cable/input and userspace.

linux-cachyos 7.2.0-1:
- 3840x2160 @ 60 Hz, RGB Full: black crush

linux-cachyos-lts 6.18.42-1:
- 3840x2160 @ 60 Hz, RGB Full: correct

KScreen/DRM state in the affected 7.2 mode:
- RgbRange: Full
- Broadcast RGB: Full
- Colorspace: Default
- content type: Graphics
- HDR disabled
- Wide Color Gamut disabled
- no ICC profile

The corresponding relevant connector properties are effectively the same on the working LTS boot.

AMDGPU DTN comparison:
amdgpu_dm_dtn_log was captured in both states:

GOOD:
- linux-cachyos-lts 6.18.42-1
- 3840x2160 @ 60 Hz
- RGB Full
- no black crush

BAD:
- linux-cachyos 7.2.0-1
- 3840x2160 @ 60 Hz
- RGB Full
- black crush

The two DTN dumps are functionally identical after ignoring blank lines/trailing whitespace.

No meaningful differences were found in:
- HUBP
- DLG
- TTU
- DPP
- DGAM / SHAPER / 3DLUT / RGAM
- gamut adjustment
- MPCC / OGAM
- OTG timing
- DSC
- stream/link encoder fields exposed by DTN
- calculated clocks

The DPP color pipeline is bypassed in both GOOD and BAD states.

This suggests that the failing state may be in HDMI-specific programming not exposed by amdgpu_dm_dtn_log, for example:
- SCDC programming
- HDMI scrambling
- TMDS clock-ratio programming
- HDMI transmitter / stream encoder state
- AVI InfoFrame RGB quantization signalling

No classic AMDGPU pageflip timeout has been observed on this system.

Kernel log check:

journalctl -b -k --no-pager | grep -Ei 'pageflip|flip_done|commit wait|amdgpu.*(error|warn)|drm.*(error|warn)'

Result on affected 7.2 boot:

The same check on the working LTS boot also produced no relevant matches.

Separate kernel-dependent backlight observation:

linux-cachyos-lts 6.18.42-1:
brightness: 65535
actual_brightness: 0
max_brightness: 65535

linux-cachyos 7.2.0-1:
brightness: 65535
actual_brightness: 65535
max_brightness: 65535

Both kernels report:
[drm] Using custom brightness curve

Therefore, on this hardware:
- LTS: 4K60 RGB Full is correct, but the known 100% internal-panel backlight issue is present
- 7.2: the 100% backlight issue is fixed, but 4K50/60 RGB Full shows black crush

This may be unrelated, but it could be useful as AMD Display Core regression/bisect context.

At the time of testing:
- Arch core/linux: 7.1.8.arch1-3
- cachyos-v3/linux-cachyos: 7.2.0-1
- cachyos/linux-cachyos: 7.1.8-1

Therefore a same-version stock Arch/vanilla 7.2 comparison was not yet available from the repositories.

Current workaround:
- RGB Limited at 4K50/60, or
- 4K30 with RGB Full

Neither is preferred as a permanent solution.