Display (bitmap overlay)

reyalp

14082

Re: Display (bitmap overlay)

« Reply #160 on: 09 / January / 2020, 01:59:54 »

Advertisements

I think srsa_4c may have explored most of this already, but anyway:
The canon code references displaytype values 11 and 12, with resolutions 1024x768 and 900x600.

On sx710 (101a), these can sometimes actually be set, using the function called by DispCon_SetDisplayType:

Code: [Select]

=call_func_ptr(0xfc0f0dfb,12)

The canon UI is garbled, but CHDK OSD is OK if the buffer sizes from canon code are used. I think it crashes if the function is called with an image on the camera, but there might be random crashes too. Switching to rec crashes if PTP is connected, but works if not. The live view is garbled in rec. Shooting works.
I don't think there's any real use for these modes.

I also found that if you connect HDMI to a lower res monitor (1280x1024, with an HDMI-DVI adapter in this case) it uses displaytype 8, 720x480 res. This low res HDMI still doesn't allow rec mode. Unlikely other TV out modes, this is 8 regardless of the NTSC/PAL setting.

In regular HD HDMI, the playback live buffer is full 1920x1080, 2x the size of the bitmap. The code I used on G7X and sx710 supports this over PTP, although I have trouble imagining a use case for it.

sx710-undoc-mode-12-live.jpg (1289.49 kB, 2000x1502 - viewed 65 times.)

sx710-undoc-mode-12-chdk.png (361 kB, 900x600 - viewed 82 times.)

« Last Edit: 19 / January / 2020, 20:42:57 by reyalp »

Logged

Don't forget what the H stands for.

srsa_4c

4451

Re: Display (bitmap overlay)

« Reply #161 on: 05 / April / 2021, 17:29:30 »

ML forum member kitor has just posted a large amount of DIGIC 7-8-X overlay related reversed information. It may not directly apply on PowerShot-based firmware, but looks like a good starting point.

Logged

kitor

20

Re: Display (bitmap overlay)

« Reply #162 on: 10 / April / 2021, 05:29:11 »

Oh hello. It was a bit funny (and disappointing?) to see that most of my research is a duplicate of this thread

Anyway, the interesting bit for you is probably Ximr Context structure and layers implementation from Digic 7 (with pure Ximr functions).

From what I understand some CHDK cameras have separate buffer for GUI and for focus box overlay, which is similar to EOS R/RP setup (Digic 8 ), while other have single buffer (like on 200D / Digic 7).

Of course this can still be depending on Zico firmware, but since 200D don't use this feature and it is still available, I guess D6 cameras should have it too.

Additional info, not posted yet: "flags" or "color" field of MARV structure is kind of bitfield, It seems to contain 4 things (starting from MSB): Type (?), bits per pixel, subsampling and flag if VRAM has separate opacity layer (UYVY + Alpha). I experimented with that a bit yesterday and had "input" YUV+Alpha layers working on EOS R for different subsampling modes. Unfortunately I found no traces of potential indexed RGB mode - it would be too easy

Now, questions time

@srsa_4c - do you have any idea for accessing drysh on zico core? At least on EOS Zico firmwares there are all the strings there. But we are able to switch UART only between main core and Lime with drysh uart_change command. Turtius traced how this switch works and it just sets 2 bit bitmasks at locations:
- d01202f0 (RX) and d01202f4 (TX) for R/D8
- d20702e4 (RX) and d20702e0 (TX) for 200D/D7
"11" switches to Lime, "00" to ICU, as for 01 and 10 - there's just a silence.

« Last Edit: 10 / April / 2021, 05:51:48 by kitor »

Logged

Magic Lantern / EOS R / 200D

srsa_4c

4451

Re: Display (bitmap overlay)

« Reply #163 on: 10 / April / 2021, 12:47:09 »

Quote from: kitor on 10 / April / 2021, 05:29:11

Anyway, the interesting bit for you is probably Ximr Context structure and layers implementation from Digic 7 (with pure Ximr functions).

Yes. My guess is that the Zico firmware is the product of a single development team. So, the Zico side of your findings should also apply on our cameras. The ARM side is unfortunately different. Some sort of layers support should be available, since the sx280 (as one of the first D6 cameras) already uses 2 large RGBA buffers.

Quote

From what I understand some CHDK cameras have separate buffer for GUI and for focus box overlay

To make things more difficult, the "focus box" layer is also used for other things, for example the menu is drawn there. That has prevented me from trying to repurpose the second buffer as CHDK overlay.

Quote

Unfortunately I found no traces of potential indexed RGB mode - it would be too easy

I think I could live with a yuv or rgba overlay if a small buffer could be magnified to full screen size.

Quote

do you have any idea for accessing drysh on zico core?

No, unfortunately not. I only wired UART on cameras that are more or less broken already, my D6 or newer cams are still fully operational.

Quote

At least on EOS Zico firmwares there are all the strings there. But we are able to switch UART only between main core and Lime with drysh uart_change command.

It appears to me that the uart line switching related commands are not consistent. For example, the two ARM firmwares on sx280 appear to have a shell command named sw. The Zico firmware is missing that, but has its own related commands (cpusel for example). Later (D7) versions of Zico no longer have cpusel.

