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

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

  • 79 Replies
  • 14306 Views
Re: HDMI power and alternative remote inputs ( was Re: G7 X porting thread)
« Reply #50 on: 11 / February / 2019, 15:09:41 »
Advertisements
I am a bit confused. I've measured all the wires of the cut cable. No wire is connected to pin 14 (+ 5V). Ground and hot plug were unique. The red wire that I had previously identified as + 5V was actually DDC clock.
I have now ordered a new adapter and will repeat the measurements…
M100 100a, M3 101a, 2*G1x (101a,100e), S110 (103a), SX50 (100c), SX230 (101a), S45,
Flickr https://www.flickr.com/photos/136329431@N06/albums
YouTube https://www.youtube.com/channel/UCrTH0tHy9OYTVDzWIvXEMlw/videos?shelf_id=0&view=0&sort=dd

Re: HDMI power and alternative remote inputs ( was Re: G7 X porting thread)
« Reply #51 on: 22 / February / 2019, 13:25:14 »
Minimal HDMI remote for testing ;)
1 micro or mini HDMI to standard HDMI adapter
1 HDMI standard to DVI female adapter
1 paper clip
I used a HDMI C plug that has a small PCB (see picture) to make soldering easier.

I now have both adapters, but had no success.
With both adapters I get identical results.
All my cameras (G1x, S110, SX230, M3) have 5 volts on the HDMI port in playback and recording mode.
With the G1X and S110 I've tried HDMI ChangePowerState and EnableHDMIPower /DisableHDMIPower in both playback and recording modes, in no case has the output changed.
Would be interesting if someone could confirm ....

To control an external device, I now probably only the focus lamp. However, it will be difficult to attach a light sensor there.

Would it really be possible for cameras with a hot shoe to switch the flash contact?
M100 100a, M3 101a, 2*G1x (101a,100e), S110 (103a), SX50 (100c), SX230 (101a), S45,
Flickr https://www.flickr.com/photos/136329431@N06/albums
YouTube https://www.youtube.com/channel/UCrTH0tHy9OYTVDzWIvXEMlw/videos?shelf_id=0&view=0&sort=dd

*

Offline srsa_4c

  • ******
  • 4262
Re: HDMI power and alternative remote inputs ( was Re: G7 X porting thread)
« Reply #52 on: 22 / February / 2019, 17:19:22 »
All my cameras (G1x, S110, SX230, M3) have 5 volts on the HDMI port in playback and recording mode.
With the G1X and S110 I've tried HDMI ChangePowerState and EnableHDMIPower /DisableHDMIPower in both playback and recording modes, in no case has the output changed.
Would be interesting if someone could confirm ....
Tried 3 of my cameras - m10, sx280, ixus115. Only the sx280 reacted to EnableHDMIPower and DisableHDMIPower, and this was also the only cam that switched the 5V off in rec mode.
Quote
Would it really be possible for cameras with a hot shoe to switch the flash contact?
Probably, but I don't know how often the cam would allow you to "flash". HDMI also has alternative communication channel(s) DDC and CEC, but they are used by firmware tasks for obvious reasons. As far as I know, there have been no experiments with those.

Re: HDMI power and alternative remote inputs ( was Re: G7 X porting thread)
« Reply #53 on: 23 / February / 2019, 02:06:46 »
Tried 3 of my cameras - m10, sx280, ixus115. Only the sx280 reacted to EnableHDMIPower and DisableHDMIPower, and this was also the only cam that switched the 5V off in rec mode.

Thank you for the confirmation. Then I do not need to search for mistakes from my side anymore ...
M100 100a, M3 101a, 2*G1x (101a,100e), S110 (103a), SX50 (100c), SX230 (101a), S45,
Flickr https://www.flickr.com/photos/136329431@N06/albums
YouTube https://www.youtube.com/channel/UCrTH0tHy9OYTVDzWIvXEMlw/videos?shelf_id=0&view=0&sort=dd


Re: HDMI power and alternative remote inputs ( was Re: G7 X porting thread)
« Reply #54 on: 28 / February / 2019, 12:35:25 »
but I don't know how often the cam would allow you to "flash".
It is not necessary to control the flash contact.
The time the contact is closed is pretty much the exposure time (measured on G1x an M3 ). The value does not go below 40ms.
M100 100a, M3 101a, 2*G1x (101a,100e), S110 (103a), SX50 (100c), SX230 (101a), S45,
Flickr https://www.flickr.com/photos/136329431@N06/albums
YouTube https://www.youtube.com/channel/UCrTH0tHy9OYTVDzWIvXEMlw/videos?shelf_id=0&view=0&sort=dd

