Spoofing analog A/V detect:
It might be desirable to provide something like usb_force_active for the A/V detect. This should allow A/V out while also using the detect signal as a remote trigger, which would potentially be useful for FPV applications. Using the USB remote for triggering would also work in this situation, but a full splitter cable is harder to make.
I finally got around to revisiting this. Messy preliminary patch attached.
It implements a lua function
force_analog_av(n)
0 means leave the AV bit alone
1 force AV present
2 force not present
This is different from force_usb_present, where 1 / true = force USB present, 0/ false = leave it alone.
This is enabled for all cams with ANALOG_AV_FLAG, regardless of whether it's enabled as a remote input.
Initially, elph130, g7x and (sometimes?) sx710 crashed when I tried to use force present. One further investigation, I found elph130 with CHDK running would also crash when using an actual Canon AV connector. It works fine without CHDK. The other cameras seemed to only crash when overriding the bit from CHDK using chdkptp. I did not try standalone script, but I think this may be due to the script making it more likely that CHDK tries to update the screen during the change.
There appears to be two issues:
Redrawing (vid_bitmap_refresh) while the display type change is in progress can crash. Often an assert in MakeOsdVram.c from spytask. This applies to both digic 6 and earlier.
One elph130, the palette pointer from vid_get_bitmap_active_palette can be NULL (which ends up being 4 because of the p+1) after the first time the video cable is connected. This causes CHDK palette to stomp all over ITCM. I did not see this on other pre-digic 6 cameras (d10, sx160, elph180)
For the first issue, my workaround is to ignore draw_restore for 1 second after the AV bit changes. This is not a complete solution, because vid_bitmap_refresh is called directly in some cases, but it's in platform code and I didn't feel like changing everywhere. I tried shorter times, 500ms did not seem to be enough.
For the second issue, I made elph130 platform load_chdk_palette bail out if the palette pointer was NULL. I think all the other usage is read, which should be fine on these cameras.
I would be tempted to drop the whole thing, but crashing on real analog AV would be nice to fix.
Being able to force AV present allows using PTP live view while it's enabled, without a physical splitter. Some observations:
The placement of the Canon UI changes, to put stuff further from the edges of the screen, presumably to account for the vagaries analog displays
Viewport resolution changes in ways that aren't all accounted for in the current code:
G7X rec viewport height changes to 720x426. Playback has black bars at the top and bottom.
SX710 live view is 720x480 in both play and rec (displays correctly)
Pre-digic 6 cameras seem to use 480 height in playback, 240 in rec. This affects different cameras differently, since the default resolutions may be 240 or 480:
D10 is 704x240 in rec, 720x480? in play (vs 240 normal)
sx160 is 720x240 in rec (same as normal), 720x480? (vs 240 normal)
elph130 is 720x240 in rec (half normal 480), 720x480 in play (same as normal)
elph180 is 720x480? in play, (vs 240 normal). It doesn't support video out in REC, switching causes it to switch back to camera LCD. SetVideoOutType(1) does enable AV out in rec, vp resolution is 720x240 as normal. Shooting and video recording works (previous thread about enabling video out on cams without Canon FW support
https://chdk.setepontos.com/index.php?topic=11439.0) Note I called the underlying function (ffb93458) directly, rather than registering event procs.
The cameras that are normally 240 but 480? above in playback get cut off in PTP live view, since the viewport height is hard coded (? because I haven't check if they are exactly 480). elph130 in rec gets a squished half-height display, since physcal_height is hard coded. These would also affect zebra, histogram etc in AV out.
It would be nice to make load_chdk_palette null safe on the the platforms that have it. It's pretty much copy / paste, so finding a way to make it generic might be worthwhile.