When testing nafraf's patch to remove the KEY_PRINT to KEY_PLAYBACK alias on the SX260 and D20, I discovered that the test build started with no valid <ALT> key defined. Thus, I couldn't enter <ALT> mode. Deleting the .cfg files didn't help, since the default <ALT> key is still KEY_PRINT. The only way I could get it to work was to set the <ALT> key to "video" on the old build first.
The solution is to check the <ALT> key in conf.c on startup. It looks like the best place to do this is in clear_values(). This is what I added at the end of clear_values()
//make sure <ALT> key is a valid option
#if defined(CAM_ALT_BUTTON_OPTIONS)
int keys[] = CAM_ALT_BUTTON_OPTIONS;
int i=0;
while((i < sizeof(keys)/sizeof(keys[0]))&&(conf.alt_mode_button != keys[i]))i++;
if(i == sizeof(keys)/sizeof(keys[0]))
{
conf.alt_mode_button=keys[0];
kbd_set_alt_mode_key_mask(conf.alt_mode_button);
}
#endif
"sizeof(keys)/sizeof(keys[0])" is the crazy way you find the number of elements in an array in C. I assume the compiler evaluates it to a constant. Is there a better way to do this?
Testing "i" first in the "while" statement should ensure that the "keys[]" array index stays in bounds. Doing it this way saves adding a "break" and second "if" test. Every byte and microsecond counts!
If CAM_ALT_BUTTON_OPTIONS isn't defined, then it looks like you're stuck with KEY_PRINT as the <ALT> key. All of my cameras have the alt button options, so I'm not sure how to deal with it, or if it needs to be dealt with.
I tested nafraf's patch (attached) on the d20 and sx260, and both cameras were left without an <ALT> key. Both worked normally, using KEY_PLAYBACK as the <ALT> key, with the above changes. I'll attach nafraf's patch, and a patch file for my changes.
