The raw backend may be overwriting the raw_info structure and set it (or parts of it) back to 14 bits.
The easiest way is probably to block all overlays and other raw tools for other bit depths, and override the bit depth only while recording.
Supporting all bit depths in the raw backend requires a bit more work. Additionally, some features use direct pixel access (rather than using raw_get_pixel) for speed reasons; this access is probably fastest in 12-bit mode, as the packing should be a little easier (just a guess, didn't do any benchmarks).
Nice to see it working on the M; I've expecting it to work only on DIGIC 4. Here's why:
If you remember the "raw type" register (see
PR #732) and look it up on the
Register_Map page, the register used on DIGIC 4 models (0xC0F08114) is labeled PACK32_ISEL (probably "input selection"). The bit depth register is 0xC0F08094 PACK32_MODE, so they must be related somehow. On 5D3, this register is 0xC0F37014, so I've expected the ISEL register to be moved as well. Didn't try yet.
Side note: PACK16 and PACK32 are probably image processing modules that write data from the image processor to the main RAM (the RAM visible from the ARM processor) and can convert it to various bit depths (hence the name "pack"). In a similar way, DSUNPACK, ADUNPACK and UNPACK24 are used to read image data from the ARM processor (which can be packed at various bit depths) and bring it somehow to other image processing modules. In all cases, the MODE register for each of these modules is used to configure the bit depth.
It isn't clear how to connect those processing modules together, but it's probably done with the ISEL switches (whose exact meaning is largely unknown, other than the above assumption about their naming).
