Display (bitmap overlay)

reyalp

waterwingz
Any thoughts on why CHDK screws up the HDMI output on the current trunk release? I don't recall anything in the porting process specific to HDMI output.

HDMI needs the CAM_SUPPORT_BITMAP_RES_CHANGE found in many D6 ports.

FWIW, I believe the SX710 handles all the available output modes correctly, both in ximr tree and the trunk, and being a 640x480 cam, should be similar to G16 in terms of viewport/bitmap dimensions.

philmoz
I will need to create a version using the old display code that dumps the ximr_context structure data to a file.

FWIW, my take on this is in https://chdk.setepontos.com/d/12788/349

philmoz

Here's a G16 XIMR build with the SX710HS HDMI values - on the chance that these are the same for the G16.
Thanks reyalp.

g16-101c-1.6.0-6032-full.zip

753.09KB

waterwingz

philmoz
Here's a G16 XIMR build with the SX710HS HDMI values - on the chance that these are the same for the G16.
Thanks reyalp.

Bad news, good news.

The bad news is that your new version still crashes right away if HDMI is connected.

The good news is that I basically C&P'd the SX710HS code from its lib .c to the G16 and rebuilt the trunk. Now HDMI is stable for the G16, which suggests at least some of the SX710HS values work for the G16.

I'll post a patch file momentarily in the usual place.

philmoz

waterwingz
The bad news is that your new version still crashes right away if HDMI is connected.

