fix(session): decode RGBA QOI bitmaps instead of dropping the frame

[clintcan]

Companion to #1335 on the client side. Addresses Marc-Andre Lureau (@elmarco)'s review comment on that PR: "if the server is correctly encoding RGBA bitmap, why not fix the client instead?" — short answer: doing both, because they fix different things and reinforce each other (server-side is also a bandwidth optimization, client-side is correctness against third-party RDP servers).

What's broken

In crates/ironrdp-session/src/fast_path.rs::qoi_apply, the Channels::Rgba arm is literally:

qoi::Channels::Rgba => {
    warn!("Unsupported RGBA QOI data");
}

So any server that emits an *a-channel QOI header — which is the natural mapping from a BgrA32 / ARgb32 / etc. screen capture in ironrdp-server::encoder::qoi_encode today — gets one warning per frame and a blank window on the viewer. #1335 fixes the server side of that for the in-tree ironrdp-server. But:

1. There's nothing in the QOI codec spec that forbids Channels::Rgba. A third-party RDP server that genuinely cares about alpha (layered composition, premultiplied content from a different capture path, etc.) is well within its rights to emit it.
2. Until fix(server): emit RGB-channel QOI for opaque captures so ironrdp-session can decode #1335 lands and ships in a published ironrdp-server release, every other ironrdp-server consumer in the wild keeps emitting RGBA QOI. Clients carrying this patch render those sessions correctly; clients without it don't.

So the client-side fix is the durable one. The server-side fix in #1335 stands on its own merits (it's a bandwidth optimization — opaque-capture alpha is always 0xFF and costs one byte per QOI literal chunk for zero information).

Fix

Mirror the existing apply_rgb24 / apply_rgb24_iter pair with a 4-bytes-per-pixel apply_rgba32 / apply_rgba32_iter that passes the alpha byte through to the framebuffer (instead of forcing 0xFF the way the rgb24 path does), and call it from the QOI Rgba arm. The Rgb arm is unchanged.

The screen framebuffer is a flat RGBA blit target with no blending, so for an opaque-capture server (everything carrying #1335, plus all current in-tree servers) the only observable effect is that the warning is gone and the frame renders. For a server that legitimately encodes translucent content, the alpha byte is now preserved end-to-end.

Reproduction (before the fix)

Built ironrdp-viewer with --features qoi and pointed it at macrdp 0.5.50 with its vendored QOI Rgb-only workaround disabled (so it emits the natural RGBA mapping):

$ ironrdp-viewer 127.0.0.1:3390 -u $USER -p ...
WARN ironrdp_session::fast_path: Unsupported RGBA QOI data
WARN ironrdp_session::fast_path: Unsupported RGBA QOI data
... (412 warnings in ~12s; viewer renders nothing)

After the fix

Same loopback session against the same macrdp build, no other changes:

• 0 Unsupported RGBA QOI data warnings
• viewer renders the desktop normally
• visual quality is identical to the pre-fix(server): emit RGB-channel QOI for opaque captures so ironrdp-session can decode #1335 Rgb path (alpha is ignored by the framebuffer either way)

Test plan

• cargo build -p ironrdp-session --features qoi — clean
• cargo clippy -p ironrdp-session --features qoi --all-targets -- -D warnings — clean (only pre-existing repo-wide MSRV-mismatch notice)
• cargo test -p ironrdp-session --features qoi — clean
• cargo fmt --check — clean
• Loopback ironrdp-viewer --features qoi against a macrdp build emitting RGBA QOI: desktop renders, zero RGBA warnings

Notes

• apply_rgba32 takes the same flip parameter shape as apply_rgb24 for symmetry; QOI calls it with flip = false.
• No format/codec advertisement changes — the client already accepts QOI without distinguishing Rgb vs. Rgba in the capability set. Only the apply path changes.
• If fix(server): emit RGB-channel QOI for opaque captures so ironrdp-session can decode #1335 lands first, this PR still has value as the durable correctness fix described above.

[Marc-Andre Lureau (elmarco)]

thanks! lgtm

[Benoît Cortier (CBenoit)]

LGTM!

[Copilot]

Pull request overview

This PR fixes the client-side QOI decode path in ironrdp-session so RGBA-channel QOI frames are decoded and applied to the framebuffer instead of being dropped, improving interoperability with third-party RDP servers and older ironrdp-server builds that emit RGBA QOI.

Changes:

• Add DecodedImage::apply_rgba32 / apply_rgba32_iter to blit RGBA32 pixel data (including alpha) into the session framebuffer.
• Update qoi_apply to apply decoded QOI frames for both qoi::Channels::Rgb and qoi::Channels::Rgba (removing the “Unsupported RGBA QOI data” drop path).

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
crates/ironrdp-session/src/image.rs	Adds an RGBA32 apply path mirroring the existing RGB24 path, preserving the alpha byte.
crates/ironrdp-session/src/fast_path.rs	Routes QOI RGBA frames to the new RGBA32 apply function instead of warning + dropping.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.