HDMI power and alternative remote inputs ( was Re: G7 X porting thread) - page 8 - General Discussion and Assistance - CHDK Forum
supplierdeeply

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

  • 77 Replies
  • 13271 Views
*

Online reyalp

  • ******
  • 12586
Re: HDMI power and alternative remote inputs ( was Re: G7 X porting thread)
« Reply #70 on: 26 / April / 2020, 17:04:03 »
Advertisements
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.
Code: [Select]
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
Quote
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.
Don't forget what the H stands for.

*

Online reyalp

  • ******
  • 12586
Re: HDMI power and alternative remote inputs ( was Re: G7 X porting thread)
« Reply #71 on: 26 / April / 2020, 20:37:48 »
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.
« Last Edit: 03 / May / 2020, 02:19:18 by reyalp »
Don't forget what the H stands for.

*

Online reyalp

  • ******
  • 12586
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.
Don't forget what the H stands for.

*

Offline srsa_4c

  • ******
  • 4228
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).

Quote
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:
Code: [Select]
#define B_INSTR(pc,dest) \
    ( 0xEA000000 \
    | ((( ((uint32_t)dest) - ((uint32_t)pc) - 8 ) >> 2) & 0x00FFFFFF) \
    )


*

Online reyalp

  • ******
  • 12586
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.

Quote
Attached one of my (dirty) research patches - I logged the function's input struct members and compared the logs later.
Thanks.
Don't forget what the H stands for.

*

Offline srsa_4c

  • ******
  • 4228
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.

Quote
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.

*

Online reyalp

  • ******
  • 12586
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.

Quote
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.
Don't forget what the H stands for.

*

Offline srsa_4c

  • ******
  • 4228
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.
Code: [Select]
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);
Quote
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).