As far as I know, it's currently not possible to do remote capture (via ptp) without SD-card wear. There may be eventproc's for that, but I haven't tried to play with those.
The following is the result of a partial investigation of the picture recording process. The result was not tested much, but I think it should work.
Investigated and tested on the A420,
VxWorks.
There are several tasks involved in the shooting process. As my current goal was to catch the creation and writing of the jpeg, I have narrowed down the search to the following tasks:
- CaptSeqTask
- DvlpSeqTask (which stands for DevelopSequenceTask)
- FileWriteTask
- FileScheduleTask
I already knew that FileScheduleTask and FileWriteTask is absent when movie record is in progress, so I suspected that they are related to the writing of jpg's. This turned out to be true.
The jpeg creation process goes like this:
- CaptSeqTask's main loop enters case 1 (shooting). This routine is already patched to include our RAW, remote and NR-prevention hooks. There's a subroutine here which posts a message (1) to DvlpSeqTask (not fully investigated, it seems to pick up some procase values), and later (near its end) another subroutine, which posts a different message (0) to that task. The latter message causes the engine to start processing.
- DvlpSeqTask is responsible for the RAW development process. Once the engine has finished, the task sets an eventflag which is owned by FileWriteTask.
A lot of other things also happen, but I'm happy I got this figured out.- FileWriteTask and FileScheduleTask play together. The latter is a mess for me, fortunately FileWriteTask's code is simpler. What it does is roughly the following:
- The appearance of the above mentioned eventflag (1) wakes up the task.
- Now there's data in the task's data area (I don't know where that comes from, it's the filename, pointers to the exif, the main jpeg and other stuff)
- The task has a main routine with a case structure.
- case 0: creates and opens the file for writing
- case 1,2,3: writes into the file then closes it
- After it has finished, the (1) flag is cleared
After a lot of trial and error (brute force methods like preventing the task to process don't work because of the mess of eventflags, semaphores, etc), I found a simple method:
I changed the filename to "/null" which is the /dev/null of VxWorks. With this, open() returns a valid file handle, and nothing is written to the card (and it's also fast).
As the file name is checked several times for correctness - it has to start with "A/" - I had to dig down to open(), and change its first parameter. Fortunately, it's only a BL away.
This place looks like a good candidate for a jpeg hook - for ptp.
With this method, the file counter is incremented as usual.
Now the problem: does anybody know whether there is a /dev/null for DryOS? If not (or not found), the solution might involve bigger changes. Or it has to be done differently...
Looked at FileWriteTask of a DryOS camera (SX100), it's roughly similar (it has more states).
