HDMI power and alternative remote inputs ( was Re: G7 X porting thread)

An unexpected bonus is that AF point zoom works (not sure if correctly centered, but it's there). If I remember right, no PowerShot ever supported this feature on displays other than the LCD. We can now see that there is no technical limitation behind that.

Interesting, elph180 crashes on half press if AF point zoom is enabled.
ASSERT!! LivePathParamCommon.c Line 320
Occured Time  2020:04:26 12:47:30
Task ID: 7077901
Task name: _imageSensor8
which is at least the same file as you got on ixus150

Could we get a compilation error when CAM_UNLOCK_ANALOG_AV_IN_REC is defined but ANALOG_AV_FLAG isn't?

It currently doesn't, but it seems like an explicit #error check in camera.h would be good.

Here's an updated patch, which reflects the propset changes from r5479, and includes sanity checks for the defines.

On elph180 (propset 10), the AF point zoom setting appears to be in propcase 639. Setting the propcase has no effect.

Earlier propsets (sx710 = PS9, g7x = PS7, elph130 = PS6) do not appear to store the setting in a propcase. I assume it's in a param and/or UI prop, but haven't identified it.

SX730 (PS12) does not have AF point zoom at all.

Not sure what the best way to deal with the crash is, but at worst it could just be a documented issue.

edit:
The elph180 crash with AF point zoom enabled appears to be the function equivalent to the one that crashes ixus150 (elph180 ffb6be1c = ixus150 ffb38668) though there are significant code differences.

Checked in initial implementation in trunk 5488. This is essentially the -work-3 patch above. Currently only enabled for elph180, feel free to enable or post patches for other tested cams.

I didn't fix the AF point zoom crash. This is a niche enough feature that I'm not too worried about it, though obviously fixing would be nice. I'll try to test the ixus150 fix at some point, if I can figure out the right values.

Checked in initial implementation in trunk 5488.

Thanks, enabled the feature on a3400. I might enable it on ixus150, but that hack is a bit more invasive than I like (no ports hook DebugAssert at the moment).

I didn't fix the AF point zoom crash. This is a niche enough feature that I'm not too worried about it, though obviously fixing would be nice. I'll try to test the ixus150 fix at some point, if I can figure out the right values.

Attached one of my (dirty) research patches - I logged the function's input struct members and compared the logs later. Cache hacks header attached here, plus this useful macro, also from ML:
#define B_INSTR(pc,dest) \
    ( 0xEA000000 \
    | ((( ((uint32_t)dest) - ((uint32_t)pc) - 8 ) >> 2) & 0x00FFFFFF) \
    )


I might enable it on ixus150, but that hack is a bit more invasive than I like (no ports hook DebugAssert at the moment).

Did you confirm if the crash on ixus150 happens without AF point zoom enabled?

Anyway, I'm not against using the assert hook like this, if it's tested and only affects that specific assert.

A bit off topic, but something I've wanted to add for a long time is hooks to optionally include CHDK information in the romlogs: platform, version, canon firmware version, module info.

Attached one of my (dirty) research patches - I logged the function's input struct members and compared the logs later.

Thanks.

Did you confirm if the crash on ixus150 happens without AF point zoom enabled?

Yes (just now).
The other bad news is that the current CAM_UNLOCK_ANALOG_AV_IN_REC code still does not cover this camera, despite the LivePathParamCommon hack.
Apparently, changing to video out causes a crash if the display is on:
ASSERT!! DispCon.c Line 1827
Task name: SpyTask
Assert comes from inside SetVideoOutType, checking a fw variable. I was using the short Lua script during my experiments.

A bit off topic, but something I've wanted to add for a long time is hooks to optionally include CHDK information in the romlogs: platform, version, canon firmware version, module info.

Do you mean adding more text before it is saved to ROM, or via the camera log? In my S1IS port, I saved stuff to card in my replacement assert handler.

Quote from: reyalp on 13 / May / 2020, 21:55:45

Did you confirm if the crash on ixus150 happens without AF point zoom enabled?

Yes (just now).
The other bad news is that the current CAM_UNLOCK_ANALOG_AV_IN_REC code still does not cover this camera, despite the LivePathParamCommon hack.
Apparently, changing to video out causes a crash if the display is on:
ASSERT!! DispCon.c Line 1827
Task name: SpyTask
Assert comes from inside SetVideoOutType, checking a fw variable. I was using the short Lua script during my experiments.

Could try adding
TurnOffDisplay / TurnOnDisplay around the SetVideoOutType calls.

Do you mean adding more text before it is saved to ROM, or via the camera log? In my S1IS port, I saved stuff to card in my replacement assert handler.

My preference would be in the romlog. Reasons:
- Writing to the card seems complicated, might fail if things go bad, or not be possible from the exception handlers
- Keep everything together, so users just have to post the one file

Don't really care if it's in the camera log or elsewhere.

OTOH, if writing to the card is usually reliable, we could send everything to the card, and avoid the current situation where romlogs leave traces of CHDK. Optionally writing a memory dump could also be quite useful.

Could try adding
TurnOffDisplay / TurnOnDisplay around the SetVideoOutType calls.

That worked, I guess it won't hurt the other cameras that don't need it.
Index: platform/generic/wrappers.c
===================================================================
--- platform/generic/wrappers.c (revision 5493)
+++ platform/generic/wrappers.c (working copy)
@@ -1996,7 +1996,9 @@
 #ifdef CAM_UNLOCK_ANALOG_AV_IN_REC
 void SetVideoOutType(int x) {
     extern void _SetVideoOutType(int);
+    _TurnOffDisplay();
     _SetVideoOutType(x);
+    _TurnOnDisplay();
 }
 int GetVideoOutType(void) {
     extern int _GetVideoOutType(void);

My preference would be in the romlog. Reasons:
- Writing to the card seems complicated, might fail if things go bad, or not be possible from the exception handlers
- Keep everything together, so users just have to post the one file

Don't really care if it's in the camera log or elsewhere.

OTOH, if writing to the card is usually reliable, we could send everything to the card, and avoid the current situation where romlogs leave traces of CHDK. Optionally writing a memory dump could also be quite useful.

The code could cover both kind (could be build time or runtime option).

Quote from: reyalp on 15 / May / 2020, 21:21:48

Could try adding
TurnOffDisplay / TurnOnDisplay around the SetVideoOutType calls.

That worked, I guess it won't hurt the other cameras that don't need it.

Added this in r5560. Confirmed harmless on elph180

In r5571 I updated elph130 and elph180 viewport functions to be mostly correct for video out, fixing various issues with PTP live view, zebra, histogram, edge overlay and MD.

This adds yet more complexity to the various size/offset functions, and the exact changes required will vary between ports (see https://chdk.setepontos.com/index.php?topic=13451.msg142423#msg142423). I don't intend to implement it for every cam, but I wanted to a have a couple examples. Support can be added to other cams on request if someone actually needs these these things.

One thing I noticed is that in playback mode when output is set to PAL, both cameras viewport height is 576, while in NTSC it's 480. This means things like zebra and edge overlay won't be correct, since vid_get_viewport_yscale is an integer. Given that it only affects playback, it's not something I'd put effort into fixing.

edit:
Also did g7x. Although the buffer (for non-HDMI) stays 720x480 (technically 736, but max 720 is used), the assumed aspect ratio of the display changes, which changes the offsets at different aspect ratios. So on the real LCD,  3:2 is 720x480 and 4:3 is 640x480, with TV out it's 720x426 and 720x480, respectively. Unlike the pre-digic 6 cams, NTSC and PAL appear to be the same in playback.