The change you made in recv_ptp_data() is quite large (took out that while block), but I can't say I'm familiar with that code. One of the ifdefs has a typo.
Yeah, that loop was the "buffering" logic I mentioned earlier. It was a leftover that didn't really make sense: in practice size was almost always <= buffer_size (half of the largest free block at the start of the PTP operation), and there appears to be no reason to operate in smaller chunks.
Thanks for catching the typo, I hadn't got around to testing it on digic 6. Patch updated.
I've now tested on a540, d10, sx160, and elph180, sx710, g7x like
!m=require'extras/msgtest'
!m.test{size=1,sizeinc=1,count=10000,gc='step'}
!m.test{size=500,sizeinc=128,count=400,gc='step'}
The first tests single byte increments. The second covers a larger range including the problem (0x23f4 +n*512) values. It might fail on low memory cams trying to send a ~50k message.
I took a look at the ComMemMan routines. The first(?) two inits and uninits the communication memory, the following two look like an allocator and a de-allocator. But, as previously mentioned, we don't necessarily want to use memory from there due to corruption risk.
Agreed. I guess we could maybe use a similar approach to CHDK exmem and allocate an unused amount to cover the video buffers (if it allocates in a predictable way), or only use it in playback, but neither seems attractive for the amount of work.
We could also make a umalloc implementation that could use all memory available to CHDK, and use that on cameras thought to be affected (replacing mallocs in ptp code, if that's even possible).
It's not that bad, but in the case of script messages, the memory is passed on and freed elsewhere. When I was testing, I made a version of memmgmt.c free() that detected uncached memory and called ufree on it. Any processing on the allocated buffer would be slow, but it's likely insignificant compared to the transfer. Script is compiled directly from the buffer. Messages are copied into Lua strings.
uses of recv_ptp_data
flush_recv_ptp_data
mallocs/frees buffer. Discards results.
PTP_CHDK_SetMemory
Target address passed direct. Not implemented in chdkptp
PTP_CHDK_CallFunction
mallocs and frees a typically very small buffer for function arguments
PTP_CHDK_TempData
mallocs buffer for filename used with subsequent camera->pc transfer. Freed by additional TempData operation
PTP_CHDK_UploadFile
mallocs up to half largest free block, transfers in chunks, frees when complete. Currently uses fopen, but could be switched to open/write which also want uncached memory.
PTP_CHDK_ExecuteScript
mallocs and frees buffer with script source. Lua is compiled from the buffer, so performance impact could be relatively significant. Potentially large.
PTP_CHDK_WriteScriptMsg
mallocs message, which includes header and content. Freed by lua when de-queued. Potentially large