Cameras with DryOS >= r50 have a more complicated filewritetask. This means that a protocol change and a change of the hooking method will be needed to successfully retrieve those files.
In
changeset 2226 I have checked in support code for this. It hasn't been tested on a DryOS r50 camera yet, so it may contain some errors.
Remote capture protocol:
I had to add (back) param3 as "position" value in PTP_CHDK_RemoteCaptureGetData. R50 and newer cameras will need it.
Some background info about the behaviour of new cameras:
The jpeg data is either completely present in memory when filewritetask is notified (similarly as in older cameras), or appears like this:
- first filewritetask invocation: file is opened, seek is performed to skip over the (future) exif data, first chunk of jpeg written, file left open
- second, third invocation: additional chunks (one per invocation) are written sequentially, file left open
- last invocation: seek to position 0, exif written, file closed
According to my observations, exif is placed into the same buffer as the second jpeg chunk. There is some delay between the availability of the big jpeg chunks, my code tries to wait when needed.
I have created a new #define in camera.h, with the name CAM_EXTENDED_FILEWRITETASK. As indicated by my comment, this could be substituted by a (not yet created) CAM_DRYOS_2_3_R50 define.
I'm considering to change the filewrite hook function to only require the pointer to the start of the task's data block as argument, and use #define'd offsets to the values of interest.
edit:
The r50 code is not working as expected, needs to be fixed. However, the camera-specific part is OK.
edit2:
After analyzing the code (and the debug data provided by nafraf) I concluded that there must be some multitasking issue between the ptp and filewrite tasks. If that's the case,
changeset 2243 should fix it.
