Found a way to allocate the entire SRM memory without locking the exposure controls... sort of:
- When allocating the entire SRM memory (normally used for still photos, for holding uncompressed 14-bit raw data), Canon code locks the shutter button and shows the BUSY screen (to prevent you from taking any more pictures until some buffer becomes free again).
- Unfortunately, they also lock the exposure controls after you press the shutter halfway.
- I've tried a bunch of tricks, such as calling their unlock routines used in this allocator (
ClearBusy, RealClearBusy); they did unlock the GUI, but pressing the shutter fully (by mistake or for whatever reason) gave ERR80. Unlocking the GUI for a short time and re-locking it again did not re-activate the exposure controls.
- Low-level note: RealSetBusy/RealClearBusy only changes a GPIO; the MPU does react to this change.
- There is another way to lock the GUI - using PROP_ICU_UILOCK (our wrapper is gui_uilock). That one lets you lock only the shutter button (UILOCK_SHUTTER), but does not lock the exposure controls.
- Guess what: having both locks enabled (UILOCK_SHUTTER and Canon's SRM lock) works and DOES NOT LOCK THE EXPOSURE CONTROLS!!!
Therefore, one possibility would be to avoid the UILOCK_NONE state as long as the entire SRM memory is allocated.
However, this has another issue: half-shutter events are no longer present. Not sure how to solve it...
The MPU does send a message that tells the main CPU to show the BUSY screen. Maybe I should just interpret that as half-shutter press. I believe the message is some part of:
45B7B> **INT-36h*:000afe84:00:00: *** mpu_recv(26 24 0a 08 6f 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 01 01 00 00 00 00 00 00), from ff2e87f8
CDA4B> **INT-36h*:000afe84:00:00: *** mpu_recv(26 24 0a 08 6f 00 01 00 01 01 a0 10 00 68 01 01 50 20 30 01 01 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00), from ff2e87f8
Good luck
decoding that, though...