# DF-4226 — radeon legacy commit paths re-LOCK the output instead of unlocking

## What (pure source-level finding, hardware-gated)

The prepare/commit protocol of the DRM encoder helpers is:
prepare() locks the output PLL against BIOS command-processor updates
(`radeon_atom_output_lock(encoder, true)`), commit() must release it
(`..., false`).

In sys/dev/drm/radeon/radeon_legacy_encoders.c two commit functions pass
**`true` (lock)** again:

- `radeon_legacy_tmds_int_commit()` — drm lines **775, 777**
- `radeon_legacy_tv_dac_commit()` — drm lines **1146, 1148**

Every sibling in the same file does it correctly:
- `radeon_legacy_lvds_commit()` — lines 169/171 (`false`)
- `radeon_legacy_primary_dac_commit()` — lines 578/580 (`false`)
- `radeon_legacy_tmds_ext_commit()` — lines 940/942 (`false`)

Consequence: after any modeset on the internal-TMDS (DVI) or TV-DAC encoder,
the output remains locked; subsequent DPMS/modeset PLL programming via the
BIOS command tables is inhibited — persistent display malfunction (blank
output / failed modesets) until re-init. This is a functional DoS of the
display pipeline; **no memory-safety impact** (register bit only).
Upstream Linux fixed both call sites to `false`.

## Reproduce

Not reproducible on the QEMU guest: requires r100–r500 radeon hardware
(guest has Bochas VGA, no DRM device). Source-level certainty: the asymmetry
is self-evident against the three correct siblings in the same file, and
prepare() at lines 762/764 (tmds_int) and 1133/1135 (tv_dac) locks with
`true` — commit() must mirror with `false`.

## Fix

`true` → `false` at the four cited lines (see fix.diff).