supplierdeeply

Display (bitmap overlay)

  • 114 Replies
  • 21587 Views
*

Offline Ant

  • ****
  • 318
Re: Display (bitmap overlay)
« Reply #110 on: 24 / July / 2017, 10:55:28 »
Advertisements
what are the addresses for 'transfer_src_overlay' ?

https://app.assembla.com/spaces/chdk/subversion/source/4888/trunk/platform/m10/sub/110d/stubs_entry.S#ln224
https://app.assembla.com/spaces/chdk/subversion/source/4888/trunk/platform/m10/sub/110f/stubs_entry.S#ln224

Re: Display (bitmap overlay)
« Reply #111 on: 02 / September / 2017, 19:54:43 »
Thought I'd drop a quick placeholder here based in a conversation with reyalp on IRC today.

Code: [Select]
[14:56] <reyalp> we totally forgot about grids and script drawing
[15:02] <waterwingz> understandable
[15:05] <reyalp> my feeling is script should be able to draw at "native" resolution, but maybe something could be added to drawings.lua (or another library) to make screen size relative stuff easier
[15:10] <waterwingz> thinking about that - it will make all scripts that draw now not able to work with newer cameras - and the code gets bigger as they try to play with scaling everything correctly relative to all the other screen drawings
[15:10] <waterwingz> all it buys you is the ability to draw more finely on larger pixel x-y displays
[15:11] <waterwingz> vs just assuming drawings work in a 360x240 sandbox
[15:11] <waterwingz> and letting CHDK figure out how to map that
[15:12] <reyalp> aspect ratios kinda mess that up though
[15:14] <reyalp> and my thought was giving you the option of sandbox drawing in lua

I played with the G16 (digic6) port today with CHDK grids and script drawing (CHDKplus.lua) The results were "interesting" in the case of grids and awful in the case of script drawing.


Ported : A1200  SD940  G10  Powershot N  G16*

*

Offline srsa_4c

  • ******
  • 3474
Re: Display (bitmap overlay)
« Reply #112 on: 02 / December / 2017, 16:11:16 »
I have ported the experiments to the M10 and have some findings to share.

- The XimrExeGain mzrm message is used by firmware when the overlay "fades in" (upon exiting the shooting menu or the rec menu). It does everything the regular XimrExe does (copies an RGBA buffer's content to one of the YUV overlay/opacity buffer pairs) plus it handles the fade effect.

- I tried modifying the source and destination buffer addresses that can be found in the big structure that is passed through with the XimrExe message. It can be done, the Xtensa side does not check their validity.

An example XimrExe message from the M10 (1st column is decimal byte offset, 2nd column hexadecimal word, 3rd column interpretation):
Code: [Select]
header
25
13
304
message
0 bff00510
4 2d00000 720
8 50001e0 480
12 1000000
16 0
...
40 0
44 5652414d 'VRAM'
48 5fe05c00 dest. yuv buf
52 5fd08a00 dest. opacity buf
56 1000102
60 2e0 736, dest full width
64 1e0 480, dest full height
68 2c60164
72 0
76 3000000
80 1
84 3000000
88 10500
92 0
96 1e00000 480
100 2d0 720
104 10000
108 5652414d 'VRAM'
112 41e7eb00 RGBA buffer (2nd one)
116 0
120 5000004
124 3c0 960, src buf width
128 1e0 480, src buf height
132 0
136 3000000
140 1
144 3000000
148 10500
152 0
156 1e00000 480, src used height within buffer
160 2d0 720, src used width within buffer (the rest is ignored/not copied)
164 10000
168 5652414d 'VRAM'
172 41cbcb00 RGBA buffer (1st one)
176 0
180 5000004
184 3c0 src buf width
188 1e0 src buf height
192 0
...
616 0
620 808000
624 1
628 0
632 1
636 1000000
640 1
644 0
648 0
652 1010101
656 0
660 1e002d0 480, 720
664 0
668 0
672 0
676 0
680 0
684 1000
688 0
692 0
696 0
700 0
704 0
708 4000000
712 0
716 0
720 0
724 0
728 0
732 0
736 3ff51000
740 3fc0001e
744 3f1c007e
748 3ce40199
752 a16
756 0
760 4000000
764 340ff4
768 2760f62
The only changing parts of this message I've seen so far are the destination yuv and opacity buffer addresses. Those most likely depend on the parameter passed to transfer_src_overlay().

This is still not enough to make a new D6 CHDK display implementation, but it might give ideas.
« Last Edit: 03 / December / 2017, 15:19:54 by srsa_4c »

*

Offline srsa_4c

  • ******
  • 3474
Re: Display (bitmap overlay)
« Reply #113 on: 03 / December / 2017, 16:19:28 »
What is known about D6 display so far.

- The DIGIC display device is configured to use YUV+opacity buffers (double buffering).
It also supports legacy, paletted mode(s), but that is only used on DSLRs in their bootloader.

- The Xtensa side draws to 2 big RGBA buffers. The first buffer is used usually.
If there's content in the second buffer, it will appear as top(?) layer.
Menus tend to use exclusively the second buffer.
In the cams I know, these RGBA buffers are sized 960x480 (max. supported resolution is full HD). G5x might have even larger buffers.
If the current output device has less resolution, surplus pixels on the right are not transferred to the final buffers.

- Transfer between the source RGBA and destination YUV+opacity buffers is done on the Xtensa side.
Two known messages (as mentioned earlier): XimrExe, XimrExeGain (early models don't have the latter).
Transfer is initiated in the ARM side transfer_src_overlay() function. The parameter to this function is
very likely for selecting the destination buffer.

- Currently known possibilities and limitations

 - We can't prevent the Xtensa side from drawing to its RGBA buffers.
 - It's possible to suppress the XimrExe messages completely. While these are suppressed, we can freely use the YUV+opacity overlays.
   Caveat: the firmware will continue to switch those buffers whenever it wants.
 - It's possible to modify the XimrExe messages.
   - Destination can be modified (possible use: refresh a certain buffer deliberately)
   - Source can be modified (possible use: replace the first/second RGBA buffer with our RGBA buffer).
 - If we decide to draw on our own RGBA buffer, we face the following problems:
   - Need to allocate 960*480*4 bytes (~1.8MB) from somewhere. It _might_ be possible to use a much smaller RGBA buffer and let XimrExe scale it, but I'm not sure. A smaller buffer may not combine very well with a large one.
   - Need to detect when the firmware switches to the 2nd RGBA buffer and switch to that in XimrExe.
   - Need a method for erasing that huge area (memset is ineffective and hogs the CPU). Some kind of DMA or a clever XimrExe modification, perhaps.
 - Unknown weirdness on G5x. Above findings may not apply there.


*

Offline philmoz

  • *****
  • 3049
    • Photos
Re: Display (bitmap overlay)
« Reply #114 on: 04 / December / 2017, 05:50:56 »
- Unknown weirdness on G5x. Above findings may not apply there.


Thanks for that, good summation. Clarifies what I've seen with the G5X and fills in some gaps.


Main differences on the G5X:
- RGBA buffer is 864 x 480 pixels (x 4 bytes per pixel), total size 1.58MB.
- There is only one RGBA buffer (that I can find).


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)

 

Related Topics