Display (bitmap overlay)

pigeonhill

Please forgive me if this post doesn’t link to the topic.

My feedback is that on my M3, the CHDK drawing is always skewed left relative to the image, when I use HDMI out.

srsa_4c

philmoz
Additional RGBA layers are rendered twice when using HDMI. They are rendered once at the RGBA frame size and again at the YUV frame size on the screen. The attached image shows this - only two blue boxes were drawn into the RGBA layer.

I just tried, happens on m10 as well.
When I copied the second layer (which uses the first RGBA buffer and is used for most of overlay) ximr struct to a later layer and zeroed out the second layer struct, I seemingly got identical result to normal, no double draw.
I suspect the key is somewhere in the ximr struct.

The RGBA layers are not full screen when using HDMI, they are smaller and centered (affects Canon UI as well).

The ximr struct does have data that looks like border size in that case.

Could you make dumps of the whole struct on your g5x? It has 3 different resolution output devices, seeing one dump for each could be helpful. I only have lcd and hdmi.

philmoz

Attached zip file has ximr context dumps from LCD, EVF and HDMI.

I am copying layer[1] (second layer) from offset 0x48+0x3c in the ximr context data - in HDMI the first layer looks like YUV format.

I can see the centering offsets in the layer struct just before the 'MARV' marker - changing these I can make the RGBA layer full screen; but I still get the double rendering (even if I zero out the second layer).

Edit: I also tried just replacing the RGBA buffer pointer in the 2nd layer and not modifying anything else - I still get the double rendering ???

On a side note - one plus in all this is that patching dry_memcpy and checking if the call is from the function that updates the display gives a very reliable way to detect when the CHDK UI needs to be refreshed. I've tried this on the G5X and G7X2 to replace the current guard pixel logic and it gives a much better CHDK UI with much less flickering.

Phil.

g5x_ximr_context.zip

1.3KB

srsa_4c

philmoz
Attached zip file has ximr context dumps from LCD, EVF and HDMI.

Thanks. From a quick look, the ximr structure seems to match the m10 struct.

Edit: I also tried just replacing the RGBA buffer pointer in the 2nd layer and not modifying anything else - I still get the double rendering

I had a thought that maybe the zico side needs to know the buffers in advance, so I added an offset (+256) to the 2nd layer's rgba buffer address. Aside from the shifted view, no artifacts are visible on hdmi output (no double drawing).

@kitor: Can you check whether your cameras have such drawing issues on HDMI?

kitor

Double rendering - no. Magic Lantern menus worked fine on my own layer on HDMI output of EOS R.
Maybe your buffers overlap or something?

Part of layer definition structure in XimrContext contains offsets that are cut off from full buffer (not rendered) and layer offset (move "0,0" somewhere else on screen). See XimrSetLayerDimensions:

src_x, src_y, src_w, src_h is region from buffer that will be rendered. Everything outside this region is just not visible (not rendered / transparent). This will "crop" potential junk that you don't want to be visible.

dst_x, dst_y is offset in output buffer where 0,0 from input layer will be rendered. With that you can move output horizontally and vertically.

Additionally, somewhere in XimrContext structure there is scaling ratio (or really two ratios - horizontal and vertical) set. Those apply to all layers and are used to up/downscale from layers to output buffer. This is set once per XimrContext, so it applies to all layers at once - thus as long as you alter Canon generated XimrContext this should be fine.

All those params change for each output type. They are different for LCD, HDMI, EVF (or in general per output YUV resolution). So when switched to HDMI, you would need to update both crop region and offsets to probably something like (0,0, buf_w, buf_h),(0,0) to both properly start buffer from 0,0 and tell Zico to render whole buffer content.

For horizontal shift there maybe an issue with buffer memory alignment - i touched that topic in my writeup, I had to memory-align buffers on Digic 7 to 256 blocks - see my PoC from chapter 1.2
But if this would be the issue, you would get a random shift on every boot / buffer allocation unless your method of malloc returns the same address every time 😉

philmoz

srsa_4c
I had a thought that maybe the zico side needs to know the buffers in advance, so I added an offset (+256) to the 2nd layer's rgba buffer address. Aside from the shifted view, no artifacts are visible on hdmi output (no double drawing).

Try shifting it by a larger negative amount.
In the attached image I have copied layer 2 and just adjusted the RGBA buffer address lower in memory by 40 rows.

