CAM_CAN_SD_OVERRIDE seems like it should just become ( CAM_SD_OVER_IN_AF || CAM_SD_OVER_IN_AFL || CAM_SD_OVER_IN_MF)
It's a holdover from the current code. And if you grep it, you find that it's perhaps most useful as #undef CAM_CAN_SD_OVERRIDE for cams that do not support SD override at all. Replacing it with the logical OR of the other three conditions looks kind of messy there.
I am not fond of defines that can be setup to have contradictory values, and I am even less fond of setting the defaults to be that way...
What does it mean to define CAM_CAN_SD_OVERRIDE and not define any CAM_SD_OVER_IN*?
What does it mean to undefine CAM_CAN_SD_OVERRIDE but define some of the CAM_SD_OVER_IN*?
If different parts of the code check different combinations, this will continue the kind of mess we have now.
If you want to keep it to avoid dealing with the things that check #ifdef CAM_CAN_SD_OVERRIDE right now (very reasonable), make it conditionally confined in camera.h *below* the platform include,
#if defined(CAM_SD_OVER_IN_AF) || defined(CAM_SD_OVER_IN_AF) || (CAM_SD_OVER_IN_MF)
#define CAM_CAN_SD_OVERRIDE
#else
#undef CAM_CAN_SD_OVERRIDE
#endif
You could set up #error checks for contradictory values instead, but I think this is worse, because it still puts redundant values in platform_camera.h
As we discussed on IRC, we may want a special define for untested / unknown cams.
IIRC, that discussion was in the context of adding something to UI to indicate that the camera needs testing / SD override is disabled. Something to encourage the user to help out with the testing by posting results to the forum so that his/her camera can be properly enabled.
Yes, what I was getting at is if you are going to go through all the platform_camera.h files, and already have a list, it might be worth defining it now.
edit:
And thanks again for working on this. I may be a picky SOB, but I really, really appreciate all the work you have put into this