Display (bitmap overlay)

Ant

509

Re: Display (bitmap overlay)

« Reply #110 on: 24 / July / 2017, 10:55:28 »

Advertisements

Quote from: zweistein68 on 24 / July / 2017, 05:32:27

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

Logged

waterwingz

12140

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.

Logged

Ported : A1200 SD940 G10 Powershot N G16

srsa_4c

4451

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 »

Logged

srsa_4c

4451

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.

Logged

philmoz

3450

Re: Display (bitmap overlay)

« Reply #114 on: 04 / December / 2017, 05:50:56 »

Quote from: srsa_4c on 03 / December / 2017, 16:19:28

- 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.

Logged

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)

srsa_4c

4451

Re: Display (bitmap overlay)

« Reply #115 on: 13 / December / 2017, 16:10:11 »

DIGIC 6 findings continued.

When JediDraw messages are intercepted, all Canon drawings disappear - except for text (which keeps accumulating on screen as, apparently, JediDraw is needed for erasing text). The JediDraw message does include one RGBA buffer address, ~~so it might be possible to redirect the drawing (with unknown consequences)~~*. I have not yet been able to find the message responsible for drawing text.
This time, I used an Xtensa side wrapper to replace the original message handler. It can be copied to an arbitrary place in Xtensa program memory (I used the unused part of the 0xbff20000...0xbff27fff area), and the address of 'jdraw_replacement' needs to be written at the appropriate place in the message handler table (related post).

Code: [Select]

# xtensa-elf-as try1.s -o try1.o
# xtensa-elf-objcopy -O binary try1.o try1.bin
# to check generated code: xtensa-elf-objdump -d try1.o

.text

.begin

.literal_position
orig_jedidraw:
.word   0x80AD1A2C
jdraw_enabled:
.word   0xbff07ffc

.word 0

.align  4

jdraw_replacement:

entry   a1, 32
l32r    a3, jdraw_enabled
l32i    a3, a3, 0
beqz    a3, jd_skip
mov     a10, a2
l32r    a8, orig_jedidraw
callx8  a8
mov     a2, a10
retw

jd_skip:

movi    a2, 0
retw

.end

When copying stuff to the 0xbff2xxxx area, following precautions are needed:
- The procedure should happen in or after zicokick_start. There's an unused Canon debug callback that lets hijack this function.
- Whole words need to be written

edit:
*Looking at the Xtensa side code, only the first 4 words of this particular message are used, the rest (including the framebuffer address) is ignored.

Message handlers (the ones I've seen) only have a single argument: a pointer that points to the message body (I managed to dump message content on the Xtensa side to prove this).
The Xtensa core is able to reach near the end of physical RAM (I copied stuff there from the Xtensa side), so I assume it is able to address the whole RAM.

« Last Edit: 14 / December / 2017, 11:34:59 by srsa_4c »

Logged

Ant

509

Re: Display (bitmap overlay)

« Reply #116 on: 17 / December / 2017, 16:13:50 »

Quote from: srsa_4c on 13 / December / 2017, 16:10:11

I have not yet been able to find the message responsible for drawing text.

SflwWrpDrawStringWithinRect message contains coordinates(220,220) and "Test" string (0x74736554) taken from LCDMsg_Create function:

Code: [Select]

Message: 0064: SflwWrpDrawStringWithinRect, size:0072 (0072), addr:bff00598
00000040 00000000 00000048 bff005d0 00dc0000 00dc0000 003f0000 002c0000 bff005c8 00000004 00000000 00000000 74736554 aaaaaa00 5652414d 42703000 00000000 05000004 000003c0 000001e0 00000000 
Stack:
bff00598 ffffffe8 00000000 00434ce8 00dc0000 006a2680 002c0000 006a25d8 006a2610 00000000 00000000 fc268925 002c0000 005a98b0 00000004 00000000 00000000 00000001 00000000 00020064 bff00064 00000064 bff00064 00640064 00640064 00000000 00000000 00dc0000 00dc0000 003f0000 002c0000 00434ce8 00433228 006a25d8 00000001 006a2610 005a98b0 000000dc 000000dc 00000108 000000dc 00000003 00434ce8 fc268a79 006a2610 005a98b0 00000004 006a2698 006a2680 00000000 00000000 000003c0 006a26a0 005a98b0 00433228 fc3f2cdd 0000011b 4d746e46 632e6e61 37333720 0000000a 000000dc 000000dc 0000003f

« Last Edit: 17 / December / 2017, 16:31:21 by Ant »

Logged

srsa_4c

4451

Re: Display (bitmap overlay)

« Reply #117 on: 17 / December / 2017, 16:36:51 »

Quote from: Ant on 17 / December / 2017, 16:13:50

SflwWrpDrawStringWithinRect message contains coordinates and "Test" string (0x74736554) taken from LCDMsg_Create function:

Yes, that was one of the suspects, but I did not yet go further with those experiments.
Preventing Canon drawings from appearing on the RGBA buffers could potentially enable us to draw on one of them, but there are still unresolved issues in the way:
- the destination buffer is not always known
- we don't know when the firmware switches to the second buffer (when menus are active, mostly)
...

Logged

Ant

509

Re: Display (bitmap overlay)

« Reply #118 on: 17 / December / 2017, 17:25:47 »

It looks like the 5th word in JediDraw message points to the structure containing coordinates of rectangle(100,100,520,280) taken from LCDRect_Create function:

Code: [Select]

Message: 0108: JediDraw, size:0044 (0044), addr:bff00500
0000006c 00000000 0000002c bff0051c 02341140 00000000 000000c0 5652414d 42703000 00000000 05000004 000003c0 000001e0 00000000 
Stack:
bff00500 fffffffc 00000000 00000000 00000000 000000c0 0002868c 00028640 000286a8 02341140 80000002 fc3f04b1 80000002 0003f30c 0019e468 00434d50 fd82d41c 00000000 ffffffff 006a24a8 006a2400 00000000 00434ce8 006a2498 00000000 00000000 42c80000 fc3f0597 00000000 fc268f35 00000000 000001e0 00000000 00000000 04380000 05000064 01000064 00000064 00000064 00640064 00640064 00000000 00000000 00000118 00000208 0003f30c 00000000 00000064 00000064 0000026c 0000017c 00434ce8 00000064 00000064 00000000 006a2400 006a2498 006a24a8 00434ce8 00000064 00000000 00000028 00000064 fc269077 
JediDraw content at 0x02341140:
00c00101 02341200 fd82d41c 00000000 023411d8 00000004 00000000 00000000 000000c0 00000001 00000000 00000000 000000ff 00000000 00000000 00000000 42c80000 42c80000 01180208 00640064 00640064 00000000 00000000 023411cc 00000000 00000000 000000ff 00640064 00640064 00000000 00000000 00000000 00640100 00000000 0003f30c 0000000c 00000001 00800080 00000064 00000064 00000208 00000118 ab92caab ab82ba0f a8b1ae70 ea28faa5 a8a2bcf2 a288aef9 00c00101 023412c0 fd82d41c 00000000 02341298 00000004 00000000 00000000 000000c0 00000001 00000000 00000000 000000ff 00000000 00000000 00000000

But I'm not sure about the length of this structure ...

Logged

srsa_4c

4451

Re: Display (bitmap overlay)

« Reply #119 on: 18 / December / 2017, 11:24:01 »

Quote from: Ant on 17 / December / 2017, 17:25:47

But I'm not sure about the length of this structure ...

It's either one of the members of the JediDraw structure (or the other structure it points at), or, it doesn't appear in the structure at all because it's pre-defined.

Logged