ASSERT!! LensController.c Line 1106
I'm not sure what the script interface should be. It will be separate from the analog AV bit override. It should only be needed on cameras that don't normally allow video out in rec, but allowing it on others shouldn't hurt. It would provide an alternate way to use video out and and the analog AV remote at the same time.
I meant the Lua analog AV bit override. It's potentially useful, but with so many issues in just the cameras I own, it could be a lot of effort to make it work well and dealing with all the permutations of video out + PTP live view (the real use cases for PTP live view and video out seem limited, but it's useful for testing).
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.
I'd vote for a menu entry - it would allow using existing scripts. Plus, I'd expect that each (enabled) port would have to be tested for frame buffer issues and stability.
I noticed that forced AV out combined with set_lcd_display(0) results in a slightly lower power consumption than just set_lcd_display(0).
I haven't had luck reproducing this on the one cam I tried (a3400). Is this difficult to trigger?
What are you thinking the menu option would be: Something like "Force video out in rec" where CHDK detects when it's in rec, and sets the video out type? Or should it allow using the detect bit, so it acts like the canon firmware?
QuoteI noticed that forced AV out combined with set_lcd_display(0) results in a slightly lower power consumption than just set_lcd_display(0).That's interesting.
Did you disable the workaround? (draw_restore_suspend_tick = get_tick_count() + 1000; in core/kbd_common.c?)
set_lcd_display(0) sleep(1000) call_func_ptr(0xFFB553E8,2) set_lcd_display(1)