I have no explanation for this - it is just weird.

Edit: This also happens if I just change the RGBA buffer address in layer 2 by the same amount without duplicating the layer (2nd screenshot).

Phil.

kitor

Try shifting it by a larger negative amount.

I'm 99% sure this is your problem. I never tried to shift layer by "negative amount", only positive. And srsa confirms no issues on that.

Can you dump XimrContext struct for me while this weird issue is visible?

philmoz

kitor

Try shifting it by a larger negative amount.

I'm 99% sure this is your problem. I never tried to shift layer by "negative amount", only positive. And srsa confirms no issues on that.

Can you dump XimrContext struct for me while this weird issue is visible?

Attached is a zip file with the ximr context dump from the second screen shot in my earlier post.
The only change made to the context is to shift the RGBA buffer address in the second layer as I described. Everything else is unchanged.

In this dump the buffer address is 0x42584800, the normal address is 0x425aa000.

Edit: This is from the G7X2 as were the earlier screen shots. The G5X behaves the same.

Phil.

ximr.dat.zip

376b

kitor

Hi,
According to your dump:
OutputChunk:

Layer config:
- width: 960
- height: 540
VRAM struct:
- width: 1024
- height: 768
- pBitmap @ 0x7FD00000
- pOpacity @ 0x7FB80000
- flags: 0x1040280 (UYVY + Alpha)

Layer 0 (Canon):

Layer config:
- color_type: 1 (UYVY + Alpha ?!?!)
- src_x: 0
- src_y: 0
- src_w: 960
- src_h: 540
- dst_x: 0
- dst_y: 0
VRAM struct:
- width: 1024
- height: 768
- pBitmap @ 0x4196A000
- pOpacity @ 0x41AEA000
- flags: 0x1040280 (UYVY + Alpha ?!?!)

Layer 1 (yours):

Layer config:
- color_type: 5 (RGBA)
- src_x: 0
- src_y: 0
- src_w: 720
- src_h: 480
- dst_x: 120
- dst_y: 30
VRAM struct:
- width: 960
- height: 540
- pBitmap @ 0x42584800
- pOpacity @ 0x0
- flags: 0x5040100 (RGBA)

Please note, I might have swapped src_x/y with dst_x/y. Digic 8 uses slightly different struct in terms of both fields order and data types.

This both answers and raises some questions.

First, looks like Canon switches to YUV GUI rendering ?! It uses 1024x768 YUV buffer and renders 960x540 starting from 0,0.
Since output is also 960x540 - I believe scaling factor is 1:1 (idk where it is located in XimrContext).

With that said, your layer is 960x540 RGBA but you told it to render 720x480 starting from 120,30. This is probably source of most problems.
Change layer config to 960x540 from 0,0 - like Canon layer does.

Layer config:
- color_type: 5 (RGBA)
- src_x: 0
- src_y: 0
- src_w: 960
- src_h: 540
- dst_x: 0
- dst_y: 0

I believe this will solve your layer offset problems.

I attached partial grammar for Hexinator. If you load your dump + this grammar, you can see what different fields mean. This is specific for dump provided, as XimrContext may differ on other cameras.

XimrContext_grammar.zip

898b

philmoz

kitor
With that said, your layer is 960x540 RGBA but you told it to render 720x480 starting from 120,30. This is probably source of most problems.
Change layer config to 960x540 from 0,0 - like Canon layer does.

Thanks for looking; but in this dump I have NOT added any new layers to the display. Both layers are Canon layer with Canon values for all properties.

The only change I made was to adjust the Canon RGBA buffer address to demonstrate that the weird rendering issue also happens unless the buffer addresses are exactly what the Canon UI uses. You can see the rendering error at the top of the screen shot where content that should have been off the bottom of the screen is being shown.

Phil.

kitor

Oh, I misunderstood that. This is even funnier if they mix RGBA and YUV layers.
This is Digic 7, am I correct? I'll try to replicate it on 200D.

This happens only on HDMI out?

philmoz

kitor
Oh, I misunderstood that. This is even funnier if they mix RGBA and YUV layers.
This is Digic 7, am I correct? I'll try to replicate it on 200D.

This happens only on HDMI out?

Same on G5X which is Digic 6.

It only appears to happen when using HDMI.

