changelog of trunk including comments / devtalk

[reyalp]

lua_error will prevent that from actually happening, but I'll fix the warning.

BTW, the 710 checking fixes a fairly serious (and seriously stupid!) bug I introduced in md back in 684. Not quite sure how I missed that in testing

[reyalp]

#720
* preliminary 12bpp support (my sd990 code + ewavr sx10 code).
  Curves are disabled for 12 bpp
  sd990 and sx10 sections included in camera.h as examples, the rest of the code isn't.
* Digic IV memory layout support with CAM_UNCACHED_BIT
* make g9 stubs_entry.S match what is generated from SVN

This will hopefully help other people working on 12bpp and digic IV cams.

[PhyrePhoX]

hey guys, planning to committ a huge patch in the next days.
it is not finished yet, here is first version attached.
99% of the changes have been coded by PlasmaHH (an irc guy )

basically it fixes a lot of warnings (and enables warning options for gcc), adds long time exposure for ixus950 and also introduces a better handling of the long exposure time thingy - also it enables you to set longer times than 64 seconds (so you dont have to use the factor stuff).

however, i am yet unclear about the compiler options.

a) somehow the hostccflag "-Wextra" isnt accepted in gcc 4.3.3, BUT it can be used in the "normal cflags"
b) enabling things like "-Wextra" gives a tremendous amount of warnings when you compile stuff. some warnings can be ignored, others should be corrected.
solution to b) would be: add a flag to buildconf.inc (that enables "debugging") and also squash the warnings by fixing the code

i invite everybody who know how to use a patch to test and comment the diff.



p.s. Used whims chdk shell for first time in months, boy, this thing is great

[reyalp]

using unsigned for things that are really unsigned is nice.

Adding casts for long is silly. Since long and int refer to the same thing, it would be better to just not use long anywhere. If CHDK ever gets ported to a platform where sizeof(long) != sizeof(int) whoever does it will be in a world of hurt anyway, and casts won't help them.

I'd prefer to see the functionality changes in a separate commit from the warning cleanup.

Also

Code: [Select]

-const char* img_prefixes[NUM_IMG_PREFIXES]={ "IMG_", "CRW_", "SND_" /*, "AUT_", "ETC_","SDR_", "MVI_", "MRK_"*/};
-const char* img_exts[NUM_IMG_EXTS]={ ".JPG", ".CRW", ".CR2", ".THM", ".WAV"/*, ".AVI", ".MRK"*/};
+const char* img_prefixes[NUM_IMG_PREFIXES]={ "IMG_", "CRW_", "SND_", "crw_" , "AUT_", "ETC_","SDR_", "MVI_", "MRK_"};
+const char* img_exts[NUM_IMG_EXTS]={ ".JPG", ".CRW", ".CR2", ".THM", ".WAV", ".AVI", ".MRK", ".DNG" };


Particularly CRW_ and crw_ are almost certainly wrong, and dng doesn't belong there either. I don't remember if I left the others commented for a particular reason.

[PhyrePhoX]

