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

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

  • 64 Replies
  • 11772 Views
*

Offline reyalp

  • ******
  • 12433
Re: HDMI power and alternative remote inputs ( was Re: G7 X porting thread)
« Reply #60 on: 27 / January / 2020, 01:35:50 »
Advertisements
More weirdness:
On SX160 and ELPH130, forcing the analog AV bit and then switching to rec using the chdkptp 'rec' command extends the lens, but fails to switch to rec (get_mode() returns false). After a ~30 seconds, the camera crashes with an assert like
Code: [Select]
ASSERT!! LensController.c Line 1106
(sx160 line number)

which appears to be a WaitForAnyEventFlagStrictly timing out. This does not appear to happen without PTP. Forcing the AV bit after switching also seems fine, even switching to play, waiting for the lens to retract and going back to rec. :blink:

Weirdly, on SX160, using the GUI rec button is fine. The only significant difference is the gui code does a require'capmode' between the switch and waiting for the mode change to finish. Using a simple =switch_mode_usb(1) is also fine. On ELPH130, all of these seem to hit the assert, although I *think* I tested it successfully before.

G7X, SX710 and D10 do not appear to suffer this problem.

Another thing I noticed on SX160 is that the CHDK palette is wrong when using video out. This is only visible using the real video output, both live view and  load_chdk_palette use the same incorrect palette. Switching the lib.c code to use palette_buffer_ptr rather than palette_buffer resolves this.
« Last Edit: 23 / February / 2020, 02:48:55 by reyalp »
Don't forget what the H stands for.

*

Offline srsa_4c

  • ******
  • 4144
Re: HDMI power and alternative remote inputs ( was Re: G7 X porting thread)
« Reply #61 on: 27 / January / 2020, 16:48:53 »
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'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.
Quote
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).
I'm for adding it. It's a lot more convenient than messing with the AV cable - not to mention what the manual says about connecting that cable. It could be documented like that (does not do anything on most cameras, can cause crashes on others, etc).
When trying the new function on a3400 in a PTP session, 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).
Quote
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 haven't had luck reproducing this on the one cam I tried (a3400). Is this difficult to trigger?

*

Offline reyalp

  • ******
  • 12433
Re: HDMI power and alternative remote inputs ( was Re: G7 X porting thread)
« Reply #62 on: 27 / January / 2020, 17:41:29 »
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.
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?

Quote
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).
That's interesting.

Quote
I haven't had luck reproducing this on the one cam I tried (a3400). Is this difficult to trigger?
Did you disable the workaround? (draw_restore_suspend_tick = get_tick_count() + 1000; in core/kbd_common.c?)

I think it was reliably reproducible on my cams when calling force_analog_av(1) over PTP. Definitely on ixus130 and g7x. It may depend on the implementation of vid_bitmap_refresh. CHDK settings may also influence whether it gets hit, I typically have CHDK OSD enabled in playback with battery and clock displays enabled.

ixus130 was the only camera I saw reliably crash on connecting a real video out cable. It wouldn't boot with the cable connected. I'm pretty sure it still crashed after fixing the palette issue, but I should double check.
Don't forget what the H stands for.

*

Offline srsa_4c

  • ******
  • 4144
Re: HDMI power and alternative remote inputs ( was Re: G7 X porting thread)
« Reply #63 on: 27 / January / 2020, 19:32:59 »
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?
The latter, user could force it using force_analog_av() when desired.
Quote
Quote
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).
That's interesting.
I just watched the battery voltage displayed on CHDK overlay, but did not measure anything.
Quote
Did you disable the workaround? (draw_restore_suspend_tick = get_tick_count() + 1000; in core/kbd_common.c?)
I commented out the added return in draw_restore(). Protection for NULL palette was added to load_chdk_palette().

edit:
Before I/we get too excited, the ixus150 doesn't like the video out @ rec workaround and crashes on halfshoot / wakeup.

edit2:
The ixus150 crash happens due to sub_FFB38668 (LivePathParamCommon.c) returning 'invalid' when tv-out is forced in rec mode. Due to the fact that this routine has no external dependencies, it's likely possible to hook DebugAssert and correct the return value.
I made some logs (using cache hacks) and it turned out that the word at byte offset +8 of the input struct becomes 2 when tv-out is active (it's normally 0). Forcing that word to 0 appears to fix everything (live view, shooting, video recording). Finding out where that 2 comes from would probably be useful, but it's not easy to trace it through huge structs.

edit3:
Attaching the ixus150 workaround for the LivePathParamCommon.c crash when using forced tv-out. This patch is a standalone one. Activating tv-out on this model can be done with this Lua script (PAL version, use 1 in below call_func_ptr call for NTSC):
Code: [Select]
set_lcd_display(0) sleep(1000) call_func_ptr(0xFFB553E8,2) set_lcd_display(1)
« Last Edit: 08 / February / 2020, 19:31:02 by srsa_4c »


*

Offline reyalp

  • ******
  • 12433
Re: HDMI power and alternative remote inputs ( was Re: G7 X porting thread)
« Reply #64 on: 02 / March / 2020, 01:36:27 »
I checked in the MakeOsdVram.c crash workaround for analog AV, along with palette related fixes for sx160 and elph130 in 5432. I still intend to work on the analog AV control features, just figured this was worth checking in since it uses the same code as the HDMI fix.

FWIW, elph180 does not seem to need the workaround that ixus150 does when forcing video out in rec. Half press wakes up from display/sensor off power saving without issue.
Don't forget what the H stands for.