fix(graphics): mirror decoder GR-mode adaptation in RLGR1 encoder

[Rocco De Angelis (rdeangel)]

Problem

In rlgr::encode, the RLGR1 GR-mode zero branch updates kp with UP_GR (+4), while the decoder's corresponding branch (compute_rlgr1_magnitude) uses UQ_GR (+3), which is the value MS-RDPRFX 3.1.8.1.7.2 and FreeRDP's rfx_rlgr.c prescribe for GR mode. Because RLGR adaptation is implicit, encoder and decoder must update k identically from the coded symbols alone; with this mismatch the two sides' k diverges as soon as a zero value is coded in GR mode, and the remainder of the bitstream is misinterpreted (mode selection and run lengths depend on k).

Evidence

A randomized encode→decode round-trip (deterministic LCG, mostly-zero inputs with small magnitudes, i.e. the shape of quantized wavelet coefficients) failed on 1877 of 2000 inputs before this change. Example:

input:   [0, 2, -1, 7, 0, 0,  4,  -6, 7, 0, 1, 0, -4,  0,  0,  4, 1]
decoded: [0, 2, -1, 7, 0, 0,  2, -16, 5, 0, 2, 1,  4, -1, -1, -2, 0]

The divergence starts right after the first GR-mode zero. With the one-line fix, all 2000 round-trips pass.

Changes

• Use UQ_GR in the GR-mode zero branch of the RLGR1 encoder, mirroring the decoder.
• Add a rlgr1_round_trip_randomized regression test (rlgr.rs previously had no tests).

Found while debugging RemoteFX Progressive (EGFX) interop against xrdp in an IronRDP-based client.

🤖 Generated with Claude Code

[Greg Lamberson (glamberson)]

Nice catch. The UQ_GR fix is correct: it brings the GR-mode kp update in line with the decoder's compute_rlgr1_magnitude.

One note for merge ordering: elmarco's draft #1179 fixes this same UP_GR/UQ_GR line too, alongside two other RLGR encoder bugs it found, so there's a one-line overlap between the two PRs. No opinion from me on sequencing, just flagging it so the fix doesn't get duplicated. Whatever's easiest: this lands as a focused fix and #1179 rebases without that hunk, or it waits on #1179.

Good to see this one fixed regardless. It's on the RemoteFX Progressive encode path that #1199's round-trip tests cover.

[Rocco De Angelis (rdeangel)]

Thanks for flagging the overlap with #1179. If this lands first, elmarco can drop the overlapping hunk on rebase, otherwise happy to wait, whatever you prefer.