Thanks for that, I wanted to use Nparam for an additional check, not sure whether it will still be needed when the protocol becomes final.
Yeah, I'm not sure varying the number of return parameters is a great idea, but it seemed like something the PTP code should provide.
I'm considering the simplification of filewrite_main_hook()'s arguments. If the FileWriteTask data block is mapped to a camera-specific structure, only a pointer would be needed as a single argument. It would also make the assembly (glue) part simpler and the code less ugly.
Reducing the amount of glue sounds good.
A question about fwt_open etc. Is there a reason these can't be C code? Since they are called as a replacement for a normal function call, it seems like you should just be able to make normal C function with the appropriate number of parameters. The registers will be preserved or not according to the ARM ABI, just like the replaced call.
eg:
int fwt_open(char *name,int flags,int mode) {
if(ignore_current_write) {
current_write_ignored = ignore_current_write;
return 0xff;
}
return _Open(name,flags,mode);
}
not promising I understood the current asm correctly... which is a good reason to do it in C
Some more general thoughts, (thinking out loud, not saying anything has to change)
YUV:
Is this really worth the effort? What situations would the jpeg not be good enough, but the raw too much much? I know it is relatively easy to get, but it's still several functions that have to be added to each lib.c and then it isn't available in all shooting modes. I guess the YUV may be nice because some third party libraries would already be able to deal with it directly, with even less overhead than jpeg. I'm not against including it, just wondering if there is a specific use that makes it important.
DNG:
For applications that want to maximize speed, it would be useful to be able to get the DNG header without having the DNG data bytes reversed. This could also provide a way for dealing with reduced cropped images. You would get the full header (with the dimensions set normally) and the client application could reverse the bytes and pad it to the desired size, or adjust the dng dimensions.
Getting a fully ready to use DNG is still convenient, so I think that capability should be preserved even if we make non-reversed available.
I'm not sure I like relying the chdk UI DNG setting to decide if raw returns plain raw or DNG, especially since you have to use set_config_value / get_config_value to modify it from script. It seems like the client should explicitly ask for what it wants.