checked in the new buildconf.inc flag "OPT_WARNINGS" (#743). if set, compiler will throw out warnings by the dozen.
somehow i couldnt manage to set the hostcc flags for gcc 4, thats why i commented them out. weird.

attached example errors.txt for s3is, gcc 3.4 (created with chdk shell)

[whim]

i couldnt manage to set the hostcc flags for gcc 4

Can't believe i missed this thread's posts - especially because i use OPT_WARNINGS a lot 

so thanks, and about the 'hostflags': IIRC that's to configure the win32 compiler, and that's still gcc 3.2.3 - so you can't use gcc 4+ options;
could that be the problem ?

sorry for late reaction,

wim

[PhyrePhoX]

ah yes, thats exactly the problem. the 3.2.3 doesnt know about the flags that were introduced with v4, so i guess i have to do something differently there. thanks

[ewavr]

Here is my old patch "AF after optical zoom in video" (without lang strings). It seems that it works on a710,    but I can not guarantee anything (   I do not remember how it works)...

[vit40]

Ewavr, I noticed a small bug regarding refocusing after zooming in video mode

I made a short script to switch to MF and preset focusing distance, before starting recording a movie clip (usefull in dark places, where the camera struggles to do AF)

On A620 everything is fine

On A650, if I zoom during recording movie clip AFTER USING THAT SCRIPT, it doesn't set focus correctly after zooming, but it refocus to about 0.5m. But, if I use my script, then change a focusing distance slightly with left or right key, then start recording a movie, everything is fine again

----

EDIT: The same thing happens even if I execute this script and use zoom right after that, even without starting recording a movie or something - A650 refocuses to wrong distance after using zoom rocker. Looks like a bug in set_focus command on this model

script looks like this:

....
click "down"
click "up"
sleep 500
set_focus a
sleep 500
exit_alt

[reyalp]

I've committed extra long exposure support for a560 (svn 777) and a590 (svn 778).

I have not had any test reports for a590 100e. However, it is very similar to 101b (only a couple functions at different offsets), so hopefully it's OK.  If any 100e users can confirm that build 778 or later work, that would be appreciated!

[reyalp]

Changeset 794:
update dancingbits to support multiple multiple diskboot formats.
NEED_ENCODED_DISKBOOT in platform/<camera>/sub/<firm>/makefile.inc must now be a number that specifies the encoding version. Existing ports which set NEED_ENCODED_DISKBOOT must use 1. Cameras like the SX200 use 2.
Discussion http://chdk.setepontos.com/index.php/topic,4095.0.html

[reyalp]

changeset 812

Correct canon_menu_active, canon_shoot_menu_active, recreview_hold and zoom_status for sd600. Only version 100a is tested (thanks to cowbud on irc) but 100d is very similar.

[reyalp]

Potentially build breaking checkin:
Changeset 817.

I've added ixus200/sd980 100C as sig_ref_dryos_3. For your build to work, you need to place this dump http://chdk.setepontos.com/index.php/topic,288.msg39913.html#msg39913 in your tools directory as sig_ref_dryos_3.bin

This ixus200 port is not in SVN yet, but existing sigs appear to work quite poorly on this and many other newer cameras. This is probably related to DryOS version 2.3 release 39.

I've also corrected the sig for SetPropertyCase in sig_ref_dryos_1.txt This previously pointed at a what was just a B instruction to the real function. Since gensig/finsig aren't smart enough to to follow branches, this made it a bad reference for all but the most similar cameras.

Where the new sigs match stuff that was previously found manually before, I've removed them or commented them out of the cameras stubs_entry_2.S. This probably isn't really needed, but I had to go through and check everything anyway.

Finally, I noticed that finsigs sorting algorithm compares the number of successful matches. This means that a longer sig can match "better" than a shorter one, even if the shorter one is 100% and the long one has a substantial number of misses. Given that gensig stops on RET, even sigs that don't have an explicit length can have variable length. I haven't changed this, since it would probably break all kinds of working ports.

[RaduP]

BTW, some functions still need to be found.
Here are some functions I am still missing, if someone wants to hunt for them:
//implemented in the wrappers, in C
//NHSTUB(strrchr, 0xDEADC0DE)
//NHSTUB(strncpy, 0xDEADC0DE)
//NHSTUB(strcat, 0xDEADC0DE)
//NHSTUB(rename, 0xDEADC0DE)
//NHSTUB(RenameFile_Fut, 0xDEADC0DE)
//NHSTUB(stat, 0xFF835560)
NHSTUB(SetFileTimeStamp, 0xFF810B04)//nullsubed

I guess people can use my implementation of those functions, but my implementation of stat() so far only puts the file size, and now I need to handle the attributes (directories do not show properly in the file menus because of that).

[reyalp]

Added rawconvert.c to tools. This tool is intended to help porters verify their raw buffers and active area settings, by making 1:1 conversions of CHDK raw to easily viewable formats. It isn't built by default since it isn't normally needed. It can also be used to convert 10 to 12 bit or vice versa.

Unlike dcraw, it does absolutely no interpolation, cropping, beautifying, folding, spindling or mutilating.

Usage:
rawconvert -<op> -w=<width> -h=<height> [-noshift] <infile> <outfile>
where <op> is XtoY with X and Y being the source and destination BPP
by default
 converting to lower BPP discards the lower bits of the input value.
 converting to higher BPP shifts the input so the a max value input pixel will be a max value output pixel
if -noshift is specified
 converting to a lower BPP discards the upper bits
 converting to a higher BPP leaves the values unchanged
NOTE:
 Host is assumed to be little endian!
 This is a debugging tool not an imaging tool.