Here's a new test build - this is using the old display code and includes reyalps code for recording the ximr_context data.
When you have a chance can you do the following with this build.
- start in play mode on the lcd
- open the Canon menu a few times to fill the buffers to be saved
- connect chdkptp console to the camera (don't restart the camera)
- run this command in chdkptp
rmem 0x00325f3c 6272 -f=ximr_lcd_play.bin
- repeat all the above in REC mode; but change the filename in the chdkptp rmem command
- finally repeat the above connected to HDMI (both play and REC modes, changing filename each time).

If you can then upload the 4 .bin dump files please.

Edit: incorrect build removed.

waterwingz

philmoz
Here's a new test build - this is using the old display code and includes reyalps code for recording the ximr_context data.
When you have a chance can you do the following with this build.
- start in play mode on the lcd
- open the Canon menu a few times to fill the buffers to be saved
- connect chdkptp console to the camera (don't restart the camera)
- run this command in chdkptp
rmem 0x00325f3c 6272 -f=ximr_lcd_play.bin
- repeat all the above in REC mode; but change the filename in the chdkptp rmem command
- finally repeat the above connected to HDMI (both play and REC modes, changing filename each time).
If you can then upload the 4 .bin dump files please.

I was pretty careful to follow your instructions step-by-step but the resulting files all see to be filled with NULs? (I ran the chdkptp gui and used the console from there if that matters). Files attached.

EDIT : my version of chdkptp is from April 2017 if that matters

ximr.zip

874b

philmoz

waterwingz
I was pretty careful to follow your instructions step-by-step but the resulting files all see to be filled with NULs?

Sorry about that - my mistake. Here's a new version that should work (fingers crossed).

Edit: the chkdkptp rmem command should now be:
rmem 0x00326d84 6272 -f=dump_filename.bin

g16-101c-1.6.0-6035-full.zip

752.36KB

waterwingz

philmoz
Sorry about that - my mistake. Here's a new version that should work (fingers crossed).
Edit: the chkdkptp rmem command should now be:
rmem 0x00326d84 6272 -f=dump_filename.bin

No problem - less than two minutes to rerun the tests as I left everything setup.

New files attached - non-zero contents so hoplefully that's more useful. I'll leave everything setup just in case.

ximr_2.zip

2.06KB

reyalp

Here are the dumps decoded with a slightly updated ximrdesc.lua (chdkptp r1081). Since dryos52 seems have a different layout, you can use something like

!xd=require'extras/ximrdesc'
!xd.export('ximr_hdmi_rec.bin',nil,{dry_ver=52})

I haven't looked at this stuff for a while, but the fields generally seem reasonable.

Also..
G16 supports HDMI out in rec, or does the HDMI turn off when you switch to rec? I thought this was only supported on the EOS M and newer cams like G7 X II and G5 X.

waterwingz-g16-20211231-ximr_2-decoded.zip

55.53KB

waterwingz

Reloaded the second version of @philmoz 's ximr G16 code (g16-101c-1.6.0-6032-full.zip). Crashes regardless of whether the HDMI cable is plugged in before boot or after boot. I've attached ROMLOG's from both cases.

reyalp
G16 supports HDMI out in rec, or does the HDMI turn off when you switch to rec? I thought this was only supported on the EOS M and newer cams like G7 X II and G5 X.

G16 does not actually support HDMI out in rec. The files I posted were create using chdkptp while the camera was in REC mode with the HDMI cable connected (even though no HDMI output was active).

ROMLOG - HDMI before boot.LOG

3.85KB

ROMLOG - HDMI after boot.LOG

4KB

philmoz

waterwingz
Reloaded the second version of @philmoz 's ximr G16 code (g16-101c-1.6.0-6032-full.zip). Crashes regardless of whether the HDMI cable is plugged in before boot or after boot. I've attached ROMLOG's from both cases.

Thanks for that. It's the same crash as earlier and it seems to be happening when CHDK tries to refresh the display before the display type has been set up properly.

Here is a new ximr version that does not try and refresh the display if the 'displaytype' variable is not valid.

Edit: removed non-working attachment.

waterwingz

philmoz
Here is a new ximr version that does not try and refresh the display if the 'displaytype' variable is not valid.

No joy - crashes the same way, again regardless of when the HDMI cable is plugged in. ROMLOG attached although it seems to be the same as previous logs.

ROMLOG.LOG

3.95KB

philmoz

waterwingz
No joy - crashes the same way, again regardless of when the HDMI cable is plugged in. ROMLOG attached although it seems to be the same as previous logs.

Damn - yes it's the same crash. Guess it's more complicated than I thought.

Another test version - this time I've duplicated the 'transfer_src_overlay' code into CHDK and replaced the ASSERT with a return.

Make sure this works on the LCD before trying HDMI in case I messed up something else.

g16-101c-1.6.0-6037-full.zip

753.88KB

waterwingz

philmoz
Another test version - this time I've duplicated the 'transfer_src_overlay' code into CHDK and replaced the ASSERT with a return.

It works!! Tested multiple boots and inserting the HDMI connector both before and after boot and playback display on my HDMI monitor works correctly every time.

Very nice. 😀

philmoz

waterwingz
It works!! Tested multiple boots and inserting the HDMI connector both before and after boot and playback display on my HDMI monitor works correctly every time.

Finally - thanks for testing 😀
One more test version when you have time - this one just simplifies the added code by jumping back to the firmware where possible.

g16-101c-1.6.0-6037-full.zip

753.51KB

waterwingz

philmoz
[One more test version when you have time - this one just simplifies the added code by jumping back to the firmware where possible.

Works fine as well. 🧑‍🎄

philmoz

@waterwingz - when you have a chance can you please test this G16 version for the HDMI crash issue.

I've changed this based on what srsa_4c did with the SX270/280 version which remove the need for the custom transfer_src_overlay function.

g16-101c-1.6.0-6089-full.zip

753.71KB

waterwingz

philmoz
@waterwingz - when you have a chance can you please test this G16 version for the HDMI crash issue.

Can do but might not be until this weekend 😀

waterwingz

philmoz
@waterwingz - when you have a chance can you please test this G16 version for the HDMI crash issue.

Okay - here's what I observed. (tl;dr - same start up issue as before?)

1) Start camera with Play button or short press of power button and active HDMI cable attached. Camera starts and CHDK seems to start but then shuts back down just as CHDK logo draws. ROMLOG attached.
2) Start camera with long press of power button (i.e. force to start in shooting mode) and active HDMI cable attached. Camera starts up properly in shooting mode. Press Play button to go to playback mode. Video switches to HDMI output and external monitor takes over as the display. Playback mode works properly.
3) Start camera with Play button or short press of power button and HDMI cable unplugged. Wait for camera to finish startup and then plug in HDMI cable. Display works properly, switching from camera's LCD to external monitor and back as I cycle between play and shooting mode.

Edit: I confirmed that I had loaded your April 27 2022 09:39:44 rev 6089 build.

ROMLOG.LOG

3.96KB

philmoz

waterwingz
Okay - here's what I observed. (tl;dr - same start up issue as before?)

1) Start camera with Play button or short press of power button and active HDMI cable attached. Camera starts and CHDK seems to start but then shuts back down just as CHDK logo draws. ROMLOG attached.

Thanks for testing - does the previous version work in this scenario (starting in PLAY mode with HDMI cable attached?

waterwingz

philmoz
does the previous version work in this scenario (starting in PLAY mode with HDMI cable attached?

Yes. Press PLAY with HDMI attached and camera starts up sending the LCD info to the HDMI port. All functions work normally.

Build Info for reference :

CHDK Ver : 1.6.0
Revision : 6037
Date : Jan 3 2022
Time : 08:58:24

« Previous Page Next Page »