srsa_4c

@philmoz
Have you tried dumping the contents of the yuv layer (layer0) in hdmi mode?
Because I just did that and found my new layer's content in it - that's the full width junk that appears as extra.
Also, that layer seems to visually disappear when I enter the Canon menu. When I compare the ximr structures in those cases, I find a changed byte in layer2 (that layer is supposed to be invalid) and a changed word in the unparsed part of the struct that follows the layer definitions (plus the output buffers can be flipped, but that's normal and doesn't influence anything).

kitor

I checked, and:
- no such thing happen on EOSR or 200D
- 200D XimrContext mapped directly to grammar I made for you

I think your problem is related to YUV layer itself. It is strange for me that Canon uses one YUV and one RGB layer... I'd look how this YUV layer is created by Canon code.

I attached XimrContext from 200D for reference. May be helpful in future.
This is with my layer setup (Canon has only one layer on 200D), while in HDMI output mode.

[Edit]
Brainfart. I removed most of the post as it was wrong.

MARV buffer size (resolution) is one thing, Layer config is just "put that rectangle from buffer, starting from 120x30 of size 960x540 on screen; start drawing from 0,0".
This was source of that noise in my case, I told it to go outside the buffer myself 😉

ximr_200d.zip

323b

philmoz

srsa_4c
@philmoz
Have you tried dumping the contents of the yuv layer (layer0) in hdmi mode?

Yes layer 0 is where the extra stuff us being rendered to - setting it's visibility to 0 makes it go away.

Unfortunately this layer is also where the Canon focus rectangle is drawn so disabling it is not really an option.

Phil.

srsa_4c

philmoz
Yes layer 0 is where the extra stuff us being rendered to - setting it's visibility to 0 makes it go away.

Unfortunately this layer is also where the Canon focus rectangle is drawn so disabling it is not really an option.

I tried going after that buffer (0x41141000 in multiple models), but did not get very far. The sole display-related reference to it is one level up from the ximr-creating routine, where it is placed in a MARV struct. I also could not find that address in the zico firmware. It's not impossible that it's being mov + add'ed together somewhere else, but, for the time being, I have no idea how that buffer gets its original content.
For another trial, I zeroed out the third layer's descriptor (which does have some bytes other than zero in hdmi mode), but the double render was unaffected.

srsa_4c

Found it. The firmware uses ximrexe (a separate call, just before the overlay is refreshed) to create the yuv layer in hdmi mode. Recognizing that case is simple: the yuv layer is updated when the output buffer is 0x41141000 (for most cameras I guess).
It looks like that buffer only has secondary use in a few cases (factory exe, developtest and such), so it could potentially be used for display purposes. Inside are 960x540 yuv and opacity buffers in m10.

kitor

This come through my mind, but I thought it would be stupid to go rgb -> yuv and then yuv + rgb -> yuv once again. Looks that I was wrong.
So with that (if you skip adding your layer to overlay render calls) everything is fine?

srsa_4c

kitor
So with that (if you skip adding your layer to overlay render calls) everything is fine?

The extra full width copy of the new layer disappears, so it's fine.
The source of the yuv layer is the second 960x480 rgba buffer (on m10). I guess they decided to do this in order to resize that layer to correctly show at 16:9 aspect.

philmoz

srsa_4c
Found it. The firmware uses ximrexe (a separate call, just before the overlay is refreshed) to create the yuv layer in hdmi mode. Recognizing that case is simple: the yuv layer is updated when the output buffer is 0x41141000 (for most cameras I guess).
It looks like that buffer only has secondary use in a few cases (factory exe, developtest and such), so it could potentially be used for display purposes. Inside are 960x540 yuv and opacity buffers in m10.

Awesome - thanks for that.

Comparing the firmware code to the M10, the corresponding G7X2 buffer address is 0x4196a000.

If I skip adding my layer when the layer 0 buffer is 0x4196a000 then I get my layer scaled up to the YUV layer size and rendered underneath the Canon UI.
However if I only add my layer when the buffer is 0x4196a000 (for HDMI) then I get my layer un-scaled and on top of the Canon UI.

Edit: On the G7X2, when using HDMI out, the new layer I add must have dimensions of 960x540 in the MARV section. Any other size results in random garbage being added to the output YUV layer.

Phil.

« Previous Page Next Page »