Quote from: lapser on 28 / December / 2012, 20:01:11This shoot_full_only fix is separate from the shot metering and time lapse stuff. I think it could be added to the trunk soon, without breaking anything. The key functions should manipulate key state, period. As I explained in my earlier post, I am extremely unlikely to accept a patch that makes them do something else or change their behavior based on shooting state.
This shoot_full_only fix is separate from the shot metering and time lapse stuff. I think it could be added to the trunk soon, without breaking anything.
In several posts you have mentioned "the" shoot bug, but I'm not clear what this actually refers to. If you can describe the specific bug you are referring to (or link to previous reports) that would be helpful.
The key functions already do more than that. press and release first press or release the key (manipulate the key state), and THEN wait a camera specific delay time. click does both keys, with a delay in between and after.
Someone reported a problem where shoot() worked for a few hundred shots, and then hung the camera. Everyone seems to suggest avoiding shoot() for this reason.
This is not true of your change. Your change adds a non-deterministic delay that may vary in camera and setting dependent ways. As I said earlier, movie mode not the only place this matters. Some modes on some cameras will simply refuse to shoot if focus fails. In this case, it appears your shoot_full_only will simply wait indefinitely.
A far more flexible approach would be to give script access to the shutter open time, and let script authors use whatever logic with it they want. You would have to deal with the case of cameras which don't get that value. If the implicit 10ms (+key delays) overhead of action stack actions is too high, that should be addressed. This could address the sleep bug I mentioned earlier too.
In any case, a bug that is so ill specified and non-reproducible should not be used as an argument for making specific changes.
So why not extend the raw_savefile code to allow it to call a defined function in your script each time a raw image buffer is ready. Lua includes a mechanism for calling script functions from C code (this is used to call the 'restore' function when a script is interrupted).
Please don't be offending by the satire. I'm just trying to make it as clear as possible how I interpret what you're saying; that is, acknowledge what you have communicated to me, not just what you have said.
1. The key functions are not just a manipulation of the key state. Their fundamental purpose is to communicate with a different thread (task), so that thread will start a new action.
The key functions are currently implemented unreliably.
After changing the key state, they wait a fixed amount of time hoping that the other thread will notice the new state.
My modifications are a simple way to get an acknowledgement that the other thread has received the message. I have tested them, and they have worked every time.
When my test scripts do click("shoot_full_only"), it works every time, period. You can't argue with success (maybe I should re-examine this belief?)
3. Using script functions to wait for an acknowledgement from a different thread has real problems. Scripts are not reliable for real time operations. They are slow, and can be interrupted at any time, for several seconds even.
The camera could finish the shot and return to its resting state without the script ever noticing.
More importantly, it is important to hold the shoot_full or shoot_full_only keys DOWN until receiving the acknowledgement. The only way to do this for the "click" function is to wait for acknowledgement before returning. It can't be done in Lua, so "click" will never work. My changes make "click" work reliably (tested and proven).
CHDK scripts run in the keyboard thread. The keyboard thread also reads the key presses generated by the key functions. The script has to be interrupted repeatedly for the key presses to be recognized. You're also asking the script to monitor the state of the camera to look for an acknowledgement that a key action has been received, but which won't be received unless the script is interrupted often enough. The complexity and inefficiency of this is mind boggling.
What's more, I've implemented this script-based scheme in my time lapse modifications and it doesn't work correctly. The script randomly delays pictures for seconds at a time before it finally recognizes the signal from my C code, and signals back that it's OK to shoot the next picture. If you try to shoot faster than about 2 shots per second, the shots are no longer regular. Attempts at 1 shot per second vary from 1 to 3 seconds between shots.
QuoteThe key functions are currently implemented unreliably.Only if you think they should do something more than approximate a user pressing physical buttons.