A possibility is that the uart output (and/or the dryos shell) is blocked by default and needs to be activated somehow (either from ARM or from the Zico firmware).
Since everything except the main firmware runs from RAM, the possibility to modify the code is there.

Logged

kitor

20

Re: Display (bitmap overlay)

« Reply #164 on: 10 / April / 2021, 13:26:39 »

If you can dump memory structure that is sent via XimrExe (size is probably less than 0x300 - which is size for D7) I can tell you a bit more from that.
If there's a place for more layers there - even if ARM side is missing other Ximr family functions, it should be possible to setup this manually.

Quote

To make things more difficult, the "focus box" layer is also used for other things, for example the menu is drawn there. That has prevented me from trying to repurpose the second buffer as CHDK overlay.

So similar but quite different - R use layer 0 for GUI and LV overlays, layer 1 seems to be utilized just for focus overlay.

« Last Edit: 10 / April / 2021, 13:53:37 by kitor »

Logged

Magic Lantern / EOS R / 200D

reyalp

14082

Re: Display (bitmap overlay)

« Reply #165 on: 10 / April / 2021, 17:23:40 »

Quote from: kitor on 10 / April / 2021, 05:29:11

@srsa_4c - do you have any idea for accessing drysh on zico core? At least on EOS Zico firmwares there are all the strings there.

Since (on our cameras at least) the zico code is all in RAM, it seems like you should be able to do something like the console hook (https://chdk.setepontos.com/index.php?topic=11029.0) relatively easily: That is, override the tty read/write function to read/write from RAM shared with the main core instead. Unfortunately, the relative lack of xtensa tooling and documentation compared to arm makes it annoying to work with.

Logged

Don't forget what the H stands for.

srsa_4c

4451

Re: Display (bitmap overlay)

« Reply #166 on: 10 / April / 2021, 17:24:28 »

Quote from: kitor on 10 / April / 2021, 13:26:39

If you can dump memory structure that is sent via XimrExe (size is probably less than 0x300 - which is size for D7) I can tell you a bit more from that.

I made some captures some years ago. I put a few on a spreadsheet (one word per row), with some annotations (I have not worked on them recently). I hooked mzrm_sendmsg to get the "message", so there are some words of message header before the actual struct. The sizes are not uniform, sx280 uses a longer struct than the eos m10. All captured words are in hex.

ximrexe_captures.7Z (20.99 kB - downloaded 12 times.)

Logged

reyalp

14082

Re: Display (bitmap overlay)

« Reply #167 on: 10 / April / 2021, 17:54:53 »

FWIW, you've probably already worked them out, but I added some reverse engineered structures in https://app.assembla.com/spaces/chdk/subversion/commits/5762

Logged

Don't forget what the H stands for.

kitor

20

Re: Display (bitmap overlay)

« Reply #168 on: 11 / April / 2021, 04:17:25 »

Quote from: reyalp on 10 / April / 2021, 17:54:53

FWIW, you've probably already worked them out, but I added some reverse engineered structures in https://app.assembla.com/spaces/chdk/subversion/commits/5762

Thanks! I was looking just at Ximr part, without underlying mzrm messages. But Turtius from ML forum/discord was experimenting with OpenVG functions from D7 Zico - it may be helpful for him.

Quote from: srsa_4c on 10 / April / 2021, 17:24:28

I made some captures some years ago. I put a few on a spreadsheet (one word per row), with some annotations (I have not worked on them recently). I hooked mzrm_sendmsg to get the "message", so there are some words of message header before the actual struct. The sizes are not uniform, sx280 uses a longer struct than the eos m10. All captured words are in hex.

Interesting that those two have different size of Ximr Context structures. M10 uses 15 words per layer, SX280 has 16 words per layer (ends with 7 word VRAM/MARV struct, last struct word is 0 - it is PMEM pointer). 15 words per layer are used in 200D / D7. This apply only to "input layers", output chunk definition structure (first VRAM in Ximr Context) is different than input layers.

But in both cases there's a huge chunk of empty space after last layer structure is the place where D7 and D8 puts next layers. Size would fit 9 input layers total (including existing ones), but both on 200D (8 layers) and R (5 layers) there's some empty space after last layer definition.

I need to dump from from my mum M10 and take look at it. Considering two cameras of the same generation must have slightly different Zico firmware (so Ximr structure is different), I don't think those structures are hardcoded, and I except to find similar setup to 200D.

« Last Edit: 11 / April / 2021, 04:20:40 by kitor »

Logged

Magic Lantern / EOS R / 200D

srsa_4c

4451

Re: Display (bitmap overlay)

« Reply #169 on: 11 / April / 2021, 10:11:29 »

Quote from: kitor on 11 / April / 2021, 04:17:25

But in both cases there's a huge chunk of empty space after last layer structure is the place where D7 and D8 puts next layers. Size would fit 9 input layers total (including existing ones)

That's my hope too.

Perhaps worth to mention that most or all framebuffers are fixed in PowerShot firmware, whereas (AFAIK) they are allocated at run-time in EOS firmware.

I briefly looked at my sx280 disasm and found that the big ximr structure is allocated on stack just before it is sent. A bunch of functions are used to populate it - next step is to analyze them.

Logged