Display (bitmap overlay) - page 20 - General Discussion and Assistance - CHDK Forum

Display (bitmap overlay)

  • 403 Replies
  • 123895 Views
*

Offline kitor

  • *
  • 20
Re: Display (bitmap overlay)
« Reply #190 on: 24 / April / 2021, 17:48:43 »
Advertisements
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?
« Last Edit: 24 / April / 2021, 17:54:02 by kitor »
Magic Lantern / EOS R / 200D

*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: Display (bitmap overlay)
« Reply #191 on: 24 / April / 2021, 18:25:18 »
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.

CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)

*

Offline srsa_4c

  • ******
  • 4451
Re: Display (bitmap overlay)
« Reply #192 on: 26 / April / 2021, 14:59:50 »
@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).

*

Offline kitor

  • *
  • 20
Re: Display (bitmap overlay)
« Reply #193 on: 26 / April / 2021, 16:02:40 »
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 ;)
« Last Edit: 26 / April / 2021, 16:37:05 by kitor »
Magic Lantern / EOS R / 200D


*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: Display (bitmap overlay)
« Reply #194 on: 26 / April / 2021, 18:25:42 »
@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.
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)

*

Offline srsa_4c

  • ******
  • 4451
Re: Display (bitmap overlay)
« Reply #195 on: 27 / April / 2021, 12:34:56 »
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.

*

Offline srsa_4c

  • ******
  • 4451
Re: Display (bitmap overlay)
« Reply #196 on: 28 / April / 2021, 12:07:32 »
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.

*

Offline kitor

  • *
  • 20
Re: Display (bitmap overlay)
« Reply #197 on: 28 / April / 2021, 12:38:22 »
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?
Magic Lantern / EOS R / 200D


*

Offline srsa_4c

  • ******
  • 4451
Re: Display (bitmap overlay)
« Reply #198 on: 28 / April / 2021, 17:25:35 »
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.

*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: Display (bitmap overlay)
« Reply #199 on: 28 / April / 2021, 19:06:43 »
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.

« Last Edit: 29 / April / 2021, 02:04:00 by philmoz »
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)

 

Related Topics