Thanks. Added in trunk r5937 with minor cosmetic changes. Autobuild disabled for the moment, but I think it can be turned on once you verify the trunk source works on your cam and the nrflag issue is addressed.
Overall, this looks very good for a first port. Please don't take the long post that follows as a flame, I'm just trying to flag potential issues while there's someone with camera to address them:
The patch was missing the loader directory. It's pretty much all boilerplate at this point, so I just copied the ixus145 files
In capt_seq_hdr.c
static long *nrflag = (long*)(0xa0e0)
is the same as the address in ixus145. Based on the addresses of other variables, this is quite unlikely to be correct (variables like zoom_busy at 0x6... moved, so a variable at 0xa... is unlikely to be the same between the two cams), which would result in corrupting memory if someone used this feature. So unless you've verified that dark frame override works, I suggest looking for an equivalent variable, or guessing an offset from the ixus145 and testing, but beware ixus145 could be wrong too.
Makefile has TODO comments on movie_rec.c, but still includes it in the source/object list. Since the hook isn't implemented (commented in boot.c), it shouldn't be linked.
Based on the camera generation, I would expect it to need different, more complicated quality override code (like ixus150) for video overrides to work, so I'd leave it out for now.
If video quality isn't implemented/working, the related define in platform_camera.h
#define CAM_VIDEO_QUALITY_ONLY 1
should be changed to
#undef CAM_VIDEO_CONTROL
In platform lib.c, vid_get_viewport_live_fb has a TODO on it, and based on other cams, the video case is probably incorrect. I'd suggest using a build with OPT_VIEWPORT_DEBUG=1 and turning on display misc values to determine the number of buffers used, both when recording video and not. (see
https://chdk.setepontos.com/index.php?topic=14022.msg143092#msg143092)
Additionally, the use of mode_get() should be switched to use camera_info.* like ixus140_elph130
vid_get_bitmap_active_palette should check for null in the fallback case too (like the current elph130 code), and load_chdk_palette should not modify the palette on null. (These are wrong in the ixus145 port too)
For the stuff above, you can submit a new patch based on the trunk, or I could provide diffs or builds to test.
In platform_camera.h:
TODO on CAM_CIRCLE_OF_CONFUSION. 5 matches the result from
http://www.dofmaster.com/digital_coc.htmlTODO on active area. You can determine the active area using the procedure on
https://app.assembla.com/spaces/chdkptp/wiki/DNG_ProcessingTODO on jpeg size: It matches the Canon specs, should be fine.
All the CAM_SD_OVER* are 1. Are these verified? If not, you can check using mftest as described on the testing page.
I undef'd CAM_USE_ZOOM_FOR_MF. That feature is only intended for cams with native MF, and is broken on all non-ancient cams. This is the only non-comment / whitespace change I made.
Finally, I used the ixus
157 dump from our archive
https://drive.google.com/drive/u/0/folders/0B08pqRtyrObjTy11Y003Sk1lYTQ (ixus157 dump + discussion
https://chdk.setepontos.com/index.php?topic=12543.msg124442#msg124442) to build, because the 155 one we have is incomplete. This is verified compatible based on stubs and firmware CRC values, and can be mentioned in the notes + wiki page.
If you want to post a dump from your actual ixus155, it would nice to have just in case there turns out to be some significant difference down the road.