HDMI power and alternative remote inputs ( was Re: G7 X porting thread) - page 7 - General Discussion and Assistance - CHDK Forum
« previous next »
Pages: 1 2 3 4 5 6 [7] 8   Go Down

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

  • 79 Replies
  • 37019 Views
*

Offline reyalp

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

Offline srsa_4c

  • ******
  • 4451
Re: HDMI power and alternative remote inputs ( was Re: G7 X porting thread)
« Reply #61 on: 27 / January / 2020, 16:48:53 »
Quote from: reyalp on 26 / January / 2020, 17:06:10
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?
Logged
*

Offline reyalp

  • ******
  • 14118
Re: HDMI power and alternative remote inputs ( was Re: G7 X porting thread)
« Reply #62 on: 27 / January / 2020, 17:41:29 »
Quote from: srsa_4c on 27 / January / 2020, 16:48:53
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.
Logged
Don't forget what the H stands for.
*

Offline srsa_4c

  • ******
  • 4451
Re: HDMI power and alternative remote inputs ( was Re: G7 X porting thread)
« Reply #63 on: 27 / January / 2020, 19:32:59 »
Quote from: reyalp on 27 / January / 2020, 17:41:29
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 »
Logged
*

Offline reyalp

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

Offline reyalp

  • ******
  • 14118
Re: HDMI power and alternative remote inputs ( was Re: G7 X porting thread)
« Reply #65 on: 24 / April / 2020, 19:39:28 »
I checked in initial support for Lua force_analog_av in r5475
Code: [Select]
result=force_analog_av(state)
where state 0 = don't force, 1 = on, 2 = off
result true if implemented by port (ANALOG_AV_FLAG defined), otherwise false.

Tested on D10, SX160, ELPH130, ELPH180, SX710, G7X. A few other cameras have the bit defined, but I don't know if it's verified. It is only meaningful on cameras with analog NTSC/PAL output, and not (some of?) the early ones with a A/V plug separate from the USB port.

Known issues:
On elph130 and sx160, sending force_analog_av(1) while chdkptp live view is running results in the PTP connection stalling. It's possible to reset the connection and reconnect. I suspect something in the switching process blocks PTP in some way. Turning off the live avoid this. This only appears to affect the first time analog AV is enabled.

On elph130 and sx160, switching to record after using force_analog_av(1) fails. The lens extends, but the camera isn't in rec mode, and shuts down a few seconds later with an assert in LensController.c,  LensControll0 task triggered by WaitForAnyEventFlagStrictly.
This can be avoid by switching to rec before enabling analog AV. Subsequent rec/play switches seem OK.
I don't have a good idea what the mechanism behind this is.

On SX710, chdkptp live view hits a lua error "width  > buffer_width" when turning analog AV off with live view running. This has to do with the buffer dimensions being updated in update_screen_dimensions (called periodically from mode_get) while the width comes directly from _GetVRAMHPixelsSize, called when the frame is requested. There error is harmless, aside from popping up a dialog. It might make sense to call update_screen_dimensions in live_view_get_data

Viewport dimensions are incorrect on many cameras in some modes (https://chdk.setepontos.com/index.php?topic=13451.msg142423#msg142423)
This applies to using the real AV connector too. It could be fixed on a per port basis.
Logged
Don't forget what the H stands for.
*

Offline waterwingz

  • ******
  • 12140
    • Waterwingz
Re: HDMI power and alternative remote inputs ( was Re: G7 X porting thread)
« Reply #66 on: 24 / April / 2020, 21:42:53 »
I update the wikia this weekend if nobody beats me to it.
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline reyalp

  • ******
  • 14118
Re: HDMI power and alternative remote inputs ( was Re: G7 X porting thread)
« Reply #67 on: 25 / April / 2020, 18:55:44 »
Here's an initial patch to enable video out in rec mode for cams that don't support it in stock firmware. It appears to work on elph180.

There is one menu option under video:
"Enable video out in rec"
If checked, when the camera is in rec mode, spytask periodically checks if the analog AV bit is set, and if so, sets video out to 1. If the option is cleared or the AV bit goes away, it sets video out to 0.
The physw_status bit check is after overrides, so it can be combined with force_analog_av. Switching to and from playback seems to work as expected, both using a real video out cable and while connected to PTP.

There are still some loose ends:
* Currently doesn't allow control of NTSC vs PAL. It should be possible to use the Canon menu setting, which is exposed as a bit in the language propcase.

* Elph180 doesn't seem to need workarounds like ixus150. Neither the assert hook, nor turning the display off and on like srcs_4c's example script (https://chdk.setepontos.com/index.php?topic=13451.msg142512#msg142512). If the sleep logic is needed, it would be more complicated.

* When the video out status changes in rec, the bitmap is clear until something forces it to refresh, entering / leaving alt mode or the canon menu. It might be worth forcing a redraw after draw_suspend expires.

* It doesn't know anything about HDMI, but I don't think this should matter for current cams, since it only takes effect in rec.

* I used GetVideoOutType (added to dryos sig finder) to get the current status, while digic 6 ports uses a variable directly for update_screen_dimensions. Not wrong, but inconsistent.
Logged
Don't forget what the H stands for.
*

Offline reyalp

  • ******
  • 14118
Re: HDMI power and alternative remote inputs ( was Re: G7 X porting thread)
« Reply #68 on: 25 / April / 2020, 22:28:24 »
Updated patch that handles video out type based on menu NTSC/PAL setting.

There is some weirdness on elph180: When PAL is set in the canon menu, live view is garbled after video out is turned on in rec (either by switching to rec, or connecting the cable). The top ~1/4 of the live view appears on the bottom of the video output, with the rest above it. This is NOT seen in PTP live view, only the video capture device.
Half pressing, or going into the main canon menu, or letting the camera go into power save corrects it.

I can't directly determine if the camera is actually outputting NTSC or PAL. I use a cheapo USB capture dongle (https://www.newegg.com/p/207-000K-00032) for testing.

On elph130 (which natively supports video out in rec) switching from between NTSC and PAL in the Canon menu causes a moment of distortion and the image changes slightly.

On elph180, the same happens in playback, but not when the camera is in rec.
Logged
Don't forget what the H stands for.
*

Offline srsa_4c

  • ******
  • 4451
Re: HDMI power and alternative remote inputs ( was Re: G7 X porting thread)
« Reply #69 on: 26 / April / 2020, 16:48:15 »
Quote from: reyalp on 25 / April / 2020, 22:28:24
Updated patch that handles video out type based on menu NTSC/PAL setting.
Tested on a3400, video out in rec and PAL/NTSC switch works (one difference to native is that the video standard can only change upon entering rec mode).
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.
Could we get a compilation error when CAM_UNLOCK_ANALOG_AV_IN_REC is defined but ANALOG_AV_FLAG isn't?
Logged
Pages: 1 2 3 4 5 6 [7] 8   Go Up
« previous next »
 
SimplePortal 2.3.6 © 2008-2014, SimplePortal