Re: HDMI power and alternative remote inputs ( was Re: G7 X porting thread)
« Reply #55 on: 01 / March / 2019, 04:31:31 »
What can the 5V voltage drive?

Definitely enough to run an ARDUINO Nano with OLED display ...  :)


M100 100a, M3 101a, 2*G1x (101a,100e), S110 (103a), SX50 (100c), SX230 (101a), S45,
Flickr https://www.flickr.com/photos/136329431@N06/albums
YouTube https://www.youtube.com/channel/UCrTH0tHy9OYTVDzWIvXEMlw/videos?shelf_id=0&view=0&sort=dd

*

Offline reyalp

  • ******
  • 12690
Re: HDMI power and alternative remote inputs ( was Re: G7 X porting thread)
« Reply #56 on: 01 / March / 2019, 13:15:17 »

Definitely enough to run an ARDUINO Nano with OLED display ...  :)
According to the HDMI 1.3 spec
Quote
The HDMI connector provides a pin allowing the Source to supply +5.0 Volts to the cable and Sink.
All HDMI Sources shall assert the +5V Power signal whenever the Source is using the DDC or TMDS signals. The voltage driven by the Source shall be within the limits specified for TP1 voltage in Table 4-22. An HDMI Source shall have +5V Power signal over-current protection of no more than 0.5A.
All HDMI Sources shall be able to supply a minimum of 55 mA to the +5V Power pin.
A Sink shall not draw more than 50 mA of current from the +5V Power pin. When the Sink is powered on, it can draw no more than 10mA of current from the +5V Power signal. A Sink shall assume that any voltage within the range specified for TP2 voltage in Table 4-22 indicates that a Source is connected and applying power to the +5V Power signal.
A Cable Assembly shall be able to supply a minimum of 50mA to the +5V Power pin to a Sink, even when connected to a Source supplying no more than 55mA.
The return for the +5V Power signal is DDC/CEC Ground signal.
Don't forget what the H stands for.

*

Offline reyalp

  • ******
  • 12690
Re: HDMI power and alternative remote inputs ( was Re: G7 X porting thread)
« Reply #57 on: 20 / January / 2020, 23:23:36 »
Spoofing analog A/V detect:
It might be desirable to provide something like usb_force_active for the A/V detect. This should allow A/V out while also using the detect signal as a remote trigger, which would potentially be useful for FPV applications. Using the USB remote for triggering would also work in this situation, but a full splitter cable is harder to make.
I finally got around to revisiting this. Messy preliminary patch attached.
It implements a lua function
force_analog_av(n)
0 means leave the AV bit alone
1 force AV present
2 force not present
This is different from force_usb_present, where 1 / true = force USB present, 0/ false = leave it alone.

This is enabled for all cams with ANALOG_AV_FLAG, regardless of whether it's enabled as a remote input.

Initially, elph130, g7x  and (sometimes?) sx710 crashed when I tried to use force present. One further investigation, I found elph130 with CHDK running would also crash when using an actual Canon AV connector. It works fine without CHDK. The other cameras seemed to only crash when overriding the bit from CHDK using chdkptp. I did not try standalone script, but I think this may be due to the script making it more likely that CHDK tries to update the screen during the change.

There appears to be two issues:
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.

One elph130, the palette pointer from vid_get_bitmap_active_palette can be NULL  (which ends up being 4 because of the p+1) after the first time the video cable is connected. This causes CHDK palette to stomp all over ITCM. I did not see this on other pre-digic 6 cameras (d10, sx160, elph180)

For the first issue, my workaround is to ignore draw_restore for 1 second after the AV bit changes. This is not a complete solution, because vid_bitmap_refresh is called directly in some cases, but it's in platform code and I didn't feel like changing everywhere. I tried shorter times, 500ms did not seem to be enough.

For the second issue, I made elph130 platform load_chdk_palette bail out if the palette pointer was NULL. I think all the other usage is read, which should be fine on these cameras.

I would be tempted to drop the whole thing, but crashing on real analog AV would be nice to fix.

Being able to force AV present allows using PTP live view while it's enabled, without a physical splitter. Some observations:
The placement of the Canon UI changes, to put stuff further from the edges of the screen, presumably to account for the vagaries analog displays

