cdmc: correct the IndyCam register map and power-on defaults#57
Open
hanshuebner wants to merge 1 commit into
Open
cdmc: correct the IndyCam register map and power-on defaults#57hanshuebner wants to merge 1 commit into
hanshuebner wants to merge 1 commit into
Conversation
Live camera capture came out uniformly green: luma and geometry correct, red and blue crushed to near zero. Every CDMC subaddress except VERSION (0x0E) was mapped to the wrong control. The IndyCam register map is CONTROL 0x00, SHUTTER 0x01, GAIN 0x02, BRIGHTNESS 0x03 (read-only), RED_BALANCE 0x04, BLUE_BALANCE 0x05, RED_SATURATION 0x06, BLUE_SATURATION 0x07, GAMMA 0x08, VERSION 0x0E (read-only), RESET 0x0F. Mapping VERSION to 0x00 also made every CONTROL write get dropped as a write to a read-only register. The register file powered up at all-zero while apply_uyvy_field treated 0x80 as each control's neutral point, so every unprogrammed control sat at its extreme. The balance and saturation terms pulled Cb and Cr from 128 down to 96, which through BT.601 is R-51, G+38, B-64 per pixel — the green cast. The hardware defaults are not uniformly 0x80: red balance is 0x18 and blue saturation 0xC0. apply_uyvy_field is now anchored at the power-on values, so a guest that leaves the camera alone gets the host frame through byte-identical, and controls respond proportionally as the guest moves them. AGCENA and AWBCTL suppress the gain and balance terms, matching a host camera running its own auto-exposure and auto-white-balance. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Contributor
Author
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.

Live camera capture (
[vino] source = "camera") came out uniformly green — luma and geometry correct, red and blue crushed to near zero. Reproduced on IRIX 6.5.22 withvidtomem -f /tmp/cap -v 0.Two compounding bugs in the emulated CDMC:
The register map was wrong on every subaddress except VERSION (0x0E). The IndyCam map — same silicon the Linux
indycamdriver drives — is:Mapping VERSION to 0x00 also meant every CONTROL write was dropped as a write to a read-only register.
The register file powered up at all-zero while
apply_uyvy_fieldtreated 0x80 as each control's neutral point, so every unprogrammed control sat at its extreme. The balance and saturation terms pulled Cb and Cr from 128 down to 96, which through BT.601 is R−51, G+38, B−64 per pixel — exactly the observed cast. Note the hardware defaults are not uniformly 0x80, so "0x80 is neutral" is wrong even with a correct map.Fix
apply_uyvy_fieldis anchored at the power-on values: with the defaults in place every term is unity and the field passes through byte-identical. Controls respond proportionally as the guest moves them away from default. AGCENA and AWBCTL suppress the gain and balance terms respectively, matching a host camera running its own auto-exposure and auto-white-balance. RESET and read-only enforcement are handled.Verification
Isolated host capture from the guest first: a probe through the same nokhwa path showed macOS AVFoundation delivering correct 1920×1080 packed YUYV, clearing
src/camera.rs. Replaying that real frame throughCdmc::apply_uyvy_fieldoffline with candidate register states reproduced the reported green image exactly from the "gain set, everything else zero" state, and produced a clean frame with correct defaults.Six new tests in
src/cdmc.rs, includingpower_on_defaults_pass_the_field_through_untouched. Full suite passes (308).Write-up in
rules/irix/indycam-cdmc-register-map.md.Not addressed
The live preview in the video tool is still grey. That is the separate continuous-capture gap noted in
rules/irix/indycam-end-to-end-capture.md—read_channel_reg'sfield_counter >= 2descriptor-table readback anddma_emit_dword'sfield_counter == 0defer are one-shots tuned for a single interlaced frame, so nothing is delivered once a channel streams past the second field.Also unconfirmed: which subaddresses the IRIX driver actually writes. The cast is cured either way since the defaults are now pass-through, but confirming the map end-to-end wants a run with
log vino on.🤖 Generated with Claude Code