All information in this post do refer to EOS RP with firmware 1.6.0.
I have done some further investigations on VRAM handling and it seems that Canon has changed it on newer models. On my
initial investigations I have done a full RAM dump and searched for the MARV signatures manually to find the VRAM buffers. This worked fine as a first entry point to draw simple things on the LCD but drawing in EVF or HDMI output did not work properly with this method. Therefore I have analysed the
SaveVRAM event procedure to find out some more information about the buffer handling.
In the past the structure of
struct bmp_vram_info was like this:
struct bmp_vram_info
{
struct MARV * vram1; /* one of the two bitmap buffers - statically allocated? */
struct MARV * vram2; /* the other bitmap buffer */
struct MARV * back_vram; /* we need to write to the other one */
};
vram1 and
vram2 are two buffers which are written in an alternating way to prevent flicker.
back_vram points to the back buffer.
On RP Canon has changed it to this:
struct bmp_vram_info
{
struct MARV * vram1; /* one of the two bitmap buffers - statically allocated? */
struct MARV * vram2; /* the other bitmap buffer */
};
Plus now there is a global buffer index at
0xFF6C with the index of the current back buffer. It is either 0 or 1.
There are 3 YUV (UYVYAA) buffer pairs in total. One back and one front buffer each. Only one of the three buffer pairs seems to used:
vramBufferPairNo = 0: Final image displayed on LCD or EVF without sensor image
vramBufferPairNo = 1: Nullptr (Unknown)
vramBufferPairNo = 2: Nullptr (Unknown)
I don't know if buffer pairs 1 and 2 are ever used.
Formular for getting YUV buffers:
DAT_e0255238 + vramBufferPairNo * 0x28 + (1 - vram_current_buffer) * 4 - 0x5c
DAT_e0255238 is the dereferenced value on address 0xE0255238 which is 0x722B0.
vramBufferPairNo selects the buffer pair. Valid values are 0 to 2. It seems that buffer 1 and 2 are unused.
vram_current_buffer is the dereferenced value of 0xFF6C and is either 0 or 1.
There are 6 BGRA buffers in total. They are not double buffered and only two them are used in practice:
vramBufferNo = 0: Menu and Live View Overlays
vramBufferNo = 1: Focus point overlay
vramBufferNo = 2: Nullptr (Unknown)
vramBufferNo = 3: Nullptr (Unknown)
vramBufferNo = 4: Nullptr (Unknown)
vramBufferNo = 5: Nullptr (Unknown)
Formular for getting BGRA buffers:
DAT_e0331888 + vramBufferNo * 0xc
With this information I am now able to draw proper images on LCD, EVF and HDMI output. However, due to the pixel wise "software" rendering via CPU the current rendering performance with about 3 fps is quite bad.
I assume that actual rendering by Canon code is done in the BGRA buffers and are then composited and converted to YUV by some coprocessor. I don't know how to trigger that conversion in Canon firmware. Once I have found that out rendering speed should increase significantly. Until full ML does not run on RP, speed is not in focus so I will keep it like that for now.
Bad news are, that the new VRAM handling does require some adjustment in ML code. Good news are that R5 and R6 do also seem to use this new rendering method so they will profit from these changes as well. EOS R does still use the old method.
