Oops--but isn't that essentially what is going on in the allocate-raw-lv-buffer branch?
Nope -
https://en.wikipedia.org/wiki/C_dynamic_memory_allocationRAW_LV_BUFFER_ALLOC_SIZE gets passed to fio_malloc; this returns a pointer to the allocated buffer, which is then stored in raw_allocated_lv_buffer (and used to save the LiveView frame there). The same happens in crop_rec_4k, with some additional bounds checking (which is only valid on 5D3 - the other models use dummy values just to compile).
DEFAULT_RAW_BUFFER is used as a pointer to some valid raw buffer (allocated by Canon code). On recent models (60D and newer), it is allocated when entering LiveView (evfActive), but that pointer is no longer valid when leaving LiveView (it's still there, but stale); on older models
I believe it's allocated on request (by whatever code gets triggered by lv_save_raw)
edit: it's also allocated when entering LiveView! edit2: false alarm, I forgot photo raw overlays enabled during the test!
5D3 1.2.3 (it appears to allocate 0x1cae000 bytes; MEM1 is the raw buffer we are looking for):
79152> Evf:ff16b0dc:a9:03: [2] Flicker Address[0x4d318000][0x52518000]
791E9> Evf:000aef04:00:00: *** lv_raw_buf(0x0, 0x0, 0x94897c, 0xc, 0x4d318000, 0x52518000, 0x1cae000), from ff1650d4
79200> Evf:ff16b334:a9:03: Mem1 Address[0x4d31a000][0]
500D (
full log):
1B512> LiveViewAn:ff1f6224:9a:07: [00000000:043A8818] lvaStart
...
1B944> LiveViewMg:00092b38:00:00: [00000000:043A8818] *** LVState: (1) --20--> (1) ff0e5424 (x=869970 z=4099b360 t=1)
1B9B4> LiveViewMg:ff0e5470:98:03: [00000000:043A8818] HPCopyAsync pvParam:0x4099b360 -copy-> Lucky:0x43fd4420
1BA24> LiveViewMg:ff0de974:9b:03: [00000000:043A8818] GetResource 0x1000 (0xF07/0x1F07)
1BB16> LiveViewMg:ff1f8e28:99:02: [00869A28:00000000] SetFlickerPassParameter
...
(after a while; LiveView working normally without raw for a few seconds)
...
42F97> run_test:00059408:00:00: [00869A28:00000000] *** call lv_save_raw ***
43011> run_test:00093268:00:00: [00869A28:00000000] *** TryPostEvent(LiveViewMgr, 0x9, 0x1, 0x200), from ff032728
430BD> LiveViewMg:00092b38:00:00: [00869A28:00000000] *** LVState: (2) --9--> (2) ff0e56ec (x=869970 z=1 t=200)
43126> LiveViewMg:ff0e5738:98:16: [00869A28:00000000] Set Debug Flag 0x000006A1(0x08200)
...
7FB00> LiveViewMg:ff1fb03c:99:02: [00869A28:00000000] StopQuarkPass
7FB5F> LiveViewMg:ff1f5a94:98:02: [00869A28:463390A4] GetEngineResource SUCCESS Res:4, Free:fffffffc
The numbers in brackets are (added this to my_DebugMsg to print the possible raw buffer address on every debug message):
len += snprintf(buf+len, buf_size-len, "[%08X:%08X] ", MEM(0x15CB0), MEM(MEM(0x15CB0) + 0x328));
Addresses coming from:
DebugMsg(153, 4, "StartPass_x1 CrawAddr : %lx / KindOfCraw : %d", *(v15CB0 + 0x328), *(v15CB0 + 0x32C));
BC24B> LiveViewMg:ff1f7190:99:04: [00869A7C:463390A4] StartPass_x1 CrawAddr : 463390a4 / KindOfCraw : 0
so DEFAULT_RAW_BUFFER on 500D would be MEM(MEM(0x15CB0) + 0x328) = MEM(MEM(0x15CA4 + 0xC) + 0x328).
7D: MEM(MEM(0x17BBC+0xC) + 0x338), not tested. (addresses are good, but they are only valid with lv_save_raw)
BTW - that "Debug Flag" from the 500D log is actually the LiveView RAW mode in Canon firmware (a feature they have used for debugging). That should explain why the x5/x10 modes in very old models are broken (pink previews, unusable x10 etc), or why the LV raw buffer on 1100D is reused for something else (as this camera has very little RAM).
Back to your question.
Pointers are memory locations; they are
not interchangeable with buffer sizes (even if the C compiler may accept this). The reason it might happened to work (sort of) is the large value of SRM_BUFFER_SIZE - it points somewhere
way above the DryOS core, so if it screws up things, it might do so in some non-obvious way (remember those obvious bugs from 5D3.134).
With shamem_read(0xC0F26008), this reads the address previously configured on EDMAC channel 0x10, by some existing code. Without CONFIG_EDMAC_RAW_SLURP, that's Canon code enabled by lv_save_raw; they have configured that channel with whatever buffer they have allocated for the LV raw image. The point of the new method is to bypass Canon code so we can have full control over it (such as, specify a different "raw type" or - in our case - a lower EDMAC transfer size for 10/12-bit), but since we are not going to call lv_save_raw, there will be no Canon code to allocate a raw buffer for us. So that won't work - you'll get some old value and the results are unpredictable.
Why do you want to change it? The only valid reason I can see would be to avoid the BUSY screen - in this case, just allocate as much as you need. Find the largest frame size you want to use (usually that's the raw resolution in 5x zoom) and allocate a buffer large enough for that (but not much larger). In this case, the memory backend will see no reason to use SRM buffers (which may print the BUSY message while they are allocated).
BTW, what's that -e doing there? That may indicate yet another bug in the Makefiles (a similar one was on Mac when generating module READMEs). This didn't help locating it:
grep -nr -- " -e" Mak* */Mak* */*/Mak*
P.S. 60D EvfState (compare to 7D's LVState):