Viewport resolution changes in ways that aren't all accounted for in the current code:
G7X rec viewport height changes to 720x426. Playback has black bars at the top and bottom.
SX710 live view is 720x480 in both play and rec (displays correctly)
Pre-digic 6 cameras seem to use 480 height in playback, 240 in rec. This affects different cameras differently, since the default resolutions may be 240 or 480:
D10 is 704x240 in rec, 720x480? in play (vs 240 normal)
sx160 is 720x240 in rec (same as normal), 720x480? (vs 240 normal)
elph130 is 720x240 in rec (half normal 480), 720x480 in play (same as normal)
elph180 is 720x480? in play, (vs 240 normal). It doesn't support video out in REC, switching causes it to switch back to camera LCD. SetVideoOutType(1) does enable AV out in rec, vp resolution is 720x240 as normal. Shooting and video recording works (previous thread about enabling video out on cams without Canon FW support https://chdk.setepontos.com/index.php?topic=11439.0) Note I called the underlying function (ffb93458) directly, rather than registering event procs.

The cameras that are normally 240 but  480? above in playback get cut off in PTP live view, since the viewport height is hard coded (? because I haven't check if they are exactly 480). elph130 in rec gets a squished half-height display, since physcal_height is hard coded. These would also affect zebra, histogram etc in AV out.

It would be nice to make load_chdk_palette null safe on the the platforms that have it. It's pretty much copy / paste, so finding a way to make it generic might be worthwhile.
« Last Edit: 25 / January / 2020, 22:16:41 by reyalp »
Don't forget what the H stands for.


*

Offline srsa_4c

  • ******
  • 4262
Re: HDMI power and alternative remote inputs ( was Re: G7 X porting thread)
« Reply #58 on: 26 / January / 2020, 14:07:20 »
elph180 is 720x480? in play, (vs 240 normal). It doesn't support video out in REC, switching causes it to switch back to camera LCD. SetVideoOutType(1) does enable AV out in rec, vp resolution is 720x240 as normal. Shooting and video recording works (previous thread about enabling video out on cams without Canon FW support https://chdk.setepontos.com/index.php?topic=11439.0) Note I called the underlying function (ffb93458) directly, rather than registering event procs.
Well, that's a nice find. I tried it on the cam mentioned in the other thread (a3400) and indeed, it works. Apparently FA.Create is causing too many side effects.
This should perhaps be turned into a feature.
Quote
The cameras that are normally 240 but  480? above in playback get cut off in PTP live view, since the viewport height is hard coded (? because I haven't check if they are exactly 480). elph130 in rec gets a squished half-height display, since physcal_height is hard coded. These would also affect zebra, histogram etc in AV out.
That would be something to fix in the affected ports - but I'd guess that will only happen when someone encounters these issues and finds them annoying (for their use).
Quote
It would be nice to make load_chdk_palette null safe on the the platforms that have it. It's pretty much copy / paste, so finding a way to make it generic might be worthwhile.
One issue with that (commonly used) code is that it requires 13 or more consecutive unused palette entries which is not always available. But, any affected port could then have its own, custom routine. I don't remember actually making such a modified version, only considering it.
Quote
I would be tempted to drop the whole thing, but crashing on real analog AV would be nice to fix.
Which whole thing? The Lua function seems useful, the crashing issues are real.

*

Offline reyalp

  • ******
  • 12690
Re: HDMI power and alternative remote inputs ( was Re: G7 X porting thread)
« Reply #59 on: 26 / January / 2020, 17:06:10 »
Well, that's a nice find. I tried it on the cam mentioned in the other thread (a3400) and indeed, it works. Apparently FA.Create is causing too many side effects.
This should perhaps be turned into a feature.
Yeah. I've noticed before that some of those registration functions lead to instability. It should be easy to add function to the sig finders, and I agree it's worthwhile.

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.

Quote
Quote
It would be nice to make load_chdk_palette null safe on the the platforms that have it. It's pretty much copy / paste, so finding a way to make it generic might be worthwhile.
One issue with that (commonly used) code is that it requires 13 or more consecutive unused palette entries which is not always available. But, any affected port could then have its own, custom routine. I don't remember actually making such a modified version, only considering it.
Yeah. The palette type check also varies.

Quote
Quote
I would be tempted to drop the whole thing, but crashing on real analog AV would be nice to fix.
Which whole thing? The Lua function seems useful, the crashing issues are real.
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). But I'd definitely like to fix the crashing when the real video out is used. Mostly it's just something I was hoping would be simple turned into a big can of worms  :haha

I'm not really satisfied with the draw_restore_suspend_tick workaround. It would be much nicer to find some firmware function or variable to know if it's safe.
Don't forget what the H stands for.