Hi,
is anybody from developers able (and interested) in adding A460 source code into trunk?
ixus850: Added into trunk #312.
@3DBruceHi GrAnd,
Your version needs more time to adapt to the latest trunk...
IXUS 55 (SD450): Added into trunk #313.Thanks GrAnd!
#if !defined(CAMERA_a530)
physw_status[USB_REG] = kbd_new_state[USB_REG] & ~USB_MASK;
#endif
Here you go grand. I added the 100d sub for the ixus55_sd450.
int get_usb_power(int edge)
{
// int x;
/*if (edge)*/ return remote_key;
// x = usb_power;
// usb_power = 0;
// return x;
}
The effect is to make the function return 0 (if no power has been applied) or 1 (if it has), rather than returning the time (in 10ms unit) that power has been applied.#!/bin/bashinstead of#!/bin/shGNU bash, version 2.04.0(1)-release-(i686-pc-msys)
will change this in the branch. i wonder why this didnt happen (or got reported) before?
/*
* make an image bootable for latest cams
* (c) 2008 chr
*
* GPL v3+
*
* Why make things easy if complex sells better?
*/
#include <stdio.h>
#include <stddef.h>
#include <string.h>
#include <stdlib.h>
#include <errno.h>
unsigned char _chr_[8] = { 4,6,1,0,7,2,5,3 };
unsigned char dance(unsigned char allbest, int fudgey);
#define GHOST 0x400
#define BARNEY 0x00
int main(int whim, char **reyalp) {
FILE *jeff666, *jucifer;
unsigned char *ewavr;
if (whim != 3) {
printf("usage: <in file> <out file>\n");
exit(1);
}
jeff666 = fopen(reyalp[1], "r");
if (jeff666 == NULL) {
printf("Error open %s: %s\n", reyalp[1], strerror(errno));
exit(1);
}
jucifer = fopen(reyalp[2], "w+");
if (jucifer == NULL) {
printf("Error open %s: %s\n", reyalp[2], strerror(errno));
exit(1);
}
fputc(BARNEY, jucifer);
ewavr = malloc(GHOST);
int grand, hacki = 0;
int phox = fread(ewavr, 1, GHOST, jeff666);
while (phox > 0) {
for (grand=0; grand<phox; grand+=8) {
unsigned char fe50[8];
for (hacki=0; hacki<8; hacki++) {
// fe50[hacki] = dancingbits(ewavr[grand + _chr_[hacki]], grand+hacki);
fe50[_chr_[hacki]] = dance(ewavr[grand + hacki], grand+hacki);
}
fwrite(fe50, 1, 8, jucifer);
}
phox = fread(ewavr, 1, GHOST, jeff666);
}
fclose(jeff666);
fclose(jucifer);
free(ewavr);
exit(0);
}
unsigned char dance(unsigned char allbest, int fudgey) {
if ((fudgey % 3) !=0)
return allbest ^ 0xff;
if ((fudgey & 1) == 0)
return allbest ^ 0xa0;
return (allbest >> 4) | (allbest << 4);
}
0001-found-O_APPEND-for-dryos.patch
0002-sd1100-support-ixus80-82-fw-100c-101a.patch
0003-mh-these-files-are-autogenerated.patch
0004-tool-for-encoding-diskboot.bin-images.patch
0005-hack-gensigs.sh-we-have-different-rom-start-adresse.patch
0006-add-signatures-from-sd1100.patch
0007-rerun-finsig.patch
0008-while-hacking-it-happend-that-.cfg-got-corrupt-and.patch
0009-hacking-debug-osd-panel.patch
0010-new-feature-save-romlog.txt-in-debug-menu.patch
0011-compile-fix-make-OPT_DEBUGGING-global.patch
--- platform/ixus850_sd800/shooting.c (revision 661)
+++ platform/ixus850_sd800/shooting.c (working copy)
@@ -65,7 +65,7 @@
{ 29, 928, "1/800", 1250 },
{ 30, 960, "1/1000", 1000 },
{ 31, 992, "1/1250", 800 },
- { 32, 1008, "1/1500", 667 },
+ { 32, 1021, "1/1600", 625 }, // ROM:FF9B5A9C 0x3FD (word) = 1021
};
ROM:FF9B5A68 a11250 DCB "1/1250",0
ROM:FF9B5A6F DCB 0
ROM:FF9B5A70 a11250_1 DCB "1250",0
ROM:FF9B5A75 DCB 0
ROM:FF9B5A76 DCB 0
ROM:FF9B5A77 DCB 0
ROM:FF9B5A78 DCW 1
ROM:FF9B5A7A DCW 0x4E2
ROM:FF9B5A7C DCW 0x3E0 // 992
ROM:FF9B5A7E DCW 0x3E0
ROM:FF9B5A80 DCW 0x3EE
ROM:FF9B5A82 DCW 0x8A
ROM:FF9B5A84 DCW 0x8B
ROM:FF9B5A86 DCW 0x149
ROM:FF9B5A88 a11600 DCB "1/1600",0 // <--- 1/1600 is last TV
ROM:FF9B5A8F DCB 0
ROM:FF9B5A90 a11600_1 DCB "1600",0
ROM:FF9B5A95 DCB 0
ROM:FF9B5A96 DCB 0
ROM:FF9B5A97 DCB 0
ROM:FF9B5A98 DCW 1
ROM:FF9B5A9A DCW 0x640
ROM:FF9B5A9C DCW 0x3FD // <--- 1021
ROM:FF9B5A9E DCW 0x3FD
ROM:FF9B5AA0 DCW 0x2710
ROM:FF9B5AA2 DCW 0x8D
ROM:FF9B5AA4 DCW 0x8D
ROM:FF9B5AA6 DCW 0x155if possible, please add this inital port for the G11 into trunk.Done, changeset #871 (http://tools.assembla.com/chdk/changeset/871/)
please update propcase.lua with the attached one (added proset 3).Done, changeset #874 (http://tools.assembla.com/chdk/changeset/874/)
Scripts wont work correctly without this on the G11.
ixus 750 1.00H sources: http://kotisivu.dnainternet.net/sakrkorh/canon/ixus750_sd550.zip (http://kotisivu.dnainternet.net/sakrkorh/canon/ixus750_sd550.zip)Added to the trunk in changeset #877 (http://tools.assembla.com/chdk/changeset/877).
here are the sources for the G11 1.00L firmware support. After a week of testing, there are no major bugs reported, so i thinks its ready for integration. ;)Done, changeset #882 (http://tools.assembla.com/chdk/changeset/882)
Hi reyalp,Done, changeset 889 (http://tools.assembla.com/chdk/changeset/889)
i have here a update for the S90 configuration in camera.h.
I forgot to undefine the CAM_HAS_ERASE_BUTTON feature for the S90,
so "User Menu editing" is currently not working properly. Please integrate the attached
update of camera.h to the trunk.
Please add the SX20 102b port to headAdded to the CHDK trunk, changeset #900 (http://tools.assembla.com/chdk/changeset/900).
here is a .zip file with everything related to ixus85/SD770IS port, firmware version 100a. It compiles against trunk version 898.Added to the CHDK trunk, changeset #901 (http://tools.assembla.com/chdk/changeset/901)/ #902 (http://tools.assembla.com/chdk/changeset/902).
* I have two patches prepared, both created against trunk918. The first one renames the "examples" folder of scripts to "EXAM". This solves the problem of the SX20 (and some other cameras too) not being able to load scripts in that folder.Done, changeset #919 (http://tools.assembla.com/chdk/changeset/919/).
* The second patch is less trivial and adds support for SX20 1.02d. Please include both in the trunk.
ultimA - pls. check the SX20 1.02d port from the SVN server - i had to adapt the diff file manually to fit the SVN tree structure, i hope i got it all right...
Could this be added to include/camera.h in the A710is section:Done with CHDK changeset #931 (http://tools.assembla.com/chdk/changeset/931/), thx for testing !
#define CAM_REAR_CURTAIN 1
Here is a set of changes: http://drop.io/ultimaa/asset/for-chdk-931-patch (http://drop.io/ultimaa/asset/for-chdk-931-patch)Done in changeset #931 (http://tools.assembla.com/chdk/changeset/931/) - used your "short log" for SVN comment this time :D
A tiny patch for the venerable A710is.
#define CAM_REAR_CURTAIN 1
But why, A710 has native rear curtain support.
In case you hadn't done this yet, I just regression-tested with GCC 4.4.0 and patched 953 still produces
exactly the same errors as the unpatched 953 :)
Oops, sorry - warnings, not errors for ixus100_sd780 ...
Some small changes I'm proposing to trunk can be found at http://drop.io/hidden/jlqkjtgpqd29rhy/asset/cGF0Y2g5NTMtZGlmZi0y (http://drop.io/hidden/jlqkjtgpqd29rhy/asset/cGF0Y2g5NTMtZGlmZi0y)
Changelog:
- Fix: Make the A2000, G11 and ixus100_sd780 ports compatible with GCC 4.5. Apparently GCC 4.4 was too forgiving and still built the code, but GCC 4.5.1 errored out on them. This patch fixes the ASM so that these cams can be built successfully. The changes were not actually tested, but the fixes are trivial. As a result, all stable ports can be built using GCC 4.5.1 now. Credit also goes to whim who noticed these cams failing to build and he also suggested the first set of fixes.
- Shut up some (not all) warnings from ixus100_sd780, ixus40_sd300, ixus65_sd630, s5is, ixus60_sd600
- Fix: Make edge overlay respect OPT_EDGEOVERLAY. Previously, generated binary size did not get significantly smaller even when OPT_EDGEOVERLAY was undefined, because undefining it only resulted in the overlay being excluded from the menu, but still being built. Excluding edge overlay now saves appr. 3Kbytes.
- Fix: Edge overlay erroneously depended on OPT_DEBUGGING. Builds failed when OPT_DEBUGGING was not defined previously.
I refreshed the patch from my 04.okt. post. It fixes all the warnings for the ixus100, and also fixes some other warnings. Some are still left, because I don't have these cameras, so I only took on the trivial fixes as I have no possibility to test. Many of the remaining warnings would have needed me to dive into firmware disassembly. Changes have been compile-tested on GCC 4.4 and 4.5.1.Thx ultimA ! ... added to the trunk, changeset #955 (http://tools.assembla.com/chdk/changeset/955/).
BL 0xFFC0BD98
BL 0xFFC0BB50
This is wrong. It does NOT jump to the given address, because B and BL only take 24 bit PC relative offsets. It will crash. The "correction"BL =0xFFC0BD98
BL =0xFFC0BB50
Is also wrong. In this case, it doesn't matter much because it's an assert anyway.First time I've done this so I hope I haven't made too much of a mess :)Quite the opposite :D
stubs_entry_2.S:2:29: fatal error: stubs_entry_ida.S: No such file or directory
compilation terminated.
C:\CHDK\gcc451-pmmx\bin\gmake.exe[4]: *** [stubs_entry_2.o] Error 1
C:\CHDK\gcc451-pmmx\bin\gmake.exe[3]: *** [all-recursive] Error 1
C:\CHDK\gcc451-pmmx\bin\gmake.exe[2]: *** [all-recursive] Error 1
C:\CHDK\gcc451-pmmx\bin\gmake.exe[1]: *** [all-recursive] Error 1
gmake: *** [all-recursive] Error 1
Hi phil,I usually just replace these names sub_**** when making the asm.
the eventproc_export_* functions are missing.
CHDKLover
gui.o: In function `gui_menuproc_swap_patitons':
gui.c:(.text+0xf8a): undefined reference to `get_part_count'
collect2: ld returned 1 exit status
???Added changeset 1008 (http://tools.assembla.com/chdk/changeset/1008/trunk)
Note added to the autobuild yet, because I have to make sure the autobuild server has the FI2 keys needed for these cams.
I have some comments on the code, I'll put in the sx30 thread
edit:
broke the build, a610Code: [Select]gui.o: In function `gui_menuproc_swap_patitons':???
gui.c:(.text+0xf8a): undefined reference to `get_part_count'
collect2: ld returned 1 exit status
edit:
Should be fixed in 1010, vx cams with multipartition were broken.
Thanks for that, sorry about breaking the VX stuff.No problem. I actually tried a vx camera before commiting, but it wasn't one with multipartition...
I've sent you the FI2 keys in a personal message.I have them already, I just need to make sure the auto build server has them.
Attached is a patch to add firmware 1.00e for the G12.Added, changeset 1019 (http://tools.assembla.com/chdk/changeset/1019)
# Misc (only used in ARM code so do not need stub)
DEF(_DebugAssert, 0xFF81EB78) // ok (comp 1.00c)
DEF(_PT_GetPropertyCaseString, 0xFF8954F0) // ok (comp 1.00c)
This compiles on some compilers (not the one on the autobuild server, apparently), but it doesn't work. I'm trying to use diff to create a patch file. Is there a command-line option for outputting relative directory paths like the patches I get from tools.assembla.com rather than the absolute paths that it generates?I'm not sure which 'diff' you are talking about (svn, gnu, other) but the person applying the patch can always use -p N to remove N leading path elements.
Below, I have posted a link to a complete version 1043 release with the changes for the S95. Perhaps someone more comfortable with the patching process could merge this into the trunk. Thanks.This is definitely NOT the preferred format for submissions :(
http://www.zshare.net/download/8529240391496f6b/ (http://www.zshare.net/download/8529240391496f6b/)
re conf.cThanks - now that I'm comfortable with the release mechanism, I'll use the time to clean-up the default settings for CCHDK.CFG a bit, remove my patch to conf.c and do some testing to assure that I can apply the patch file to a clean download and compile to get a working release. Let me know if you get some time sooner but otherwise assume I'm not ready to complete the release until I post an update ?
Yes, it would be better to have the default alt key defined some other way.
Submitted for approval and possible inclusion in the main trunk as a stable Beta version, the IXUS120 SD940.
Added in changeset 1056 (http://tools.assembla.com/chdk/changeset/1056). Thanks!Submitted for approval and possible inclusion in the main trunk as a stable Beta version, the IXUS120 SD940.
Updated with one Stub address fix : ixus120_sd940_for_trunk_1054.patch - 0.20MB (http://www.zshare.net/download/86216428157cb239/)
Below, I have posted a link to a complete version 1043 release with the changes for the S95. Perhaps someone more comfortable with the patching process could merge this into the trunk. Thanks.Aside from being a zip of an entire tree with a bunch of irrelevant white space changes and other random oddities, this doesn't even compile. and...
http://www.zshare.net/download/8529240391496f6b/ (http://www.zshare.net/download/8529240391496f6b/)
STUB(FF83457C)???
Minor patch for SX30 and G12 (patched against changeset 1064).
- fixed 'off by 1' mistake in get_focal_length (main.c) for both cameras.
- moved the call to 'capt_seq_hook_raw_here' to fix problem with exposures longer than 1 second not saving RAW/DNG file.
Patch file for trunk 1066 to correct vid_get_viewport_live_fb() in lib.c for IXUS120-SD940 firmware versions 1.02c & 1.03cAdded, changeset 1067 (http://tools.assembla.com/chdk/changeset/1067)
EDIT : implemented RefreshPhysicalScreen() correctly and removed the hacked version.
Added, changeset 1067 (http://tools.assembla.com/chdk/changeset/1067)Thanks - for adding to trunk and for prompting me to fix those things up in the first place.
Hi Phil.
I cannot find the thread where you discussed using DNG4PS2 calibration feature so I will just ask here.
An IXUS105 user presented me with a RAW file of the palette image.
The JPG compression artefacts are quite pronounced even at lowest ISO.
Anyway, I was eventually able to get all phases of the calibration to run but only seven areas from 22 had an error less than 10 %.
What was your experience of this ?
Another small update for G12 & SX30 (patched against changeset 1067).Added all except for the startup change in changeset 1068 (http://tools.assembla.com/chdk/changeset/1068)
- updates for exmem memory allocation to allow these cameras to exclude video buffer memory
- fixed set_zoom function to correctly wait until zoom is finished before returning
- fixed startup code for SX30 so that init_file_modules_task gets called correctly in all cases
- changed startup code for SX30 so that short on/off button press starts in record mode and long press starts in review mode (previously was the other way around).
Added all except for the startup change in changeset 1068 (http://tools.assembla.com/chdk/changeset/1068)Thanks reyalp,
I'm hesitant to add the startup change because
- It's inconsistent with all other cameras.
- Unexpectedly opening the lens is less friendly that unexpectedly not entering REC mode.
One idea I've been thinking about is to not embed the CHDK code into diskboot.bin; but instead load it from another file on the SD card (in the diskboot.bin code).This could be a good thing in many ways. However, the fact that you don't have the normal filesystem functions available will make it difficult. Even loading a small diskboot trashes enough of the OS that you really don't want to rely on anything working. Maybe you can boot enough of the canon OS the first time around, but the hooked tasks might give you trouble.
If the resulting diskboot.bin is small enough it would also mean that the original startup state value would not get trashed.Possible. Be aware that many cameras fail to boot an extremely small diskboot.
3) store the value somewhere else. This would have to beMaybe we can do this like Canon, and store this value in the FAT16 Boot Record's executable code (0x3E-0x1FD), which is already destroyed by BOOTDISK string.
- a specific disk sector
IXUS120-SD940 : Found a broken jump table and a small typo in Makefile. Probably not worth a trunk update on its own but would be nice to add into the next rolling update ?Added. I like small changes ;)
Just curious - are updates sync'd with the German version (CHDK-DE) in any way ? Or do they just get out of sync unless somebody who watches both forum's notices ?The CHDKDE developers are very good about picking up changes from the trunk. I'm not so good about picking up changes from CHDKDE :(
Update for G12 & SX30 (patched against changeset 1081).Thanks Phil. Added all but the motion detection optimization in changeset 1086 (http://tools.assembla.com/chdk/changeset/1086)
- Fixes startup crash (hopefully) by using different 'Open' firmware function (G12 & SX30).
- Added ND filter to G12 (from CHDK-DE).
- Faster motion detect by implementing vid_get_viewport_live_fb (G12 & SX30).
- Optimised & cleaned up motion_detect code.
- Fixed bracketing in continuous shooting mode when timer enabled.
Regards,
Phil.
Thanks Phil. Added all but the motion detection optimization in changeset 1086 (http://tools.assembla.com/chdk/changeset/1086)Thanks reyalp, I'll try and keep the patches smaller in future :)
edit:
added md stuff, changeset 1087 (http://tools.assembla.com/chdk/changeset/1087)
Fix USB_MASK for Ixus100 (SD780is) to match CHDK-DE and SDM.Added, http://tools.assembla.com/chdk/changeset/1102 (http://tools.assembla.com/chdk/changeset/1102)
http://chdk.setepontos.com/index.php?topic=6211 (http://chdk.setepontos.com/index.php?topic=6211)
Haven't forgotten about the one in your previous post, just haven't had time.
Latest G12 & SX30 patch (patched against changeset 1092).Added in changesets 1103-1106 (http://tools.assembla.com/chdk/log/trunk?action=stop_on_copy&rev=1106&stop_rev=&mode=stop_on_copy).
Hope this isn't too big,It's not size that bothers me. What I'd rather not have is a lot of unrelated changes in the same patch.
Added in changesets 1103-1106 (http://tools.assembla.com/chdk/log/trunk?action=stop_on_copy&rev=1106&stop_rev=&mode=stop_on_copy).Thanks again.
It's not size that bothers me. What I'd rather not have is a lot of unrelated changes in the same patch.Noted, will try and keep things in smaller related chunks (sometimes hard when multiple fixes are in the same files; but I'll do my best).
All added, changesets 1107-1109 (http://tools.assembla.com/chdk/log/trunk?action=stop_on_copy&rev=1109&stop_rev=&mode=stop_on_copy)Thank you, yes I've tested the video quality with this change on both cameras (at least for the firmware versions I have). Setting quality to 1 results in a very small file that has massive compression artifacts, and 99 gives a file that is about 2-3 times the size of the Canon default (although I'm hard pressed to see any visual difference).
Thanks for breaking up the patches.
I assume you've verified that the video quality is still set with the movie rec change ?
Patch to cleanup 'inline' file I/O functions from stdlib.h.Added, changeset 1119 (http://tools.assembla.com/chdk/changeset/1119)
Since inline optimisation is turned off this was causing multiple instances of each function to be generated.
Functions moved to platform/generic/wrappers.c since they were all simple wrappers for firmware code (except ftell which is in core/main.c).
Some more cleanup of the file I/O functions.Added, changeset 1122 (http://tools.assembla.com/chdk/changeset/1122). I removed fdelete completely, since it's the same as remove() remove now.
- mkdir, rename & remove now use the _Fut firmware functions (required for lua). FS_USE_FUT define no longer needed.
- All file I/O wrappers moved to platform/generic/wrappers.c. Direct calls to file I/O firmware code removed from raw.c.
- Re-org, and some cleanup of platform/generic/wrappers.c
Phil.
Small patch for G12 & SX30 - found the rand & srand functions in the firmware,Added changeset 1123 (http://tools.assembla.com/chdk/changeset/1123). If someone wants to look into adding these to the sig finder, that might help other cameras.
G12 & SX30 patch for loading CHDK into EXMEM allocated memory.Very nice. Added in changeset 1124 (http://tools.assembla.com/chdk/changeset/1124)
Could you explain the changes in suba.c ?
- fixed problem with 'Visual Settings -> Reset Files' menu option that would erase the symbol font file instead of resetting it back to the default value, causing symbols to vanish (gui.c, conf.c, conf.h).I may be mistaken, but I suspect the old behavior was intended to prevent memory being used by the symbols.
I may be mistaken, but I suspect the old behavior was intended to prevent memory being used by the symbols.
Of course, it would be better to just not load the symbols if they aren't enabled :)
Could be; but the default in a clean install is to load the icon_10.rbf file.Here's the history of that http://tools.assembla.com/chdk/changeset/696 (http://tools.assembla.com/chdk/changeset/696) and http://chdk.kernreaktor.org/mantis/view.php?id=184 (http://chdk.kernreaktor.org/mantis/view.php?id=184)
Here's the history of that http://tools.assembla.com/chdk/changeset/696 (http://tools.assembla.com/chdk/changeset/696) and http://chdk.kernreaktor.org/mantis/view.php?id=184 (http://chdk.kernreaktor.org/mantis/view.php?id=184)
Patch to cleanup font handling:Added (lib/font/rbf_font.c part only) changeset 1125 (http://tools.assembla.com/chdk/changeset/1125)
- allocate font memory in a single block instead of a small chunk for each character in the font (uses less memory and avoids fragmentation).
- cleaned up code in rbf_font.c for font loading (merged two similar functions).
- fixed problem with 'Visual Settings -> Reset Files' menu option that would erase the symbol font file instead of resetting it back to the default value, causing symbols to vanish (gui.c, conf.c, conf.h).
Initial beta for the SX130is.camera.h seems to be missing from this patch.
Original code from previous developers merged with current changeset 1124.
Testing done by achillies.
Seems pretty stable, and supports the exmem extension to get around the low memory problems on this camera.
Updates to IXUS120-SD940 for firmware 1.02C.Added, changeset 1127 (http://tools.assembla.com/chdk/changeset/1127)
Patch file attached. Some addresses in stubs_entry_2.S for fw 1.02c changed to match those used in 1.03b and 1.03c. Checked by waldo and waterwingz.
camera.h seems to be missing from this patch.
There were some bits missing from loader but I got them from the previous patch.camera.h seems to be missing from this patch.
Doh! Hopefully correct patch for sx130is attached to this post.
I've added this in changeset 1128 (http://tools.assembla.com/chdk/changeset/1128). I have not added it to the autobuild. Thoughts on the alleged camera damage in: http://chdk.setepontos.com/index.php?topic=5691.msg62825#msg62825 (http://chdk.setepontos.com/index.php?topic=5691.msg62825#msg62825) ?Thanks, not having an autobuild should not be a problem - anyone who is really keen can use CHDK-Shell to build it. It seems to work best with exmem enabled and chdk loaded into exmem (loading at the start of the Canon heap only leaves ~40K free memory, quid came up with another load address; but I'm not convinced it's a good place to load CHDK).
I don't believe CHDK would cause the sort of problem being reported, other than from the fact that the camera is probably being used more intensively by CHDK users (maybe having the camera re-focus frequently when using the motion-detect scripts contributes to quicker wear). Achillies, unfortunately, has just had this problem on his camera; but it occurred when he was turning the camera on and off (switching between CHDK and SDM partitions on his SD card).Yes, my guess is that this model just has a marginal lens mechanism. That said, I'd rather err on the side of caution when it involves other peoples $200+ toys.
Re-write of rbf_font.c to avoid cached/uncached memory issue (http://chdk.setepontos.com/index.php?topic=6261.0 (http://chdk.setepontos.com/index.php?topic=6261.0)).
Also cleaned up a few areas of the code and added some comments.
Phil.
--- trunk/lib/font/rbf_font.c (revision 1132)to:
+++ trunk/lib/font/rbf_font.c (working copy)
--- lib/font/rbf_font.c (revision 1132)and it
+++ lib/font/rbf_font.c (working copy)
Patch file attached to add support for version 1.03b firmware of the IXUS120-SD940.I'm kind of hoping that this gets in under the wire ahead of ths :
As discussed in this topic http://chdk.setepontos.com/index.php?topic=6267.0 (http://chdk.setepontos.com/index.php?topic=6267.0) here is the patch to split the current camera.h monster into separate files in the platform/camera directories.
Patch file attached to add support for version 1.03b firmware of the IXUS120-SD940.I'm kind of hoping that this gets in under the wire ahead of ths :As discussed in this topic http://chdk.setepontos.com/index.php?topic=6267.0 (http://chdk.setepontos.com/index.php?topic=6267.0) here is the patch to split the current camera.h monster into separate files in the platform/camera directories.
Updates to IXUS120-SD940 to add firmware 1.03BAdded changeset 1134 (http://tools.assembla.com/chdk/changeset/1134)
Patch file attached to add support for version 1.03b firmware of the IXUS120-SD940. Port created by rulen.
try changing (lines 3 & 4 in the patch):Just FWIW, I prefer patches in the second format, e.g. relative to the top of the trunk (or whatever branch it belongs to) not the top of the svn repo.Quote--- trunk/lib/font/rbf_font.c (revision 1132)to:
+++ trunk/lib/font/rbf_font.c (working copy)Quote--- lib/font/rbf_font.c (revision 1132)and it
+++ lib/font/rbf_font.c (working copy)should work (as in: a 'test only' mode patch succeeded)[edit: tested, works fine]
Repost of the earlier re-write of rbf_font.c to avoid cached/uncached memory issue (http://chdk.setepontos.com/index.php?topic=6261.0 (http://chdk.setepontos.com/index.php?topic=6261.0)).Added, changeset 1135 (http://tools.assembla.com/chdk/changeset/1135)
(Fixed problem with this change when starting camera with no config file, where no menu text displayed).
Also cleaned up a few areas of the code and added some comments.
This version also avoids copying the 'current_font' data into the rbf_font when there is no custom font being loaded. Instead it calls back to draw_char (in gui_draw.c) to display the 'current_font' characters.
Phil.
unless whim beats me to itnot likely (ETA = somewhere next week)
In file included from ../../include/stdlib.h:1:0,
from font_8x16.c:2:
../../include/camera.h:126:29: fatal error: platform_camera.h: No such file or directory
compilation terminated.
C:\CHDK\gcc451\bin\gmake.exe[2]: *** [font_8x16.o] Error 1
C:\CHDK\gcc451\bin\gmake.exe[1]: *** [all-recursive] Error 1
gmake: *** [all-recursive] Error 1
gmake: *** Waiting for unfinished jobs....
In file included from ../../include/stdlib.h:1:0,
from font_8x16.c:2:
../../include/camera.h:126:29: fatal error: platform_camera.h: No such file or directory
compilation terminated.
As discussed in this topic http://chdk.setepontos.com/index.php?topic=6267.0 (http://chdk.setepontos.com/index.php?topic=6267.0) here is the patch to split the current camera.h monster into separate files in the platform/camera directories.
The perl script I used to do this is also attached. This works on CHDK-DE and SDM as well.
I have added defaults into the main camera.h for the values that did not have any placeholder there and done a little bit of re-organising.
Also added a new setting which can be used override the hard coded DNG exposure bias setting (code inserts a value of -0.5 into the DNG header, which explains why my DNG files always came out underexposed!). (Use of this in dng.c will be in a later patch).
I am working on a new tool to take all the defaults and camera values and generate a tabular file with all the cameras and values (like what CHDK-Shell can do) - unless whim beats me to it :)
Edit: patch updated to include platform_camera.h for A580 just added.
Regards,
Phil.
As discussed in this topic http://chdk.setepontos.com/index.php?topic=6267.0 (http://chdk.setepontos.com/index.php?topic=6267.0) here is the patch to split the current camera.h monster into separate files in the platform/camera directories.Added, changeset 1140 (http://tools.assembla.com/chdk/changeset/1140). I hope this doesn't end up being a mistake :-[
Patch to camera.h for IXUS120 SD940 (all versions) to enable fix for camera crash at startup when opening the conf / font files (CAM_STARTUP_CRASH_FILE_OPEN_FIX) per http://chdk.setepontos.com/index.php?topic=6179.0 (http://chdk.setepontos.com/index.php?topic=6179.0)Added, changeset 1141 (http://tools.assembla.com/chdk/changeset/1141)
(@reyalp - I think I now have the relative file position in the patch right per your request in this thread ?)I don't recall problems with yours, some from philmoz had 'trunk' in them. It's not a big deal.
Added, changeset 1140 (http://tools.assembla.com/chdk/changeset/1140). I hope this doesn't end up being a mistake :-[
Added, changeset 1140. I hope this doesn't end up being a mistake Embarrassed
Patch for bug introduced in cleanup of rbf_font.c.
Patch for SX20 1.02d to enable exmem and loading CHDK into exmem.
Also enables startup crash fix for SX20.
Tested by bdasmith.
Philmoz,
the #define fix works perfectly for the startup issue, you can add that to the trunk....
It was the exmem that was causing the video to not record. it would try but the buffer bar showed and then it stopped recording.
is there anything i can do to make it work?
I used a 3mb buffer size, video works for the most part (sometimes fails) but there is still a video buffer bar on the screen that has one block highlighted - this is with the quality set at 90
The emem testing still says ok, even when the video does fail...
sorry to be unclear!
ummm..okay...
this is is at the videos default setting, i accidently wrote the wrong number in previous post (edited it)
when the video fails, i mean it just stops recording...
the buffer bar (this is just what i call it, don't know what it is for sure) is the camera OS thing.
so default settings, just stops recording, yet exmem test still says ok.
hope that helps :)
sorry to be unclear!
ummm..okay...
this is is at the videos default setting, i accidently wrote the wrong number in previous post (edited it)
when the video fails, i mean it just stops recording...
the buffer bar (this is just what i call it, don't know what it is for sure) is the camera OS thing.
so default settings, just stops recording, yet exmem test still says ok.
hope that helps :)
Sounds like your SD card can't keep up - what type/class is it?
If you disable CHDK (unlock the card) can you record videos OK?
The CHDK quality setting of 84 may not be the same as the cameras default video quality setting.
If video recording with CHDK disabled works then turn off the CHDK video quality override (Video Parameters, Video Mode = Default) and try it again with CHDK.
Phil.
Patch to fix a problem with the code generated by GCC 4.4.0 when compiling the readdir function in platform/generic/wrappers.c.Applied in changeset 1144 (http://tools.assembla.com/chdk/changeset/1144)
I believe this is the cause of the problem reported on the G12 using builds from the autobuild server (http://chdk.setepontos.com/index.php?topic=6299.0 (http://chdk.setepontos.com/index.php?topic=6299.0)).
Phil.
+ static char de[40] = ""; // (philmoz 15/4/2011) Must initialize this variable or GCC 4.4.0 will generate bad code and the File Browser will crash.
Whaaa ?
Are you sure it's compiler generating bad code ? If it's actually bad code being generated, it seems like it should affect all dryos autobuilds.
00185ba0 <readdir>:
185ba0: e92d4010 push {r4, lr}
185ba4: e59f401c ldr r4, [pc, #28] ; 185bc8 <readdir+0x28>
185ba8: e1a01004 mov r1, r4 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
185bac: eb0013d6 bl 18ab0c <_ReadFastDir>
185bb0: e5d40000 ldrb r0, [r4] <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
185bb4: e3500000 cmp r0, #0
185bb8: 11a00004 movne r0, r4
185bbc: 03a00000 moveq r0, #0
185bc0: e8bd4010 pop {r4, lr}
185bc4: e12fff1e bx lr
185bc8: 001b0104 .word 0x001b0104
0018633c <readdir>:
18633c: e92d4010 push {r4, lr}
186340: e59f401c ldr r4, [pc, #28] ; 186364 <readdir+0x28>
186344: e2841034 add r1, r4, #52 ; 0x34 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
186348: eb001248 bl 18ac70 <_ReadFastDir>
18634c: e5f40034 ldrb r0, [r4, #52]! <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
186350: e3500000 cmp r0, #0 ; 0x0
186354: 11a00004 movne r0, r4
186358: 03a00000 moveq r0, #0 ; 0x0
18635c: e8bd4010 pop {r4, lr}
186360: e12fff1e bx lr
186364: 001b0cd0 .word 0x001b0cd0
Patch for SX30 & G12 (patched against changeset 1141).Added, changeset 1145 (http://tools.assembla.com/chdk/changeset/1145)
- Added code to override the -0.5 DNG exposure bias that is set in the dng.c code. If your DNG files are 1/2 stop underexposed this is why. Exposure bias set to 0 for G12 & SX30.
- Changed logical screen width to 360 (from 320).
- Cleanup old code in capt_seq.c & added some comments to boot.c
- Aligned vid_bitmap_refresh logic on both cameras. It's still not perfect; but I get less problems with menus vanishing with this version.
Phil.
Patch for SX20 1.02d to enable exmem and loading CHDK into exmem.Added, changeset 1146 (http://tools.assembla.com/chdk/changeset/1145)
Also enables startup crash fix for SX20.
Tested by bdasmith.
Look at the lines I've highlighted - GCC 4.4.0 with 'de' uninitialized is passing and testing the address 12 bytes past the end of the 'de' memory.This shows nothing, because variable in literal pool have different value, and we dont see here address of "de" in memory.
_ReadFastDir(d, &de);
return de[0]? &de : (void*)0;
"de" itself is an address of array, by taking address of it you get pointer to pointer.Look at the lines I've highlighted - GCC 4.4.0 with 'de' uninitialized is passing and testing the address 12 bytes past the end of the 'de' memory.This shows nothing, because variable in literal pool have different value, and we dont see here address of "de" in memory.
The generated code may be correct in both cases.
The only thing that is changed when you initialize "de" is that it's moved from .bss to .data section.
The wrong code is at next two lines:Code: (c) [Select]_ReadFastDir(d, &de);"de" itself is an address of array, by taking address of it you get pointer to pointer.
return de[0]? &de : (void*)0;
GCC silently casts pointer to pointer type to just pointer.
I don't believe that this can lead to some problems, but this is definitely wrong.
Look closely at the original code generated by GCC 4.4.0 - it is passing R4+52 as the address to _ReadFastDir and is then checking the value at R4+52; but it returns R4.Yes, that is true. This looks like compiler bug.
This is an incorrect; but common mistake, arising from a misunderstanding of the difference between arrays and pointers in C.I understand the difference.
An array name in C is not a pointer, it is the address of the first element of the array.
char *test_fn(void)
{
static char test[40];
return &test;
}
Changing code to "return test;" resolves all this warnings.
G12 patch to cleanup boot.c task hook (removes changes made while tracking down startup crash that are not needed).Added changeset 1148 (http://tools.assembla.com/chdk/changeset/1148)
Also adds display of exmem start address when OPT_EXMEM_TESTING is enabled. This is the value to use for MEMISOSTART when using OPT_CHDK_IN_EXMEM (saves calculating it manually).
A small patch to the value used for vid_get_viewport_width() in IXUS120-SD940 firmware 1.02C that aligns it with the other three firmware versions of this camera.Added changeset 1149 (http://tools.assembla.com/chdk/changeset/1149)
A small patch to the value used for vid_get_viewport_width() in IXUS120-SD940 firmware 1.02C that aligns it with the other three firmware versions of this camera.Added changeset 1150 (http://tools.assembla.com/chdk/changeset/1150)
Added changeset 1149 (http://tools.assembla.com/chdk/changeset/1149)Thanks for taking care of this.
Added changeset 1150 (http://tools.assembla.com/chdk/changeset/1150)
Patch to fix a problem with the code generated by GCC 4.4.0 when compiling the readdir function in platform/generic/wrappers.c.@philmoz : This appears to break the file browser when CHDK is compiled with gcc3.4.6 (at least I've tracked that problem to this patch for the SD940)
Look closely at the original code generated by GCC 4.4.0 - it is passing R4+52 as the address to _ReadFastDir and is then checking the value at R4+52; but it returns R4.No, it isn't:
This is clearly wrong, the code when generated correctly uses the same address for all three uses of 'de', hen passed to _ReadFastDir, when tested after that call and as the return value of the function.
18634c: e5f40034 ldrb r0, [r4, #52]!
The exclamation means update R4.Patch for IXUS120-SD940 using CAM_DATE_FOLDER_NAMING as used but CHDKLover in the CHDK-DE forum. Allows RAW and DNG files to be save in the same folders as their corresponging JPG's.Added, changset 1157 (http://tools.assembla.com/chdk/changeset/1157)
Look closely at the original code generated by GCC 4.4.0 - it is passing R4+52 as the address to _ReadFastDir and is then checking the value at R4+52; but it returns R4.No, it isn't:
This is clearly wrong, the code when generated correctly uses the same address for all three uses of 'de', hen passed to _ReadFastDir, when tested after that call and as the return value of the function.Code: [Select]18634c: e5f40034 ldrb r0, [r4, #52]!The exclamation means update R4.
It's returning the same value it passes to _ReadFastDir
My guess is that the size of dirent has increased.
That makes a lot more sense - glad it's sorted properly now.No problem. You wouldn't be the first one to convince yourself some blob of assembler was doing something it didn't :-[
Apologies for sending things off in the wrong direction.
That makes a lot more sense - glad it's sorted properly now.No problem. You wouldn't be the first one to convince yourself some blob of assembler was doing something it didn't :-[
Apologies for sending things off in the wrong direction.
I'm pretty sure the size of dirent was the problem, but if you can verify that the current autobuild does work correctly on g12 and sx30, that would be appreciated.
Just out of curiosity, why did you use _malloc and _free in opendir and closedir?Yes (although the amount of memory is pretty trivial...) I used the _ version just to avoid some warnings, with the intention of switching it after I made stdlib.h include cleanly. Then I forgot when I did clean up stdlib.h ;)
Wouldn't malloc and free be preferable in case exmem is enabled?
Patch for SX130 IS to stop get_effective_focal_length value from overflowing and displaying negative values.Added, changeset 1161 (http://tools.assembla.com/chdk/changeset/1161)
Patch for G12 & SX30 (patched against changeset 1150).Note that the heap start and size shown here are simply constants from ROM (at least on D10), so they don't account for CHDK stealing part of the heap (assuming CHDK not in exmem).
While looking at the EXMEM code in the firmware I noticed the 'memshow' eventproc that displays various useful information about the firmware heap memory allocation.
Tracing through this code I found a function that fills an array of 10 int's with this memory info. It gives things like start and end address of the heap, total size, size allocated, free space and size of the largest free block. This last one is what the code in 'core_get_free_memory' (in main.c) attempts to calculate in a somewhat crude manner.
I checked the firmware for the SX20, D10, S95 and IXUS1000 and they all appear to have this function.The format of the structure does not appear to be quite the same in D10. For example, it stores start, length and calculates end, where g12 has start, end, size in the struct itself. I would guess (but haven't verified yet) this varies by dryos release, so we should only need a handful of different versions, rather than one for each camera.
This one slipped through the cracks, thanks for the reminder.Patch for G12 & SX30 (patched against changeset 1150).Note that the heap start and size shown here are simply constants from ROM (at least on D10), so they don't account for CHDK stealing part of the heap (assuming CHDK not in exmem).
While looking at the EXMEM code in the firmware I noticed the 'memshow' eventproc that displays various useful information about the firmware heap memory allocation.
Tracing through this code I found a function that fills an array of 10 int's with this memory info. It gives things like start and end address of the heap, total size, size allocated, free space and size of the largest free block. This last one is what the code in 'core_get_free_memory' (in main.c) attempts to calculate in a somewhat crude manner.QuoteI checked the firmware for the SX20, D10, S95 and IXUS1000 and they all appear to have this function.The format of the structure does not appear to be quite the same in D10. For example, it stores start, length and calculates end, where g12 has start, end, size in the struct itself. I would guess (but haven't verified yet) this varies by dryos release, so we should only need a handful of different versions, rather than one for each camera.
Rather then exposing the canon firmware dependent structure to normal CHDK code, it would be better to have a standard CHDK function that extracts the useful values in a consistent way, and restrict the ifdefs to the implementation of that function and possibly struct.
It would probably be worth trying to add this function to the sig finder.
A function to find the largest free block was found for vxworks a long time ago. I have a patch for this sitting around, probably time to revisit it.
Patch for SX30 & G12 to fix AV bracketing in continuous drive mode.Added, changeset 1162 (http://tools.assembla.com/chdk/changeset/1162)
Although the PROPCASE_AV value is set in shooting_av_bracketing (via shooting_set_av96_direct) these cameras don't appear to use the new value to change the iris aperture when in continuous shooting mode.
Added a call to MoveIrisWithAv in shooting_av_bracketing for these two cameras to force the physical aperture change when the property is changed.
Edit: Also, could we have the 'beta' tag removed from the G12 and SX30 autobuilds please.Done, 1163 (http://tools.assembla.com/chdk/changeset/1163)
OK, thanks. Probably best to put this patch on hold for now. Will revisit it again when I have some time :)I'm looking into putting the functions into the sig finder at least. The vxworks one is slightly annoying because you need to find the mempart id of the canon heap for each camera :/
Phil.
Added, changeset 1162 (http://tools.assembla.com/chdk/changeset/1162)Many thanks.
Note I changed the logic with 'value' slightly in shooting.c, since 0 is theoretically a valid value (not that I see Canon shipping an f/1.0 lens in a P&S any time soon ;))
Also wanted to check that Av override works correctly in with just the propcase in non-continuous mode ? Otherwise the _MoveIrisWithAv would be needed elsewhere, for scripting at least.Yes, Av override works fine in single shot mode.
Although, wouldn't a value of 0 be an f/0.0 lens (infinite aperture)? (f/1.0 = Av value of 96 by my calculation) :)APEX Av = log2 (f number)2. Camera works in APEX*96 so 0 is f/1.0 and 96 is f/1.4 (or f/sqrt(2) if you want to be pedantic ;))
I'm looking into putting the functions into the sig finder at least. The vxworks one is slightly annoying because you need to find the mempart id of the canon heap for each camera :/in changeset 1165 (http://tools.assembla.com/chdk/changeset/1165) I've added GetMemInfo to the sig finder for dryos. There appears to only be 2 variants, < R39 and >= R39
Looking at the code the older version returns 9 values instead of 10, with the 'end address' missing (it calculates this from the start address and size in the function that uses the values).I'm looking into putting the functions into the sig finder at least. The vxworks one is slightly annoying because you need to find the mempart id of the canon heap for each camera :/in changeset 1165 (http://tools.assembla.com/chdk/changeset/1165) I've added GetMemInfo to the sig finder for dryos. There appears to only be 2 variants, < R39 and >= R39
I haven't checked all the cams, but all the ones I did check were all 100% matches so it should be good.
That agrees with my observation.Looking at the code the older version returns 9 values instead of 10, with the 'end address' missing (it calculates this from the start address and size in the function that uses the values).I'm looking into putting the functions into the sig finder at least. The vxworks one is slightly annoying because you need to find the mempart id of the canon heap for each camera :/in changeset 1165 (http://tools.assembla.com/chdk/changeset/1165) I've added GetMemInfo to the sig finder for dryos. There appears to only be 2 variants, < R39 and >= R39
I haven't checked all the cams, but all the ones I did check were all 100% matches so it should be good.
What's the best way to handle this in the wrapper code?As safe as anything else in CHDK ;)
Is it safe to use the CAM_DRYOS_2_3_R39 define to have differentiate the two - and fill in the missing value if this is not defined>
On the G12 / SX30 this reduces the time to generate the stubs_entry.S file from 29 seconds to 14 seconds (on my dev PC).About the same on mine, and 89 to 44 on my laptop(!). This should make full batch builds with sigs a little less painful.
Tested on a sampling of vxworks and dryos cameras and this still generates the same stubs_entry.S file (have not tested all cameras though so there's a small chance this may break something).autobuilds don't run with primary.bin, so that shouldn't a concern for the moment. Running a batch build now.
Second go at the GetMemInfo patch - now that reyalp has added the signature for this function.Is there a reason this fills in a global, rather than just having the caller pass a cam_meminfo * ?
Enabled & tested for G12 & SX30 - note I have not tested this for any pre R39 dryos cameras (as I don't own one).
Added, changeset 1168 (http://tools.assembla.com/chdk/changeset/1168)On the G12 / SX30 this reduces the time to generate the stubs_entry.S file from 29 seconds to 14 seconds (on my dev PC).About the same on mine, and 89 to 44 on my laptop(!). This should make full batch builds with sigs a little less painful.QuoteTested on a sampling of vxworks and dryos cameras and this still generates the same stubs_entry.S file (have not tested all cameras though so there's a small chance this may break something).autobuilds don't run with primary.bin, so that shouldn't a concern for the moment. Running a batch build now.
edit:
Backing out. This doesn't find any matches for ixus75_sd750 101a using this dump http://www.zshare.net/download/89721005ad516519/ (http://www.zshare.net/download/89721005ad516519/)
Works fine with the old finsig. I haven't looked into why.
edit #2:
One thing I notice is this is a very short dump, which ends with some FFFFs
Attached patch tested with all dryos and vxworks cameras in current trunk.http://www.zshare.net/download/897597441c33b3aa/ (http://www.zshare.net/download/897597441c33b3aa/)
Works correctly except for:
A570 1.01a
- cannot find fimware dump
IXUS120_SD940 1.02cHere's the one I'm using http://www.zshare.net/download/89759875db5af9f3/ (http://www.zshare.net/download/89759875db5af9f3/)
- found firmware dump but appears to be wrong (original finsig generates same entries as new one; but neither matches SVN).
Second go at the GetMemInfo patch - now that reyalp has added the signature for this function.Is there a reason this fills in a global, rather than just having the caller pass a cam_meminfo * ?
Enabled & tested for G12 & SX30 - note I have not tested this for any pre R39 dryos cameras (as I don't own one).
Seems to work fine on D10, (dryos R31)
If we can check it on a couple of other cameras, I'd be tempted to just enable it for all dryos and not add another ifdef. The 100% matches indicate this has changed very little except the R39 transition.
I'd like to expose this in lua (useful for forcing garbage collection, debugging over ptp). For exmem enabled builds, it would be useful to have this for both the camera heap and whatever similar values are applicable in suba. Not saying you have to go and implement this, just thinking out loud.
New version attached for review.Added, changeset 1175 (http://tools.assembla.com/chdk/changeset/1175). Thanks for your patience with my various nitpicking. I'll take care of the lua part.
- removed global variable, caller must pass pointer to cam_meminfo struct
- addded ExMem version (GetExMemInfo) and support code to suba.c (a couple of things still to do in here)
- implemented pre & post R39 code versions
I've left the CAM_FIRMWARE_MEMINFO define in for now, if you think this will work safely for all dryos cameras the checks for this can be changed to CAM_DRYOS instead.I'd like to get a few users of different cameras to report first.
ACDSee Pro 4 does not like the previous 'DNG Exposure Bias' value change for the G12 and SX30 (Pro 3 still works apparently).Added, changeset 1176 (http://tools.assembla.com/chdk/changeset/1176)
This patch changes the bias divisor to 1 which fixes the problem while still keeping the actual exposure bias at 0 for these cameras.
i entered the define in Platform.hThis should go in platform/<your camera>/platform_camera.h (putting it in include/camera.h would also work, turning it on for any camera you build)
for the sx20 but don't know what to look for as to changes?Just look at "miscellaneous stuff"->"show memory info". The "free memory" section should be similar to what you see without it enabled.
everything seems to be working properly though...
Patch for IXUS120-SD940 to set more reasonable default battery voltage levels for the battery percentage OSD display.Added, changeset 1177 (http://tools.assembla.com/chdk/changeset/1177)
Btw, the new dryos getmeminfo stuff reminds me of this old vxworks mempartfindmax osd/lua thing:Yes, thanks for the link, I had the patch but hadn't found the original thread. It's my plan to revisit that, so getmeminfo can return whatever equivalent information is available on vx and we can get rid of the silly malloc loop entirely.
http://chdk.setepontos.com/index.php?topic=2831.msg29364#msg29364 (http://chdk.setepontos.com/index.php?topic=2831.msg29364#msg29364).
Patch that (hopefully) fixes the intermittent problem with the recent rbf_font changes.Added, changeset 1186 (http://tools.assembla.com/chdk/changeset/1186).
See http://chdk.setepontos.com/index.php?topic=6365 (http://chdk.setepontos.com/index.php?topic=6365)
Appears to be related to mixing cached and uncached memory references when loading a font from the SD card. Passing the uncached font address to rbf_font_load seems to fix the problem.
Also cleaned up the comments in the code.
Phil.
Small patch to cleanup up some stub addresses and redundant stubs for G12 & SX30.Added, changeset 1188 (http://tools.assembla.com/chdk/changeset/1188), chdkde 666 (http://tools.assembla.com/chdkde/changeset/666) \m/
Patch file to add firmware version 100e support for the IXUS120-SD940.Added, changeset 1189 (http://tools.assembla.com/chdk/changeset/1189).
Just a note that my main development machine has gone to the big data center in the sky. It may be a while before I get to any patches.
So I've never thought to ask before, but is there a backup plan if you decide to do something else other than be the CHDK guru some day ?The source is available. Even if all the people with admin access to the official assembla project SVN disappear, you can always fork it. There's also CHDKDE which has several active participants.
Patch file to add firmware version 100i support for the S95.
G12 firmware 1.00f.
Patch file to add firmware version 100i support for the S95.G12 firmware 1.00f.
added in changeset 1192 (http://tools.assembla.com/chdk/changeset/1192/trunk)
msl
platform/g12/sub/100f directory in SVN is missing the files:
boot.c
Makefile
makefile.inc
stubs_auto.S
stubs_entry_2.S
stubs_min.S
Phil.
Patch for S95 (all versions) CAM_STARTUP_CRASH_FILE_OPEN_FIX
Patch file for Beta release of A495 - firmware 1.00d, 1.00e, 1.00f.
Patch file for Beta release of A495 - firmware 1.00d, 1.00e, 1.00f.
added in changeset 1198 (http://tools.assembla.com/chdk/changeset/1198/trunk)
Thx waterwingz for the great job. I don't know, if a fi2 key (d4a) is available for the autobuild. Maybe we must commented out the a495 in makefile for the moment. We will see. :)
msl
Changeset 1198 overwrites change to core/kbd.c from changeset 1196.
SX30 firmware version 1.00n.
Changeset 1198 overwrites change to core/kbd.c from changeset 1196.Thanks for catching that Phil. It was certainly rude of me - my apology to pixeldoc2000.
This sounds complicated.
I suggest:
- do your work in an SVN working copy, Compile there as needed
- before creating the patch, do an svn update and resolve any conflicts (should be very rare), build and test.
- create the patch with tortoise "create patch" or svn diff.
SX130is firmware version 1.01d. Plus some cleanup for 1.01c
IXUS120-SD940 update to misc. stub_entry_2.S values
Patch for edge_overlay.c.
Patch for 'propset4.h'
Hello Everyone,Thanks, excellent work. Added in trunk changeset 1205 (http://tools.assembla.com/chdk/changeset/1205). Should appear on the autobuilds shortly.
I think this thread is appropriate for adding patches. I'm really a newbie but with the kind help of reyalp on the forum I could make A490 100f port work (see http://chdk.setepontos.com/index.php?topic=5051.msg67184#msg67184 (http://chdk.setepontos.com/index.php?topic=5051.msg67184#msg67184)). I'd like to see others using my work so I'd like to share the code. Unfortunately I've met with TortoiseSVN at first today so if my patch is not correct, please don't kill me. :-) Anyway, find it attached.
mrowl
Couple of minor things were missing:Thanks indeed. I forgot to take notes what files I have changed, sorry. ZSTEP_TABLE_SIZE is 7 apparently. I'll doublecheck all the files.
- ZSTEP_TABLE_SIZE stuff from core/kbd.c (that ugly SOB needs to get moved into platform code one of these days...)
I assumed this was 7, based on a495 and platform/a495/main/c fl_tbl
- platform/a490/Makefile
copied from d10, since they are all pretty much the same.
You should double check if there were any other changes in core/ that should have gone in. Shortcuts key settings in gui.c would is the other likely place that comes to mind.
I'll doublecheck all the files.If you have your stuff in a working copy already, you can just update and "check for modifications" in tortoise.
IXUS120-SD940 : Patch file to correct vid_get_viewport_fb_d() address for all firmware versions. Discovered after working through this stub address for several other cameras and matching that to the IXUS120-SD940 firmware.Added, changeset 1207 (http://tools.assembla.com/chdk/changeset/1207)
S95 Firmware 1.00i : update to stubs_min.S file - corrected two addresses.Added, changeset 1208 (http://tools.assembla.com/chdk/changeset/1208)
DEF(FlashParamsTable,0xFFC724C4) // @FFB0F34C
DEF(FlashParamsTable,0xFFC72B4) // @FFB0F34C
@reyalpGood catch, thanks. Looking for the correct one now.
@waterwingz
(from changeset 1208)QuoteDEF(FlashParamsTable,0xFFC724C4) // @FFB0F34C
DEF(FlashParamsTable,0xFFC72B4) // @FFB0F34C
Isn't there a character missing in the bolded hex address ?
wim
SX30 firmware version 1.00m.Added, changeset 1210 (http://tools.assembla.com/chdk/changeset/1210) chdkde changeset 689 (http://tools.assembla.com/chdkde/changeset/689)
I hope this is the correct way to do this.Correct ? Probably not, but it's how we do it ;) You did have an extra -full in the batch-zip, which I took out.
@philmoz
I took a look at your changes and I'd like to know why did you remove the refresh_physical_screen from stubs_min.S. Thanks.
Beta release of IXUS200_SD980 firmware 1.01cAdded, chdk changeset 1212 (http://tools.assembla.com/chdk/log/trunk)
Original port for 1.00c by RaduP. Port from there to 1.01c by philmoz & waterwingz. Testing by simon96 and titbb.
G12 & SX30 minor patchAdded, chdk changeset 1213 (http://tools.assembla.com/chdk/changeset/1213)
- stubs cleanup and address fixes.
- removed redundant entries from platform_camera.h
- changed CAM_BLACK_LEVEL in camera.h to a calculated value based on bits-per-pixel (CAM_BLACK_LEVEL and CAM_WHITE_LEVEL overrides can be removed from most platform_camera.h files)
- removed definition of O_RDONLY from generic/wrappers.c since stdlib.h is now included
S95 firmware 1.00k release.Added, chdk changeset 1215 (http://tools.assembla.com/chdk/changeset/1215)
Code cleanup in ubasic.c and script.cThis looks like a nice memory saving (>1k in my build.)
Code cleanup in ubasic.c and script.cThis looks like a nice memory saving (>1k in my build.)
How thoroughly has this been tested ? The short/int conversion concerns me slightly: for signed values the difference between casting and simply passing an int to a function that expects a short will be significant, even though they both use a full register. Most of the APEX96 values can legitimately be negative.
IXUS120-SD940 : Updates to the stub_entry_2.S files for all firmware versions and stubs_min.S for 1.00e firmware. Thanks to philmoz for the use of his new gensig2 software.Added, chdk changeset 1216 (http://tools.assembla.com/chdk/changeset/1216)
Also corrected modemap[] in shooting.c based on testing with actual camera.
If it is an issue, you can probably make the shooting* functions take and int and do any required casting there. The lua side probably won't need any adjustment if the prototypes match what the function actually expects.
IXUS200_SD980 fw 1.01C : fix for shooting_get_drive_mode() to allow bracketing with auto timeradded, chdk changeset 1217 (http://tools.assembla.com/chdk/changeset/1217)
A495 firmware 1.00d, 1.00e, 1.00fadded, chdk changeset 1218 (http://tools.assembla.com/chdk/changeset/1218)
Updates to stubs_entry_2.S & stub_min.S for all versions.
Note that this also made the same change for a495. I'm guessing that needs it as well, so I've left it in.Thanks - it seemed like a low risk guess given that the A480 has the same change. And sorry to say, its not like anyone has actually reported playing with that yet. If we get a complaint, we can change it back.
I have some additional questions:This will have to be done as a special case for the camera. I'd guess you could put it in the platform/sx220/sub/<version>/makefile.inc
- the sx220 port needs to be compiled with exmem_malloc and chdk_in_exmem. Can this be a problem?
- do I need to add the localbuildconf.inc file?
override OPT_EXMEM_MALLOC=1
override OPT_CHDK_IN_EXMEM=1
I guess this works...- do I need to add the BETA extension next to the camera name?If you add the batch build commands, that would be appreciated.
The CHDKDE sx130 hasCode: [Select]override OPT_EXMEM_MALLOC=1I guess this works...
override OPT_CHDK_IN_EXMEM=1
Updated patch attached.Added, changeset 1221 (http://tools.assembla.com/chdk/changeset/1221)
Added additional helper functions with correct signatures for the passed in function pointer.
Should avoid any casting / conversion issues.
Tested get_user_tv96 and set_user_tv96, and negative values handled correctly (both returned and as parameters).
Trivial but overdue small cleanup for core/kbd.c. (been meaning to submit this for a while)Added (a while ago, forum was down) changeset 1219 (http://tools.assembla.com/chdk/changeset/1219)
G12 modemap patch:Added, changeset 1222 (http://tools.assembla.com/chdk/changeset/1222)
- added additional video modes to platform/g12/shooting.c
- added video miniature mode definition to include/modelist.h
- convert MODE_IS_VIDEO monster macro to a function (include/platform.h & platform/generic/shooting.c).
Enable JPEG quality override for A495. Also updated comment for this option in camera.hAdded, changeset 1223 (http://tools.assembla.com/chdk/changeset/1223)
Trivial but overdue small cleanup for core/kbd.c. (been meaning to submit this for a while)Added (a while ago, forum was down) changeset 1219 (http://tools.assembla.com/chdk/changeset/1219)
Yes, something like that. See http://chdk.setepontos.com/index.php?topic=6528.0 (http://chdk.setepontos.com/index.php?topic=6528.0)Is this another one that really should be in camera.h & platform_camera.h ?Trivial but overdue small cleanup for core/kbd.c. (been meaning to submit this for a while)Added (a while ago, forum was down) changeset 1219 (http://tools.assembla.com/chdk/changeset/1219)
I made a patch using TortoiseSVN. I think it should be ok. I needed to add some sx220 code to generic, core, and include files. Can somebody check if everything is ok? If something can be done differently I can modify it if needed. Thanks.Thanks.
Minor patch - modemap update for SX30.Added, changeset 1227 (http://tools.assembla.com/chdk/changeset/1227)
Minor patch - modemap update for SX30.Added, changeset 1227 (http://tools.assembla.com/chdk/changeset/1227)
Note, if the new generation finsig could find the canon modelist, that would be handy :)
I find it starting with "AC:PTM_Init" and several layers of function calls. You can see this easily by going to one of the known table addresses (commented in many cameras modemaps), finding the function that references it and working backwards. Might be hard to automate unless you can match one of the deeper calls.Minor patch - modemap update for SX30.Added, changeset 1227 (http://tools.assembla.com/chdk/changeset/1227)
Note, if the new generation finsig could find the canon modelist, that would be handy :)
Thanks, any pointers on how to find the modelist. I took a look; but haven't found anything so far.
I find it starting with "AC:PTM_Init" and several layers of function calls. You can see this easily by going to one of the known table addresses (commented in many cameras modemaps), finding the function that references it and working backwards. Might be hard to automate unless you can match one of the deeper calls.Minor patch - modemap update for SX30.Added, changeset 1227 (http://tools.assembla.com/chdk/changeset/1227)
Note, if the new generation finsig could find the canon modelist, that would be handy :)
Thanks, any pointers on how to find the modelist. I took a look; but haven't found anything so far.
You might be able to find or sanity check it by looking for common mode values together as 16 bit ints.
Thanks, I may be able to find that table ok; but do the mode numbers always mean the same thing for all cameras?For recent cameras (everything but some very early vxworks ones like s2is) the number for common modes like P, M, Tv etc seem to be the same. Note that the "manual" mode of cameras without a true manual use the "P" mode number. I'm not sure if all the scene / special modes are the same, or whether the values get re-used for different things on different cameras.
I thought they changed between cameras which is why the modemap table is needed (I read another thread which seemed to imply they were different)?Aside from the old cameras mentioned above, the modemap predates the discovery of the table. The table is useful for verifying that all the canon modes are accounted for.
There's some values in the tables for G12 and SX30 - 8240 & 8241. Can't seem to find what these modes are for - they don't seem to be defined in any camera modemap table in CHDK. Have you come across these before?I think these correspond to C1 and C2, but these values aren't returned by the propcase we use for shooting mode. They are available in a different propcase if used.
No problem. I think I fixed it now.Thanks. Added in changeset 1230 (http://tools.assembla.com/chdk/changeset/1230)
I also removed AFScan from the port to keep the gui.c in the original state.Some platform specific ifdefs are OK where they are really needed. I just don't want to add a bunch for cosmetic stuff like the games. Feel free to post patches against the trunk for any adjustments that are needed.
Modemap update for G12 & SX30 (thx reyalp for the pointers to the firmware table).Added, changeset 1231 (http://tools.assembla.com/chdk/changeset/1231)
- Added new modes for 'wink self timer' and 'face self timer'.
- Updated comments
- table order matches firmware (cosmetic change so I can compare them).
Note, if the new generation finsig could find the canon modelist, that would be handy :)
Hi phil,
Re: #359, space_optimization.patch
Works great on ixus570_sd880 (100a) and S95 (100h); tested with r1232 / GCC 451
DISKBOOT.BIN size reduction for both cams ~ 8.1 kB.
thanks,
wim
Beta version for A1100 firmware 1.00c.Added changeset 1233 (http://tools.assembla.com/chdk/changeset/1233). I've disabled FI2 generation in makefile.inc, so that people who download the autobuild won't get a non-working FI2.
Converted from CHDKDE version.
Fixed stub addresses, updated values in platform_camera.h etc.
Tested by blackhole (http://chdk.setepontos.com/index.php?topic=4727.msg69830#msg69830 (http://chdk.setepontos.com/index.php?topic=4727.msg69830#msg69830)).
Note: manual booting (via firmware update) is not working, although I think I have the correct FI2 values. I don't have this camera to do more in depth testing of this feature.
Hi phil,Have either of you tested this with non-default languages ?
Re: #359, space_optimization.patch
Works great on ixus570_sd880 (100a) and S95 (100h); tested with r1232 / GCC 451
DISKBOOT.BIN size reduction for both cams ~ 8.1 kB.
Hi phil,Have either of you tested this with non-default languages ?
Re: #359, space_optimization.patch
Works great on ixus570_sd880 (100a) and S95 (100h); tested with r1232 / GCC 451
DISKBOOT.BIN size reduction for both cams ~ 8.1 kB.
Regarding the patch:
1) As I've mentioned before, I'd rather have the pieces in separate patches. I know it's all reducing memory usage, but the lang, conf and miscellaneous gui drawing changes seem like are distinct, independent changes. Multiple, simpler patches lets me apply the ones I think are obviously safe, while taking more time on anything I have questions about.
2) It looks to me like all the lang strings are accessed from uncached memory. This doesn't seem like a good thing -- I guess it was this way before though.
3) It looks like there some unrelated changes snuck in: Palette for a1100 in gui_draw.h, removing defined (CAMERA_sx30) from an ifdef in gui.c.
In fact I don't understand what's going on with the bitmap palette, a1100 camera.h uses 2, while sx220hs already defined 9 (differently from a1100)
Hi reyalp, I'll split it up into smaller pieces tonight and re-post. Some of the changes are dependent on the new functions in gui_draw.c & gui_draw.h and I didn't want to create a broken patch by missing something.No need, I think I can apply this one as is with your clarifications below. More of a reminder for a the future. I understand SVN doesn't make this particularly easy...
The uncached memory was what the language code was using so I didn't change it.Fair enough :)
The palette numbering was a mistake - I'm working on the A1100 which initially used palette 2; but in fact needs a new one. I changed it to 9 and was waiting till the A1100 beta got added to the build before posting a patch; but the sx220 got in first :) This should not have been included in the patch.Thanks for clearing that up.
The change to gui.c was to remove an un-necessary check for CAMERA_s30 - I thought I'd already done this in a previous patch, sorry.
I understand SVN doesn't make this particularly easy...
A topic for a different thread (this one, to be specific: http://chdk.setepontos.com/index.php?topic=2304.0 (http://chdk.setepontos.com/index.php?topic=2304.0) ), but I'm open to switching to a DVCS. It really would be a better fit for the CHDK development model, but there are issues...I understand SVN doesn't make this particularly easy...Time to switch to Mercurial :D
In gui_menu.h, making title a short means you can't stuff an actual string in there, you have to use a lang string. I think this is OK with the current code, but in other places it's assumed you can interchangeably use a string or lang id. Given that this is only for top level menu tiles, I'm not sure the saving is worth the confusion. Doing this for menu items would be a much bigger saving, but the string problem is bigger there (we actually use strings in a few places).
In gui_draw.c, the globals for xMin getting initialized as a side effect of draw_rectangle makes me cringe.
Probably right - I tried changing both but ran into the issue with the strings being stored instead of the lang id (now this really makes me cringe). Didn't see any cases of this being done at the menu level so I left that one in. Was going to fix menuitem as well (using special lang id codes for the string cases); but need more time to analyse the code.If you can't just stuff a string in there, I'm not sure what a special ID will gain you. It's quite convenient to be able to just throw in a string for development, rather than going through the whole lang system.
Should have made these variables static so they are at least local to gui_draw.c. Not perhaps the most elegant code; but it does help keep the size down :)They are static, it just assumes draw_rectangle will be called before the other functions.
Probably right - I tried changing both but ran into the issue with the strings being stored instead of the lang id (now this really makes me cringe). Didn't see any cases of this being done at the menu level so I left that one in. Was going to fix menuitem as well (using special lang id codes for the string cases); but need more time to analyse the code.If you can't just stuff a string in there, I'm not sure what a special ID will gain you. It's quite convenient to be able to just throw in a string for development, rather than going through the whole lang system.
QuoteShould have made these variables static so they are at least local to gui_draw.c. Not perhaps the most elegant code; but it does help keep the size down :)They are static, it just assumes draw_rectangle will be called before the other functions.
Freeing up memory is good, but there's a limit how much readability/maintainability I'm willing to sacrifice. I'd really rather go in the other direction...
Have either of you tested this with non-default languages ?
Done, changeset 1236 (http://tools.assembla.com/chdk/changeset/1236)
Have either of you tested this with non-default languages ?
Can you roll back the change to lib/lang/lang.c - the new version I posted doesn't work with the language files that don't contain translations for all of the strings.
Back to the drawing board :(
I noticed in generic/shooting.c _MoveIrisWithAv is used both in the same ifdef as SX30 and G12 in shooting_av_bracketing as well as in shooting_set_av96_direct with an ifdef just for sx220hs
This looks like it will get called 2x in the bracketing case. I'm wondering if all the cameras couldn't just do it in the shooting_set_av96_direct ? Or is this really only needed for bracketing (not script overrides) on the SX30 and G12 ?
========== C:\CHDK\TRUNK\TRUNK1236\BIN\LOGS\ERR-IXUS120_SD940-103C.TXT ==========
C:\CHDK\gcc4\bin\gmake.exe[2]: *** No rule to make target `../../tools/font_8x16_pack.exe', needed by `font_8x16_uni_packed.h'. Stop.
C:\CHDK\gcc4\bin\gmake.exe[1]: *** [all-recursive] Error 1
gmake: *** [all-recursive] Error 1Back from vacation and trying to build the latest versions for some of the cameras I'm keeping an eye on.
Getting this with the ones I have tried so far :Code: [Select]========== C:\CHDK\TRUNK\TRUNK1236\BIN\LOGS\ERR-IXUS120_SD940-103C.TXT ==========
C:\CHDK\gcc4\bin\gmake.exe[2]: *** No rule to make target `../../tools/font_8x16_pack.exe', needed by `font_8x16_uni_packed.h'. Stop.
C:\CHDK\gcc4\bin\gmake.exe[1]: *** [all-recursive] Error 1
gmake: *** [all-recursive] Error 1
Straight download of trunk 1236 via CHDK-Shell-v332.
Forgot to mention that I loaded your latest sig finder, if that matters.Back from vacation and trying to build the latest versions for some of the cameras I'm keeping an eye on.
Getting this with the ones I have tried so far :Code: [Select]========== C:\CHDK\TRUNK\TRUNK1236\BIN\LOGS\ERR-IXUS120_SD940-103C.TXT ==========
C:\CHDK\gcc4\bin\gmake.exe[2]: *** No rule to make target `../../tools/font_8x16_pack.exe', needed by `font_8x16_uni_packed.h'. Stop.
C:\CHDK\gcc4\bin\gmake.exe[1]: *** [all-recursive] Error 1
gmake: *** [all-recursive] Error 1
Straight download of trunk 1236 via CHDK-Shell-v332.
Check the Makefile in the tools directory - it should have the entries to build this tool.
The correct Makefile is in SVN so I'm not sure why CHDK-Shell isn't picking it up.
Phil.
Forgot to mention that I loaded your latest sig finder, if that matters.Back from vacation and trying to build the latest versions for some of the cameras I'm keeping an eye on.
Getting this with the ones I have tried so far :Code: [Select]========== C:\CHDK\TRUNK\TRUNK1236\BIN\LOGS\ERR-IXUS120_SD940-103C.TXT ==========
C:\CHDK\gcc4\bin\gmake.exe[2]: *** No rule to make target `../../tools/font_8x16_pack.exe', needed by `font_8x16_uni_packed.h'. Stop.
C:\CHDK\gcc4\bin\gmake.exe[1]: *** [all-recursive] Error 1
gmake: *** [all-recursive] Error 1
Straight download of trunk 1236 via CHDK-Shell-v332.
Check the Makefile in the tools directory - it should have the entries to build this tool.
The correct Makefile is in SVN so I'm not sure why CHDK-Shell isn't picking it up.
Phil.
gmake.exe[1]: *** Warning: File `Makefile' has modification time in the future (1310489588 > 1310474842)
Compiler throws a funny warning now :D . Philmoz is a time traveler! Why would the compiler even check the time? Like everybody lives in the same time zone.This happens after every update if you grab the update as soon as it comes out and live in time zones west of GMT. Fixes itself in 24 hours and can safely be ignored.Code: [Select]gmake.exe[1]: *** Warning: File `Makefile' has modification time in the future (1310489588 > 1310474842)
Following a report by maverick here (http://chdk.setepontos.com/index.php?topic=5641.msg70096#msg70096) and the following posts (#913 - 918) here is the requested patch.
This essentially resets CAM_JPEG_WIDTH, CAM_JPEG_HEIGHT, and the 4 CAM_ACTIVE_AREA
camera properties for S95 to the values used for S90 and G11, which use the same sensor.
According to maverick, this allows S95 generated DNGs to be opened in Photoshop CS5.
Note that I have no idea why this would be, this was just a lucky guess :D
Patch generated by diffing modified trunk1236 with trunk1236
Patch to update palette for A1100.
I contacted philmoz and he suggested to make a new define in camera.h. He tested the fix for both sx30 and g12.
I made some additional changes for sx220:
-added the adjustable ALT button code in core/gui.c and camera/kbd.c
-fixed and added two new modes in camera/shooting.c modelist
-added CAM_KEY_CLICK_DELAY 150 to platform_camera.h like the sx30 to fix the button clicks in ptp
Fix for a bug introduced with my recent space optimisation changes.
SX130is firmware version 1.01f
Attached a diff (against trunk rev. 1239) for the A410, contains the following:
- USB power sensing corrected (USB remote should work, tested with remote.bas)
(I threw away most of /platform/a410/kbd.c, used "#ifdef"s in /platform/generic/kbd.c instead)
- modemap filled with correct values
- changes noted to /platform/a410/notes.txt
Cleanup of 'capt_seq.c' for G12 (all firmware versions).Added in changset 1241 (http://tools.assembla.com/chdk/changeset/1241/trunk).
Change to lib/lang/lang.c to use malloc/free instead of umalloc/ufree to store the language strings.Added in changeset 1242 (http://tools.assembla.com/chdk/changeset/1242/trunk).
Patch for G12/SX30/IXUS 310/SX220.
Fixes AV override causing camera to crash if the shutter button half pressed repeatedly too quickly.
Patch for S95, all firmware versions (thx maverick for testing and getting all the modemap values)Added, changeset 1244 (http://tools.assembla.com/chdk/changeset/1244).
- updated stub addresses and added stubs entries or strrchr, rand and srand. removed custom S95 versions from code
- fixed get_flash_params_count
- changed display aspect ratio setting from 9/4 to x2 (http://chdk.setepontos.com/index.php?topic=6395.0 (http://chdk.setepontos.com/index.php?topic=6395.0))
- removed redundant values from platform_camera.h
- updated DNG active area values
- updated modemap
- fixed option to save RAW/DNG in same folder as JPEG
Patch to disable raw/dng saving in 'low light' mode on G12 & SX30 (can be enabled for other cameras using '#define CAM_DISABLE_RAW_IN_LOW_LIGHT_MODE 1' in platform_camera.h).Added, changeset 1245 (http://tools.assembla.com/chdk/changeset/1245)
The raw files in this mode are corrupted and not usable.
This patch is for raw/dng saving on the SX220HS and IXUS 310HS (probably the SX230HS will need it as well).
Patch for sx220 includes:
Addition of philmoz CAM_DETECT_SCREEN_ERASE for the IXUS120_SD940.
Added in changeset 1255.
Hi!
Attached is a patch for the A410. It increases the movie time limit from 3 minutes to 1 hour in 320x240 and 640x480 modes.
The firmware function I changed here can be found in many VXWORKS cameras. There is a possibility that the usual 1 hour time limit could be lifted (but I've never tried that).
IXUS200-SD980 port for firmware 1.01D by gbit.
Implements CAM_DETECT_SCREEN_ERASE so firmware 1.01C will also pickup that fix.
I've been porting some scripts to lua. get_display_mode() function is only accessible to ubasic, attached patch adds it to lua too.Because there is no need for it in lua. Just use the propcase.lua, that's what it was meant for
IXUS100-SD780 : adds support for firmware version 1.00b. Also updates a few stubs for 1.00c and implements CAM_DETECT_SCREEN_ERASE for both versions. Tested by voodoolady & dagokun (100B) and andrewhazelden (100C).
Cleanup of debug_led()
Patch for sx220 platform_camera.h.
Added CAM_DRYOS_2_3_R47 and CAM_DETECT_SCREEN_ERASE
Includes:
-fix in generic/shooting.c that caused Av bracketing to not calculate the lowest Av value http://chdk.setepontos.com/index.php?topic=6726.0 (http://chdk.setepontos.com/index.php?topic=6726.0)
-in generic/shooting.c disabled bracketing when camera in best image selection mode (MODE_SCN_BEST_IMAGE). In this mode the camera shoots 4 images and auto selects the best one.
-added new keys for sx220 to include/keyboard.h
-added new key "playback" for sx220 in adjustable alt button in gui.c
-key changes in sx220 kbd.c
-from sx220 platform_camera.h removed unneeded define entries and comments cleanup.
-in sx220 lib.c corrected the led_table.
Currently you select an amount to bracket by and if applying that amount to the Av value is out of range the bracketed value is not changed - your update causes it to use the largest aperture which amounts to a bracketed change of less than the requested amount.
Attached is a patch for the A410
- subject distance override made possible by duplicating (and disabling an assert in) MoveFocusLensToDistance(). I'm not sure whether I chose the proper place for its declaration (I put it into /include/lolevel.h) or a proper name for it ( MoveFocusLensToDistanceA410() ).
- movie time limit fix (the standard, 60min one) was tested, I no longer call it experimental.
- included CAM_DETECT_SCREEN_ERASE
- typo fixed in /platform/a410/shooting.c
I didn't include any MFOn() MFOff() stuff. While it does make manual focus work better in these cameras (A410, 420, ...) by eliminating the unnecessary af-scan, it would be too much work for now to implement it. Its state would need to be properly tracked, if not, it causes more problems than it solves.
Oh, and about that assert: I strongly believe, that removing it won't cause any hardware trouble, everything seems to work just fine.
edit:
grammar fix
Added in changeset 1287.
Added in changeset 1287.
I added missing focushack.c in changeset 1288
msl
SX220 patch:
-fix for save raw file counter not being updated correctly
-fix for ISO overrides in capt_seq.c and shooting.c
-fix for jogdial task in boot.c and kbd.c
Thx to philmoz.
New colormatrix for sx220hs.
ifeq ($(KEYSYS), d3enc)
FI2KEY=6F....71
FI2IV =53....3D
endif
A580 now fully working.
- Extra long exposure feature supported.
Added new camera version SX220 HS 1.01b + removed a not needed line in camera/shooting.c ISOTable.
A few additions to the comments in include/camera.h that help explain how to select some of the constants necessary for DNG creation.Added changeset 1307 (http://tools.assembla.com/chdk/changeset/1307/trunk)
A580 final (fixed stubs).I added the patch to chdk trunk, changeset 1308 (http://tools.assembla.com/chdk/changeset/1308/trunk)
Can you add a580 to autobuild in CHDK and remove "alpha" status from download in CHDK-DE? thx
A580
- Now is EXMEM supported
- Manual Focus adjustments tested and works
- + makefile
Hey,
I have a patch against SVN 1324 which adds sx230hs for the 100c and the 101a firmwares.
It needs changes to /core/dng.c
Hey,
I have a patch against SVN 1324 which adds sx230hs for the 100c and the 101a firmwares.
It needs changes to /core/dng.c
I tried applying your patch to my local build, so I could commit the changes.
I use TortoiseSVN on Windows - unfortunately TortoiseSVN doesn't like the patch file.
If you can create a patch file that I can use with TortoiseSVN I can add this, otherwise it will need to wait for someone more familiar with it who can apply the patch.
Phil.
Hey,
I have a patch against SVN 1324 which adds sx230hs for the 100c and the 101a firmwares.
It needs changes to /core/dng.c
I tried applying your patch to my local build, so I could commit the changes.
I use TortoiseSVN on Windows - unfortunately TortoiseSVN doesn't like the patch file.
If you can create a patch file that I can use with TortoiseSVN I can add this, otherwise it will need to wait for someone more familiar with it who can apply the patch.
Phil.
See if this one works any better
Thanks
Taliesin
Hey,
I have a patch against SVN 1324 which adds sx230hs for the 100c and the 101a firmwares.
It needs changes to /core/dng.c
I tried applying your patch to my local build, so I could commit the changes.
I use TortoiseSVN on Windows - unfortunately TortoiseSVN doesn't like the patch file.
If you can create a patch file that I can use with TortoiseSVN I can add this, otherwise it will need to wait for someone more familiar with it who can apply the patch.
Phil.
See if this one works any better
Thanks
TaliesinSorry, still no luck applying it with TortoiseSVN.
With help from reyalp I've managed to get the patches working.
Phil.
Hey,
I have a patch against SVN 1324 which adds sx230hs for the 100c and the 101a firmwares.
It needs changes to /core/dng.c
G10 f/w 1.02a, 1.03b, 1.04a
Beta testing complete - port done.
G10 f/w 1.02a, 1.03b, 1.04a
Beta testing complete - port done.
Added in changeset 1327.
(I left out the stubs_entry.S.orig files from the new signature finding testing phase.)
Phil.
Patch for the new 101b firmware for the sx230hs, and porting accross some changes from sx220 into sx230
Thanks
Taliesin
I noticed that reyalp had to do 54 fix-ups to the G10 svn properties in change set 1329G10 f/w 1.02a, 1.03b, 1.04aAdded in changeset 1327.
svn props for g10
Commit from user: reyalpI'm not sure whether I chose the proper place for its declaration (I put it into /include/lolevel.h) or a proper name for it ( MoveFocusLensToDistanceA410() ).:-[
Was there something I should have done differently in the patch or original source files ?No, the person committing the patch has to do it.
Patch for IXUS120-SD940 (all firmware versions)Added changeset 1334 (http://tools.assembla.com/chdk/changeset/1334)
This patch corrects a major bug in capt_seq.c for all firmware versions. The bug had been partially masked by commenting out one of the calls to the CHDK hooks. This resulted in impaired USB_Remote functionality and possible crashes in some shooting modes.
This patch enables USB remote operation in "Synchable Remote" mode. In this mode the camera does a "half shoot" on application of 5V on the USB port and a "full shoot" when the 5V is removed.
Attached is a cosmetic patch regarding A410. It removes the "global" declaration and use of MoveFocusLensToDistanceA410() as it seems to be unneeded. It's now only a local function for the port.Added, changeset 1335 (http://tools.assembla.com/chdk/changeset/1335)
Oh, btw. Is there something wrong with this (http://chdk.setepontos.com/index.php?topic=237.msg72276#msg72276) patch for the SX100? If it gets accepted, I could do the same for the other firmware revision (the change should be trivial, but I will not be able to test that of course). Here (http://chdk.setepontos.com/index.php?topic=650.msg72277#msg72277) is my previous post.
Yes, I have tested it on my 1.00c camera.I'm not clear if this is tested ? If it is then it should be fineLooks like you do have that camera.
On some cameras the second "taskhook" is only needed for some tasks, but in your case there is only one task started this way.Looking at some (earlier) discussions and also at some DryOS ports, it's still not clear to me, how this mechanism works. When I removed the modification of the 0x1934 location, the modified exp_drv_task() still managed to start. I have only tested this twice: first time with the camera started in playback mode, second time with the camera started with a long press on the on/off button. Both tests were succesful.
The way our ifdefs are set up, it is hard to have features like extra long exposure enabled for only one sub so you'd need to do both before we can put it in the trunk.Yeah, I forgot about that. So here's the patch for both fw revisions, also included the fix for the vanishing menus.
Yes, I have tested it on my 1.00c camera.I'm not clear if this is tested ? If it is then it should be fineLooks like you do have that camera.QuoteOn some cameras the second "taskhook" is only needed for some tasks, but in your case there is only one task started this way.Looking at some (earlier) discussions and also at some DryOS ports, it's still not clear to me, how this mechanism works. When I removed the modification of the 0x1934 location, the modified exp_drv_task() still managed to start. I have only tested this twice: first time with the camera started in playback mode, second time with the camera started with a long press on the on/off button. Both tests were succesful.
But, since most ports use two taskhook locations (with the override for exp_drv_task included in both), I decided to follow that practice.QuoteThe way our ifdefs are set up, it is hard to have features like extra long exposure enabled for only one sub so you'd need to do both before we can put it in the trunk.Yeah, I forgot about that. So here's the patch for both fw revisions, also included the fix for the vanishing menus.
Hi, I ported the firmware version 100f to 100d, for the powershot a490, with the help of CHDK-PT.
Everything seems to be working fine...
I have attached a patch-file for the trunk. I think everything should be included. Could someone add this to the repository?
Here's a patch file to add get_config_value() and set_config_value() to Lua and uBASIC. Its taken directly from CHDK-DE.
This is in response to this request http://chdk.setepontos.com/index.php?topic=6429.msg73673#msg73673 (http://chdk.setepontos.com/index.php?topic=6429.msg73673#msg73673).
It actually seems like a good idea but reyalp may have some history as to why this was not added in the past.
If its accepted, I'll update the wiki as best I can.
A patch to add four really simple scripts (Lua and uBasic versions so 8 files total) to the install files. These scripts implement the most common functions people want from CHDK (shoot with delay, intervalometer, motion detect, HDR). Lots of room for people to experiment and improve. What I was looking for was the most basic way to do the core CHDK scripted functions - curiously those are not included in the standard CHDK build.
The scripts are written to be generic - nothing specific to a particular camera model.
If someone can explain how to correct the addresses, assuming little foreknowledge, I can do that, but I have little time the next two weeks...If you read through the stubs_entry.S file, you will see that it flags where things it found do not match some of the values you have found in shooting.c, stubs_min.S, lib.c, kbd.c, platform_camera.h and stubs_entry_2.S. The values in stub_entry.S are probably correct so you need to be really sure why the values you put into those other files do not match.
Hi Phil,
Here is the patch with capt_seq included. Sorry for that. I don't know how to check/correct the addresses in stubs_entry.S, but so far, things seem to be working.
If someone can explain how to correct the addresses, assuming little foreknowledge, I can do that, but I have little time the next two weeks...
Patch file to add outslider's editor to the CHDK/SCRIPTS directory under subdirectory EDITOR.
@Glomeris
Delete (or rename) your CHDK config file on the SD card ( \CHDK\cchdk.cfg ).
Hi! I've ownloaded the lastest (1359) release from autobuild for sx130is firmware C, but the EDITOR directory is empty... I looked also in a few other cameras builds and always it's empty. Any reason or a mistake?
If it's a mistake I suggest to wait untill this evening I'll post a new vrsion of editor with file_browser() command used and then apply another, working patch.
Greetings;)
Patch file to enable colored icons on IXUS120-SD940.
Patch to fix one of the "simple" scripts recently added. As a "C" programmer, I need to learn that in Lua, a zero value does not evaluate to the same thing as "false". Don't know how I missed that in the testing - probably because the uBasic version worked so I missed it when translating to Lua. My bad.
Hello,
so finally i found some time to rebase my port for the A3000IS to the current trunk and create a diff file.
So please add this port for the A3000IS (FW Versions 1.00b, c and d) to the trunk.
IXUS1000-SD4500 : firmware 1.00d & 1.00f
- based on Bernd R's port.
- stubs_entry.S updated with latest sigfinder results.
- camera_list.csv marked as SKIP_AUTOBUILD
- NOT TESTED
Gets it off my hard drive and available for tweaking prior to inclusion in autobuild.
(Note: the included camera_list.csv patch is missing commas on many of the lines - there should be five entries on each line.)Yup - I wondered about that. I opened the camera_list.csv with a slightly older version of Excel and then saved it after adding the IXUS1000. I noticed a lot of "changes" in the patch file that really were not changes. Which makes me think using .CSV as a file format might be a source of problems if people edit it with spreadsheet software rather then text editors ?
(Note: the included camera_list.csv patch is missing commas on many of the lines - there should be five entries on each line.)Yup - I wondered about that. I opened the camera_list.csv with a slightly older version of Excel and then saved it after adding the IXUS1000. I noticed a lot of "changes" in the patch file that really were not changes. Which makes me think using .CSV as a file format might be a source of problems if people edit it with spreadsheet software rather then text editors ?
It's an easy file format to process - so long as anyone committing changes to SVN is careful it should be OK.I'm with you there - the six or so separate places in Makefile for a new port took patience to find. Still, it will be interesting to see what the various spreadsheet programs out there do to the CSV file format ....
It's certainly a lot easier to update and add new versions to though :)
Correction to English .lng file to match a default menu value in the embedded in core files.
Patch for G10, G11 & G12 - all firmware versions - that enables the adjustable ALT button option. ALT button can be changed from the default PRINT button to the AE_Lock/Microphone, DISP or Jump/Metering button.
Tested on the G10. Should work on G11 as is. Code change on G12 probably warrants a little testing (philmoz?).
One suggestion - the 'alt_mode_key_mask' variable is not needed and the 'kbd_set_alt_mode_key_mask' function can actually be empty.Yup - a few minutes of clicking with grepWin now tells me the same thing. Not sure I want to go cleanup the 44 files that reference it though. Maybe when I get the rest of kdb.c straighened out, I'll add the changes at the same time ?
The variable is set; but never used, on any of these cameras.
Patch for G10, G11 & G12 - all firmware versions - that enables the adjustable ALT button option. ALT button can be changed from the default PRINT button to the AE_Lock/Microphone, DISP or Jump/Metering button.
Tested on the G10. Should work on G11 as is. Code change on G12 probably warrants a little testing (philmoz?).
1) Language library optimization. It save 2.5kb of chdk size always and about 15kb of heap if no language file loaded.
Second attachment contain simple tool (source and executable) to convert gui_lang.c and/or apply to it any .lng file (to avoid load .lng file and so extend saving to native language).
2) Also small fix done in russian.lng
Its even better.
I also would like to integrate language choice to building process, but I don't know how. I do prepare all required components and ask you to integrate them into ChdkShell.
I see one more benefit of this: now developer shouldn't care about consistency build-in language list with english.lng. String list in header file will be created automatically even for english language.
But I propose to keep this new .h file (though it will be created automatically on build) in repository for non-windows hosted developers and for autobuild-server.
Below are two files:
* patch.zip - consist patch (separate strings to different .h file, add missed strings to english.lng )
* make_gui_lang.zip - consist source and compiled executable of convertor, which make strings header file for any language
How to use this convertor:
make_gui_lang.exe path_to_english.lng [path_to_secondary.lng] > path_to_trunk/core/gui_lang_str.h
Please fill free to change remarks in gui_lang.c, because english is not my strongest point.
Another small improvement:Improvements are good. Even better is somebody adding new stuff to the code. Welcome onboard !!
Massive ubasic speed optimization come soon... So memory-careful language going to be more useful.Hmmm ... I'm assuming english is not your native language? No problem if it is not. The word "massive" might be more than you intend with your comment though ? "Good" or "nice" are better words uniess you have a way to increase script execution speed to ten times faster or more ?
Another small improvement:
- set_console_autoredraw functionality is extended. If value =-1 that mean do not display value on the screen
- print_screen functionality is extended. If negative value provided, logfile will be not cleared but appended.
Cheap extension to even more control. Useful for fastening of any dumps for example.
And especially extend ubasic control. Because it is very limited in any file operations.
Massive ubasic speed optimization come soon... So memory-careful language going to be more useful.
Added in changeset 1394 (also added some comments to the code).wiki updated set_console_autoredraw() (http://chdk.wikia.com/wiki/Script_commands#set_console_autoredraw)
Ok. In attachment new version of convertor.
It succesfully was compiled in tools and work ok
Added in changeset 1394 (also added some comments to the code).
Added in changeset 1394 (also added some comments to the code).
Sorry. I did miss one line during preparation workspace to diff. So print_screen extension work not as expected.
Below patch for that
Colored icons for sx130is - colors tuned as best possible (I guess).
Pretty simple bugfix.
Fixed problem:
If try to open text reader "Miscelanous - Text File Reader - Open New File..." and then press "menu" in file selector, clear screen is displayed and then I can't do power off (lens keep retracted), can't see any CHDK screen etc. Only removing battery help.
Because I often use text reader (to read debug info) it was extremely annoying bug.
get_tv k
@title hang2a
print "Grab property to LOG_".a
print_screen a
One more small bugfix.
I do separate it from my big ubasic enhancement package by waterwingz request.
CHDK will hangup and then shutdown with retracted lens on some scripts (like Omni-Intervalometer) because wrong UnknownStatement processing. Below are two extremely simple examples when my S95 will hangup.Code: [Select]get_tv kCode: [Select]@title hang2a
print "Grab property to LOG_".a
print_screen a
I would like do not make conflict with my own big requests, so only small piece of planed interface changes below...
All the more small steps are integrated quickly.
1. Add comments to some data structure. Such comments are always helpfull and save time.
2. In my opinion CHDK interface require to be significatelly improved. One of issue is displaying many things when they have no sense. Small step to fix that - filemanager do not display some Raw operation when it surely anymore.
3. Another usability issue is non-intuitive control key sometimes. I was very surprised when found that to cancel filemanager popup menu I have to press 'Left'. I add much more reasonable 'Menu'.
Patch for IXUS65_SD630 to allow the use of alternate ALT button per http://chdk.setepontos.com/index.php?topic=7088 (http://chdk.setepontos.com/index.php?topic=7088)
Patch to add sx150is 1.00a alpha port. Patch created based on trunk rev 1414.
sgtrum
While big changes are on hold, try to go on with small interface improvements.
What patch contain:
1. Forgotten change to make item#3 of 1407changeset workable
2. Text reader become default action of filemanager (before filemanager just quit)
3. We return from text reader to filemanager, instead of menu. Much easier to press Menu once more, then select text reader again and browse through directory hierarcy in case if select wrong or would like to read something more (for me this is especially useful, because during development a lot of debug log files created and I don't wont remove card from camera to read it comfortable).
Not sure about this one.Consistence for me is that "Menu" works like Escape/Back. If we open through file selector - we go to it back, if we open directly from menu - we return back directly to menu.
Some of my concerns are:
- Inconsistent U/I. If you enter the text reader from the 'Open New File', then when you leave you are put back in the file selector. When you enter the text reader from the 'Open Last Opened File', then when you leave you are back at the menu. The behaviour when leaving the text reader should be consistent.
- Having text reader specific code buried in the file selector is not a good practice (I know there is a lot of this in CHDK; but we should try and avoid adding more).What exactly piece of code do you mean? If you talking about two lines, where I add make default action, then it easily could be moved, Just do not call without parameter.
Also, as suggested earlier, it would really help if you set your editor to insert spaces instead of tabs and set the tab size to 4, not 8.I did. And I checked before sending. But probably something miss. Sorry.
Patch for the G10 to fix issues with the set_zoom() command in LUA and uBASIC scripts.Added, changeset 1419 (http://tools.assembla.com/chdk/changeset/1419/trunk)
Note that the patch added redundant PROPCASE_DIGITAL_ZOOM_STATE and PROPCASE_DIGITAL_ZOOM_POSITION defines. The numeric values were the same, so I just put the comments on the existing defines.Thanks - I hate it when that happens. I actually checked out each prop_case on the camera to make sure they were the right ones for propcase2. Didn't notice the ones that were already defined I guess.
Patch for all versions of IXUS120_SD940 to fix fl_tbl[] in main.c. Entered actual values from exif data and corrected table length (now has 10 rather than 11 elements).Added, changeset 1421 (https://tools.assembla.com/chdk/changeset/1421) (broken link, assembla trac seems to be messed up...)
Also changed stub for SetScriptMode in all versions to reflect value recommended by new sig finder.
broken link, assembla trac seems to be messed up...
We are planning a release tomorrow 22 November, at 07:00 UTC. We will make some changes to the database, so the server team has asked me to tell you that there may be up to 10 minutes downtime. I will post notes about enhancements tomorrow.Guess something went wrong ...
You might want to check the ZSETP_TABLE_SIZE / nTxtbl stuff in core/kbd.c for this camera, I'd guess it should be the same as ixus870I actually did take a look at that but decided not to change it just yet.
So far, the best feedback I've had is from reyalp - "Nuke it from orbit".:P
Apparently remote zoom via USB is not a much used feature in CHDK (SDM may be different).Remote zoom and features like this can (and IMO also should) be done completely from the script side, without any special code.
Remote zoom and features like this can (and IMO also should) be done completely from the script side, without any special code.I tend to agree with the exception that having a simple "press to focus, release to shoot" mechanism that does not need a script seems to make sense for many users. Also, the CA1 and sync delay features would be hard to implement in a script - the timing is too tight.
We should also make sure that all builds in CHDK & CHDKDE behaves the same way...Agreed. But I'll get a separate thread for this started shortly - let's not discuss it here.
Another small patch. It improve useful tool "incrementor".
We could change incrementor step using zoom (and on some camera disp) to rapid change current menu item value.
What is done:
1. Refresh on-screen correctly
2. Resolved collision with ERASE_GUARD
3. Use incrementor for enums (useful for Tv override for example + unificate chdk behaviour)
While big changes are on hold, try to go on with small interface improvements.
What patch contain:
1. Forgotten change to make item#3 of 1407changeset workable
2. Text reader become default action of filemanager (before filemanager just quit)
3. We return from text reader to filemanager, instead of menu. Much easier to press Menu once more, then select text reader again and browse through directory hierarcy in case if select wrong or would like to read something more (for me this is especially useful, because during development a lot of debug log files created and I don't wont remove card from camera to read it comfortable).
Personally I still think that exiting the text reader should always take you back to the same place regardless of how you entered; but I'm open to it working either way. Perhaps a configuration option to allow you to exit the text reader to either the menu or file selector could be used.
Gee phil - while you're at it, how about fixing the "<- Back" menu item in the Script menu so that it works when you enter that menu via the Func/Set key rather than the Main Menu. :-X
Where should it go 'back' to?The blank <ALT> screen it "came" from ? Much like the second time you press the Menu key in <ALT> mode.
Where should it go 'back' to?The blank <ALT> screen it "came" from ? Much like the second time you press the Menu key in <ALT> mode.
Is this a reasonable solution?Sounds good to me. Its obviously really not a big deal - just a minor annoyance that came to mind when you were commenting on the correct way to leave the file viewer.
/core/gui.c // add support for ixus220_elph300hs
/core/kbd.c // add support for ixus220_elph300hs
/camera_list.csv // add BETA Status entry for ixus220_elph300hs
/loader/ // add new folder "ixus220_elph300hs" with loader files for ixus220_elph300hs
/platform/ // add new folder "ixus220_elph300hs" with platform files for ixus220_elph300hs Firmware 1.00c/1.01a/1.01c
No real changes.
1. Just well documenting script.c module before its upcoming improvement
2. Minor renames ( conf.ubasic_vars -> conf.script_vars) to match name to usage.
Also some changes are produced because tab to space replacing.
A while ago I complained about the memory dump debug function, here: http://chdk.setepontos.com/index.php?topic=7067.msg75696#msg75696 (http://chdk.setepontos.com/index.php?topic=7067.msg75696#msg75696) (also see reyalp's answer).
Attached is a patch which aims to correct it.
Another possibility to fix write() with NULL as source address would be this:
write(fd, (void*)0 | CAM_UNCACHED_BIT, 0x1900);
I'd also like to note that on at least the Ixus30/40 models, these addresses only work when specified as uncached. It's just a note, I don't think it will affect anyone else than me :)
CAM_RAM_SIZE_IN_MB would have to be corrected for cameras which have more or less RAM than 32MB - but that's only up to the interested developers.
I hope this is not unpolite, didn't want to open a thread for this.
long val0 = *((long*)(0|CAM_UNCACHED_BIT));
write(fd, &val0, 4);
write(fd, (void*)4, MAXRAMADDR-3); // MAXRAMADDR is last valid RAM location
Dear Developers,
this is my request to add a first Beta version of CHDK port for ixus220_elph300hs camera with firmware version 1.00c/1.01a/1.01c (related thread: http://chdk.setepontos.com/index.php?topic=6341 (http://chdk.setepontos.com/index.php?topic=6341)).
Also I noticed the stubs_entry.S file is reporting a lot of errors in the modemap table for each firmware version.
Can I suggest a simpler approach:Thanks, I haven't looked into makefile.inc, that's why I have missed this already existing #define.Code: [Select]long val0 = *((long*)(0|CAM_UNCACHED_BIT));
write(fd, &val0, 4);
write(fd, (void*)4, MAXRAMADDR-3); // MAXRAMADDR is last valid RAM location
No additional #defines in camera.h and the correct RAM size is already defined for many cameras.
Note: This requires an update to makefile.inc to change the default value of MAXRAMADDR from 0x200000 to 0x1FFFFFF (this will make it consistent with other usage).I have attached a new patch with your suggested changes. The patch also defines MAXRAMADDR for two cameras that only have 16MB of RAM. I have tested this new version: it works on the A410, Ixus65, SX100IS.
Also I noticed the stubs_entry.S file is reporting a lot of errors in the modemap table for each firmware version.
Modemap table issues fixed by finding camera values via debug output. Values put into shooting.c file.
attached: shooting.c.patch for subversion integration for ixus220_elph300hs platform
Can I suggest a simpler approach:Thanks, I haven't looked into makefile.inc, that's why I have missed this already existing #define.Code: [Select]long val0 = *((long*)(0|CAM_UNCACHED_BIT));
write(fd, &val0, 4);
write(fd, (void*)4, MAXRAMADDR-3); // MAXRAMADDR is last valid RAM location
No additional #defines in camera.h and the correct RAM size is already defined for many cameras.QuoteNote: This requires an update to makefile.inc to change the default value of MAXRAMADDR from 0x200000 to 0x1FFFFFF (this will make it consistent with other usage).I have attached a new patch with your suggested changes. The patch also defines MAXRAMADDR for two cameras that only have 16MB of RAM. I have tested this new version: it works on the A410, Ixus65, SX100IS.
I'd also like to request a "promotion" to beta for my A410 port. I got feedback (more or less) from 4 different users and the port doesn't currently have unsolved bugs I know about. I've developed it using the 1.00f firmware, two people reported success using it with their 1.00e revision camera. Patch also attached. Porting thread is here: http://chdk.setepontos.com/index.php?topic=2597.0 (http://chdk.setepontos.com/index.php?topic=2597.0)
Attached a patch that fixes viewport dimensions for the IXUS 220 / ELPH 300 HS, and thus allows zebras and edge detection to work.
I haven't tried your patch yet, but I think that A/CHDK/SCRIPTS/EDITOR/ is a better place for the editor than directly in A/CHDK/SCRIPTS/ (that's only my opinion at the moment).FYI - it seems there are issues with path length on some cameras. The simple scripts in A/CHDK/SCRIPTS/4pack/Lua do not run on some cameras unless copied to A/CHDK/SCRIPTS. Your proposed editor path might be an issue too.
Attached a patch that fixes the location of focus_busy and zoom_busy on ixus220/elph300, and thus fixes the ISO override crash. (tested on 1.01a; probably the same across firmwares, since variables on either side didn't move)
Also - I understand that now one can run editor directly from file selector for selected file? But editor script always run its own file browser instance - isn't this a conflict?
BTW - I'm going to work on on-camera grid editor, but have not enough time now. I need to finish my lua drawing first which are required. I guess, that this editor could be also run from file selector.Yes sure.
I cleaned up stubs_entry2.S files and of course this results in new generated versions of stubs_entry.S files.
Please find attached a patch with new versions of stubs_entry2.S and stubs_entry.S for firmware versions 100c, 101a and 101c for ixus220_elph300hs.
I cleaned up stubs_entry2.S files and of course this results in new generated versions of stubs_entry.S files.
...
I cleaned up stubs_entry2.S files and of course this results in new generated versions of stubs_entry.S files.
...
Oh, additional changes I did for 100c I missed to do for 101a and 101c before providing patch. :(
Therefore please find attached another patch with missing change for 101a and 101c firmware. :)
Thanks to CHDKLover from german CHDK Forum for the hint!
Removed unnecessary functions/variable for JogDial from lib.c and kbd.c.
Please find attached the patch.
Here's a patch which makes drawing function available from Lua. More described here:
http://chdk.setepontos.com/index.php?topic=7097.0 (http://chdk.setepontos.com/index.php?topic=7097.0)
The zip contains also drawings.lua module which is going to be placed in LUALIB directory (I don't know how to add new file to the code through .patch file). This module enhances drawing from lua so it is intended to be added if patch will be applied.
Remote trigger Ricoh CA-1 currently does not work with CHDK - the emulated half-press is released after 1s.Tested on my G10 and SD940. The CA-1 works much better now - although it still refocuses between the half-press and full-press.
This is a fix ported from SDM.
I changed the while loop to look like the SX30 etc. one:Code: [Select]while (zoom_busy) msleep(10);
... which fixed the problem for the IXUS 220 (allowing me to zoom all the way out in the lua script with no hang), and I suspect might fix the S95 too, although I can't test that.
This fix has been confirmed to work for the S95 as well; but I haven't got around to fixing the code.
Adding the msleep(10) to the default case loop should also be done in my opinion (infinite loops are not a good practice in my opinion).
Phil.
Remote trigger Ricoh CA-1 currently does not work with CHDK - the emulated half-press is released after 1s.
This is a fix ported from SDM.
Patch to enable manual focus (in AF lock mode) on IXUS220/ELPH 300 HS. Can be enabled in other models via #define CAM_CAN_SD_OVER_IN_AF_LOCK 1 in platform_camera.h (assuming PROPCASE_AF_LOCK is defined for the model).
From the ELPH 300 HS porting thread:
I changed the while loop to look like the SX30 etc. one:Code: [Select]while (zoom_busy) msleep(10);
... which fixed the problem for the IXUS 220 (allowing me to zoom all the way out in the lua script with no hang), and I suspect might fix the S95 too, although I can't test that.
This fix has been confirmed to work for the S95 as well; but I haven't got around to fixing the code.
Adding the msleep(10) to the default case loop should also be done in my opinion (infinite loops are not a good practice in my opinion).
Phil.
I've attached a diff that does this, which you can merge if you'd like.
Can you explain the steps to cause this in more detail please - I can't get the current editor or file selector to hangup in build 1457.
Can you explain the steps to cause this in more detail please - I can't get the current editor or file selector to hangup in build 1457.
1. Set UserMenu=OnDire
2. Go to Alt mode
3. Run editor script and select file
4. Press ALT to go to None mode
5. Press ALT again. You go to User Menu but no one button works
print_screen(2)
show_osd=get_config_value(1);
conf_batt_volts_max=get_config_value(8);
ubasic_vars_table=get_config_value(5);
histo_pos1,histo_pos2=get_config_value(21);
conf_reader_file=get_config_value(38);
print("show_osd="..show_osd);
print(";conf_batt_volts_max="..conf_batt_volts_max);
print(";histo="..histo_pos1..","..histo_pos2);
print("conf_reader_file="..conf_reader_file);
print("ubasic_v"..ubasic_vars_table[1]);
In attachment fix for get_config_value()/set_config_value() for LUA.
It incorrectly works with fields different from simple int/color: OSD_pos, int array, strings.
Reason: 1)using of wrong defines when process values; 2) plain CONF list.
#define PARAM_CAMERA_NAME 4 // parameter number for GetParameterData
#define PARAM_DISPLAY_MODE1 57 // param number for LCD display mode when camera in playback
#define PARAM_DISPLAY_MODE2 58 // param number for LCD display mode when camera in record view hold mode
Patch to allow the CHDK OSD to track the state of the DISP key (so they are basically only visible when the Canon icons are also visible).
Patch to move the scripts from the /CHDK/SCRIPTS/4Pack/lua & /CHDK/SCRIPTS/4Pack/uBasic directory to /CHDK/SCRIPTS.
#define SCREEN_COLOR 0x15Adds :Code: [Select]#define SCREEN_COLOR 0x15
to palette 2 in gui_draw.h
Simple one line patch to fix a long standing major bug for the IXUX120_SD940 firmware version 1.00e.For bug fixes like this, just post a patch for one branch or the other, after it's applied to one we can merge over to the other as needed. If a fix impacts an area that has changed radically, then two equivalent patches might be needed, but most platform specific stuff should be pretty clear.
Recommended for both the release-1_0 branch and the main (unstable) trunk.
Not sure how we are supposed to do that now so I'm posting it like this.
Another little fix - this time the USB_MASK bit for the IXUS220 as per recent discussion on the forum.Added release-1_0 changeset 1528 (http://trac.assembla.com/chdk/changeset/1528/branches/release-1_0) , trunk changeset 1529 (http://trac.assembla.com/chdk/changeset/1529/trunk)
I tried using the test draw lua but the files had to be in lualib for the draw test to work
Please add to trunk the IXUS 220HS 1.01G port described here:I think that the preferred method to submit a port here is to provide a patch file against the current svn. Typically people use TortoiseSVN for compatability with the dev's systems. You should probable also indicate if the port is to be considered alpha or beta status (somewhat arbitrary based on the amount of testing by different peope) and if it should be included in the autobuild server build for public use.
http://chdk.setepontos.com/index.php?topic=6341.msg79508#msg79508 (http://chdk.setepontos.com/index.php?topic=6341.msg79508#msg79508)
along with the necessary line in camera_list.csv
Since this is a new firmware port, all the files are new. A patch would bring no extra info.
All the ports for this camera are alpha, so this is alpha too.
TortoiseSVN is just a GUI for SVN that only runs on Windows. I doubt that using it is somehow required.
When I introduced my Lua drawings Phil said that it would be good to have the function that provides colors for lua a available for other parts of CHDK. Now I had some time so I decided to move color function and color array from luascript.c to gui_draw.c. This is the first change suggested in below patch.
Second change is to define several new #defines to make color usage more comfortable. I hope in future we could replace COLOR_XXX with these new COLOR_UNI_XXX.
I did it mostly because on my SX130IS COLOR_RED is not red and there is no way to define correct red in both rec and play mode. The same for green. Above functions allows us to do so in future.
I know, that for now it makes some mess since it adds new defines and we have more and more of them. But I believe that the next step should be to rename COLOR_ICON/HISTO_XXX_REC/PLY to simply COLOR_UNI_REC/PLY, put them on universal_colotr[] array and use in code only COLOR_UNI_XXX. It would give you mostly correct color on most of cameras! And would be much more simple.
This patch contains also minor changes in SX130 icon colors (for my pleasure:) ).
All suggestions would be welcome! If this will be more discussed I'll start separated thread.
There is no two meaning. 0-17 values are just entries in an array. When they are put into uni_colors it just returns 0-255 usual value.
Since this is a new firmware port, all the files are new. A patch would bring no extra info.
All the ports for this camera are alpha, so this is alpha too.
TortoiseSVN is just a GUI for SVN that only runs on Windows. I doubt that using it is somehow required.
Make a patch file and all is good. ;)
For the maintainers it's easier when you provide a patch file. There are many ways to create patch files. Here is a comparison of svn clients: http://en.wikipedia.org/wiki/Comparison_of_Subversion_clients (http://en.wikipedia.org/wiki/Comparison_of_Subversion_clients)
Attached is a patch file against branch release1.0 - untested.
msl
Patch file to add mk11174's A3300 1.00a port as ALPHA build marked "SKIP_AUTOBUILD".
Captures this early release in the svn without releasing to the general public.
First patch file for v2 USB remote code. Submitted now to prep the main dev trunk for pending changes. Will not break existing builds.Added, trunk changeset 1555 (http://trac.assembla.com/chdk/changeset/1555/trunk).
This patch adds a #define REMOTE_SYNC_STATUS_LED variable to all platform_camera.h files.
If the release-1_0 camera blinked an LED in the routine wait_until_remote_button_is_released() that LED's address will be used in v2 USB remote code to indicate the same thing. This decouples the USB remote code from the debug_led() routine used in v1.
The variable is commented out if no LED blink was used in the original code. It is available for implementation if requested.
Patch file to add ixus230_elph310hs 1.00b port as ALPHA build marked "SKIP_AUTOBUILD".
Captures this early release in the svn without releasing to the general public.
Submitted for review - second patch file to complete new USB remote code first release.Added, changeset 1568 (http://trac.assembla.com/chdk/changeset/1568/trunk). Further discussion in the above thread.
Release notes at : http://chdk.setepontos.com/index.php?topic=7127.msg79948#msg79948 (http://chdk.setepontos.com/index.php?topic=7127.msg79948#msg79948)
Patch for the dev trunk to update the ixus230 for the new USB remote functionality.Added, changeset 1573 (http://trac.assembla.com/chdk/changeset/1573)
Small changes related to lang - new entries in polish.lng (and a few fixes).Added, changeset 1574 (http://trac.assembla.com/chdk/changeset/1574)
Also - added RMDIR define to be used in fselect.c (for file deletion) and MORE used instead of hardcoded string. LANG_ITEMS incremented. This is for trunk, could be used in reyalp-flt also.
I am in progress to deliver new code for DNG, RAW, Motion detection and shot histogram.If you want to make significant changes, I'd suggest a thread to discuss them before posting here. Also, as I've mentioned before, I really prefer that unrelated changes be submitted in individual patches. If the changes are non-trivial, I will probably insist on this.
First, I start with some C optimizations and minor corrections to test the delivery process.Did you check if these optimizations improve performance or binary size ?
0014b3cc <foo_old>:
14b3cc: b510 push {r4, lr}
14b3ce: 2400 movs r4, #0
14b3d0: 1c20 adds r0, r4, #0
14b3d2: 3401 adds r4, #1
14b3d4: f7ff fff2 bl 14b3bc <bar>
14b3d8: 2c0a cmp r4, #10
14b3da: d1f9 bne.n 14b3d0 <foo_old+0x4>
14b3dc: bc10 pop {r4}
14b3de: bc01 pop {r0}
14b3e0: 4700 bx r0
0014b3e2 <foo_new>:
14b3e2: b510 push {r4, lr}
14b3e4: 240a movs r4, #10
14b3e6: 3c01 subs r4, #1
14b3e8: 1c20 adds r0, r4, #0
14b3ea: f7ff ffe7 bl 14b3bc <bar>
14b3ee: 2c00 cmp r4, #0
14b3f0: d1f9 bne.n 14b3e6 <foo_new+0x4>
14b3f2: bc10 pop {r4}
14b3f4: bc01 pop {r0}
14b3f6: 4700 bx r0
One of these is for(i=0;i<10;i++) and the other is for(i=10;i--;)Bonjour,
I am in progress to deliver new code for DNG, RAW, Motion detection and shot histogram.
First, I start with some C optimizations and minor corrections to test the delivery process.
Here is a patch file generated from CHDK shell's source tool "Diff" comparing with 1572 trunk.
fix to allow USB V2 remote debug display to not crash the dev trunk build ( adds a startup delay to allow things to settle before hammering the LCD display).Added, trunk changeset 1578 (http://trac.assembla.com/chdk/changeset/1578/trunk)
My last patch post (above) did not "take" for some reason ?? So I did an svn revert & update, reapplied my original file and created a new patch file. Changes are the same as listed above. Let's hope it works this time.Added changeset 1585 (http://trac.assembla.com/chdk/changeset/1585/trunk)
Patch #5 for USB remote V2.Added, changeset 1593 (http://trac.assembla.com/chdk/changeset/1593/trunk)
Change is backward compatible.I think ubasic is not quite backward compatible.
I think ubasic is not quite backward compatible. b=get_usb_power would be equivalent to mode 0, but now it's a syntax error unless you explicitly give it a number.Darn - tested that case for Lua, missed it when testing uBasic. Thanks for checking that for me.
Patch #6 for USB remote V2.Added, trunk changeset 1596 (http://trac.assembla.com/chdk/changeset/1596/trunk)
A possible solution to the problem with the A495 keyboard. This was merged 2 days ago into CHDK-DE, a tester in the German forum reported a preliminary success (no 100% report yet).
Bug fixed (it was experienced with CHDK-DE): camera crashed on startup when any script was set to autostart.
The four buttons really seem to be inverted. Idle value of physw_status[2] has already been reported here: http://chdk.setepontos.com/index.php?topic=5570.msg56110#msg56110 (http://chdk.setepontos.com/index.php?topic=5570.msg56110#msg56110) .
As the A490's kbd.c is identical, this change may also be useful there.
Hi, I would like to apply this patch to the stable release-1 0 to update my a3300 port.
This is my first time doing this, but I think I did it correctly.
After creating my patch I reverted the release back so I could test the patch and everything went fine.
Thanks
Updated patch file with fixed hook raw address, and active area values, thanks to Phil!!
Patch #7 for USB Remote V2. Changes are :
1) New & improved Ricoh CA-1 input module provided by vnd (http://chdk.setepontos.com/index.php?action=profile;u=15952).
2) High speed remote status debugging code provided by vnd (http://chdk.setepontos.com/index.php?action=profile;u=15952). Available but currently disabled in this patch.
3) Modified pulse counting code so that logic modules get an identical but seperate pulse count from that provide to Lua and uBasic scripts. Avoids a potential race condition when scripts poll for pulse counts and logic modules are also using that value.
A470 update for release 1.0Thanks. Added in stable changeset 1625 (http://trac.assembla.com/chdk/changeset/1625/branches/release-1_0) and trunk changeset 1626 (http://trac.assembla.com/chdk/changeset/1626/trunk)
- multiple corrections for 1.02c according to stubs_entry.S (can't be sure it would be ok for the other 2)If the sig finder values are correct on your cam then I'd say that's good enough to apply them to the other subs.
A question: finsig_dryos reports different addresses for "rename" and "write". Is there a way to test which function is the correct one?If they work, then they are probably not wrong. The others might also work.
I would like to update the A430 too (I posted a patch here a while ago). If there's anything I should do differently, just tell me.If we ignored a patch without comment, it probably just means we got distracted and missed it. Feel free to remind us. If you can update it for the current tree, that would make it easier to apply.
A question: finsig_dryos reports different addresses for "rename" and "write". Is there a way to test which function is the correct one?
I would like to submit this patch for stable release 1_0 to add firmware 100c to my a3300 port. Thanks.
Update for USB remote code in dev trunk.Added, changeset 1682 (http://trac.assembla.com/chdk/changeset/1682/trunk)
The following is a cumulative patch for the ixus220hs / elph300hs.
-ShouldCould fix the USB-related E41 error, as reported by c10ud here (http://chdk.setepontos.com/index.php?topic=6341.msg81752#msg81752). It was probably caused by a typo in boot.c . (I had to hunt down the difference in the diff c10ud has provided but he deserves the credit for his work.) The patch restores a constant to its original value.
- Also fixes a problem for 1.01g that made movie recording impossible. It was a typo again, the patch restores a function address to its original value. This was tested by Fischauge in the German forum here (http://forum.chdk-treff.de/viewtopic.php?f=3&t=2657&p=24715#p24715).
edit: I'm no longer sure about the above fixing E41 as the Ixus220 and Ixus230 kbd.c's are a bit questionable at places...
Nevertheless, the patch does fix actual mistakes.
Patch file 9 for USB remote v2 update. Allows cameras with separate video button to activate filming via USB remote.
Thanks to msl for making this happen.
It wanted to create a propset5 but from the quick look I took, it seemed that was mostly because it started as propset3 and changes were made that seemed to result in something a lot like propset4. So I just changed it to use propset4.Being a dryos R43 camera, I'd expect it to be a propset3, but I suppose it's possible Canon changed mid stream (or the other R43 cams are wrong...)
Hello!Since lua numbers are integers in CHDK, I'm not sure how useful or correct this will be.
Might I ask to unlock math.sqrt() function in Lua?
Ixus220hs/Elph300hs: hiker_jon's confirmed addresses turned into a patch - affects recreview_hold and vid_get_viewport_fb_d().release changeset 1717 (http://trac.assembla.com/chdk/changeset/1717/branches/release-1_0)
And finally: the patch in my previous post here hasn't been committed yet (A1000).release changeset 1716 (http://trac.assembla.com/chdk/changeset/1716/branches/release-1_0). Thanks for the reminder.
I would also like to ask something: I tried to help imtheguy in the same thread by implementing dark frame subtraction control. I tried two possible locations for capt_seq_hook_set_nr, but reportedly neither works properly (stops working after some time ???). Has anybody experienced something like this on a recent camera? CaptSeqTask's code seems correct, I don't know what could go wrong...No idea, the described behavior is very strange.
I've been experimenting with working only in Linux on CHDK. So I took the liberty of using mland's A800-100.c port to exercise the linux svn commands. I've attached a patch file for the latest build for trunk rev 1650 - the dev trunk. Its not a Windows TortoiseSVN file so I will be curious to see if its useful ?Thanks.
http://chdk.setepontos.com/index.php?topic=7409.msg81169;topicseen#msg81169 (http://chdk.setepontos.com/index.php?topic=7409.msg81169;topicseen#msg81169)
The only change that I made from his zip file was to change the case of the sub directory from 100C to 100c.
Okay - here's another orphan camera that should go into the svn as an alpha - the sx210is.
Based on the latest code in the forum <link here> (http://chdk.setepontos.com/index.php?topic=5045.msg69449#msg69449), I got these to build against both trunks and have posted the executables to the porting thread to see if someone will test them.
There as a couple of funky things with this port.
It wanted to create a propset5 but from the quick look I took, it seemed that was mostly because it started as propset3 and changes were made that seemed to result in something a lot like propset4. So I just changed it to use propset4.
I changed the stubs_entry_2.S file to not override addresses found by the new sig finder. However, there is something goofy going on with boot.c - several ROM subroutine addresses were added manually to stubs_entry_2.S because they were not picked up during the compile process. Some sort of address range issues ?
There are a few stubs_entry.S suggestions for different DEF() values. Also, several of the mode map values show up in stubs_entry.S as "not in current modemap".
Other than that, its a pristine port :)
Update : Deleted patch file for dev trunk as user testing says it does not run. Updated patch for stable trunk to use propset3 rather than propset4 based on user testing.
Not sure what you want to do about the trunk version?Give me a couple of days to see if I can "fix" the trunk version and get somebody to test it.
#define KEYS_MASK1 (0x000FFC05)into#define KEYS_MASK1 (0x000FFC0F)(for details, see the declaration of keymap[])I have a recommendation for the SX210 code: the camera's zoom lever has two speed steps, but only one of those is masked. I think this leads to undesired sideeffects.Is this tested ? If so, I could submit a patch (or you can - see below).
So, in its platform kbd.c I'd changeCode: [Select]#define KEYS_MASK1 (0x000FFC05)intoCode: [Select]#define KEYS_MASK1 (0x000FFC0F)(for details, see the declaration of keymap[])
I have ported two of the ancient cameras (Ixus30, A420) a while ago, but haven't "forced" them into svn yet (lack of useful feedback). If there's interest, I could update their code and post here.You might add a note about it here :
Is there a guide, what should be changed in a release 1.0 port for inclusion into trunk?Generally, if you can get it to build and it works, then a patch file for the svn is the preferred method for submission. If you are using Windows, tortoise svn works really well here. There are gui tools for linux as well but the command line is pretty simple. What you need to do is "svn co" (or checkout) the current stable trunk, make the changes for the new camera ( one at a time preferrably), make sure it builds and then use tortoise of the command line to make a patch file.
And another question: recently someone posted an updated S80 port. I don't see the source anywhere. Can someone politely ask for it :) ? (Yes, I could try myself, but I'm not always able to express myself clear enough, and don't even have that camera.)Link ?
I have a recommendation for the SX210 code
Is this tested ?No. I did a similar fix for the SX200 recently (it caused even crashes there). I have found confirmation about the "two speed" zoom via a web search AND the kbd.c lines also suggest the same. I'll post a question about this in the porting thread.
or you can puzzle it out by looking at other new kbd.c filesI think I'll do that.
Another new port - the A2100 fw 1.001a - by ac.n1bs. Hopefully will not also become an orphan port.
Patch file for dev trunk made from this link :
http://chdk.setepontos.com/index.php?topic=7433.msg81924#msg81924 (http://chdk.setepontos.com/index.php?topic=7433.msg81924#msg81924)
Loads and runs - boot.c, capt_seq.c completed - movie_rec.c stubbed out. Modemap needs work.
Update : added patch file for stable trunk (untested) - details about changes made in notes.txt file
Updates for A800 - stable and dev versions.
1) Dev version change is to allow CHDK to exist in EXMEM (low memory problems without that).
2) Stable version is the dev version "back ported" to stable-1_0 trunk and tested by Qanthelas.
Its a slow news day around here today so here's something I've been meaning to do for a while : remove the Beta designation from the IXUS120 / SD940.Done, 1732 and 1733
A420 for both trunk and release 1.0Thanks. Added in 1734,1735 and 1736.
I decided to designate it "alpha" because:
- I'm the only one who tested it (the "beta" releases have been downloaded 50+ times)
- Got a weird crash while testing it (photo overrides) with the reyalp-ptp-live branch (romlog seems to indicate a kernel crash involving spytask). Couldn't reproduce it...
Otherwise it should be as functional as the A430 port.
Index: platform/sx210is/main.c
===================================================================
--- platform/sx210is/main.c (revision 1737)
+++ platform/sx210is/main.c (working copy)
@@ -41,7 +41,7 @@
{ 62, 16200},
{ 78, 22300},
{ 102, 35900},
- { 125, 60000},
+ { 125, 70000},
};
#define NUM_FL (sizeof(fl_tbl)/sizeof(fl_tbl[0]))
@reyalp: thx.
Small correction for the SX210IS, as reported by new123456 here (http://chdk.setepontos.com/index.php?topic=5045.msg65652#msg65652). This model has 14x zoom. Maybe that's the reason behind this flood http://chdk.setepontos.com/index.php?topic=5045.msg82868#msg82868 (http://chdk.setepontos.com/index.php?topic=5045.msg82868#msg82868) :)Code: [Select]Index: platform/sx210is/main.c
===================================================================
--- platform/sx210is/main.c (revision 1737)
+++ platform/sx210is/main.c (working copy)
@@ -41,7 +41,7 @@
{ 62, 16200},
{ 78, 22300},
{ 102, 35900},
- { 125, 60000},
+ { 125, 70000},
};
#define NUM_FL (sizeof(fl_tbl)/sizeof(fl_tbl[0]))
And a small correction for SX10 1.00c: http://chdk.setepontos.com/index.php?topic=7831.msg82906#msg82906 (http://chdk.setepontos.com/index.php?topic=7831.msg82906#msg82906)
Croatian language for development and stable trunk.Done, #1749 (http://trac.assembla.com/chdk/changeset/1749/) and #1750 (http://trac.assembla.com/chdk/changeset/1750/).
Patches by waterwingz.
FWIW, for stuff like this that's pretty much the same for both branches, it's fine to just post one patch. Applying it to one and then merging to the other keeps the history of what is both trees clearer, and is no more work. Where the affected code is actually significantly different (e.g. the usb remote/kbd stuff) having independent patches is useful.Wondered about that. Especially as the two patch files turn out to be identical in my last post :D
Is it better to post for the stable branch and let you merge to the other or visa-versa ?Doesn't really matter, whichever one is most convenient for you.
Also, I guess ports to new cameras kind of sit on the side of needing both patch files ?I guess so. Maybe you could split it up, so there was one common set of changes, plus a patch to clean up one or the other. Since the platform kbd.c files are new, you could just include both the files, and the rest should be pretty manageable. Don't know if any of this is worth the effort.
Don't know if any of this is worth the effort.I kind of thought the stable branch would freeze after it was forked off. But the CHDK-DE and new cam stuff keeps creeping back in.
Index: platform/ixus200_sd980/platform_camera.h
===================================================================
--- platform/ixus200_sd980/platform_camera.h (revision 1773)
+++ platform/ixus200_sd980/platform_camera.h (working copy)
@@ -34,7 +34,6 @@
#define CAM_VIDEO_QUALITY_ONLY 1
#define CAM_BRACKETING 1
#undef CAM_VIDEO_CONTROL
- #undef CAM_HAS_IRIS_DIAPHRAGM
#define CAM_MULTIPART 1
#define CAM_HAS_JOGDIAL 1
#undef CAM_USE_ZOOM_FOR_MF
Hi dvip !
Although there's still many things out of whack in CHDK-Shell, this one definitely is an error in trunk 1772.
Try changing (in /CHDK/Makefile)Quotecp $(topdir)/CHDK/$(LOGO) $(topdir)/CHDK/DATA/$(LOGO)toQuotemkdir -p $(topdir)CHDK/DATA
cp $(topdir)CHDK/$(LOGO) $(topdir)CHDK/DATA/$(LOGO)
Actually, this is 2 errors:
1) no '/' needed after $(topdir)
2) trying to write to a non-existant dir /CHDK/DATA
hope that helps,
wim
Hi devs,
There appears to be a problem with trunk 1772
Patch to add IXUS 1000 102B firmware, please add to source
Here is patch for ixus 1000 that enable real auto ISO and focus overwrite in AF lock. Please add to chdk source
Small change to enable iris support on the Ixus200/SD980. Tested by hamfent: http://chdk.setepontos.com/index.php?topic=4335.msg83262#msg83262 (http://chdk.setepontos.com/index.php?topic=4335.msg83262#msg83262)Code: [Select]Index: platform/ixus200_sd980/platform_camera.h
===================================================================
--- platform/ixus200_sd980/platform_camera.h (revision 1773)
+++ platform/ixus200_sd980/platform_camera.h (working copy)
@@ -34,7 +34,6 @@
#define CAM_VIDEO_QUALITY_ONLY 1
#define CAM_BRACKETING 1
#undef CAM_VIDEO_CONTROL
- #undef CAM_HAS_IRIS_DIAPHRAGM
#define CAM_MULTIPART 1
#define CAM_HAS_JOGDIAL 1
#undef CAM_USE_ZOOM_FOR_MF
Patch to add IXUS 1000 102B firmware, please add to source
We need the firmware dump before committing to SVN (to make sure it all compiles correctly).
Can you provide a link to the firmware please.
Also this appears to be a patch for the main development (unstable) trunk, not the stable release-1.0 branch - is this correct?
Phil.
Added thefull 8MB dump (dumped with cBasic udumper) by mwvent82 from this forum post (http://chdk.setepontos.com/index.php?topic=650.msg83646#msg83646) to the box.net/chdk (http://www.box.net/chdk) repository.
- IXUS 1000 / SD4500 1.02B
Patch to add IXUS 1000 102B firmware, please add to source
We need the firmware dump before committing to SVN (to make sure it all compiles correctly).
Can you provide a link to the firmware please.
Also this appears to be a patch for the main development (unstable) trunk, not the stable release-1.0 branch - is this correct?
Phil.
Hi Phil
Apologies, I haven't contributed here before so wasn't too sure of the process
Have popped the FW dump here
http://wattz.dyndns.org/chdk/IXUS1000_SD4500_102B.BIN (http://wattz.dyndns.org/chdk/IXUS1000_SD4500_102B.BIN)
This seems stable to me, I would like to add it to that if possible so others with my FW can benefit from CHDK as I have :D - I've zipped the contents of trunk\platform\ixus1000_sd4500\sub\102b here if its easier then using the .patch file
http://wattz.dyndns.org/chdk/102b.zip (http://wattz.dyndns.org/chdk/102b.zip)
Hope this is ok?
Patch for sx220 mentioned here http://chdk.setepontos.com/index.php?topic=6397.msg83320#msg83320 (http://chdk.setepontos.com/index.php?topic=6397.msg83320#msg83320). I didn't have a single crash related to that since.
Also a cleanup of stubs_min.S and a kbd.c key fix that caused unintentional key presses when rotating the jogdial really fast.
chdk for s100: firmware versions 100d, 100e, 101a.
porting thread: http://chdk.setepontos.com/index.php?topic=7887.0 (http://chdk.setepontos.com/index.php?topic=7887.0)
There's still some todo (see platform/s100/notes.txt and/or any unknown bug that might come up as usual in software) but i think the build is ready for alpha or beta (i didn't test everything) :)
the attached patch is against svn-trunk
Small patch to IXUS120_SD940 for both stable and dev versions.
Patch adds #undef CAM_HAS_ERASE_BUTTON to platform_camera.h so that User Menu editing works properly.
adds A800 1.00B f/w version. Also affects 1.00c version with directory where RAW/DNG files are stored.
107 "Wersja CHDK: %s %s\nPoprawka: %s\nData: %s\nCzas: %s\nAparat: %s\nWersja FW: %s\nKompilator: %s"
A small patch to enable CAM_STARTUP_CRASH_FILE_OPEN_FIX for the G11, based on this report: http://chdk.setepontos.com/index.php?topic=8024.msg84630#msg84630 (http://chdk.setepontos.com/index.php?topic=8024.msg84630#msg84630) .
One line has to be changed in polish.lng. There was a bug with no-existing 'revision' line. Entry 107 should be as follow:Code: [Select]107 "Wersja CHDK: %s %s\nPoprawka: %s\nData: %s\nCzas: %s\nAparat: %s\nWersja FW: %s\nKompilator: %s"
BTW - the Revision entry shows value of '0' - what does this entry stand for?
EDIT: I'm talking about trunk version of CHDK, if this makes difference ;)
Added CAM_HAS_MOVIE_DIGEST_MODE to platform_camera.h.
Thanks.
chdk for ixus105_sd1300 firmware 100d only. see attachment for the patch.Thanks for doing this. I've checked into the trunk in changeset 1833 (http://trac.assembla.com/chdk/changeset/1833/trunk), with SKIP_AUTOBUILD set.
This is completely untested since i do not own the camera anymore.
I ported the code from SDM (since Microfunguy ported it from my first chdk port and tested it extensively) to current chdk-trunk so it doesn't get lost and maybe it helps others (e.g. ixus107 port).
Since it compiles correctly and i trust finsig i added it as ALPHA, but feel free to remove it if you are not ok with it.
greets
edit: updated patch with platform_camera.h which i forgot in previous commit
I didn't check notes.txt, but i guess it will need a rewrite after someone tests chdk :)chdk for ixus105_sd1300 firmware 100d only. see attachment for the patch.Thanks for doing this. I've checked into the trunk in changeset 1833 (http://trac.assembla.com/chdk/changeset/1833/trunk), with SKIP_AUTOBUILD set.
This is completely untested since i do not own the camera anymore.
I ported the code from SDM (since Microfunguy ported it from my first chdk port and tested it extensively) to current chdk-trunk so it doesn't get lost and maybe it helps others (e.g. ixus107 port).
Since it compiles correctly and i trust finsig i added it as ALPHA, but feel free to remove it if you are not ok with it.
greets
edit: updated patch with platform_camera.h which i forgot in previous commit
If someone with this camera can test confirm that it actually works to some extent, we could enable the autobuild. I'll post a binary in the development thread.
I was bit confused by the notes.txt, your post says it is untested, but the notes say somethings were tested. Also contradictory "some lua stuff" tested, and "load script = camera shutdown" :-[
Anyway, I added a note that this is unfinished, and also that the modemap is incorrect.
Patch to "fix" the jog dial direction in the G10 (stable & dev) per this thread :Forgot to post added in trunk changeset 1838 (http://trac.assembla.com/chdk/changeset/1831/trunk) and stable change 1841 (http://trac.assembla.com/chdk/changeset/1841/branches/release-1_0)
some fixes for s100 (trunk) - thanks funnel and colon247
This patch is to update the palette to 7 so that all menus are clearly readable.Added in trunk changeset 1851 (http://trac.assembla.com/chdk/changeset/1851/trunk)
EXMEM support for sx200isAdded in trunk changeset 1852 (http://trac.assembla.com/chdk/changeset/1852/trunk) and stable changeset 1853 (http://trac.assembla.com/chdk/changeset/1853/branches/release-1_0)
Forgot to post added in trunk changeset 1838 (http://trac.assembla.com/chdk/changeset/1831/trunk) and stable change 1841 (http://trac.assembla.com/chdk/changeset/1841/branches/release-1_0)I noticed anyway and didn't care about the G12 reference. Thanks.
(the commit message says g12... oops!)
sx200is SCREEN_COLOR changed (there was white background/text during playback mode).
Remove EdgeOverlay restrictions if CHDK in EXMEME.
Some corrections for the Ixus65/SD630:
- usb remote made operational (trunk version only)
- various framebuffer and other addresses corrected (makes motion detection work)
Patches for rev. 1.0 and trunk attached.
Correction of the module inspector closing (added draw_restore()).
Added "_" and "£" to the textbox.
Patch is here here (http://chdk.setepontos.com/index.php?topic=7272.msg85688#msg85688)
sx260 100b 100c stable version to be applyed into trunk please
sx200is_100cAdded in trunk changeset 1886 (http://trac.assembla.com/chdk/changeset/1886/trunk) release changeset 1888 (http://trac.assembla.com/chdk/changeset/1888/branches/release-1_0)
1. vid_bitmap_refresh() from ixus870_sd880, gives less flicker than original one.
2. custom palette (philmoz), so CAM_BITMAP_PALETTE changed from 3 to 13.
Now all missing colors are in place.
I copied my sx200is_100c dump here:Thanks.
https://skydrive.live.com/redir?resid=67C21A0ED1F7A310!161&authkey=!ACChwRvupSTR7Uo (https://skydrive.live.com/redir?resid=67C21A0ED1F7A310!161&authkey=!ACChwRvupSTR7Uo)
Added thefull 8MB dump (dumped with cBasic udumper) by ADamb from this forum post (http://chdk.setepontos.com/index.php?topic=650.msg86004#msg86004) to the box.net/chdk (http://www.box.net/chdk) repository.
- SX200 1.00C
Note: this 8MB full dump replaces the old 4MB one.
v1888 does not seem to work on my SX200. It shows only wellcome screen without CHDK, and after that black screen and does nothing. v1825 does work!I'd suspect
DEF(palette_buffer, 0x15B5A0)as MEMISOSTART is 0x12351C .v1888 does not seem to work on my SX200. It shows only wellcome screen without CHDK, and after that black screen and does nothing. v1825 does work!I have these on my sx200is:
Here comes last change - I switched from palette_buffer to palette_buffer_ptr, which can be found in disassembly.Thanks, added in trunkchangeset 1891 (http://trac.assembla.com/chdk/changeset/1891) release changeset 1892 (http://trac.assembla.com/chdk/changeset/1892)
Corrected connect 4 on 16:9 screens.
Patch file to add firmware 1.00c to the IXUS200_SD980 code (installs and builds on stable & dev versions).
Also contains updates to the 1.01c & 1.01d firmware versions based on information in the latest stubs_entry.S files for those versions.
Firmware 1.00c tested by forum member SvobodaT (http://chdk.setepontos.com/index.php?action=profile;u=13394). Updates to 1.01c & 1.01d are not tested but trivial.
Still needs testing to confirm that aperture_sizes_table[], shutter_speeds_table[], iso_table[], and modemap[] are correct. (modemap[] is not)
Here is a patch for the a3300 camera. I used diff with the -cbr options: c gives 3 lines of context, b ignores whitespace changes, and r recurses through the directories. I hope this is satisfactory.I notice that nobody has said anything about this? I also noticed that nobody has added this to the trunk either. So having submitted one or two patches myself I thought I'd add this note.
Things that can be applied easily without much thought tend to go in quickly. Things that aren't, get pushed to the back of the queue.Here is a patch for the a3300 camera. I used diff with the -cbr options: c gives 3 lines of context, b ignores whitespace changes, and r recurses through the directories. I hope this is satisfactory.I notice that nobody has said anything about this? I also noticed that nobody has added this to the trunk either.
The rejects turned out to be line ending issues, no big deal. However, there are some other questions so I haven't checked in. See comments on http://chdk.setepontos.com/index.php?topic=6972.msg86536#msg86536 (http://chdk.setepontos.com/index.php?topic=6972.msg86536#msg86536)Re the line endings issue -- is this due to the Windows habit of terminating lines with crlf versus *NIX's nl (new line)?
Re the line endings issue -- is this due to the Windows habit of terminating lines with crlf versus *NIX's nl (new line)?Somewhere along the line. Most of the source has the svn eol-style property set to "native" which means it will be either lf or crlf depending on the system you checked out on... but if you edit and change the line endings, it's ignored as long as they are consistent within the file.
Currently I am using a bastardized system that's partly Windows (due to starting with CHDK-Shell) and Linux. I am working toward dropping the Windows part and then should be more UNIX-Linux compatible, at least as far as line endings are concerned. Will that resolve the line endings issues you were seeing?If you do a fresh checkout under linux, then it should all be linux endings. If you intend to do much work in the source, I strongly suggest doing it inside an SVN working copy. Being able to update easily and diff your local modifications is really a big advantage.
Second question: I looked at some other patches and I thought they had been prepared by the gnu diff command with context enabled, so that's what I did. Doesn't svn also use the diff command?svn has it's own diff command (and tortoise has 'create patch'), which produces output compatible with diff but also includes branch / revision information. If the patch is from SVN, I can apply it using tortoise which has a nice gui merge interface.
Here is a patch for the a3300 camera.Added per discussion in the other thread, release changeset 1922 (http://trac.assembla.com/chdk/changeset/1922/branches/release-1_0)
Question: Wouldn't it be a good idea to change the message "ALT +/- debug action" to "ALT DISP debug action" so it is correct for THIS camera?If we could insert the actual key name in a generic way, that would be nice, but I don't want an #ifdef for each camera.
Question: Wouldn't it be a good idea to change the message "ALT +/- debug action" to "ALT DISP debug action" so it is correct for THIS camera?If we could insert the actual key name in a generic way, that would be nice, but I don't want an #ifdef for each camera.
fix build with edge overlay disabled, patch attachedThanks, added in trunk changeset 1927 (http://trac.assembla.com/chdk/changeset/1927)
Don't we already have the #ifdefs in gui.c - the debug shortcut uses SHORTCUT_TOGGLE_RAW?The entire label comes from a lang string. Of course it could be fixed, but I don't want to expend much effort or introduce a bunch of cruft just for a label on a debug shortcut.
In trunk changeset 1928 (http://trac.assembla.com/chdk/changeset/1928), I used find_eventproc to add GetVRAM*PixelsSize for all autobuild enabled vxworks cameras except forNo such event procedures here, but the values exist of course. Attached patch adds the required functionality for liveview, seems to work (but it's sloooow, so the usability is next to zero :D).
a410
Two small patch files related to USB Remote usage in the dev / unstable trunk.
1) Patch file to allow USB remote buffered values to be cleared (pulse widths, pulse counts, pulse seen) from a script or internal CHDK code. (will update wiki once accepted)
2) Patch file to allow USB remote sync and sync delay have effect when using scripts to monitor the USB port and shooting functions.
Patch files to add user adjustable <ALT> key for the older cameras that use platform/generic/kbd.c :
a410 a420 a430 a530 a540 a610 a620
a630 a640 a700 a710 ixus800_sd700
Stable & unstable trunk included.
Small cleanup for the G10 (stable and dev trunks). Fixes the default mask for the user selectable <ALT> key. Should not really affect anything unless the CCHDK.CFG file is missing - then it would be using the wrong mask by default.
Another apparently "orphan" port. Converted from stable to dev trunk compatibility. Builds but is not tested.
Submitted as "ALPHA" and tagged SKIP_AUTOBUILD.
As we discussed on IRC the stable branch (release-1.0) is only getting bug fixes now.thanks philmoz .. if someone wants the user selectable <ALT> for a stable branch camera that uses the platform/generic/kbd.c code , the patch file is still available as posted.
No such event procedures here, but the values exist of course. Attached patch adds the required functionality for liveview, seems to work (but it's sloooow, so the usability is next to zero :D).Added in trunk changeset 1934 (http://trac.assembla.com/chdk/changeset/1934).
Patch file to add f/w 1.00e to the ixus230_elph310hs port (stable or dev trunk).Thanks. Added in trunk changeset 1936 (http://trac.assembla.com/chdk/changeset/1936) and release changeset 1937 (http://trac.assembla.com/chdk/changeset/1937)
Based on code by mrks in this forum thread :
http://chdk.setepontos.com/index.php?topic=7149.msg86905#msg86905 (http://chdk.setepontos.com/index.php?topic=7149.msg86905#msg86905)
if SCREEN_DRAWINGS[n][1] == "r" then out[1]"rect" end
if SCREEN_DRAWINGS[n][1] == "rf" then out[1]"rectf" end
if SCREEN_DRAWINGS[n][1] == "r" then out[1]="rect" end
if SCREEN_DRAWINGS[n][1] == "rf" then out[1]="rectf" end
I've found a bug in the drawings.lua library in function get_params. There is:
Lines 83-84Code: (lua) [Select]if SCREEN_DRAWINGS[n][1] == "r" then out[1]"rect" end
if SCREEN_DRAWINGS[n][1] == "rf" then out[1]"rectf" end
There should be:Code: (lua) [Select]if SCREEN_DRAWINGS[n][1] == "r" then out[1]="rect" end
if SCREEN_DRAWINGS[n][1] == "rf" then out[1]="rectf" end
"=" sign missed.
I would like to ask for some advice.
There are cameras that can not handle subject distance override except in AF lock (or movie mode). At the moment, two of these (ixus1000_sd4500, ixus220_elph300hs) use a special code path in core/shooting.c, which is selected by the CAM_CAN_SD_OVER_IN_AF_LOCK define.
short shooting_can_focus()
{
int m=mode_get()&MODE_SHOOTING_MASK;
#if !CAM_CAN_SD_OVER_NOT_IN_MF && CAM_CAN_SD_OVERRIDE
#if CAM_CAN_SD_OVER_IN_AF_LOCK
if (shooting_get_prop(PROPCASE_AF_LOCK))
return 1;
else if (!MODE_IS_VIDEO(m))
return 0;
#elif CAM_HAS_VIDEO_BUTTON
return shooting_get_common_focus_mode();
#endif
return (shooting_get_common_focus_mode() || MODE_IS_VIDEO(m));
#elif !CAM_CAN_SD_OVERRIDE
return MODE_IS_VIDEO(m);
#elif defined (CAMERA_ixus800_sd700)
// TODO whats the reason for this ?!?
return (shooting_get_zoom()<8) && (m!=MODE_AUTO) && (m!=MODE_SCN_UNDERWATER);
#else
return 1;
#endif
}
The above function is used to check whether SD override is possible (AFAIK). The current code (without the green lines) doesn't prevent some cameras (A2200, Ixus850/SD800) from crashing even when CAM_CAN_SD_OVER_IN_AF_LOCK is defined.
The two green lines would be my additions, based on the report (http://chdk.setepontos.com/index.php?topic=8263.msg87088#msg87088) of an SD800 owner. (I'm unsure about the A2200, I haven't got the expected result from the test (see the previous posts) (http://chdk.setepontos.com/index.php?topic=6254.msg85723#msg85723)).
How should I / we deal with this situation? Create yet another codepath specific to the SD800, or modify CHDK behaviour when CAM_CAN_SD_OVER_IN_AF_LOCK is defined?
To be safe you should probably wrap them in a new #define and add that to your affected cameras.Thanks, I'll do that.
EnterTo/ExitFromCompensationEVF correction for A450 :)Added, trunk changeset 1956 (http://trac.assembla.com/chdk/changeset/1956/trunk) release changeset 1957 (http://trac.assembla.com/chdk/changeset/1957/branches/release-1_0)
The functions are correctly found by finsig, but were overridden - with a nasty typo (?). Applies to both trunk and 1.0 .
physw_status[0] &= ~alt_mode_key_mask; // press the VIDEO buttonphysw_status[2] &= ~alt_mode_key_mask; // press the VIDEO buttonPatch to add user configurable ALT key (Display or Playback keys) to the IXUS120-SD940 (dev trunk).Added, trunk changeset 1968 (http://trac.assembla.com/chdk/changeset/1968)
I've found an error in the text box. Attached is an image that shows the problem (the black part at the bottom (transparent) should be grey) and an patch to fix it.Added, trunk changeset 1969 (http://trac.assembla.com/chdk/changeset/1969)
Two small patches to correct what I believe is an incorrect cut&paste of code from the IXUS120 kbd.c file to the IXUS220 and IXUS230.Added in trunk changeset 1972 (http://trac.assembla.com/chdk/changeset/1972/trunk) release changeset 1973 (http://trac.assembla.com/chdk/changeset/1973/branches/release-1_0)
Submitted : a patch file to add the IXUS115_ELPH100HS fw 1.00c, 1.01a, 1.01b&1.01c to the dev trunk & autobuild.Added, trunk changeset 1977 (http://trac.assembla.com/chdk/changeset/1977)
Based on alpha5 port by Just.J posted here : http://chdk.setepontos.com/index.php?topic=6751.msg78653#msg78653 (http://chdk.setepontos.com/index.php?topic=6751.msg78653#msg78653)
Testing progress can be read in that thread.
Thanks to dnw (http://chdk.setepontos.com/index.php?action=profile;u=1178) for his patient testing, for working through all the little details necessary to complete the main.c and shooting.c files and well as his time spent getting the keymap values right. And finally, for confirming that the build works with the the validation scripts posted here : http://chdk.wikia.com/wiki/Testing (http://chdk.wikia.com/wiki/Testing)
Also props to RueLue and siak for testing each alpha release and reporting results in the forum.
ixus115_elph100hs : A small cleanup patch file to fix something left over from the debugging phase - the CAM_EMUL_KEYPRESS_DELAY value was set to approx 2 seconds rather than the default 0.4 seconds (as noted here : http://chdk.setepontos.com/index.php?topic=6751.msg87736#msg87736 (http://chdk.setepontos.com/index.php?topic=6751.msg87736#msg87736) )Added trunk changeset 1979 (http://trac.assembla.com/chdk/changeset/1979)
ixus130_sd1400 : Another orphan port, this one from the github :https://github.com/emlyn/chdkAdded, trunk changeset 1985 (http://trac.assembla.com/chdk/changeset/1985/trunk)
Converted for the dev trunk and marked Alpha - skip_autobuild for now.
Note : breaks the build as the current makefiles cannot handle the lower case letter assembler code in the C tasksI'll make that case insensitive in the next checkin.
Patch to fix LCD width value for ixus130_sd1400. Also unlinks some LED debug code.Added, trunk changeset 1992 (http://trac.assembla.com/chdk/changeset/1992). I restored some of the lib.c comments.
#define CAM_BITMAP_HEIGHT 270
IXUS130_SD1400 : Patch to fix values in both f/w version lib.c files - corrected to match sigfinder values for vid_get_viewport_fb() and for get_flash_params_count().Added trunk changeset 1997 (http://trac.assembla.com/chdk/changeset/1997)
Might help with one of the problems listed here : http://chdk.setepontos.com/index.php?topic=5034.msg88000#msg88000 (http://chdk.setepontos.com/index.php?topic=5034.msg88000#msg88000)
Update : modified patch to include :Code: [Select]#define CAM_BITMAP_HEIGHT 270
ixus130_sd1400 fw 1.00a & 1.00c patch to override sigfinder 1st choce value for GetDrive_FreeClusters with the 2nd choice.Added, trunk changeset 2000 (http://trac.assembla.com/chdk/changeset/2000)
see : http://chdk.setepontos.com/index.php?topic=5034.msg88092#msg88092 (http://chdk.setepontos.com/index.php?topic=5034.msg88092#msg88092)
Attached is a patch that changes the filebrowser so that it opens .txt files directly (like .flt's).
EDIT: I think you have forgotten my Snake patch: here (http://chdk.setepontos.com/index.php?topic=650.msg87543#msg87543)
Small cleanup to USB remote code to remove unused passed parameter. Tested with a complete build of all cameras.Added in trunk changset 2021 (http://trac.assembla.com/chdk/changeset/2021/trunk) release changeset 2023 (http://trac.assembla.com/chdk/changeset/2023/branches/release-1_1)
Patch to fix usb remote issues ( and possibly others ) with a490 port 1.00d and 1.00f versions based on accepting stubs_entry.S suggestions from finsig (thanks philmoz!).Holding off on this one until I know whether GetBatteryTemperature crashes.
Here (http://chdk.setepontos.com/index.php?topic=8263.msg87136#msg87136)'s my updated patch to prevent the possibility of a SD override related crash on the Ixus850/SD800. I think this code will need some cleanup in the future - but that would require tests on cameras none of the current developers have...
Patch to fix usb remote issues ( and possibly others ) with a490 port 1.00d and 1.00f versions based on accepting stubs_entry.S suggestions from finsig (thanks philmoz!).Added in trunk changeset (http://trac.assembla.com/chdk/changeset/2027/trunk) release changeset 2028 (http://trac.assembla.com/chdk/changeset/2028/branches/release-1_1), plus fixed _GetBatteryTemperature
The following patch hasn't been committed yet (as it doesn't affect any other model, I think it could go to both 1.1 and trunk. The patch still applies cleanly to 1.1 and almost cleanly to current trunk. The A2200 port is planned to also use this new code path.Thanks for the reminder, I'll add this when I get a chance.Here (http://chdk.setepontos.com/index.php?topic=8263.msg87136#msg87136)'s my updated patch to prevent the possibility of a SD override related crash on the Ixus850/SD800. I think this code will need some cleanup in the future - but that would require tests on cameras none of the current developers have...
Another issue: I noticed changeset 1988 (https://trac.assembla.com/chdk/changeset/1988/trunk), which made me do a little research.That's useful info, I knew the old way was bad, but never tested how bad. This probably affects live view performance too.
CAM_FIRMWARE_MEMINFO is only activated for the following cameras:
a2100, a540, a590, d10, g10, g12, g1x, ixus310_elph500hs, s100, s95, sx130is, sx20, sx30, sx40hs
With this enabled, my usual DIGIC II test cameras showed a big performance improvement during multi file upload over CHDK-PTP (for small files: about 1-2 second/file without CAM_FIRMWARE_MEMINFO, at least five times faster with it).
Don't know how this situation should be handled:I think turning it on for all dryos should be fine. I meant to do this before the least release but didn't get to it. In this post http://chdk.setepontos.com/index.php?topic=2509.msg66350#msg66350 (http://chdk.setepontos.com/index.php?topic=2509.msg66350#msg66350) I wanted to get a few more models tested, but I expect it's OK.
a) enable for all DryOS (i.e. trust the sigfinder)
b) enable for all
c) enable only individually, after tests
If it's c), I have tested it on 3 cameras, patch attached.
I think turning it on for all dryos should be fine. I meant to do this before the least release but didn't get to it. In this post http://chdk.setepontos.com/index.php?topic=2509.msg66350#msg66350 (http://chdk.setepontos.com/index.php?topic=2509.msg66350#msg66350) I wanted to get a few more models tested, but I expect it's OK.From a quick look, sys_mempart_id could be found by looking at an eventproc named "memShow" which is a wrapper for memPartShow. The latter needs sys_mempart_id as its first param. Haven't looked at a lot of dumps, but memShow seems to be present in all of them (except in Ixus30/40).
For vxworks, we need to find sys_mempart_id, which I haven't finished doing for all cameras. Baring typos, I think to should be safe to turn on for all that have been found.
As small patch to change the default <ALT> key for the ixus115 and ixus120 to be the Playback key (both cameras already implement user adjustable <ALT> keys).Added trunk changeset 2039 (http://trac.assembla.com/chdk/changeset/2039) release changeset 2040 (http://trac.assembla.com/chdk/changeset/2040)
Question : should we consider this for every camera that does not have a Print key ?I would like to standardize on play as much as possible, but I don't think it is urgent. If there are any left that use combos, I'd like to move away from that.
I would like to standardize on play as much as possible, but I don't think it is urgent. If there are any left that use combos, I'd like to move away from that.A quick grep of the current trunk for KEY_PRINT does not show any combos remaining.
A quick grep of the current trunk for KEY_PRINT does not show any combos remaining.
Looks like my "quick grep" was too quick. I see that one now too. That camera seems to set the record for having a minimum set of buttons! And the current method of getting into <ALT> mode looks really ugly to me. Unfortunately, the kbd.c file for that camera does not have the key code for the Playback key.A quick grep of the current trunk for KEY_PRINT does not show any combos remaining.ixus300/sd4000 KEY_UP + KEY_LEFT
Patches for sx200is 100c, revision 2034.Added, trunk changeset 2045 (http://trac.assembla.com/chdk/changeset/2045) release changeset 2046 (http://trac.assembla.com/chdk/changeset/2046). Note I modified this slightly, removing COLOR_GREY_BG which isn't defined/used anywhere else.
1. Add transparent grey to use for menu background, use custom palette in video playback mode.
2. PTP live support, CAM_FIRMWARE_MEMINFO.Added, trunk changeset 2047 (http://trac.assembla.com/chdk/changeset/2047) release changeset 2048 (http://trac.assembla.com/chdk/changeset/2048)
One more fix for the IXUS115 user defined ALT function. Hopefully the last - its a pain not having the camera to test with.Added, trunk changeset 2049 (http://trac.assembla.com/chdk/changeset/2049) release changeset 2050 (http://trac.assembla.com/chdk/changeset/2050)
ixus300/sd4000 KEY_UP + KEY_LEFTTwo more "User Defined ALT key" patches using the KEY_PLAYBACK values found by the most recent sigfinder update (thanks to philmoz & srsa_4c).
-#elif defined(CAMERA_ixus120_sd940)
- static const char* names[]={ "Display", "Playback" };
- static const int keys[] = {KEY_DISPLAY, KEY_PLAYBACK };
+#elif defined(CAMERA_ixus120_sd940) || defined(CAMERA_ixus105_sd1300)
+ static const char* names[]={ "Playback", "Display", "Playback" };
+ static const int keys[] = {KEY_PRINT, KEY_DISPLAY, KEY_PLAYBACK};
ixus300/sd4000 KEY_UP + KEY_LEFTTwo more "User Defined ALT key" patches using the KEY_PLAYBACK values found by the most recent sigfinder update (thanks to philmoz & srsa_4c).
Adds adjustable ALT to the ixus300_sd4000 (replaces the existing combo key sequence) and the ixus100_sd780 (because its a twin to my SD940).
Builds but untested in camera so a quick eyeball check of the changes is probably in order.
easier than i thought, diff attached, apply after the previous one
fixes for ixus105:
- wrong free space counter
- startup fail
I have finally found a little time for posting new version of EDI. I've been using this version for some time so it should be OK. Might be added to the trunk and stable release (since it now contains new Lua functions - file_browser() and textbox()).
Some bugs were fixed, some features added. Changelog in the script file.
Regards!
Update for czech files and A580.
Submitted is a medium size patch to allow adding script selections to the User Menu. I'd like to see this added to the dev branch (although I have a patch for the current stable branch too).
Having played with tsvstar's new menu system today, I've become convinced that this patch will still be useful & compatible. Tsvstar's version still supports the User Menu and I think something like this might be important for user's who do not want to edit a text config file on their computer (or via the Lua text editor) and who still want to add and remove scripts from their user menu (without redefining their whole menu system).
( This takes nothing away from tsvstar's menu system - it seems to be very nice and useful to me ! )
fix dng header for ixus105, patch in this post: http://chdk.setepontos.com/index.php?topic=5720.msg89496#msg89496 (http://chdk.setepontos.com/index.php?topic=5720.msg89496#msg89496)
also, currently the ixus105 build is disabled, i think it can be safely enabled as alpha or beta, only movie override is missing, everything else should be working as expected
A small patch to the A3300 to flag the camera as not having an "erase" button.Done for both, in 2121 and 2122
Should work in stable & dev trunks. I suppose it could be applied to the a3200 as well. Same problem there.
Second update for czech files and A580.Added a580 updates to trunk changeset 2124 (http://trac.assembla.com/chdk/changeset/2124) and stable changeset 2126 (http://trac.assembla.com/chdk/changeset/2126)
snake[snake_tail][1] * SNAKE_ELEMENT_SIZE+SNAKE_ELEMENT_SIZE-1, COLOR_WHITE);
snake[snake_tail][1] * SNAKE_ELEMENT_SIZE+SNAKE_ELEMENT_SIZE-1, MAKE_COLOR(COLOR_WHITE,COLOR_WHITE));
Submitted : A1200 fw 1.00b & fw 1.00c - Beta version for inclusion in autobuild of stable & dev trunks.Added, trunk changeset changeset 2128 (http://trac.assembla.com/chdk/changeset/2128), release changeset 2129 (http://trac.assembla.com/chdk/changeset/2129)
Small fix to last A1200 port (with parrallel A2200 correction). Custom colors now enabled and redundant #define for colored icons removed.Added trunk changeset 2132 (http://trac.assembla.com/chdk/changeset/2132) release changeset 2133 (http://trac.assembla.com/chdk/changeset/2133)
I wonder if that color A1200 patch can also fix the A590is color palette. I get sometimes different colors from what was selected in menus...No, this was due to the wrong line getting deleted in platform_camera.h
I wonder if that color A1200 patch can also fix the A590is color palette. I get sometimes different colors from what was selected in menus...This is probably the wrong thread to discuss this but the recent ability to define user specified custom color palettes "slipped" into the code for recent ports only. Isn't going to work on my three year old cameras (or likely anything older) without a substantial amount of additional work.
sx240hs fw 1.00a & fw 1.00c - Alpha version for dev trunk.Hi nafraf. Thanks for making these. I still have to resolve the question of how to deal with these different PID but identical code models in the source.
sx260hs fw 1.00b & fw 1.00c - Alpha version for dev trunk.
sx240hs fw 1.00a & fw 1.00c - Alpha version for dev trunk.
sx260hs fw 1.00b & fw 1.00c - Alpha version for dev trunk.
No specific problem, I'll try to look at it today.sx240hs fw 1.00a & fw 1.00c - Alpha version for dev trunk.
sx260hs fw 1.00b & fw 1.00c - Alpha version for dev trunk.
Push...
What is the problem with this patch? I think it's important to have a 2012 camera as base for other cameras from this year.
Btw, rudi has improved also the GPS functions, what is included in this patch.
msl
sx240hs fw 1.00a & fw 1.00c - Alpha version for dev trunk.Added to trunk in changest 2145 (http://trac.assembla.com/chdk/changeset/2145) and changeset 2146 (http://trac.assembla.com/chdk/changeset/2146). Thanks for the nice clean patch
sx260hs fw 1.00b & fw 1.00c - Alpha version for dev trunk.
Patch to "add" 1.00a firmware to the A1200 port. The 1.00a is identical to the 1.00b so that is noted in camera_list.csv and the prototype C files in the platform/a1200/sub/100a have been deleted.
Patch to enable dual partition support for the A1000.Thanks. Trunk changesets 2149 (http://trac.assembla.com/chdk/changeset/2149), 2150 (http://trac.assembla.com/chdk/changeset/2150) and 2151 (http://trac.assembla.com/chdk/changeset/2151) release changeset 2152 (http://trac.assembla.com/chdk/changeset/2152)
Hello!Thanks. Added in trunk changeset 2155 (http://trac.assembla.com/chdk/changeset/2155) release changeset 2156 (http://trac.assembla.com/chdk/changeset/2156)
Attached patch for s100 (reference post: chdk.setepontos.com/index.php?topic=7887.msg90910#msg90910 (http://chdk.setepontos.com/index.php?topic=7887.msg90910#msg90910))
- Adds the 'ring func.' button as the erase button
- Fixed spacing in keymap array (got rid of tabs)
- Un-undefs CAM_HAS_ERASE_BUTTON
Should apply both to trunk and the 1.1 release.
Attached a small patch to a495:Added trunk changeset 2159 (http://trac.assembla.com/chdk/changeset/2159) release changeset 2160 (http://trac.assembla.com/chdk/changeset/2160)
- Modemap table corrected, new stubs_entry.S generated for 1.00d, 1.00e, 1.00f
- Some #define needed for optical zoom were added
- PARAM_EXPOSURE_COUNTER deleted.
a810 fw 1.00b & fw 1.00d - Alpha version for dev trunk.Added to trunk in changeset 2168 (http://trac.assembla.com/chdk/changeset/2168)
a3200 fw 1.00a/fw 1.00c - Alpha version for dev trunk.Added in trunk changeset 2169 (http://trac.assembla.com/chdk/changeset/2169) release changeset 2173 (http://trac.assembla.com/chdk/changeset/2173)
a3200 fw 1.00d - Source cleanup and unlock optical zoom during video added.
sx150 patch as reported here : http://chdk.setepontos.com/index.php?topic=6953.msg91147#msg91147 (http://chdk.setepontos.com/index.php?topic=6953.msg91147#msg91147)Added in trunk changeset 2170 (http://trac.assembla.com/chdk/changeset/2170) release changeset 2174 (http://trac.assembla.com/chdk/changeset/2174)
patch for a810a810 fw 1.00b & fw 1.00d - Alpha version for dev trunk.Added to trunk in changeset 2168 (http://trac.assembla.com/chdk/changeset/2168)
Note that the empty clobber list in _rand was not accepted by the compiler on the autobuild server. It was fine with gcc 4.5.1 I'm using on my main dev machine, but not on the 4.3.2 I have on my laptop. It seems to me it's also incorrect that this function has no clobbers, so I've "fixed" it by adding r0,r1 and r2 to the clobber list.
This function should just be re-written in C, and added in wrappers .c under a CAM_MISSING_RAND ifdef or something like that.
patch for a810
- CAM_MISSING_RAND added to include/camera.h
- srand() and rand() implemented in C and added to platform/generic/wrappers.c under #ifdef CAM_MISSING_RAND
- a810/platform_camera.h modified to use CAM_MISSING_RAND.
- srand() and rand() removed from platform/a810/lib.c
Update for the readme.txt file (included in every build) in response to recent newbie confusion from the out-of-date instructions posted there.
a2200 100b/100c/100d
Patch created from source files posted by Nilinhim here (http://chdk.setepontos.com/index.php?topic=6254.msg91268#msg91268)
Additionally, exmem was disabled in 100d, as was done in 100b.
patch to a490 100d. typo. Reported here (http://chdk.setepontos.com/index.php?topic=8753.msg91487#msg91487)Added in trunk changeset 2187 (http://trac.assembla.com/chdk/changeset/2187/trunk) release changeset 2188 (http://trac.assembla.com/chdk/changeset/2188/branches/release-1_1)
Update to the ixus130_sd1400 - fw 1.00a & 1.00cAdded, trunk changeset 2193 (http://trac.assembla.com/chdk/changeset/2193/trunk), release changeset 2194 (http://trac.assembla.com/chdk/changeset/2194/branches/release-1_1)
* ixus230 100a new portAdded trunk changesets 2195 (http://trac.assembla.com/chdk/changeset/2195/trunk), 2196 (http://trac.assembla.com/chdk/changeset/2196/trunk) release changeset 2197 (http://trac.assembla.com/chdk/changeset/2197/branches/release-1_1)
* Patch for ixus230 100b and 100e to fix zebra, and control unlimited video time using menu (in previous version it was always enabled).
Discussion here (http://chdk.setepontos.com/index.php?topic=7149.msg91334#msg91334)
patch to ixus115_elph100hs 101aI've deferred this one for the moment. Right now, we don't have a good way to make compile time optional features specific to a particular sub, without enabling it for the others. In any case, I rather not do this because it makes everything more confusing.
- Fix to zoom lock during video recording.
- Extended video time added
Reports here (http://chdk.setepontos.com/index.php?topic=6751.msg91202#msg91202)
patch to a810 100b and 100dAdded to trunk in changeset 2209 (http://trac.assembla.com/chdk/changeset/2209)
a495 patch to fix palette in chdkptp liveviewAdded to trunk in changeset 2210 (http://trac.assembla.com/chdk/changeset/2210)
Maybe this one is worth of adding to the source: http://chdk.setepontos.com/index.php?topic=8797.0 (http://chdk.setepontos.com/index.php?topic=8797.0) Has been published in new thread by new user instead of posting it here.Added with changeset #2214 (http://trac.assembla.com/chdk/changeset/2214/)
Patch to fix palette in ixus115. Tested in firmware version 101aAdded in trunk changeset 2217 (http://trac.assembla.com/chdk/changeset/2217) release changeset 2218 (http://trac.assembla.com/chdk/changeset/2217)
Fix for the ixus90_sd790 per this thread : http://chdk.setepontos.com/index.php?topic=8835 (http://chdk.setepontos.com/index.php?topic=8835)Added, trunk changeset 2219 (http://trac.assembla.com/chdk/changeset/2219) release changeset 2220 (http://trac.assembla.com/chdk/changeset/2220)
sx260 101a port.Added, trunk changeset 2221 (http://trac.assembla.com/chdk/changeset/2221) release changeset 2222 (http://trac.assembla.com/chdk/changeset/2222)
Comments, feedback and test log files are available here (http://chdk.setepontos.com/index.php?topic=7889.msg92180#msg92180)
a810 100e port
Thanks to beta testers.
a3400 101a port
Tester sent logs generated for test scripts, but after that I did not receive more feedback. So, the patch was created with SKIP_AUTOBUILD option enabled.
Sorry, this time the patch includes the loader directory.a3400 101a port
Tester sent logs generated for test scripts, but after that I did not receive more feedback. So, the patch was created with SKIP_AUTOBUILD option enabled.
Patch is missing the loader directory contents for the a3400.
Phil.
a810 100e port
Thanks to beta testers.
Sorry, this time the patch includes the loader directory.a3400 101a port
Tester sent logs generated for test scripts, but after that I did not receive more feedback. So, the patch was created with SKIP_AUTOBUILD option enabled.
Patch is missing the loader directory contents for the a3400.
Phil.
IXUS220_ELPH300 patch to add USB sync per http://chdk.setepontos.com/index.php?topic=6341.msg92525#msg92525 (http://chdk.setepontos.com/index.php?topic=6341.msg92525#msg92525)
Hook for noise reduction added but commented out pending testing per http://chdk.setepontos.com/index.php?topic=8810.msg92353#msg92353 (http://chdk.setepontos.com/index.php?topic=8810.msg92353#msg92353)
Update to extend video time limts for A1200 fw 1.00b & 1.00c - 1.1.0 and dev trunk.
Also includes two small changes to english language file to clean up video menu wording and let warning message fit on screen.
Patch to a2200 to add adjustable alt button, and remove SKIP_AUTOBUILD for 100d.
It was tested by nedhorning in 100d firmware, report was done here (http://chdk.setepontos.com/index.php?topic=6254.msg92772#msg92772)
A small patch to add a2200 100b to autobuild.
Thanks to ahull, and Scottydog for testing.
Patches for the A3100 and A3150, firmware versions 100b and 100d. The 100b is marked 'SKIP_AUTOBUILD' as it is untested, the 100d is a stable alpha. The A3100 & A3150 are identical.
Thanks ahull for testing, and waterwingz for preparing the source!
And the original porters of the A490 and A3000!
Patches for ixus105 100c done by casrap:
- Modemap completed
- movie_rec.c created
- active area update
Port for ixus105 100b, tested by branislav.zember and reported here (http://chdk.setepontos.com/index.php?topic=5720.msg93282#msg93282)
a1300 100d port
Tested by Gerryve7bgp (http://chdk.setepontos.com/index.php?action=profile;u=24008), reports here (http://chdk.setepontos.com/index.php?topic=8909.msg93231#msg93231)
Bur where is the 101c folder in ixus115hs???cross posted here : http://chdk.setepontos.com/index.php?topic=845.msg93479#msg93479 (http://chdk.setepontos.com/index.php?topic=845.msg93479#msg93479)
Patch to sx240/sx260:
- #define MKDIR_RETURN_ONE_ON_SUCCESS added to platform_camera.h.
- sx240/sx260 100c - Fix pointer to DeleteFile_Fut in stubs_entry_2.S
- sx240 101a port. Tested by JamesBMI6 (http://chdk.setepontos.com/index.php?action=profile;u=24626) and Uran (http://chdk.setepontos.com/index.php?action=profile;u=24645), reports here (http://chdk.setepontos.com/index.php?topic=7928.msg93274#msg93274)
Hello,
here ist the first version of the SX50HS port (1.00b, ALPHA version with SKIP_AUTOBUILD configuration).
Patch is created based on trunk revision 2289. The diff includes also a small change for tools/packfi2/fi2enc.c (DryOS R51 also needs the "extra value" as R50 to get PS.FI2 working).
small patch to fix PLATFORMID in sx240 101aAdded, changesets 2298 and 2299.
Overrides only work when the self timer is off, when you select a self timer of 2 or 10sec (or custom) overrides are ignored. Sometimes it takes one shot with timer+overrides, but all the next shots are again without overrides.
patch ixus105 to solve this bug, found and fixed by casrapQuoteOverrides only work when the self timer is off, when you select a self timer of 2 or 10sec (or custom) overrides are ignored. Sometimes it takes one shot with timer+overrides, but all the next shots are again without overrides.
I prepared the patch and ported the code to 100b.
Patch was tested in 100d, but it was not tested in 100b.
p.s. Could the problem be due to dark frame subtraction? With brief shutter time i have never had a problem.is true, the file counter is sometimes already correct when the raw hook is reached. In that case r2308 will enforce the maximum delay. Partial proposal below. Partial = some affected ports (like the Ixus220) do not currently call the NR hook, those will need an additional #define in capt_seq.c. I might be still missing something, that's the reason why I'm posting here.
@philmoz
About changeset 2308: If the followingp.s. Could the problem be due to dark frame subtraction? With brief shutter time i have never had a problem.is true, the file counter is sometimes already correct when the raw hook is reached. In that case r2308 will enforce the maximum delay. Partial proposal below. Partial = some affected ports (like the Ixus220) do not currently call the NR hook, those will need an additional #define in capt_seq.c. I might be still missing something, that's the reason why I'm posting here.
Small patch for the SX150IS to fix the file counter issue (thread starts here (http://chdk.setepontos.com/index.php?topic=6953.msg93407#msg93407), success report here (http://chdk.setepontos.com/index.php?topic=6953.msg93587#msg93587)).
When I looked at this I started out recording the before and after file counter values to see how often the loop went to the full delay period. On the cameras I have that are affected by this it happened very rarely so I decided to stick with a simple solution. It's no worse than the previous code and in most cases exits the loop after 10 - 20ms.I don't have direct experience with this as AFAIK none of my DryOS cams is affected. It's also not a question that it's better than the fixed delay.
There's no guarantee that capturing the file counter in capt_seq_hook_set_nr will behave any differently - the call to this is not that much earlier than the call to capt_seq_hook_raw_here and there is no sleep between themcapt_seq_hook_set_nr, wait_until_remote_button_is_released are all called before the shot, the raw hook is called after it. I've traced back the update of the file counter param on a DryOS cam (don't remember which, maybe A470), and it seems that the task responsible for it is DvlpSeqTask.
so in all likelihood it would get the same file counter value.That could be true, I don't know when the other task decides to increment the counter, the shot will happen anyway at that point. shooting_expo_param_override is called before decision, but it's in a different source module and in some ports it might even be skipped, so it's probably not entirely reliable (could result in overwritten files).
for i=1,10 do
print_screen(-1)
print ("testing",i)
print_screen(false)
--sleep(100)
endA small patch to
- fix up a problem with the print_screen() function in Lua
- close any open log file when logging is turned off (i.e. print_screen(false) or print_screen(0) or print_screen 0)
Currently script_print_screen_statement(n) in core/scripts.c opens a log file named LOG_nnnn.TXT in overwrite mode if n>0 or in append mode if n<0. If n=0 it disables logging (but does not close any open log files).
In luascript.c, luaCB_print_screen(n) adds 10000 to the passed value of n from the print_screen(n) function call before calling script_print_screen_statement(n). There is no (obvious) reason why it does this as the log file name uses only the 4 least significant digits. However, it means that you need to specify n < -10000 if you want to open a log file in "append" mode using print_screen() in Lua.
The corresponding uBASIC statement treats any negative number as a request for a log file in append mode.
Patch should not break any existing code although the file numbers created using print_screen() in lua will sometimes be different.
a1300 100e port
Firmware dump (http://chdk.setepontos.com/index.php?topic=8909.msg93819#msg93819) and test done by calculusrunner (http://chdk.setepontos.com/index.php?action=profile;u=24706)
This port is a copy of a810 100e, but with the PLATFORMID=12862.
a495 new loader patch. Tested using a495 100f.
A series: A590-101b, A620-100f, A630-100c
ixus series: ixus70_sd1000-101b, ixus115_elph100hs-101b, ixus220_elph300hs-100c
ixus230_elph310hs-100b, ixus300_sd4000-100c, ixus870_sd880-101a
S series: S95-100h
svn diff > patch.patch patch to a495 and a810
a495
Removed references to the RESTARTSTART in makefile.inc 100d, 100e, 100f
a810
New loader implemented, boot tested using 100b, 100d, 100e
EXMEM_BUFFER_SIZE and MEMISOSTART set to the values for 1mb buffer. As reported here (http://chdk.setepontos.com/index.php?topic=8450.msg92969#msg92969) by SnowLeopard
I think that a810 can be released as beta now.
New loader patch forQuoteA series: A590-101b, A620-100f, A630-100c
ixus series: ixus70_sd1000-101b, ixus115_elph100hs-101b, ixus220_elph300hs-100c
ixus230_elph310hs-100b, ixus300_sd4000-100c, ixus870_sd880-101a
S series: S95-100h
Patch attached here (http://chdk.setepontos.com/index.php?topic=9027.msg93896#msg93896)
Warning: created with gnu diff - I did include a stripped version which hopefully works for you guys,
although the /resetcode dirs will need to be removed manually afterwards.
By the way, nafraf's a495 patch in post #905 also appears to have left an (empty) /resetcode dir in
trunk 2328.
wim
Patch for new loader code : G10, A1200, IXUS120_SD940
This patch file seems to clear content of the files in cam/resetcode directory rather than delete them or the subdirectory itself ? Not sure what I can/should do different ?Code: [Select]svn diff > patch.patch
New loader patch for the A720 & SX220
where can I find chdk for canon sx 160http://chdk.setepontos.com/index.php?topic=9041.msg93965#msg93965 (http://chdk.setepontos.com/index.php?topic=9041.msg93965#msg93965)
All added in revision 2329 - thanks everyone.
Phil.
Implementations for A720, A1200, G10, ixus120_sd940, SX220hs and TX1 appear to missNice cleanup - thanks. Should not change the compiled code - just deletes an unused compile option.
the mods in /platform in trunk 2329 (ie. removal of RESTARTSTART - see attachment for fixes)
Implementations for A720, A1200, G10, ixus120_sd940, SX220hs and TX1 appear to missAdded in trunk changeset 2342 (http://trac.assembla.com/chdk/changeset/2342)
the mods in /platform in trunk 2329 (ie. removal of RESTARTSTART - see attachment for fixes)
ixus105 100c port
The port includes the new loader code posted by whim here (http://chdk.setepontos.com/index.php?topic=650.msg93986#msg93986).
Tested by chispiao, testing script log files are attached.
- long length = blob_chdk_core_size;
+ long length = (blob_chdk_core_size + 3) >> 2;
A small patch that includes:
- a1300 new loader patch, created by whim, tested using a810 (a1300 and a810 are CHDK compatible)
- fix to length variable in loader/a810/main.c, bug found after see a1300 patch.Code: [Select]- long length = blob_chdk_core_size;
+ long length = (blob_chdk_core_size + 3) >> 2;
edit:
attachment updated, to fix comment in loader/a810/main.c
Hello,
i made some changes for the SX210IS, so now it's working (again?).
Please see my other post: http://chdk.setepontos.com/index.php?topic=5045.msg94252#msg94252 (http://chdk.setepontos.com/index.php?topic=5045.msg94252#msg94252)
I also included diffs and if the diffs fail somehow, i also included the changed files.
Since most of the changes are trivial, and it gets the camera working (i use it with these patches for some days now without problems), it would be nice to see it activated in autobuild.
(Recent autobuild builds will probably encourage more sx210is users to contribute then probably :D)
-- pux
See my comments in the other thread - http://chdk.setepontos.com/index.php?topic=5045.msg94274#msg94274 (http://chdk.setepontos.com/index.php?topic=5045.msg94274#msg94274)
Phil.
QuoteSee my comments in the other thread - http://chdk.setepontos.com/index.php?topic=5045.msg94274#msg94274 (http://chdk.setepontos.com/index.php?topic=5045.msg94274#msg94274)
Phil.
Hey Phil,
thanks for your input, i fixed it:
http://chdk.setepontos.com/index.php?topic=5045.msg94294#msg94294 (http://chdk.setepontos.com/index.php?topic=5045.msg94294#msg94294)
(also uploading same .diff here)
Patches to remove 10 second USB remote timeout while "half pressed" (for both trunk and stable).Added, trunk changeset 2367 (http://trac.assembla.com/chdk/changeset/2367) release changeset 2368 (http://trac.assembla.com/chdk/changeset/2368)
See http://chdk.setepontos.com/index.php?topic=7127.msg94248#msg94248 (http://chdk.setepontos.com/index.php?topic=7127.msg94248#msg94248)
a1300 100b port
Firmware dump and tests thanks to aladar (http://chdk.setepontos.com/index.php?action=profile;u=24806)
sx260 100b patch to fix long exposure time.
Bug detected by lapser, reported here (http://chdk.setepontos.com/index.php?topic=9113.msg94567#msg94567)
written by whimSorry for being off topic, but there's only 1 person who has written this patch, and that's philmoz (See here (http://chdk.setepontos.com/index.php?topic=9027.msg93857#msg93857))
sx260 new loader patch, written by whim, tested by lapser on sx260 100b.
Fix for USB remote V2 operation for the S3is per this post :
http://chdk.setepontos.com/index.php?topic=9169.msg94874#msg94874 (http://chdk.setepontos.com/index.php?topic=9169.msg94874#msg94874)
Patch works for both 1.1 and dev trunks.
A couple of small patches for two of the four "default" scripts included with CHDK. Those scripts are included in CHDK as the simplest possible examples of things people might want to do with CHDK. However, I've noticed that they have become somewhat more than that to new users of CHDK. They are often assumed to be the correct (if simple) way to do these things.
So I'd like to propose the smallest possible update to address issues I've seen posted. My intent is not to produce better more complicated scripts. There are hundred of each on the wiki & forum already and any "improvements" can take us down a slippery slope likely to end up in flame-wars. So these proposed updates are just to make two of the existing scripts a little more usable.
The first update is to make the threshold and delay values in the motion.bas & motion.lua scripts into parameters. These are typically the two values people need to adjust to get reasonable motion detection performance.
The second update is add an adjustment (in 1/2 f-stop increments) to the hdr.bas & hdr.lua scripts. This will let users adjust the amount of exposure range that the hdr scripts use.
Should be trivial enough to add to both the main trunk and dev branches ?
Both added in revision 2411 (trunk) and 2412 (release-1.1).Sure - today the patches get added quickly :'(
Both added in revision 2411 (trunk) and 2412 (release-1.1).Sure - today the patches get added quickly :'(
Realized as I was driving home that the changes to the HDR script work in full f-stops rather than half stops. This corrects the patched script for half stops.
TIA.
Fix for USB remote for the ixus750_sd550 per http://chdk.setepontos.com/index.php?topic=9169.msg94984#msg94984. (http://chdk.setepontos.com/index.php?topic=9169.msg94984#msg94984.)
Patch should be good for both stable and dev branches.
Small patch to narrow the menu border width for the A1200 and IXUS120_SD940 so that menu text does not truncate.
Patch file works for both dev and stable branches.
sx230 new loader patch tested by true (http://chdk.setepontos.com/index.php?action=profile;u=2674) on sx230 1.01c
Patch files to correct bug with bracketing mode not timing out correctly when used by USB remote. Also extends the timeout interval from 5 to 10 seconds to allow a little more time between shots prior to a reset.
Patch for stable version is a minimal fix and will hit the same 1 second bug fixed in rev 2104 of dev trunk.
Patch for dev version is complete. Includes a small code cleanup.
Tested on G10, IXUS120_SD940 and A1200.
a610 and a570 new loader patch, thanks to OhmEye for testing.
a3100 100a alpha port and a3100 new loader tested. Pacth created from source posted by casrap here (http://chdk.setepontos.com/index.php?topic=5560.msg95553#msg95553)
Patch file for unstable 1.2.0 branch to clean-up some old #defines related to USB remote per this old thread : remote #defines (http://chdk.setepontos.com/index.php?topic=5851)
These old #undefs now cause problem in 1.2.0 per this thread :
http://chdk.setepontos.com/index.php?topic=7127.msg95640#msg95640 (http://chdk.setepontos.com/index.php?topic=7127.msg95640#msg95640)
In the unstable branch, #undef CAM_REMOTE causes the Remote Parameters menu to not appear. In previous versions it only removed the submenu from the Scripting menu and disabled the USB remote OSD display.
Change removes all references to CAM_REMOTE and CAM_SYNCH from the platform_camera.h files. You can stil disable the Remote Parameters menu with #undef CAM_REMOTE should somebody want to do so in the future.
Patches (1.1.0 and 1.2.0) for USB Remote Bracketing function per this post : http://chdk.setepontos.com/index.php?topic=7127.msg95671#msg95671 (http://chdk.setepontos.com/index.php?topic=7127.msg95671#msg95671)
Hello there,
here are the patches for porting S100 to the new loader code:
1) https://github.com/c10ud/CHDK/commit/a94ca402bf13c11ac473bd8c49c38a41fc78c6da.patch
2) https://github.com/c10ud/CHDK/commit/a8ad484aa8d8268d7592dfec370ffc35268e3eaf.patch
edit - if you don't want meta-data:
1) https://github.com/c10ud/CHDK/commit/a94ca402bf13c11ac473bd8c49c38a41fc78c6da.diff
2) https://github.com/c10ud/CHDK/commit/a8ad484aa8d8268d7592dfec370ffc35268e3eaf.diff
Phil, i know how to use a forum (:)) but that's not exactly an external hosting site: each link directly refers to a commit in a git repository (mine) which fits my workflow better.Hello there,
here are the patches for porting S100 to the new loader code:
1) https://github.com/c10ud/CHDK/commit/a94ca402bf13c11ac473bd8c49c38a41fc78c6da.patch
2) https://github.com/c10ud/CHDK/commit/a8ad484aa8d8268d7592dfec370ffc35268e3eaf.patch
edit - if you don't want meta-data:
1) https://github.com/c10ud/CHDK/commit/a94ca402bf13c11ac473bd8c49c38a41fc78c6da.diff
2) https://github.com/c10ud/CHDK/commit/a8ad484aa8d8268d7592dfec370ffc35268e3eaf.diff
Added in revision 2487 (trunk) and 2488 (release-1.1).
It's preferable to upload the patch files directly to the posts in this thread rather than an external hosting site. Click the 'Preview' button when creating a message - there is a section to add attachments.
Phil.
I have a proposal which would be of help for cameras that have too few buttons (and no touchscreen). This would enable normal camera use for inexperienced users, and also enable more comfortable camera control for those who don't mind that the camera's On/Off button behaves differently when in ALT mode.If I understand the patch file correctly, this allows the On/Off button to substitute in <ALT> mode for one of the buttons that the CHDK code expects the camera to have but which is in fact not available on that camera. Is that right ?
patch to sx110is 100b: new loader tested and exp_drv task implemented.
Report and comments here (http://chdk.setepontos.com/index.php?topic=2838.msg95798#msg95798).
I have a proposal which would be of help for cameras that have too few buttons (and no touchscreen). This would enable normal camera use for inexperienced users, and also enable more comfortable camera control for those who don't mind that the camera's On/Off button behaves differently when in ALT mode.
Background info: this kind of remap is currently permanently enabled in the Ixus110 port (which can be confusing for some).
The patch makes changes in core in order to introduce a new configurable option and a new menu item. Since I don't do this usually, I'd like to ask for a quick look and some advice from those who do. My question is: is this acceptable?
Looks ok - the only suggestion I have is to change the text slightly (the use of the word 'Off' could be confusing).Thanks for the review and the suggestion. I used "Off" because that's what's written on the camera (considering non-English users, and the fact that the #define'd strings can not be localized).
So instead of the default menu entry being
OFF button in <ALT> mode [Off ]
change it to
Power button in <ALT> mode [Power]
If I understand the patch file correctly, this allows the On/Off button to substitute in <ALT> mode for one of the buttons that the CHDK code expects the camera to have but which is in fact not available on that camera. Is that right ?Yes, although it could be implemented for a button other than "power" too. In that case the menu text will have to be changed.
Looks ok - the only suggestion I have is to change the text slightly (the use of the word 'Off' could be confusing).Thanks for the review and the suggestion. I used "Off" because that's what's written on the camera (considering non-English users, and the fact that the #define'd strings can not be localized).
So instead of the default menu entry being
OFF button in <ALT> mode [Off ]
change it to
Power button in <ALT> mode [Power]
There's one more thing I'm uncertain of. There are several issues with the buttons in general:
- there are new cameras (A series) with a fair amount of available buttons, but some of those are not used (KEY_VIDEO, KEY_HELP) except when chosen for the ALT button.
- there are cameras with more buttons (for ALT mode use) than needed, but some of those have no use in ALT mode (KEY_FACE for example), again, when not selected as ALT button. They could be configured as shortcuts (shooting / scripting / modules related use), according to one's liking.
- there may be a generic solution that doesn't need to be implemented individually for each camera
I don't know whether there are plans to address the above issues. If there's a plan, my current work may be in conflict.
Hadn't thought of that, good point. On all my cameras the button is labelled ON/OFF (in caps) so perhaps the menu should be:According to a quick image search for a random "Ixy" model, even Japanese cameras have English labels.
ON/OFF button in <ALT> mode [OFF ]
Are cameras labelled with ON/OFF in non-English countries?
Unless someone else has any issues with this, I don't see any reason not to add it.OK, if no objections, I'll check it in.
a3400 100f port ALPHA version. Tested by TuDo.
capt_seq.c in a3400 101a was updated, but this version remains untested.
When CHDK gets a GPS fix from gps_get_data(), it doesn't check whether the latitude coordinates are North or South or if the longitude coordinates are East or West. The attached patch fixes this behaviour by making the latitude/longitude negative if it is South/West respectively, which is what the rest of the code expects.
I've tested the patch on my SX230HS when I was somewhere with coordinates which were North and West and it worked correctly.
The gps patch from Konrad127123 is fine. I add this correct size definition for tGPS. The wrong century chars in DNGs dateStamp is the result of wrong tGPS.status size. tGPS size is always 0x110 and unknown2[] only 160 chars. For compare library gpsLib.lua for SX230, SX260 at here (http://forum.chdk-treff.de/viewtopic.php?f=7&t=2999).
Another thing, we should be use rounded pi-values in imath.
Index: core/ptp.c
===================================================================
--- core/ptp.c (revision 2515)
+++ core/ptp.c (working copy)
@@ -650,7 +650,7 @@
}
// send response
- data->send_resp( data->handle, &ptp );
+ data->send_resp( data->handle, &ptp, 0 );
return 1;
}
Index: core/ptp_chdk.h
===================================================================
--- core/ptp_chdk.h (revision 2515)
+++ core/ptp_chdk.h (working copy)
@@ -30,7 +30,7 @@
int handle;
int (*send_data)(int handle, const char *buf, int part_size, int total_size, int, int, int); // (0xFF9F525C), total_size should be 0 except for the first call
int (*recv_data)(int handle, char *buf, int size, int, int); // (0xFF9F5500)
- int (*send_resp)(int handle, PTPContainer *resp); // (0xFF9F5688)
+ int (*send_resp)(int handle, PTPContainer *resp, int zero); // (0xFF9F5688), ixus30/40 needs a third argument, which is always 0
int (*get_data_size)(int handle); // (0xFF9F5830)
int (*send_err_resp)(int handle, PTPContainer *resp); // (0xFF9F5784)
int unknown1; // ???andIndex: platform/generic/wrappers.c
===================================================================
--- platform/generic/wrappers.c (revision 2515)
+++ platform/generic/wrappers.c (working copy)
@@ -109,7 +109,7 @@
char unk6;
} flashParam;
-short get_parameter_size(long id)
+short __attribute__((weak)) get_parameter_size(long id)
{
extern flashParam* FlashParamsTable[];
I believe that both are harmless.I'd like to ask for permission to do the following changes in core:Both seem fine to me. I think we discussed the send_resp one before in the ptp thread.
Both seem fine to me. I think we discussed the send_resp one before in the ptp thread.Yes. I repeated it as that talk was months ago.
Code: [Select]Index: platform/generic/wrappers.cI believe that both are harmless.
===================================================================
--- platform/generic/wrappers.c (revision 2515)
+++ platform/generic/wrappers.c (working copy)
@@ -109,7 +109,7 @@
char unk6;
} flashParam;
-short get_parameter_size(long id)
+short __attribute__((weak)) get_parameter_size(long id)
{
extern flashParam* FlashParamsTable[];
I'd like to integrate my ixus30/sd200 port, the above changes are needed for correct operation. I plan to fix some issues on the ixus40/sd300 port too.
For the FlashParamsTable fix I think it would be better to add a #define for this table version to camera.h and set the correct structure definition in wrappers.c based on the #define. This probably affects other cameras.To my knowledge the only cameras with this structure variant are the Ixus30 and 40, and the third exception would be the S1IS with yet another variant.
I added the get_parameter_size function in my recent reorg to remove the hard wired logic elsewhere. Unless I got this all wrong the current release version will also not work properly. See the code in luascript.c that gets the size value from the table. If this the case then get_parameter_size should be added to the release version.There's nothing wrong with your code, the Ixus40 style flash params table was never supported. The port used a workaround to not crash on regular camera use.
patch to fix palette in a810.
Bug was reported here (http://chdk.setepontos.com/index.php?topic=8450.msg95856#msg95856)
a2300 100e port - alpha
Reports here (http://chdk.setepontos.com/index.php?topic=8318.msg96121#msg96121)
@philmoz
Attached is the backport of changesets 2516-2519, including get_parameter_size, for review. I have used a new #define here, it could be used in trunk too if it looks right.
(it's tested and works)
Looks ok. I assume you'll commit this when ready.Done (https://trac.assembla.com/chdk/changeset/2523/).
For the FlashParamsTable fix I think it would be better to add a #define for this table version to camera.h and set the correct structure definition in wrappers.c based on the #define.After doing it this way in release-1_1, I have done the same for trunk (https://trac.assembla.com/chdk/changeset/2524/).
the only cameras with this structure variant are the Ixus30 and 40, and the third exception would be the S1IS with yet another variant.
ixus90_sd790 new loader. Tested by NormalA (http://chdk.setepontos.com/index.php?action=profile;u=9392). Thanks.
a3400 101b port (ALPHA) Thanks to tobyjones8 (http://chdk.setepontos.com/index.php?action=profile;u=25124) for testing.
Fix exp_drv_task and code cleanup in a3400 100f and a3400 101a.
Motion detect changes for A1200 - both f/w versions.
Changes to stable trunk version to fix incorrect address used for vid_get_viewport_live_fb().
Changes to dev trunk to use new sigfinder code version for faster detection per http://chdk.setepontos.com/index.php?topic=9366.msg96664#msg96664 (http://chdk.setepontos.com/index.php?topic=9366.msg96664#msg96664)
A small patch file to fix the LED mapping for the IXUS120_SD940. Patch works for both 1.1.0 and 1.2.0 trunks.
Patch enabled DRAW_ON_ACTIVE_BITMAP_BUFFER_ONLY on sx260 and cleanup stubs.
Update for Croatian language file-developer version 1.2Added, trunk changeset 2561 (http://trac.assembla.com/chdk/changeset/2561)
Small patch for camera_set_led() function of the A1200.Added, trunk changeset 2562 (http://trac.assembla.com/chdk/changeset/2562), stable changeset 2563 (http://trac.assembla.com/chdk/changeset/2563)
a2300 100f port (ALPHA)Added trunk changeset 2565 (http://trac.assembla.com/chdk/changeset/2565) stable changeset 2566 (http://trac.assembla.com/chdk/changeset/2566)
Thanks to merxator and stefanb for testing.
Done. I have also verified the already found values (A, G series) except for a570 101a (that dump seems to be missing from the "collection"). Patch attached, enables CAM_FIRMWARE_MEMINFO for all VxWorks ports which support it.For vxworks, we need to find sys_mempart_id, which I haven't finished doing for all cameras. Baring typos, I think to should be safe to turn on for all that have been found.From a quick look, sys_mempart_id could be found by looking at an eventproc named "memShow" which is a wrapper for memPartShow. The latter needs sys_mempart_id as its first param.
Patch file to add a script function md_get_cell_val() that returns motion detection actual cell values rather than just differences as returned by md_get_cell_diff().
Discussion thread is here : http://chdk.setepontos.com/index.php?topic=9437.0 (http://chdk.setepontos.com/index.php?topic=9437.0)
Per the linked thread, function can be useful in MD scripts for determining if a scene has returned to its original quiescent state. Should also be very handy for implementing AGC for the md_detect_motion()'s sensitivity parameter.
Two small patches to enable MD testing for the G10 and ixus120_sd940.
Done. I have also verified the already found values (A, G series) except for a570 101a (that dump seems to be missing from the "collection"). Patch attached, enables CAM_FIRMWARE_MEMINFO for all VxWorks ports which support it.For vxworks, we need to find sys_mempart_id, which I haven't finished doing for all cameras. Baring typos, I think to should be safe to turn on for all that have been found.From a quick look, sys_mempart_id could be found by looking at an eventproc named "memShow" which is a wrapper for memPartShow. The latter needs sys_mempart_id as its first param.
I chose not to commit this without consent, as it has impact on many ports and the only one I can test is the Ixus65.
Added in revision 2581 (trunk only).thnks !
a810 and a1300
- stubs_entry_2.S cleanup
- platform_camera.h
- Duplicated CAM_USES_ASPECT_CORRECTION was deleted
- CAM_AF_LED was defined- lib.c
- Unused variables were deleted
- shutdown_soft() was deleted
- camera_set_led() revised
- _LockAndRefresh() and _UnlockAndRefresh() replaced by _ScreenLock() and _ScreenUnlock() respectively.- stubs_min.S: some_flag_for_af_scan was defined.
- main.c:
- Unused variable deleted- notes.txt updated
a1300 only
- CAM_LOAD_CUSTOM_COLORS enabled, CAM_BITMAP_PALETTE=13
a810 only
- CAM_PROPSET changed to 5
a1300 was updated with changes done to a810 (BETA), so A1300 was marked as BETA release.
[core/gps.c:1175]: (error) Buffer is accessed out of bounds.
=> gpx_name[17] resized to gpx_name[30] to store sprintf(gpx_name, "A/GPS/Logging/%02d_%02d-%02d_%02d.gpx",...)
[core/gps.c:1339]: (error) Resource leak: fp
=> fclose(fp) missing
[core/gui_script.c:157]: (style) Variable 'i' is assigned a value that is never used.
[core/gui_script.c:186]: (style) Variable 'i' is assigned a value that is never used.
[core/gui_script.c:507]: (style) Unused variable: i
[core/shooting.c:1512]: (style) Same expression on both sides of '||'.
Small patch to fix some errors reported by cppcheck.You could be about to become very very busy .... ;)
a3400 101a
* Remove duplicated CAM_USES_ASPECT_CORRECTION definition in platform_camera.h
* vid_get_viewport_live_fb() implemented using viewport_buffers and active_viewport_buffer
* EXMEM_BUFFER_SIZE = 1MB
* Unused variables deleted
* a3400 101a ready to autobuild
a3200 newloader and unused variables deletion in main.c
tested by ricardo28 (http://chdk.setepontos.com/index.php?action=profile;u=23859) on 3200 100d. Thanks
Small patch to fix some errors reported by cppcheck.Code: [Select][core/gps.c:1175]: (error) Buffer is accessed out of bounds.
=> gpx_name[17] resized to gpx_name[30] to store sprintf(gpx_name, "A/GPS/Logging/%02d_%02d-%02d_%02d.gpx",...)
[core/gps.c:1339]: (error) Resource leak: fp
=> fclose(fp) missing
[core/gui_script.c:157]: (style) Variable 'i' is assigned a value that is never used.
[core/gui_script.c:186]: (style) Variable 'i' is assigned a value that is never used.
[core/gui_script.c:507]: (style) Unused variable: i
[core/shooting.c:1512]: (style) Same expression on both sides of '||'.
a2300, a3400, a810, a1300: makefile.inc. Patch to fix comments of how EXMEM_HEAP_SKIP was obtained.
a2300: unused variables deleted
I don't think there are many people out there who compile CHDK from source. Probably even less who look into the source before. And probably only a fraction of those will ever mess with an old (= VxWorks) camera.Done. I have also verified the already found values (A, G series) except for a570 101a (that dump seems to be missing from the "collection"). Patch attached, enables CAM_FIRMWARE_MEMINFO for all VxWorks ports which support it.For vxworks, we need to find sys_mempart_id, which I haven't finished doing for all cameras. Baring typos, I think to should be safe to turn on for all that have been found.From a quick look, sys_mempart_id could be found by looking at an eventproc named "memShow" which is a wrapper for memPartShow. The latter needs sys_mempart_id as its first param.
I chose not to commit this without consent, as it has impact on many ports and the only one I can test is the Ixus65.
Perhaps add the stubs_min.S values with a comment that it is untested and to enable the option in platform_camera.h to test.
Add the values in platform_camera.h commented out with instructions to enable & test.
That way the info is not lost; but won't break any existing ports.
Phil.
My main concern about enabling CAM_FIRMWARE_MEMINFO for all Vx ports is that I have not verified the memPartInfoGet function for most of them. That said, the sigfinder appears to be 100% certain about its address in all cases.I think I missed this discussion the first time around. IMO, enabling something based on 100% sig finder match, and manual spot checks on a few ports is OK. I enabled it for all dryos cams in the trunk on the same basis.
And probably only a fraction of those will ever mess with an old (= VxWorks) camera.My guess is that the fraction of all the people who use CHDK and mess with old (= VxWorks) cameras is probably just one person.
I think I missed this discussion the first time around. IMO, enabling something based on 100% sig finder match, and manual spot checks on a few ports is OK. I enabled it for all dryos cams in the trunk on the same basis.OK, I will check 1-2 firmware out of each "generation", then I'll risk the commit...
8)And probably only a fraction of those will ever mess with an old (= VxWorks) camera.My guess is that the fraction of all the people who use CHDK and mess with old (= VxWorks) cameras is probably just one person.
Small fix for the A1200 - stable & unstable branch. Per this post : http://chdk.setepontos.com/index.php?topic=9482.msg97203#msg97203 (http://chdk.setepontos.com/index.php?topic=9482.msg97203#msg97203) it appears that shooting_get_prop(PROPCASE_ASPECT_RATIO) very occassionally returns a value out of the expected 0-3 range. The code was returning the same value regardless when the value was in range so I just locked it there.
a2300 100c port (ALPHA)
tested by akiro021 and mainakm
EDIT: I posted the patch again, to include changes in camera_list.csv.
Well, this patch for 100b and 100c includes:File was posted here sx50_100b_100c_trunk2606.patch.gz (http://chdk.setepontos.com/index.php?action=dlattach;topic=8932.0;attach=7886).
* the previous capt_seq.c patch to fix call to wait_until_remote_button_is_released
* EXMEM_BUFFER_SIZE and EXMEM_HEAP_SKIP
* Implementation of void *vid_get_viewport_fb() void *vid_get_viewport_live_fb() as done in g12.
Patch to sx50 100b and 100cWell, this patch for 100b and 100c includes:File was posted here sx50_100b_100c_trunk2606.patch.gz (http://chdk.setepontos.com/index.php?action=dlattach;topic=8932.0;attach=7886).
* the previous capt_seq.c patch to fix call to wait_until_remote_button_is_released
* EXMEM_BUFFER_SIZE and EXMEM_HEAP_SKIP
* Implementation of void *vid_get_viewport_fb() void *vid_get_viewport_live_fb() as done in g12.
Tests and reports here (http://chdk.setepontos.com/index.php?topic=8932.msg97403#msg97403)
Added in revision 2610 (trunk) and 2611 (release-1.1).Thanks nafraf and Phil.
Added in revision 2610 (trunk) and 2611 (release-1.1).Thanks nafraf and Phil.
Also, the jpg size is actually 4000 x 3000 instead of this:
#define CAM_JPEG_WIDTH 4072
#define CAM_JPEG_HEIGHT 3044
A4000IS port (ALPHA)
100c and 101a remain untested.
101b can be added to autobuild, it was tested by ricardo28.
Thanks.
I've checked this in. https://trac.assembla.com/chdk/changeset/2614/ and https://trac.assembla.com/chdk/changeset/2615/I think I missed this discussion the first time around. IMO, enabling something based on 100% sig finder match, and manual spot checks on a few ports is OK. I enabled it for all dryos cams in the trunk on the same basis.OK, I will check 1-2 firmware out of each "generation", then I'll risk the commit...
I would have started doing this (or enabling it) in the trunk only. Sorry I wasn't clear about this in my previous post. It's probably OK.Hmmm, I should have read your sentence a bit more thoroughly.
I enabled it for all dryos cams in the trunk on the same basis.And yes, it's really not mass-enabled in 1.1 ... :-[
I have no doubt that the function is actually the correct one in every case though. Checked 1 fw version for every camera manually.Yeah, I think it's fine. And meminfo has been enabled in the trunk for dryos a long time without problems, so we could probably move that over too. It sort of qualifies as a bug fix, because the malloc version can cause crashes in ptp...
Due to recent changes, trunk and 1.1 platform files are no longer compatible.Which ones?
Looks like the recent keyboard changes.Due to recent changes, trunk and 1.1 platform files are no longer compatible.Which ones?
Looks like the recent keyboard changes.
I've disabled a4000 in 1.1. for now.
Looks like the recent keyboard changes.Due to recent changes, trunk and 1.1 platform files are no longer compatible.Which ones?
I've disabled a4000 in 1.1. for now.
A4000 patch
camera_set_led(...) enabled. led_table[] values confirmed by rkomar.
Reported here (http://chdk.setepontos.com/index.php?topic=9443.msg97599#msg97599)
EDIT:
Patch had 0 downloads, so I modified it to fix behavior of set_led: 0 LED is off 1 LED is on
a810/a1300
Patch to fix behavior of set_led: 0 LED is off 1 LED is on
sx50hs
- New loader implemented
- Fix to modemap table
- Fix to remove crash during video recording
Reports here (http://chdk.setepontos.com/index.php?topic=8932.msg97732#msg97732)
s100 102a port ALPHA
tested by m4tt, reports here (http://chdk.setepontos.com/index.php?topic=7887.210)
Patch to fix CHDK color palette for the sx50hs.
Props to philmoz for his help : http://chdk.setepontos.com/index.php?topic=8306.msg98194#msg98194 (http://chdk.setepontos.com/index.php?topic=8306.msg98194#msg98194)
ixus125_elph110hs port
100d remains untested (SKIP_AUTOBUILD)
100e tested by Hardware-Hacker
101a tested by MKR
Fix for sx50hs Canon color corruption problem reported here :
http://chdk.setepontos.com/index.php?topic=8932.msg98227#msg98227 (http://chdk.setepontos.com/index.php?topic=8932.msg98227#msg98227)
Patch to fix crashing when using USB remote in "sync" mode for the sx240hs & sx260hs (and possibly other mystery crashes in any code that calls debug_led() ).Added, trunk changeset 2653 (http://trac.assembla.com/chdk/changeset/2653) release changeset 2654 (http://trac.assembla.com/chdk/changeset/2654)
This patch adds "#define CAM_HAS_VIDEO_BUTTON" to some models where it is missing:
a810, a1300, a2300, a3400, a4000, s100, sx150hs
A few additions by rudi to the Lua integer math package as discussed here : fast integer based trigonometry for chdk and lua (http://chdk.setepontos.com/index.php?topic=9131.msg98523#msg98523)
yukia10's updates for lib.c for the sx50 per http://chdk.setepontos.com/index.php?topic=8932.msg98711#msg98711 (http://chdk.setepontos.com/index.php?topic=8932.msg98711#msg98711)
Patch file works for both stable and dev trunks.
1) change the status of the sx50hs to BETA and include it in the autobuild.Added trunk changeset 2663 (http://trac.assembla.com/chdk/changeset/2663), release changeset 2664 (http://trac.assembla.com/chdk/changeset/2664)
2) remove the BETA status from the A1200
* A1100 100c runs on 100b, it was reported by two users on 2011 (http://chdk.setepontos.com/index.php?topic=4727.msg64539#msg64539) and 2013 (http://chdk.setepontos.com/index.php?topic=9564.msg98391#msg98391)Added trunk changeset 2665 (http://trac.assembla.com/chdk/changeset/2665), release changeset 2666 (http://trac.assembla.com/chdk/changeset/2666)
* A2200 100b runs on 100c, patch was added to A2200 porting thread (http://chdk.setepontos.com/index.php?topic=6254.msg87389#msg87389) and there is a note on A2200 wikia page (http://chdk.wikia.com/wiki/A2200) confirming that.
Hi, patch to fix zoom bugs in A495, A810, A1300:Added in trunk changeset 2668 (http://trac.assembla.com/chdk/changeset/2668) release changeset 2669 (http://trac.assembla.com/chdk/changeset/2669)
Bugfix for imath library, Changeset 2655.Added, trunk changeset 2673 (http://trac.assembla.com/chdk/changeset/2673)
Patch and desciption please see here: http://chdk.setepontos.com/index.php?topic=9131.msg98857#msg98857 (http://chdk.setepontos.com/index.php?topic=9131.msg98857#msg98857)
A4000 patches
- 101a tested by atirage21, added to autobuild as ALPHA
- Fix to zoom bugs: CAM_USE_ALT_SET_ZOOM_POINT and CAM_USE_ALT_PT_MoveOpticalZoomAt defined
- New value for PAUSE_FOR_FILE_COUNTER.
I got tired of complaining about CHDK shortcut keys and did something about it. This patch adds a menu item to the CHDK settings menu to allow shortcut keys to be enabled/disabled by the user.
I realize a full user editable shortcut key menu with individual enable/disables and configurable button choices would be nicer. But this is a good step and only took a few minutes to code and test.
For compatibility, it defaults shortcuts to be enabled - a compromise I regret but will live with for the benefit of not further confusing new users.
Update : cleaned up the help menu string spacing a bit. Also capitalized the Enable Shortcut Keys menu item.
A couple of comments:Would it work better where I suggested? Things are always more complicated than they seem in CHDK, aren't they?
- The change in gui_kbd_shortcuts will also disable the manual focus overrides for camera that don't have built in manual focus.
- The change only disables Shutter Half Press + button shortcuts, the menu item text 'Enable Shortcut Keys' doesn't reflect this.
A couple of comments:Sheesh - you haven't updated those to the trunk yet. Modified to leave a hole based on what's currently in the SVN for your branch.
- This clashes with my new modules branch on the CONF_INFO item (conf.c) and the new strings in english.lng. Can you move these please.
- The changes in gui_draw_alt_helper are hiding too many lines when you disable the shortcuts. LANG_HELP_HIDE_OSD and LANG_HELP_NOT_ALT should still display.Okay - changed to leave those in.
The change in gui_kbd_shortcuts will also disable the manual focus overrides for camera that don't have built in manual focus.Changed to leave those enabled - I haven't accidentally hit those so far anyway.
The change only disables Shutter Half Press + button shortcuts, the menu item text 'Enable Shortcut Keys' doesn't reflect this.Hmmm .. those are the only one I think of as an actual shortcuts. Text changed.
Would it work better where I suggested?No. Your patch is right before the call to where I patched the code. Doing it that way would make it impossible to leave the manual focus stuff enabled.
A couple of comments:Sheesh - you haven't updated those to the trunk yet. Modified to leave a hole based on what's currently in the SVN for your branch.
- This clashes with my new modules branch on the CONF_INFO item (conf.c) and the new strings in english.lng. Can you move these please.
What about the CONF_INFO item for conf.enable_shortcuts (I'm using 294 for conf.module_logging)?Done.
I'd prefer to put conf.enable_shortcuts as 295, otherwise it will make merging my branch harder.
What about the CONF_INFO item for conf.enable_shortcuts (I'm using 294 for conf.module_logging)?Done.
I'd prefer to put conf.enable_shortcuts as 295, otherwise it will make merging my branch harder.
We could just wait until you've finished your merge if that makes it easier.
Added in revision 2679.Need to remember to wipe the CCHDK3.CFG file.
My module changes are in 2677 - fingers crossed it doesn't break too badly :)
You guys are incredible. Thanks for all the additions.Added in revision 2679.Need to remember to wipe the CCHDK3.CFG file.
My module changes are in 2677 - fingers crossed it doesn't break too badly :)
Rebuilt now - everything looks good on the G10 & SX50.
I have a canon A580 with firmware 1.00C... Can I use CHDK with it?.CHDK is only available for the 1.01B version of the A580. Its not likely that will work on a 1.00c camera.
If not, can i load a new firmware into the cam?.No - Canon does not provide firmware updates unless there is a major bug.
If not... what can i do with this cam?... :(Hope somebody volunteers to do the port for you - this will require you to volunteer to do detailed testing.
There's no problem to testing help, but i don't understand that this port would be used.Related post here : http://chdk.setepontos.com/index.php?topic=2900.msg99002#msg99002 (http://chdk.setepontos.com/index.php?topic=2900.msg99002#msg99002)
Small patch to sx50/sx260:
sx50/sx260: CAM_USE_ALT_SET_ZOOM_POINT and CAM_USE_ALT_PT_MoveOpticalZoomAt defined
sx260: Configurable ALT button enabled.
Tested by lapser, thanks
a810/a1300, a4000 patch to mute microphone if optical zoom is used during video recording.
(#define CAM_CAN_MUTE_MICROPHONE )
a810: Tested on 100b and 100d, addresses of TurnOffMic, TurnOnMic are the same for 100e, them patch was created for all fw versions.
a4000: Tested on 101b, addresses of TurnOffMic, TurnOnMic are the same for all firmware versions, then patch was created for all fw versions.
Croatian language update,trunk and stable versions.
s100: remove todos in rear jogdial and use proper value in kbd's sleeptask
Cons:
- increases core size
- setting up for dumping the whole RAM is not obvious (new menu entry needed ?)
a3200 100d and 100a: patch to mute microphone if optical zoom is used during video recording.
(#define CAM_CAN_MUTE_MICROPHONE), and MakeAFScan address fix.
Tested on a3200 100d by ricardo28.
Looks ok - core size increase is only ~600 bytes so no issue there.Good point. Since the submenu was the last thing implemented, I hadn't noticed the need for re-wording.
Perhaps change the menu text slightly. I don't think you need 'RAM dump' in every line of text.
What about:
- Start Address
- Dump Size (0 = ALL RAM)
- Dump delay (s)
a580: 100c port and new loader implementation. Tested by javier_uy.
I'll correct the text and commit soon.Done, changeset 2711 (https://trac.assembla.com/chdk/changeset/2711/).
--[[
@title AF Assist Test
--]]
set_prop(5,0)
shoot()
set_prop(5,1)
shoot()
set_prop(5,0)
shoot()
set_prop(5,1)
shoot()
Added a propset value for the auto focus assist beam.Added, trunk changeset 2721 (http://trac.assembla.com/chdk/changeset/2721), release changeset 2722 (http://trac.assembla.com/chdk/changeset/2722)
First patch for emu.lua file. Not sure how this needs to be organized ...Added, trunk changeset 2720 (http://trac.assembla.com/chdk/changeset/2720)
CHDK for PowerShot G15 100b
Enabled BETA autobuild since it seems there's no issue
Since i already posted a big diff, here's a quick fix for CFAPattern and DNG exposure bias
edit: I now see active area is in converted EXIF data, I will use that value... patch soon
edit2: patch attached to match native raw active area and cfapattern
Added in revision 2725/2726 (trunk) and 2727 (release-1.1).Note this broke the release autobuild, so I added skip_autobuild. Since I was on my lunch break, I didn't look closely, but I think it was related to changes in the trunk core that aren't in the release branch.
Added in revision 2725/2726 (trunk) and 2727 (release-1.1).Note this broke the release autobuild, so I added skip_autobuild. Since I was on my lunch break, I didn't look closely, but I think it was related to changes in the trunk core that aren't in the release branch.
I encourage building before every checkin, even if it seems trivial.
sorry, I forgot to say I tested in trunk only :)Added in revision 2725/2726 (trunk) and 2727 (release-1.1).Note this broke the release autobuild, so I added skip_autobuild. Since I was on my lunch break, I didn't look closely, but I think it was related to changes in the trunk core that aren't in the release branch.
I encourage building before every checkin, even if it seems trivial.
My bad - normally I do build before commit; will fix it tonight if I get time.
Phil.
sorry, I forgot to say I tested in trunk only :)Added in revision 2725/2726 (trunk) and 2727 (release-1.1).Note this broke the release autobuild, so I added skip_autobuild. Since I was on my lunch break, I didn't look closely, but I think it was related to changes in the trunk core that aren't in the release branch.
I encourage building before every checkin, even if it seems trivial.
My bad - normally I do build before commit; will fix it tonight if I get time.
Phil.
Anyway, here's another load of changes (yes, for trunk), this time for S100 (tested with s100 101b):
hacked loader, removed useless comments, fixed platform_camera
with the hacked loader now booting with power button short press works
fixed defines in platform_camera for correct dng generation
tested movie_rec and it works
link to patch: https://github.com/c10ud/CHDK/commit/bee5ee88f8c94a9fb6d708bde2db3f7fea9cb36c.patch (https://github.com/c10ud/CHDK/commit/bee5ee88f8c94a9fb6d708bde2db3f7fea9cb36c.patch)
I'm not at home (so I cannot check if I did something wrong) but I got the active area and color matrices from the CR2->DNG Adobe conversion of a S100 raw filesorry, I forgot to say I tested in trunk only :)Added in revision 2725/2726 (trunk) and 2727 (release-1.1).Note this broke the release autobuild, so I added skip_autobuild. Since I was on my lunch break, I didn't look closely, but I think it was related to changes in the trunk core that aren't in the release branch.
I encourage building before every checkin, even if it seems trivial.
My bad - normally I do build before commit; will fix it tonight if I get time.
Phil.
Anyway, here's another load of changes (yes, for trunk), this time for S100 (tested with s100 101b):
hacked loader, removed useless comments, fixed platform_camera
with the hacked loader now booting with power button short press works
fixed defines in platform_camera for correct dng generation
tested movie_rec and it works
link to patch: https://github.com/c10ud/CHDK/commit/bee5ee88f8c94a9fb6d708bde2db3f7fea9cb36c.patch (https://github.com/c10ud/CHDK/commit/bee5ee88f8c94a9fb6d708bde2db3f7fea9cb36c.patch)
I've added this to the trunk in revision 2730.
However the S100 platform_camera.h file contains the active area and color matrices from your G15 port - is this correct?
Once you've confirmed (or fixed) platform_camera.h I'll update release-1.1.
Phil.
a2400: 100c, 100d, and 100e blind port ALPHA
100c firmware dump was posted here (http://chdk.setepontos.com/index.php?topic=9513.msg99598#msg99598)
Just tried current vanilla trunk, everything's good ;)I'm not at home (so I cannot check if I did something wrong) but I got the active area and color matrices from the CR2->DNG Adobe conversion of a S100 raw filesorry, I forgot to say I tested in trunk only :)Added in revision 2725/2726 (trunk) and 2727 (release-1.1).Note this broke the release autobuild, so I added skip_autobuild. Since I was on my lunch break, I didn't look closely, but I think it was related to changes in the trunk core that aren't in the release branch.
I encourage building before every checkin, even if it seems trivial.
My bad - normally I do build before commit; will fix it tonight if I get time.
Phil.
Anyway, here's another load of changes (yes, for trunk), this time for S100 (tested with s100 101b):
hacked loader, removed useless comments, fixed platform_camera
with the hacked loader now booting with power button short press works
fixed defines in platform_camera for correct dng generation
tested movie_rec and it works
link to patch: https://github.com/c10ud/CHDK/commit/bee5ee88f8c94a9fb6d708bde2db3f7fea9cb36c.patch (https://github.com/c10ud/CHDK/commit/bee5ee88f8c94a9fb6d708bde2db3f7fea9cb36c.patch)
I've added this to the trunk in revision 2730.
However the S100 platform_camera.h file contains the active area and color matrices from your G15 port - is this correct?
Once you've confirmed (or fixed) platform_camera.h I'll update release-1.1.
Phil.
Looking at the diff with the previous S100 platform_camera active area looks the same, just with numbers explicited (I guess S100 and G15 probably have the same sensor or something?)
The color matrices are different, I also remember the S100 DNG missing the calibration info, probably you looked at the wrong diff?
Anyway once I'm home I'll double check this just to be sure
p.s. While we're at it, I didn't really get what the CAM_JPEG_{WIDTH, HEIGHT} are for and which value should the hold (e.g. 4000x3000 for 12Mpix? or CAM_ACTIVE_AREA_X2-CAM_ACTIVE_AREA_X1? or else?)
It probably appropriate to disable the hooks for capt_seq_hook_set_nr in capt_seq.c for the SX50HS - at least for now.
In the current build, they do not work (i.e. you can not enable or disable dark frame subtraction) and they cause an immediate crash when the camera is used in "Sports" mode (continuous shooting).
I'll keep looking at it but in the meantime, best it's disabled.
Patch works for both 1.1.0 & 1.2.0 branches.
Added in revision 2736 (trunk) and 2737 (release-1.1).Thanks philmoz!
"BL capt_seq_hook_set_nr\n" // +++at line 433 in capt_seq.c. Do you need a patch file?
A3100 related changes (trunk, 1.1).
1) 1.00b: fixed several sub <-> loc mixups, enabled autobuild
Tested by cheddar66 (see posts from here (http://chdk.setepontos.com/index.php?topic=5560.msg99613#msg99613)). I have left a note in source about the unsuccessful "override fix for short press" test.
2) all revisions: vid_get_viewport_live_fb() implemented using fw variables found by the sigfinder. This was not thoroughly tested, but zebra works seemingly the same (http://chdk.setepontos.com/index.php?topic=5560.msg99913#msg99913) as in the single buffered case. The code is like the other (older) implementations. There appear to be 3 normal buffers (see below), so that's what the routine expects.
DEF(viewport_buffers ,0xffae1430)
ffae1430: 106f3bc0
ffae1434: 107724c0
ffae1438: 107f0dc0
ffae143c: 1062c660 ; 4th buffer: not consecutive
If this vid_get_viewport_live_fb() implementation seems risky, then please ignore all lib.c changes in the patch
A3300 patch
1) New loader implemented
2) 100a and 100c are compatible, so 100c directory was deleted and camera_list.csv was modified.
3) vid_bitmap_refresh() modified, call to draw_filled_rect() deleted
4) movie_rec.c modified to support: CAM_AF_SCAN_DURING_VIDEO_RECORD, CAM_CAN_MUTE_MICROPHONE and CAM_CAN_UNLOCK_OPTICAL_ZOOM_IN_VIDEO
Tested on 100c by nemerdekel1, reports here (http://chdk.setepontos.com/index.php?topic=9797.msg99887#msg99887)
Added in revision 2740 (trunk) and 2741 (release-1.1).Thanks.
Small patch for a bug in the hostlua stuff - a fix to camera_funcs.get_day_seconds() .Added, trunk changeset 2755 (http://trac.assembla.com/chdk/changeset/2755)
ixus125 101a: Small patch to fix nrflag.
Patch posted here (http://chdk.setepontos.com/index.php?action=dlattach;topic=8085.0;attach=8283)
Tested by geopig, report here: http://chdk.setepontos.com/index.php?topic=8085.msg100293#msg100293 (http://chdk.setepontos.com/index.php?topic=8085.msg100293#msg100293)
Patch to A810, A1300, A2300, A2400, A3400, A4000:
- Delete unnecessary lookup table implementation used in vid_get_viewport_width() and vid_get_viewport_height()
- Delete unnecessary functions vid_get_viewport_xoffset() and vid_get_viewport_yoffset() which returns 0
- Delete 80 from iso_table[], it is not a valid value for these models.
A3400, A2300:
- CAM_USE_ALT_SET_ZOOM_POINT, CAM_USE_ALT_PT_MoveOpticalZoomAt defined in platform_camera.h
A3400
- Fix value passed to LEDDrive() called inside camera_set_led()
A1300.100d:
- PAUSE_FOR_FILE_COUNTER changed to 250. It is the value used in other a1300/a810 fw versions
Patch to fix A1200 UI overlay colors when using CHDKPTP.Added, trunk changeset 2797 (http://trac.assembla.com/chdk/changeset/2797) release changeset 2798 (http://trac.assembla.com/chdk/changeset/2798)
Fix for power up crashing of SX10 per this thread :Added to the release branch, enabled startup fix for all dryos cams in the trunk.
http://chdk.setepontos.com/index.php?topic=10009 (http://chdk.setepontos.com/index.php?topic=10009)
Patch works on both stable & dev trunks.
ixus220_elph300hs: Patch to fix liveview. Tested by fronjd
a495 patch:
- boot.c: task dispatcher hook used strcmp, now it compare addresses.
- capt_seq.c: known functions replaced with their named representation
- mute_on_zoom implemented
Tested on a495. 100f.
Thanks.
D20 100b blind port ALPHA
Status and reports: D20 Porting thread (http://chdk.setepontos.com/index.php?topic=9722.msg99602#msg99602)
Sorry, missing change in attachment.D20 100b blind port ALPHA
Status and reports: D20 Porting thread (http://chdk.setepontos.com/index.php?topic=9722.msg99602#msg99602)
Missing definition for MODE_SCN_UNDERWATER_MACRO.
Phil.
Sorry, missing change in attachment.D20 100b blind port ALPHA
Status and reports: D20 Porting thread (http://chdk.setepontos.com/index.php?topic=9722.msg99602#msg99602)
Missing definition for MODE_SCN_UNDERWATER_MACRO.
Phil.
Patch to add custom palette colors to G10 and IXUS120_SD940.
Thanks to philmoz for making this happen.
Small patch for the IXUS120_SD940 to set the palette info correctly for chdkptp.
Support for S110 101b and 102b. Patch attached for trunk
101b is still untested (I have 102b).
(I will submit a RFC patch for the new task hook in platform/generic soon :))
sorry for that, i branched a while ago :)Support for S110 101b and 102b. Patch attached for trunk
101b is still untested (I have 102b).
(I will submit a RFC patch for the new task hook in platform/generic soon :))
Added in revision 2858 (trunk).
I removed the G15 & S100 changes. Will apply these separately as the also apply to release-1.1.
Updated stubs_entry.S to the latest version, removed stubs_asm.h and sub/Makefile to align with current trunk.
Also changed the status for 1.01b version to ALPHA pending test results.
Phil.
G1X patch for its notes.txt file
Custom palette colors for the IXUS100_SD780. Tested by andrewhazelden (http://chdk.setepontos.com/index.php?action=profile;u=12040)
The SD780 has a completely unused palette row in shooting, playback and the Canon menus for those modes so it was possible to get the colors right when the CHDK menu overlays the Canon menus.
Update : added a small patch file for the SD940 to make CHDK menus work over Canon menus
patch to include White Balance Mode to propsets. (WB_MODE)I verified 2 on D10. In addition to the listed values, 10 is underwater.
propset 3 and 5 were verified.
propset 2 and 4 were not verified. Values taken from http://chdk.wikia.com/wiki/PropertyCase (http://chdk.wikia.com/wiki/PropertyCase)
sx160is 100a port - beta.
This port includes code_gen files.
Small patch to release existing svn code for 1.00A firmware for ixus130_sd1400 to the autobuild.
Also, move camera to BETA status.
http://chdk.setepontos.com/index.php?topic=5034.msg101895#msg101895 (http://chdk.setepontos.com/index.php?topic=5034.msg101895#msg101895)
I think that these two ports can be released to the autobuild:
* ixus125 100d (ALPHA). Some test results were posted here (http://chdk.setepontos.com/index.php?topic=8085.msg101344#msg101344)
* a4000 102a. It is compatible with 101b, as reported here (http://chdk.setepontos.com/index.php?topic=9443.msg101790#msg101790)
Patch to propset5, verified on SX160
*DATE_STAMP
*MY_COLORS
*Custom color properties: CUSTOM_SATURATION, CUSTOM_CONTRAST, CUSTOM_BLUE, CUSTOM_GREEN, CUSTOM_RED, CUSTOM_SKIN_TONE
Patch to propset3, verified on A495
*DATE_STAMP
Patch to propset5, verified on SX160
*DATE_STAMP
*MY_COLORS
*Custom color properties: CUSTOM_SATURATION, CUSTOM_CONTRAST, CUSTOM_BLUE, CUSTOM_GREEN, CUSTOM_RED, CUSTOM_SKIN_TONE
Same for propset2, tested on G10.Patch to propset5, verified on SX160Same for propset4, tested on SX220.
*DATE_STAMP
--[[
@title timestamp
@param a Propcase 66 =
@default a 0
@range a 0 2
--]]
print("setting timestamp")
set_prop(66, a)
shoot()Same for propset4, tested on SX220.
Same for propset2, tested on G10.
Fix to enable "dark frame subtraction" and "USB remote sync" for the IXUS100_SD780 per http://chdk.setepontos.com/index.php?topic=3995.msg101958#msg101958 (http://chdk.setepontos.com/index.php?topic=3995.msg101958#msg101958)Added the above + datestamp for propset1 and mycolors for propset 2 in trunk changesets 2899-2902 (http://trac.assembla.com/chdk/changeset?reponame=&new=2902%40trunk&old=2899%40trunk), release changeset 2904 (http://trac.assembla.com/chdk/changeset/2904)
Patch to move the dark frame subtraction menu item from the RAW menu to the Enhanced Photo Operations menu.Trunk changeset 2903 (http://trac.assembla.com/chdk/changeset/2903)
This is a git formatted patch, so use 'patch -p1' to apply the patch.
=== patch comment start ===
makefile.inc: use CROSS_COMPILE variable for selecting a toolchain
By default CHDK uses toolchain with the 'arm-elf-' prefix.
If you want to change toolchain you need to change many
variables (e.g. CC, OBJCOPY etc).
In linux kernel the CROSS_COMPILE variable makes
this work easier. Let's use the same approach for CHDK too.
Usage. Just define CROSS_COMPILE in cmdline:
make CROSS_COMPILE=/my/toolchain/path/and/arm-pre-fix-
=== patch comment end ===
Update for czech lng file.
A1200 - Patch to mute mic if zoom during video recording.
Test and report here: http://chdk.setepontos.com/index.php?topic=6318.msg102484#msg102484 (http://chdk.setepontos.com/index.php?topic=6318.msg102484#msg102484)
Patch: http://chdk.setepontos.com/index.php?action=dlattach;topic=6318.0;attach=8561 (http://chdk.setepontos.com/index.php?action=dlattach;topic=6318.0;attach=8561)
Croatian language update.
sx160 100a filewrite patch
Update to Custom Auto ISO patch - previous patch failed to make a complete change for UI values not assumed to be (x10).
This version also rolls in the language file changes that I had posted seperately.
S110 and G15:
- moved code to code_gen tool usage
- new minimal taskhook code based on phil's hints
- filewrite hook (based on sx160)
S110 only:
- fixed memisostart value for 102b port
- fixed power on check for 101b port
tested with g15 100b and s110 102b
patch against today's trunk
Filewrite patch SX220, thanks rudis help.
Successfully tested with 1.01a.
msl
a590 patch:Added, trunk changeset 2951 (http://trac.assembla.com/chdk/changeset/2951)
- filewritetask implemented. Tested by blackhole on a590 101b.
- #undef CAM_CAN_SD_OVER_NOT_IN_MF added to platform_camera.h. Report here (http://chdk.setepontos.com/index.php?topic=8263.msg88764#msg88764)
The A590IS has a tendency to overexpose video (and images).You should discuss in the development thread, see the posts starting at http://chdk.setepontos.com/index.php?topic=2361.msg102624#msg102624 (http://chdk.setepontos.com/index.php?topic=2361.msg102624#msg102624)
I think CAM_EV_IN_VIDEO is useful to correct for video overexposure.
Patch for S100:
- use Video button as Display button (thanks to msl)
- enable GPS Menu
All successful testet on S100-102a by Peter_A720 from german CHDK forum http://forum.chdk-treff.de/viewtopic.php?f=10&t=2651&start=45#p27962 (http://forum.chdk-treff.de/viewtopic.php?f=10&t=2651&start=45#p27962)
rudi
sx240 patch:
- New loader
- Code converted to code_gen
- filewritetask implemented
- function in platform/sx240hs/sub/*/kbd.c moved to platform/sx240hs/kbd.c
Tested on sx240 101a
small patch to fix OSD zoom value behavior.
Bug reported and patch tested by dvip: http://chdk.setepontos.com/index.php?topic=2361.msg102713#msg102713 (http://chdk.setepontos.com/index.php?topic=2361.msg102713#msg102713)
S100 patch:
- custom bitmap palette
- changed bitmap palette definition 7 => 13
- tested by by Peter_A720 from german CHDK forum: http://forum.chdk-treff.de/viewtopic.php?p=27980#p27980 (http://forum.chdk-treff.de/viewtopic.php?p=27980#p27980)
S100 diff
- bugfix for DISPLAY_KEY, Changeset 2953
- tested on S100-102a
SX260 diff
- update equal to nafrafs patch for SX240, Changeset 2953
- code-gen, filewrite, delete kbd.c in /sub/
- tested on sx260-100b, include usb remote capture
rudi
a2300 filewrite task supportAdded, trunk changeset 2961 (http://trac.assembla.com/chdk/changeset/2961)
a490 update
- new loader
- mute on zoom
- code_gen
- filewrite task support
Tested on a490 100f by tpont.
http://chdk.setepontos.com/index.php?topic=5051.msg103086#msg103086 (http://chdk.setepontos.com/index.php?topic=5051.msg103086#msg103086)
A720 patch
- filewrite task support (with great help by rudi)
patch to remove unused spytask function.
patch to platform/*/main.c to remove unused variable ptrAdded, trunk changeset 2986 (http://trac.assembla.com/chdk/changeset/2986)
a530: fix the free space display related function addressesAdded, trunk changeset 2985 (http://trac.assembla.com/chdk/changeset/2985)
Tested (http://forum.chdk-treff.de/viewtopic.php?f=3&t=3154&sid=b7e3beade2f7e8e6b65f4e219c83c130&p=28071#p28069) in the German forum.
I could commit this myself, but I don't want to clash with any restructure operation in the svn.
sx240hs/sx260hs: Patch to remove unnecessary spytask function.Added, trunk changeset 2987 (http://trac.assembla.com/chdk/changeset/2987)
patch to platform/*/main.c to remove unused variable ptrAdded, trunk changeset 2986 (http://trac.assembla.com/chdk/changeset/2986)
This included a patch for the ixus500_elph520hs that is not in the trunk, SVN has created an empty directory for this camera?Oops, you are right. Removed.
a590 patchAdded trunk changeset 2996 (http://trac.assembla.com/chdk/changeset/2996) release changeset 2997 (http://trac.assembla.com/chdk/changeset/2997)
- capt_seq.c using code_gen
- fix CAMERA_MIN_DIST/CAMERA_MAX_DIST
- Enabled REMOTE_SYNC_STATUS_LED
Discussion and report: http://chdk.setepontos.com/index.php?topic=2361.msg103386#msg103386 (http://chdk.setepontos.com/index.php?topic=2361.msg103386#msg103386)
a590 patchAdded, trunk changeset 3000 (http://trac.assembla.com/chdk/changeset/3000) release changeset 3001 (http://trac.assembla.com/chdk/changeset/3001)
- fix capt_seq task param override (bug in code_gen.txt)
- new hook implementation for capt_seq task and init_file_modules
- boot.c and movie_rec.c generated using code_gen
sx160 patchAdded, trunk changeset 3016 (http://trac.assembla.com/chdk/changeset/3016) release changeset 3017 (http://trac.assembla.com/chdk/changeset/3017)
Patch to create "Port Under Development" versions.This forum doesn't have a "Like" button but if it did, I'd be pressing it here. This patch is not going to turn our new camera owners into dedicate testers all by itself, but it will serve as a "not so gentle reminder" to those "Please port my camera, I'm really really willing to test" people.
Patch to fix definitions in plaform_camera.hThanks. Added in trunk changeset 3027 (http://trac.assembla.com/chdk/changeset/3027), release changeset 3028 (http://trac.assembla.com/chdk/changeset/3028)
D20: filewrite taskAdded, trunk changeset 3038 (http://trac.assembla.com/chdk/changeset/3038) release changeset 3039 (http://trac.assembla.com/chdk/changeset/3039)
tested by lapser
a495 updateAdded, trunk changeset 3042 (http://trac.assembla.com/chdk/changeset/3043) release changeset 3044 (http://trac.assembla.com/chdk/changeset/3044)
OSD shows "BRACKET:Off" instead of "BRACKET:-/+" (expo_type is one element short, so array index gets out of bounds).Thanks, and welcome to the forum.
Fixed in attached patch. Tested on my SX260.
Patch to create "Port Under Development" versions.I have checked a heavily modified version of this into the trunk, changeset 3051 (http://trac.assembla.com/chdk/changeset/3051)
Motivation: http://chdk.setepontos.com/index.php?topic=10259.msg103774#msg103774 (http://chdk.setepontos.com/index.php?topic=10259.msg103774#msg103774)
To enable it, add #define UNDER_DEV_PORT 1 in platform_camera.h.
CHDK works normally during 7 days, after that a message will remind user to post feedback.
Thanks to waterwingz for suggestions and test.
Both phil and I were uncomfortable effectively making the camera unusable with CHDK after expiration. I think a more moderate nagging will probably be enough for most of the users who would provide useful feedback. You are of course free to do something more aggressive in your own test builds.I tested, I think that it is enough. Thanks.
Patch to create "Port Under Development" versions.My compiler (CHDK Shell) throws a warning from this line in gui.c when compiling the D20:
Motivation: http://chdk.setepontos.com/index.php?topic=10259.msg103774#msg103774 (http://chdk.setepontos.com/index.php?topic=10259.msg103774#msg103774)
To enable it, add #define UNDER_DEV_PORT 1 in platform_camera.h.
CHDK works normally during 7 days, after that a message will remind user to post feedback.
Thanks to waterwingz for suggestions and test.
I commented out the last line of localbuildconf.incAre you saying CHDKSHELL enabled this option by default? If so, it shouldn't do that. If you checked it yourself, well, don't do that.
//OPT_EXPIRE_TEST=7
Is this the right way to disable it? I don't want my custom builds to expire. Maybe it should be commented out by default?
Patch for A495Thanks. Added trunk changeset 3061 (http://trac.assembla.com/chdk/changeset/3061) release changeset 3062 (http://trac.assembla.com/chdk/changeset/3062)
- capt_seq_hdr.c and code_gen.txt files (I forgot to include them in previous patch).
- override GetBatteryTemperature() to prevent crash
- kbd.c clean up.
- notes.txt update
- key names for KEY_FACE, KEY_MODE, KEY_HELP included in modules/script_key_funcs.c
sx500is 100c/100d port beta. Thanks to beta testers.Added, trunk changeset 3075 (http://trac.assembla.com/chdk/changeset/3075) release changeset 3076 (http://trac.assembla.com/chdk/changeset/3076)
Small patch to disable RAW/DNG when A1200 is in "Low Light" mode. Thank to msl for pointing this out.Added, trunk changeset 3072 (http://trac.assembla.com/chdk/changeset/3072) release changeset 3074 (http://trac.assembla.com/chdk/changeset/3074) along with some similar fixes for d10, sx240 and sx260
fix live view while recording video in g15 and s110Added, trunk changeset 3120 (http://trac.assembla.com/chdk/changeset/3120), release changeset 3121 (http://trac.assembla.com/chdk/changeset/3121)
defined max sd for s110Are you sure about this value? It seems very low. I haven't checked it in for now.
Hello,Added, trunk changeset 3122 (http://trac.assembla.com/chdk/changeset/3122) release changeset 3123 (http://)
This patch adds support for firmware revision 100b of the ixus95_sd1200. It is based on the changes to boot.c proposed by luddek in the SD1200 IS porting thread with the addition of stubs_entry.S and stubs_auto.S. Tested with svn revision 3081
well if you go in MF and move the Canon slider that's the last value before -1 (zoom = 0)fix live view while recording video in g15 and s110Added, trunk changeset 3120 (http://trac.assembla.com/chdk/changeset/3120), release changeset 3121 (http://trac.assembla.com/chdk/changeset/3121)Quotedefined max sd for s110Are you sure about this value? It seems very low. I haven't checked it in for now.
well if you go in MF and move the Canon slider that's the last value before -1 (zoom = 0)My understanding is it should be the largest value in the longest zoom.
if I zoom in I get much bigger values but they mostly vary.. probably I misunderstood the meaning of this define
All right, then the value is 131579 :)well if you go in MF and move the Canon slider that's the last value before -1 (zoom = 0)My understanding is it should be the largest value in the longest zoom.
if I zoom in I get much bigger values but they mostly vary.. probably I misunderstood the meaning of this define
All right, then the value is 131579 :)Done, 3127 and 3128
Can you add 0xF8000000 to dumputil too? Thank you
I added some functionalities regarding the Eyefi SD cards.Excellent work, thank you.
I found some key mappings missing for the G15 and updated a couple of files consequently.Added, trunk changeset 3141 (http://trac.assembla.com/chdk/changeset/3141) release changeset 3142 (http://trac.assembla.com/chdk/changeset/3142)
Here is the patch
The diff is relative to the 3118 release, not to the previous patch (hope i did the right thing)Please make your patch relative the the current trunk, or at least a trunk revision after the original was applied.
Please make your patch relative the the current trunk, or at least a trunk revision after the original was applied.
Thanks. Unfortunately, I think some bits may have been lost, the code forPlease make your patch relative the the current trunk, or at least a trunk revision after the original was applied.
Diff to version 3144 for Eyefi attached, sorry for the inconvenience
//big endian
#define host_to_be32(n) (n)
in eyefi.h, since the cameras are in fact little endian.Sorry, I shouldn't try to do merges late at night.
Hope everything is ok now (but please do give a check...)
Patch to fix ND filter "flashing" problem with the G10. Updates propset2.h with correct param for ND filter state and adds CAM_HAS_NATIVE_ND_FILTER to G10 platform_camera.h
As the G12 & G15 already have this patch, I suspect the G11 and maybe G9 need it too but I have no way to test that.
Patch file to enable the G10 to use set_focus() in both MF and non-MF modes.Added, trunk changeset 3166 (http://trac.assembla.com/chdk/changeset/3166) release changeset 3167 (http://trac.assembla.com/chdk/changeset/3167)
I know the A590IS always has to be in MF for this to work. I wonder if this patch to enable the G10 toFor what its worth, the SD override code is pretty much the same for every camera. There are five #defines that control when CHDK will try to use this code :
use set_focus() in both MF and non-MF modes will do the same using the A590IS.
#define CAM_CAN_SD_OVERRIDE 1 // Camera allows to do subject distance override
#define CAM_CAN_SD_OVER_NOT_IN_MF 1 // Camera allows subject distance (focus) override when not in manual focus mode
#undef CAM_CAN_SD_OVER_IN_AF_LOCK // Camera allows subject distance (focus) override when in AF Lock mode
#undef CAM_CAN_SD_OVER_IN_AF_LOCK_ONLY // Camera allows subject distance (focus) override only when in AF Lock mode OR in movie mode
#define CAM_HAS_MANUAL_FOCUS 1 // Camera has manual focus mode
A particular camera's CHDK port will have some combination of these mode - testing is mostly trial & error to figure out which ones work and which don't. After that, its really only a question of the MoveFocusLensToDistance address in platform_camera.hSmall patch for config file ID typo in 1.3.0.
Was causing the "Shutter halfpress show" menu item to not save / restore properly.
Small fix for the "circles of confusion" parameter for the G10 found here : http://www.dofmaster.com/digital_coc.html (http://www.dofmaster.com/digital_coc.html)
I spot checked a few other cameras but did not find problems although I may very well have missed them if they are there.
Should probably go in trunk and dev branches.
Fix for variable OSD font sizes not drawing misc values and state display properly as reported by msl here :
http://chdk.setepontos.com/index.php?topic=10869.msg107011#msg107011 (http://chdk.setepontos.com/index.php?topic=10869.msg107011#msg107011)
Index: modules/dng.c
===================================================================
--- modules/dng.c (revision 3220)
+++ modules/dng.c (working copy)
@@ -845,6 +845,7 @@
fwrite(c, 1, 4, f);
}
count = count + len;
+ y += len - 1;
}
}
}
Can somebody upload a real life badpixel.bin made on a CMOS camera (preferably after the fix)? I'd like to test something...
Can somebody upload a real life badpixel.bin made on a CMOS camera (preferably after the fix)? I'd like to test something...Sorry - not much help here. Tried it on my only CMOS sensor camera (SX50 with BSI-CMOS sensor) both with and without the patch. I get a zero bad pixel (and therefore zero file length badpixel.bin file) report from the camera either way.
Patch to fix a regression in raw_init_badpixel_bin() - CHDK 1.2 and 1.3.Code: [Select]Index: modules/dng.cCan somebody upload a real life badpixel.bin made on a CMOS camera (preferably after the fix)? I'd like to test something...
===================================================================
--- modules/dng.c (revision 3220)
+++ modules/dng.c (working copy)
@@ -845,6 +845,7 @@
fwrite(c, 1, 4, f);
}
count = count + len;
+ y += len - 1;
}
}
}
Tried it on my only CMOS sensor camera (SX50 with BSI-CMOS sensor) both with and without the patch. I get a zero bad pixel (and therefore zero file length badpixel.bin file) report from the camera either way.Don't know how new cameras behave, it could be that bad pixels are now corrected before they reach the RAM...
Don't forget to update your dng module ;) The issue knocked out the RLE compression of repeating bad pixels and made the camera report a higher badpixel count.
w new cameras behave, it could be that bad pixels are now corrected before they reach the RAM...
y + = len - 1;has no effect on the number of bad pixels. At least not in my camera.
@srsa_4cThe above hexdump is from the start of your file. The red blocks are "wrong", only their first line (4 bytes) should be present in the file when you re-create the badpixel.bin with the fixed dng module.
It seems thatQuotey + = len - 1;has no effect on the number of bad pixels. At least not in my camera.
Attached is a patch for finsig_dryos to include ARAM_HEAP_START and ARAM_HEAP_SIZE in stubs_entry.S. I have intentionally not checked it in myself, in case the output or the code is not optimal.
Attached is a patch for finsig_dryos to include ARAM_HEAP_START and ARAM_HEAP_SIZE in stubs_entry.S. I have intentionally not checked it in myself, in case the output or the code is not optimal.
SX230 in aram seems like it should be fine. It would be good to know how much canon heap is available, if it is really low exmem might still be required.I have posted a request for malloc heap details. Enabling aram beside exmem would not bring much visible improvements, so I hope there's enough Canon heap...
For SX210, keymap and adjustable alt should be fine.Committed.
For the firmware variables, it would be good to either sanity check in the disassembly (look for equivalent code on a known working camera) or get a direct report from the test. recreview_hold being wrong in the original port would not be a surprise at all.Problem is, these may not be too easy to test (unless you have an idea), and I don't know whether the other r43 ports are a reliable source. I'll try to trace things in the disassembly...
a530Add in trunk changeset 3272 (http://trac.assembla.com/chdk/changeset/3272) release changeset 3273 (http://trac.assembla.com/chdk/changeset/3273)
PTP display stuff
Menu colors and digital zoom corrected.
Propcase left out of propset3 - PROPCASE_AF_LOCK.Added, trunk changeset 3286 (http://trac.assembla.com/chdk/changeset/3286) release changeset 3287 (http://trac.assembla.com/chdk/changeset/3287)
Tested on ixus120_sd940.
Found the other two AF props for propset3 as well.Added, trunk changeset 3288 (http://trac.assembla.com/chdk/changeset/3288) release changeset 3289 (http://trac.assembla.com/chdk/changeset/3289)
Patch to add USB remote precision sync code to the 1.3.0 trunk. Only enabled for A1200 at this point. Details posted here in forum thread : http://chdk.setepontos.com/index.php?topic=8312.msg108644#msg108644 (http://chdk.setepontos.com/index.php?topic=8312.msg108644#msg108644)
Note : unused #define SYNCHABLE_REMOTE_NOT_ENABLED in camera.h & ixus200_sd980/platform_carmera.h removed.
Currently usb_remote.c is built as platform independent code. It should not include platform_camera.h or have any platform dependent #ifdef code. Either make the decisions at run time from camera_info state variables, or move usb_remote.c to be part of the platform dependent code (platform/makefile_sub.inc).I think I know the answer to this, but why?
Currently usb_remote.c is built as platform independent code. It should not include platform_camera.h or have any platform dependent #ifdef code. Either make the decisions at run time from camera_info state variables, or move usb_remote.c to be part of the platform dependent code (platform/makefile_sub.inc).I think I know the answer to this, but why?
Platform independent code is only compiled once for all cameras in the batch build. If it contains platform dependent stuff, then every camera will get the settings from the first one compiled. It can also be converted to a module more easily.The second reason was my guess. The first reason is (I think) a relatively new change but makes sense to me.
Either make the decisions at run time from camera_info state variables, or move usb_remote.c to be part of the platform dependent code (platform/makefile_sub.inc).Phil :
Index: lib/core/Makefile
===================================================================
--- lib/core/Makefile (revision 3301)
+++ lib/core/Makefile (working copy)
@@ -11,7 +11,7 @@
OBJS = gui_batt.o gui_space.o gui_usb.o gui_mbox.o gps.o gui_script.o gui_menu.o gui_user_menu.o
OBJS+= suba.o levent.o console.o gps_math.o live_view.o ptp.o action_stack.o script.o
-OBJS+= usb_input.o usb_module.o usb_remote.o autoiso.o
+OBJS+= autoiso.o
OBJS+= $(topdir)modules/exportlist.inc module_load.o modules.o
all: libcore.a
Index: platform/makefile_sub.inc
===================================================================
--- platform/makefile_sub.inc (revision 3301)
+++ platform/makefile_sub.inc (working copy)
@@ -16,7 +16,7 @@
#add platform dependent 'core' files (build as THUMB)
OBJS+=main.thm.o gui_draw.thm.o memmgmt.thm.o \
gui.thm.o kbd_process.thm.o conf.thm.o gui_osd.thm.o raw.thm.o \
- shot_histogram.thm.o shooting.thm.o camera_info.thm.o remotecap.thm.o
+ shot_histogram.thm.o shooting.thm.o usb_input.thm.o usb_module.thm.o usb_remote.thm.o camera_info.thm.o remotecap.thm.o
libplatformsub.a: $(OBJS) bin_compat.h
I would suggest moving just that code to a function in a platform dependent file (core/usb_sync.c?). The function can be NOP if CAM_REMOTE_USES_PRECISION_SYNC is not defined. I think your makefile is correct, but you should only have to move the one file, not the other usb remote related files. Being compiled as thumb is not a change, since the lib/core files are also thumb.Moved wait_until_remote_button_is_released() into its own platform dependent file and added to platform/makefile_sub.inc .
Added in trunk changeset 3302 (http://trac.assembla.com/chdk/changeset/3302)I would suggest moving just that code to a function in a platform dependent file (core/usb_sync.c?). The function can be NOP if CAM_REMOTE_USES_PRECISION_SYNC is not defined. I think your makefile is correct, but you should only have to move the one file, not the other usb remote related files. Being compiled as thumb is not a change, since the lib/core files are also thumb.Moved wait_until_remote_button_is_released() into its own platform dependent file and added to platform/makefile_sub.inc .
A proposal patch to fix the eyefi functionalities I added. Relative to revision 3311.
- fixes a bug when user choses not to test a network being added
- more wait time network testing (it was often not enough)
I made extensive testing while traveling during 4 weeks, so it should be pretty stable right now.
I published this patch more than a week ago but got no reply and the code didn't end up in the repository. Am I missing something/should have done something different?A proposal patch to fix the eyefi functionalities I added. Relative to revision 3311.
- fixes a bug when user choses not to test a network being added
- more wait time network testing (it was often not enough)
I made extensive testing while traveling during 4 weeks, so it should be pretty stable right now.
Change to custom_auto_iso discussed here : http://chdk.setepontos.com/index.php?topic=11118.msg108981#msg108981 (http://chdk.setepontos.com/index.php?topic=11118.msg108981#msg108981)
Applies cleanly to 1.3.0 trunk and with automatic patch offsets in 1.2.0.
Update : added 1/2000 shutter speed in response to this request : http://chdk.setepontos.com/index.php?topic=11118.msg110742#msg110742 (http://chdk.setepontos.com/index.php?topic=11118.msg110742#msg110742)
One question concerning waterwingz statement here:
...
Will I have to make a special request for that? Or will you consider that "bug" automatically in future releases?
Update patch to cleanup USB remote code in 1.3.0 prior to submitting separate changes for battery 3rd terminal triggering and high speed pulse width measurement.Added, trunk changeset 3396 (http://trac.assembla.com/chdk/changeset/3396).
diff --git a/platform/s110/kbd.c b/platform/s110/kbd.c
index 512c136..1f968a3 100644
--- a/platform/s110/kbd.c
+++ b/platform/s110/kbd.c
@@ -17,7 +17,7 @@ static long kbd_mod_state[3] = { 0xFFFFFFFF, 0xFFFFFFFF, 0xFFFFFFFF };
extern void _GetKbdState(long*);
#define KEYS_MASK0 (0x000181EF)
-#define KEYS_MASK1 (0x00C00000)
+#define KEYS_MASK1 (0x00800000)
#define KEYS_MASK2 (0x000000C0)
#define SD_READONLY_FLAG 0x00000800 // Found @0xf864bc7c, levent 0x20a
@@ -46,9 +46,11 @@ static KeyMap keymap[] = {
{ 0, KEY_VIDEO ,0x00000100 },
{ 0, KEY_ZOOM_OUT ,0x00008000 }, // Found @0xf864bc2c, levent 0x03
{ 0, KEY_ZOOM_IN ,0x00010000 }, // Found @0xf864bc34, levent 0x02
- { 1, KEY_POWER ,0x00400000 }, // Found @0xf864bc54, levent 0x100
+
+// Removed since it breaks when shooting with KEY_POWER pressed
+// { 1, KEY_POWER ,0x00400000 }, // Found @0xf864bc54, levent 0x100
{ 1, KEY_PLAYBACK ,0x00800000 }, // Found @0xf864bc5c, levent 0x101
- { 1, KEY_PRINT ,0x00800000 }, // = Default ALT button
+
{ 2, KEY_SHOOT_FULL ,0x000000c0 }, // Found @0xf864bc6c, levent 0x01
{ 2, KEY_SHOOT_FULL_ONLY ,0x00000080 }, // Found @0xf864bc6c, levent 0x01
{ 2, KEY_SHOOT_HALF ,0x00000040 }, // Found @0xf864bc64, levent 0x00
diff --git a/platform/s110/platform_camera.h b/platform/s110/platform_camera.h
index fc80d34..3241060 100644
--- a/platform/s110/platform_camera.h
+++ b/platform/s110/platform_camera.h
@@ -37,8 +37,8 @@
#define CAM_HAS_NATIVE_ND_FILTER 1 // Camera has built-in ND filter with Canon menu support for enable/disable
#define CAM_ADJUSTABLE_ALT_BUTTON 1
- #define CAM_ALT_BUTTON_NAMES { "Playback", "Video", "Display" }
- #define CAM_ALT_BUTTON_OPTIONS { KEY_PRINT, KEY_VIDEO, KEY_DISPLAY }
+ #define CAM_ALT_BUTTON_NAMES { "Display", "Video" }
+ #define CAM_ALT_BUTTON_OPTIONS { KEY_DISPLAY, KEY_VIDEO }
#undef CAM_CAN_SD_OVER_NOT_IN_MF
#undef CAM_CAN_UNLOCK_OPTICAL_ZOOM_IN_VIDEO
Also removed KEY_PRINT entry since I see a number of ports deprecated it.KEY_PRINT alias has been removed from some ports, it was discussed here (http://chdk.setepontos.com/index.php?topic=10659.msg105005#msg105005), but KEY_PLAYBACK is the "standard" button used for ALT mode in several models:
#define CAM_ALT_BUTTON_NAMES { "Playback", "Video", "Display" }
#define CAM_ALT_BUTTON_OPTIONS { KEY_PLAYBACK, KEY_VIDEO, KEY_DISPLAY }
whoops sorry, I always think playback=disp (and I know it's wrong!)Also removed KEY_PRINT entry since I see a number of ports deprecated it.KEY_PRINT alias has been removed from some ports, it was discussed here (http://chdk.setepontos.com/index.php?topic=10659.msg105005#msg105005), but KEY_PLAYBACK is the "standard" button used for ALT mode in several models:Code: [Select]#define CAM_ALT_BUTTON_NAMES { "Playback", "Video", "Display" }
#define CAM_ALT_BUTTON_OPTIONS { KEY_PLAYBACK, KEY_VIDEO, KEY_DISPLAY }
A patch for 1.3.0 to reset the behavior of the set_mf and set_focus uBASIC commands for backwards compatibility. Currently they try to return a status value which needs to be used somehow. This patch reverts them to no longer returning status. See : http://chdk.setepontos.com/index.php?topic=11373.msg111673#msg111673 (http://chdk.setepontos.com/index.php?topic=11373.msg111673#msg111673)Added, trunk changeset 3403 (http://trac.assembla.com/chdk/changeset/3403)
The Lua equivalent functions are not affected by this patch and will continue to return status.
There may very well be a better way to do this.
This patch adjusts S110's kbd so it doesn't interfere with shooting (ptp) when keeping the KEY_POWER phisically pressed.Added (adjusted per later comments) in trunk changeset 3404 (http://trac.assembla.com/chdk/changeset/3404) release 3405 (http://trac.assembla.com/chdk/changeset/3405)
Also removed KEY_PRINT entry since I see a number of ports deprecated it.
This does not address concerns about overloading the camera using the function,Updated patch file that adds a #define to camera.h for specifying the shortest interval to which a script can set the HP timer. Defaults to 1000 uSec, which is a big speed-up from the standard USB remote timing and slower than the 500 uSec rate that my cameras all seemed to manage just fine with.
Added in trunk changeset 3408 (http://trac.assembla.com/chdk/changeset/3408)This does not address concerns about overloading the camera using the function,Updated patch file that adds a #define to camera.h for specifying the shortest interval to which a script can set the HP timer. Defaults to 1000 uSec, which is a big speed-up from the standard USB remote timing and slower than the 500 uSec rate that my cameras all seemed to manage just fine with.
Fix attached.Added, trunk changeset 3410 (http://trac.assembla.com/chdk/changeset/3410)
Small patch to fix timing error in USB remote HP timer mode.Added, trunk changeset 3414 (http://trac.assembla.com/chdk/changeset/3414)
Update italian language
Sorry. Your are right.
I reposted the file (patch).
If you need I can post also the language file
IXUS255 / ELPH330HS port for firmware 100f and 100h. See http://chdk.setepontos.com/index.php?topic=10150 (http://chdk.setepontos.com/index.php?topic=10150) and https://github.com/mpetroff/chdk-elph330hs. (https://github.com/mpetroff/chdk-elph330hs.)
Update for czech lng file.
Sorry. Your are right.
I reposted the file (patch).
If you need I can post also the language file
Sorry; but message 563 is still too long.
Phil.
IXUS255 / ELPH330HS port for firmware 100f and 100h. See http://chdk.setepontos.com/index.php?topic=10150 (http://chdk.setepontos.com/index.php?topic=10150) and https://github.com/mpetroff/chdk-elph330hs. (https://github.com/mpetroff/chdk-elph330hs.)
I was not able to cleanly apply this patch to either the current revision of 1.2 or 1.3.
Phil.
patch -p0 < ixus255_elph330hs_v2.patch from the base directory of the development trunk (i.e, the directory containing README, COPYING, camera_list.csv, etc.).
... and some way to query the CAM_SD_OVER_IN* values.
Small patch file to implement this :Added, trunk changeset 3423 (http://trac.assembla.com/chdk/changeset/3423/trunk)... and some way to query the CAM_SD_OVER_IN* values.
Adds a get_sd_over_modes() function to Lua and uBASIC. Returns a bit map where the bits are :
- = can set focus in Autofocus mode (0x01)
- = can set focus in AFL mode (0x02)
- = can set focus in MF mode (0x04)
Sorry. Your are right.
I reposted the file (patch).
If you need I can post also the language file
Sorry; but message 563 is still too long.
Phil.
Hi. Msg 563 reduce. Sorry again...
IXUS255 / ELPH330HS port for firmware 100f and 100h. See http://chdk.setepontos.com/index.php?topic=10150 (http://chdk.setepontos.com/index.php?topic=10150) and https://github.com/mpetroff/chdk-elph330hs. (https://github.com/mpetroff/chdk-elph330hs.)
I was not able to cleanly apply this patch to either the current revision of 1.2 or 1.3.
Phil.
It applies cleanly for me from the root of the svn tree (i.e. the directory with the trunk, branches, and tags directories). Attached is a new version that applies cleanly for me usingCode: [Select]patch -p0 < ixus255_elph330hs_v2.patchfrom the base directory of the development trunk (i.e, the directory containing README, COPYING, camera_list.csv, etc.).
Fix for missing "core_spytask_can_start" call in boot.c for ixus960_sd950 per this thread : http://chdk.setepontos.com/index.php?topic=11498 (http://chdk.setepontos.com/index.php?topic=11498)Added, trunk changeset 3438 (http://trac.assembla.com/chdk/changeset/3438) release changeset 3439 (http://trac.assembla.com/chdk/changeset/3439)
Tested on 1.2.0, should also work on 1.3.0.
Patch to remove menu items related to using battery third terminal remote if CAM_REMOTE_AtoD_CHANNEL is not defined.
Problem reported here : http://chdk.setepontos.com/index.php?topic=10385.msg112854#msg112854 (http://chdk.setepontos.com/index.php?topic=10385.msg112854#msg112854)
Tested on G10 (no AtoD channel defined) and SD940 (AtoD channel defined). Trunk 1.3.0 rebuilt with patch applied.
Per msl's suggestion (http://chdk.setepontos.com/index.php?topic=7127.msg112912#msg112912), I think it's time to enable the HP timer function in scripts.
The attached patch does that for 1.3.0 but leaves the minimum timer interval at 1 mSec for safety.
Patch file for the S95 to enable the user defined <ALT> key function.
Forum thread > S95, S90 alt button (http://chdk.setepontos.com/index.php?topic=11515.0)
Also attached is an untested identical S90 patch - posted here for interest only pending somebody volunteering to test ( http://chdk.setepontos.com/index.php?topic=4509.msg112901#msg112901 (http://chdk.setepontos.com/index.php?topic=4509.msg112901#msg112901) ).
Small patch to fix an issue with the RAW/DNG disabled warnings when OSD state display is not enabled.Added, trunk changeset 3453 (http://trac.assembla.com/chdk/changeset/3453)
Patches for problem with fast Ev switch mode where enabling the mode caused Canon menus to no longer respond to the Up/Down keys as reported here : http://chdk.setepontos.com/index.php?topic=11557 (http://chdk.setepontos.com/index.php?topic=11557)Added, trunk changeset 3455 (http://trac.assembla.com/chdk/changeset/3455) release changeset 3456 (http://trac.assembla.com/chdk/changeset/3456) (adjusted slightly to compile)
Here's a simple patch based on a conversation with reyalp on IRC the other day.Added in trunk changeset 3459 (http://trac.assembla.com/chdk/changeset/3459) with some further modification based on our discussion in irc.
The idea is to force an error message on the screen if there are no modules on the SD card (i.e. typically due to an incorrect install).
Update for czech lng file.
Is this for version 1.2 or 1.3?
Phil.
Patch for ixus125_elph110hs. Upgrade to this (redacted) patch : http://chdk.setepontos.com/index.php?topic=650.msg113650#msg113650 (http://chdk.setepontos.com/index.php?topic=650.msg113650#msg113650) to include better set_mf() functions and enable RAW shortcut toggling.
Tested here : http://chdk.setepontos.com/index.php?topic=11078.msg113791#msg113791 (http://chdk.setepontos.com/index.php?topic=11078.msg113791#msg113791)
It is for version 1.3, but in attachment is updated version :).Update for czech lng file.
Is this for version 1.2 or 1.3?
Phil.
Fixes for various issues with the IXUS1000/SD4500 port.
- My 100b version seems identical to 100d except that it's called SD4500 instead of IXUS1000.
- The alt mode key is configurable between Movie and Playback. Movie is still the default.
- The DNG active area, color matrix, and white and black points are corrected.
- Override subject distance should work.
- Other minor fixes.
Submitted : a patch file to add the IXUS115_ELPH100HS fw 1.00c, 1.01a, 1.01b&1.01c to the dev trunk & autobuild.
Submitted : a patch file to add the IXUS115_ELPH100HS fw 1.00c, 1.01a, 1.01b&1.01c to the dev trunk & autobuild.
Someone asked me to compile an SDM test version for the IXUS115 101c.
So, I quickly ported a build for 101b, a fairly trivial task.
Except ..... it refuses to boot.
Absolutely nothing happens.
This has never happened with any earlier or later camera ports to SDM.
Because SDM still uses the loader code that has a separate resetcode folder, I tried using all the loader files from changeset 1977, but it makes no difference.
(I do not fully understand the loader code anyway.)
Have there been any changes to CHDK PLATFORM code that affects cameras whose firmware version (101c) is identical to another version (101b) ?
https://yotann.org/~tmp/ixus1000_sd4500_100b.bin (https://yotann.org/~tmp/ixus1000_sd4500_100b.bin)Fixes for various issues with the IXUS1000/SD4500 port.Can you provide a firmware dump please, just want to verify that it is compatible with 100d.
- My 100b version seems identical to 100d except that it's called SD4500 instead of IXUS1000.
- ...
A couple of suggestions before I commit this:There are already duplicates for many other modes because they aren't hidden under a SCN menu like in other cameras. Someone apparently thought that was important enough to make new modes. I've switched to the existing MODE_SCN_ entries, but I haven't changed the existing non-SCN duplicates, which are also used by a few other cameras.
- modelist.h already has MODE_SCN_WINK_SELF_TIMER and MODE_SCN_FACE_SELF_TIMER, do we really need two new entries?
- the color matrix entries (platform_camera.h) all have the denominator set to 1,000,000 (was done by the original port). A value of 10,000 probably makes more sense (e.g. first entry would be 1.4134, not 0.014134)Fixed.
https://yotann.org/~tmp/ixus1000_sd4500_100b.bin (https://yotann.org/~tmp/ixus1000_sd4500_100b.bin)Fixes for various issues with the IXUS1000/SD4500 port.Can you provide a firmware dump please, just want to verify that it is compatible with 100d.
- My 100b version seems identical to 100d except that it's called SD4500 instead of IXUS1000.
- ...
QuoteA couple of suggestions before I commit this:There are already duplicates for many other modes because they aren't hidden under a SCN menu like in other cameras. Someone apparently thought that was important enough to make new modes. I've switched to the existing MODE_SCN_ entries, but I haven't changed the existing non-SCN duplicates, which are also used by a few other cameras.
- modelist.h already has MODE_SCN_WINK_SELF_TIMER and MODE_SCN_FACE_SELF_TIMER, do we really need two new entries?Quote- the color matrix entries (platform_camera.h) all have the denominator set to 1,000,000 (was done by the original port). A value of 10,000 probably makes more sense (e.g. first entry would be 1.4134, not 0.014134)Fixed.
.
Are you sure it's an IXUS115 and not an ELPH115 (IXUS132)?
It would seem the IXUS115 is the only camera supported by SDM that has the 'new' AgentRam.AdditionAgentRAM - an unused piece of memory? (http://chdk.setepontos.com/index.php?topic=10886.0)
I will investigate why it was added for this camera.
.
The port used EXMEM (http://chdk.setepontos.com/index.php?topic=5980.0) before which results in over-compressed JPEGs on certain cameras - this model was affected by that.
Small extension to outslider's drawing.lua library to enable font scaling (via the 1.3.0 version of draw_string())Added, trunk changeset 3487 (http://trac.assembla.com/chdk/changeset/3487/trunk)
Not exactly the world's most exciting change but here's a fixup for RAW/DNG directory naming conventions per : http://chdk.setepontos.com/index.php?topic=11615.msg113826#msg113826 (http://chdk.setepontos.com/index.php?topic=11615.msg113826#msg113826)Added, trunk changeset 3499 (http://trac.assembla.com/chdk/changeset/3499)
Too bad we don't have the equivalent of a mailing list for the good people who help maintain the language files. I'm sure that they would respond quickly to small changes like this if they were aware of them.Not exactly the world's most exciting change but here's a fixup for RAW/DNG directory naming conventions per : http://chdk.setepontos.com/index.php?topic=11615.msg113826#msg113826 (http://chdk.setepontos.com/index.php?topic=11615.msg113826#msg113826)Added, trunk changeset 3499 (http://trac.assembla.com/chdk/changeset/3499)
Patch files for 1.2.0 & 1.3.0 to fix this long standing bug / missing functionality related to the USB remote not triggering wait_click(0) per http://chdk.setepontos.com/index.php?topic=7127.msg115071#msg115071 (http://chdk.setepontos.com/index.php?topic=7127.msg115071#msg115071)Added, trunk changeset 3549 (http://trac.assembla.com/chdk/changeset/3549) release changeset 3550 (http://trac.assembla.com/chdk/changeset/3550)
Tested on A1200 and by msl
Powershot N 1.00a BETA release per http://chdk.setepontos.com/index.php?topic=11460.msg115211#msg115211 (http://chdk.setepontos.com/index.php?topic=11460.msg115211#msg115211)
One integration item of note - I made kbd_blocked in core/kbd_process.c not static so that my touch task hack would know if CHDK was active or not. Works well and doesn't seem to cause any issues with a complete trunk rebuild. However, if there is a better way to do this I'd be happy to change it.
Update patch for A1300 SD override modes based on test submitted by an A1300 owner.Added, trunk changeset 3563 (http://trac.assembla.com/chdk/changeset/3563)
Small patch file for Powershot N to fix RAW/DNG save folder and to correct zoom in / zoom out orientation.Added, trunk changeset 3576 (http://trac.assembla.com/chdk/changeset/3576)
Small fix for the Powershot "N" ( failure to update a C&P'd value ... )Added, trunk changeset 3579 (http://trac.assembla.com/chdk/changeset/3579)
Second small fix for Powershot "N". This time to enable starting in shooting mode when power button is held down during powerup.Added, trunk changeset 3582 (http://trac.assembla.com/chdk/changeset/3582)
Patch file for the Powershot N to correct three recently reported problems.Added, trunk changeset 3593 (http://trac.assembla.com/chdk/changeset/3593)
Patch file to add the Powershot N Facebook addition as an ALPHA release.Added, trunk changeset 3595 (http://trac.assembla.com/chdk/changeset/3595)
Powershot N & Powershot N FacebookAdded, trunk changeset 3602 (http://trac.assembla.com/chdk/changeset/3602)
Fix for CAM_LOAD_CUSTOM_COLORS conflict with Canon Color Option setting as summarized here :
http://chdk.setepontos.com/index.php?topic=11460.msg116119#msg116119 (http://chdk.setepontos.com/index.php?topic=11460.msg116119#msg116119)
Patch file to correct SD override values in platform_camera.h and/or wrappers.c for various cameras based on test data supplied by koshy (and a few others).Added, trunk changeset 3603 (http://trac.assembla.com/chdk/changeset/3603)
Rest of code_gen patches for sx200is
4. capt_seq
5. movie_rec
6. boot
Patches for sx200is:
1. rewrite of taskCreateHook.
2. implementation of task_FileWrite.
3. OPT_RUN_WITH_BATT_COVER_OPEN.
All tested and working.
P.S. Patches are adjusted for svn by hand, since I use svn-git, I included original patches under git subdirectory.
Fix for Powershot N & Powershot N Facebook video crashing reported here :
http://chdk.setepontos.com/index.php?topic=11460.msg117059#msg117059 (http://chdk.setepontos.com/index.php?topic=11460.msg117059#msg117059)
Thanks to nafraf and srsa_4c for jumping on this right away.
Patch for 1.3.0 to allow the file select window to have different column widths on different cameras as discussed here :
http://chdk.setepontos.com/index.php?topic=11937 (http://chdk.setepontos.com/index.php?topic=11937)
Tested on Powershot N and A1200 with 1.3.0 version (complete 1.3.0 branch rebuilds properly as well).
Another small fix for the two Powershot N models - corrects occasional issues with <ALT> key causing pseudo-random activities to happen at startup.
Simplified loader code for the SX200is.
code_gen comments for sx200is
Powershot N & Powershot N Facebook : Patch for pallete pointers needed for chdkptp liveview.
Props to reyalp for pointing out what was missing.
Cleanup of double code_gen comments for sx200is after r3636
Patch files to fix the USB remote zoom function for "super zooms" as discussed here : Remote Zoom Strange Behavior w/A4000 (http://chdk.setepontos.com/index.php?topic=11954.0)Added, trunk changeset 3640 (http://trac.assembla.com/chdk/changeset/3640) release changeset 3641 (http://trac.assembla.com/chdk/changeset/3641)
Changes to the S100's platform_camera.h to improve CHDK driven zoom positioning.
Not sure why this has been omitted so far - the change nafraf made to the uBASIC test script looking for the playback key has been in the autobuild for a while now.Just forgotten I think. Added in trunk changeset 3644 (http://trac.assembla.com/chdk/changeset/3644).
A small patch to correct how the jog dial direction is interpreted on the S100. Currently, turning the dial in the Canon menus moves through the selected menus in the opposite direction than when you turn the dial in the CHDK menus.
Annoying.
This patch fixes that.
Corrects the Powershot N, Powershot N Facebook, S100, and A1200.Added, trunk changeset 3775
All tested on 1.3.0 (except n_facebook camera) with vidtest.lua and now perform properly (i.e. no reported errors).
Before this gets "stepped on" again, patch file for the GPS code suitable for 1.4.0.
Builds cleanly against the new 1.4.0 trunk.
Once this is in, I'll work on the enhancements mentioned in the GPS thread.
It is probably worth adding rudi's patch from here : http://chdk.setepontos.com/index.php?topic=12076.msg118315#msg118315 (http://chdk.setepontos.com/index.php?topic=12076.msg118315#msg118315) to the 1.3.0 build.
I've tested his changes as part of the 1.4.0 patch and encorporated them there. It fixes the bug mentioned in the thread linked here.
Several minor/cosmetic cleanups to 1.4.0 GPS code.
Fix for video button interaction with Canon shooting mode per this discussion : http://chdk.setepontos.com/index.php?topic=12163.msg119879#msg119879 (http://chdk.setepontos.com/index.php?topic=12163.msg119879#msg119879)
Has no effect on cameras without video button (none needed).
On camera with video button that have no CHDK defined Canon shooting modes that contain the 0x0400 video bit, it prevents the return of a null shooting mode. Tested on S100 using USB Remote Control Mode [ Video ].
On camera with video button but with defined Canon modes that contain the 0x0400 video bit, everything works as before. Tested on Powershot N using USB Remote Control Mode [ Video ].
.
Wow - bizarre patch file. Please ignore the 1.3.0 patch - no idea what happened there. 1.3.0 users can struggle on with the way it has been for years I guess.Fix for video button interaction with Canon shooting mode per this discussion : http://chdk.setepontos.com/index.php?topic=12163.msg119879#msg119879 (http://chdk.setepontos.com/index.php?topic=12163.msg119879#msg119879)
Has no effect on cameras without video button (none needed).
On camera with video button that have no CHDK defined Canon shooting modes that contain the 0x0400 video bit, it prevents the return of a null shooting mode. Tested on S100 using USB Remote Control Mode [ Video ].
On camera with video button but with defined Canon modes that contain the 0x0400 video bit, everything works as before. Tested on Powershot N using USB Remote Control Mode [ Video ].
.
1.3 patch uses VID_REC_ACTIVE_BIT in shooting.c instead of CAM_MASK_VID_REC_ACTIVE. It also includes spurious changes for SX240 & SX260 (looks like a partial failed patch).
Phil.
Fix for video button interaction with Canon shooting mode per this discussion : http://chdk.setepontos.com/index.php?topic=12163.msg119879#msg119879 (http://chdk.setepontos.com/index.php?topic=12163.msg119879#msg119879)
Has no effect on cameras without video button (none needed).
On camera with video button that have no CHDK defined Canon shooting modes that contain the 0x0400 video bit, it prevents the return of a null shooting mode. Tested on S100 using USB Remote Control Mode [ Video ].
On camera with video button but with defined Canon modes that contain the 0x0400 video bit, everything works as before. Tested on Powershot N using USB Remote Control Mode [ Video ].
.
Edit : deleted 1.3.0 patch file - contents were bizarre
A couple more updates to shooting modes per http://chdk.setepontos.com/index.php?topic=12163.msg119906#msg119906 (http://chdk.setepontos.com/index.php?topic=12163.msg119906#msg119906) and conversations with reyalp on IRC.
The 1.3.0 patch file is the corrected version of what I meant to post earlier to fix USB remote video mode lockups for cameras with a seperate video button (patch already applied to 1.4.0)
The 1.4.0 patch file removes mode definitions that can't actually be set via set_capture_mode().
Edit : complete trunk build was completed for both patches. Results tested on Powershot N and S100 using USB remote video control mode.
MF mode patches for ixus132_elph115 per http://chdk.setepontos.com/index.php?topic=12200.msg120152#msg120152 (http://chdk.setepontos.com/index.php?topic=12200.msg120152#msg120152)Added, trunk 3946 stable 3947
User menu mods to expand how scripts are handled. Pressing the shutter button runs the script when it's selected in the User Menu. Pressing Func/Set brings up a dialog box to allow the script to be loaded and then jump to the Script menu, or to cancel.
From the Script menu, selecting Back returns you to the User Menu.
forum thread : alternative ways to start a script (http://chdk.setepontos.com/index.php?topic=10933.msg120427#msg120427)
Patch file (1.4.0) to cleanup USB remote code per the discussion here : http://chdk.setepontos.com/index.php?topic=7127.msg120508#msg120508 (http://chdk.setepontos.com/index.php?topic=7127.msg120508#msg120508)Added, trunk changeset 4002 (https://www.assembla.com/code/chdk/subversion/commit/4002)
Patch file (1.4.0) to cleanup USB remote code per the discussion here : http://chdk.setepontos.com/index.php?topic=7127.msg120508#msg120508 (http://chdk.setepontos.com/index.php?topic=7127.msg120508#msg120508)
Patch simplifies the code by removing unnecessary interlocks, fixes some issues with debug mode, and adds a usb_sync_wait() function to Lua and uBASIC for scripting use with multi-camera setups.
Updates to the usb_force_active() function per this discussion : http://chdk.setepontos.com/index.php?topic=7127.msg120539#msg120539 (http://chdk.setepontos.com/index.php?topic=7127.msg120539#msg120539) deferred pending reyalp updates to kbd.c files.
For consistency the 'usb_sync_wait_flag' entry in module_exportlist.c should be '&usb_sync_wait_flag' - this generates a variable reference instead of a function reference in module_hashlist.c.Patch :-X
Patch for S100 ND filter as discussed here :Added in trunk 3028, stable 4029
Patch to re-enable the creation of a ps.fi2 file for the S100. Tested on the 1.02A and thus assumed to likely work on the other versions.Added in trunk 4030. As you suggested in IRC, I'll leave it there for people to try other firmware versions before enabling in 1.3
Patch to show gps errors (no signal, no gps info in image, ...) using the message box instead of writing directly to the screen and wait/block for a few seconds. Because of the limited string length in the message box I had to insert some newlines (only fixed english and german).This was definitely on my list of things to clean up but I'm currently traveling with almost no internet access so have not had a chance to test it. Perhaps it would have been better to post to the forum thread for the GPS code first? I try to make it a point to submit my patches that way in case there is any discussion.
Patch file to add codegen for the G10. Includes the addition of filewrite.cAdded, trunk 4066. Did you check remote capture, including -cont?
Would be good to add only to unstable until the 1.03b & 1.04a are tried.Added to testing needed page. That said, diffing the files between platforms and verifying that only offsets change is probably good enough.
Did you check remote capture, including -cont?Yes & yes. Works great!
kbd.c 1.4.0 changes for G10 (with jog dial)Added, trunk 4068.
Tested kbd.c 1.4.0 patch for the S100. Adds the necessary hooks for the current GPS code to kbd_common.c as well.Added, trunk 4069
CHDK 1.4.0 kbd patch file for S90, S95, & S110. Builds but not tested.Thanks. Added in trunk 4077, with the addition of SD_READONLY_IDX for s90, s95.
S80 uses older style kbd code - was not comfortable blind converting that one.
Patch to show gps errors (no signal, no gps info in image, ...) using the message box instead of writing directly to the screen and wait/block for a few seconds. Because of the limited string length in the message box I had to insert some newlines (only fixed english and german).Thanks.
CHDK 1.4.0 kbd patch file for ixus120_sd940. Tested on f/w 1.03C.Thanks. Added in trunk 4099-4100.
As noted in the commit log, this patched made the battery door hack no longer hard coded. I added the OPT_RUN_WITH_BATT_COVER_OPEN to the corresponding parts of boot.c, so people not using the hack won't get the boot delay.My patch did not do that so I assume you made that choice? I guess it's fine for "standardization" but it will make things a little harder on script writers if they haven't figured out how to use chdkptp to xfer script files. It really does not "cost" much to build it in and it does not really work in a non-standard manner if you don't actually use the feature.
The patch also removed some code involving altDownTimer in kbd.c. I'm not clear what it did, but figured I'd mention it in case you didn't mean to get rid of it.My bad - in converting everything to match the other ports revised code I missed this.
New dancing bits and keysys for DryOS r55. Made against 4150.Thanks, added in trunk r4151, stable r4152.
Patch file to add sx530hs to the 1.4.0 svn. Marked SKIP_AUTOBUILD for now.Added, trunk 4181. Comments in http://chdk.setepontos.com/index.php?topic=12418.msg123295#msg123295 (http://chdk.setepontos.com/index.php?topic=12418.msg123295#msg123295)
Based on jeronymoGustavo (http://chdk.setepontos.com/index.php?action=profile;u=28443)'s work in the Porting a camera sx530hs (http://chdk.setepontos.com/index.php?topic=12418.msg123262#msg123262) thread.
A small patch file for CHDK 1.3.0 so that uBASIC scripts don't throw a syntax error if there is an @chdk_version statement in the script.Added in 4216
Two more small patch files for uBASIC.Added in trunk 4217, release 1.3 4218. As discussed in IRC, I changed the 1.3 version to continue allowing the old syntax. I doubt anyone is using this, but may as well stick to the "stable versions script compatible" where possible.
Changes set_remote_timing to be a statement rather than a factor. I believe this is more consistent with uBASIC style (i.e. does not force user to check the return value).
Also a small parsing fix for usb_sync_wait in 1.4.0
Wow - first submitted patch in almost six months. That must be something of a record.
Patch to fix OSD keyboard for Powershot N & Powershot N Facebook when CHDK OSD is rotated 180 deg.
(per http://chdk.setepontos.com/index.php?topic=12684.msg126574#msg126574 (http://chdk.setepontos.com/index.php?topic=12684.msg126574#msg126574))
Also removed a bit of dead code just because. As noted elsewhere, the touchscreen code for the four or five ported cameras needs to be harmonized at some point.
Patch to enable the RAW exception for "Sports" mode on the SX50hs per Disable raw in Sports Mode on SX50? (https://chdk.setepontos.com/index.php?topic=12800)Added, trunk 4562, stable 4563
Patch works for both 1.4 and the dev trunks. Tested on 1.00c firmware.
The default.lua script does not work correct when the user uses another display language as german or english.The script (https://www.assembla.com/spaces/chdk/subversion/source/HEAD/trunk/CHDK/SCRIPTS/default.lua) reads (http://chdk.wikia.com/wiki/Lua/Lua_Reference#get_prop) property case (http://chdk.wikia.com/wiki/PropertyCase) 196 or 61 (depending on the cam's propset). It then tries to work out the correct offset for the recognized languages.
While this is not a show stopper, I would like to modify this script, so all languages are supported. But can someone give me a hint where I can find the language numbers for all other languages?
About auto-recognizing the toolchain: I'm neutral on this. Let reyalp decide.I don't care much one way or the other about auto-detection, but I think eabi should be the default and should be used for all normal CHDK development now. It's already the default on the autobuild and required for D6, and pre-built toolchains are available for most platforms. We could still use the auto-detect logic.
Index: core/shooting.c
===================================================================
--- core/shooting.c (revision 4635)
+++ core/shooting.c (working copy)
@@ -304,6 +304,11 @@
// Some cameras will crash if flash used and ISO set lower than this value (most easily tested in AUTO mode)
if ((iso > 0) && (iso < CAM_MIN_ISO_OVERRIDE)) iso = CAM_MIN_ISO_OVERRIDE;
#endif
+#ifdef CAM_MAX_ISO_OVERRIDE
+ // Limit max ISO
+ // Some cameras will crash if ISO set higher than this value (dependence on flash is unclear)
+ if (iso > CAM_MAX_ISO_OVERRIDE) iso = CAM_MAX_ISO_OVERRIDE;
+#endif
return shooting_iso_market_to_real(iso); // return real value (after limits applied)
}
@@ -416,6 +421,10 @@
// Limit min (non-zero) ISO
if ((iso > 0) && (iso < ISO_MARKET_TO_REAL(CAM_MIN_ISO_OVERRIDE))) iso = ISO_MARKET_TO_REAL(CAM_MIN_ISO_OVERRIDE);
#endif
+#ifdef CAM_MAX_ISO_OVERRIDE
+ // Limit max ISO
+ if (iso > ISO_MARKET_TO_REAL(CAM_MAX_ISO_OVERRIDE)) iso = ISO_MARKET_TO_REAL(CAM_MAX_ISO_OVERRIDE);
+#endif
shooting_set_sv96(shooting_get_sv96_from_iso(iso), is_now);
}
}
Index: include/camera.h
===================================================================
--- include/camera.h (revision 4635)
+++ include/camera.h (working copy)
@@ -207,6 +207,7 @@
#undef CAM_DISABLE_RAW_IN_DIGITAL_IS // For cameras with 'Digital IS' mode that does not work with raw define this
#undef CAM_DISABLE_RAW_IN_SPORTS // For cameras that corrupt DNG/JPEG in Sports mode
#undef CAM_ISO_LIMIT_IN_HQ_BURST // Defines max 'market' ISO override value for HQ Burst mode (higher values crash camera)
+ #undef CAM_MAX_ISO_OVERRIDE // Defines max 'market' (non-zero) ISO override value - higher value may crash
#undef CAM_MIN_ISO_OVERRIDE // Defines min 'market' (non-zero) ISO override value - lower value may crash if flash used [0 = AUTO, so always allowed]
#undef CAM_HAS_GPS // for cameras with GPS reseiver: includes the GPS coordinates in in DNG file
Index: platform/sx520hs/platform_camera.h
===================================================================
--- platform/sx520hs/platform_camera.h (revision 4635)
+++ platform/sx520hs/platform_camera.h (working copy)
@@ -142,7 +142,10 @@
#define CAM_SD_OVER_IN_AFL 1
#define CAM_SD_OVER_IN_MF 1
+ #define CAM_MIN_ISO_OVERRIDE 100 // https://chdk.setepontos.com/index.php?topic=12314.msg128518#msg128518
+ #define CAM_MAX_ISO_OVERRIDE 3200 // https://chdk.setepontos.com/index.php?topic=12314.msg128683#msg128683
+
#undef DRAW_ON_ACTIVE_BITMAP_BUFFER_ONLY //jeronymo
#define DRAW_ON_ACTIVE_BITMAP_BUFFER_ONLY 1
//----------------------------------------------------------
Index: platform/sx530hs/platform_camera.h
===================================================================
--- platform/sx530hs/platform_camera.h (revision 4635)
+++ platform/sx530hs/platform_camera.h (working copy)
@@ -142,7 +142,10 @@
#define CAM_SD_OVER_IN_AFL 1
#define CAM_SD_OVER_IN_MF 1
+ #define CAM_MIN_ISO_OVERRIDE 100 // https://chdk.setepontos.com/index.php?topic=12314.msg128518#msg128518
+ #define CAM_MAX_ISO_OVERRIDE 3200 // https://chdk.setepontos.com/index.php?topic=12314.msg128683#msg128683
+
#undef DRAW_ON_ACTIVE_BITMAP_BUFFER_ONLY //jeronymo
#define DRAW_ON_ACTIVE_BITMAP_BUFFER_ONLY 1
//----------------------------------------------------------
Posting this here before commit, so there's a chance someone will notice if there's something obviously wrong with it.Looks fine to me.
Looks fine to me.Thanks, I checked it in (https://www.assembla.com/spaces/chdk/subversion/commits/4638).
Patch for Powershot N and Powershot N Facebook to add script control of the focus assist / camera flash lamp on the front of the camera via the set_led() function.Thanks. Added in trunk 4677, stable 4678.
See Re: Powershot N Porting Thread (https://chdk.setepontos.com/index.php?topic=11460.msg129702#msg129702)
Files for sx410is, firmware version 100c.Thanks. Checked into the trunk r4686, followed by some additions to notes.txt. Comments will go in the porting thread.
Posting a patch for SX60HS to update 4706. Correct stubs for live view video clips, recreviewhold.Thanks for that.
See SX60HS porting thread:
https://chdk.setepontos.com/index.php?topic=12532.new (https://chdk.setepontos.com/index.php?topic=12532.new)
Hopefully I've corrected things to your satisfaction: :)Thanks. Checked in.
Posting a patch for SX60HS to update 4712. Include support for firmware version 100c. Shortcut key replaces Wifi for a substitute ALT key.Thanks. Checked in.
See SX60HS porting thread:
https://chdk.setepontos.com/index.php?topic=12532.new
SX410_100c NR_hook patch.Thanks. Committed (https://app.assembla.com/spaces/chdk/subversion/commits/4749) with some modifications (moved the hooks closer to sub_FF9B4AF8 where the nr flag is evaluated).
Related with this discussion. (https://chdk.setepontos.com/index.php?topic=12144.msg130865#msg130865)
EDIT:Patch is replaced. (https://chdk.setepontos.com/index.php?topic=12144.msg130868#msg130868)
Attached is a small patch to allow user activation/deactivation of the RAW toggle keyboard shortcut.Nice. Checked in, trunk r4751.
This is a change from the current CHDK operation but I think it's the correct option as this "feature" is better disabled unless you consciously select it.I agree with having it disabled by default. It's a behavior change, but far less likely to frustrate new users.
I'm not entirely fond of tying in the OSD, since the OSD only shows when raw is enabled anyway, but I do see the logic of ensuring the OSD shows when you use the shortcut, so I left it in for now.Understood.
Here is a SX60HS patch for v4785. It standardizes the loader code, changes the direction of the jogdial, and adds CAM_QUALITY_OVERRIDE.Thanks. Added in trunk 4786
EOS M3:Thanks, added in r4789
focal_length functions reworkedIf you describe how this works, that would be useful for anyone else trying to support interchangeable lens cameras.
If you describe how this works, that would be useful for anyone else trying to support interchangeable lens cameras.
Patch for SX60HS v4805..Thanks. In trunk 4806.
You can also remove any stubs from stubs_entry_2.S which are found correctly by the sig finder. These are noted with == or < veneer in stubs_entry.SDone.
Done.Thanks. Is a 120f firmware dump posted somewhere?
+ fw 120f.
Is a 120f firmware dump posted somewhere?AFAIK, no.
#ifdef THUMB_FW
int offset_y = ((camera_screen.height-LOGO_HEIGHT)>>1) - 66 ;
#else
int offset_y = ((camera_screen.height-LOGO_HEIGHT)>>1) - 42 ;
#endif
There might be a better way to do this - I just adjusted the hard coded offset in gui.c for D6 builds - i.e.:Thanks. Added in trunk 4824
A better way to do this could be either logo scaling code or a new D6 logo.dat file.Your workaround seems fine to me, but I admit I've never cared much about the splash logo.
Patch for SX60HS to make Play the default ALT-KEY. The Shortcut key is eliminated as a possible choice for ALT mode at this time.Thanks, added in trunk 4831. Will appear in the autobuild shortly.
Patch to include a separate camnotes.txt in the ZIP.Added in trunk 4832.
Added in trunk 4832.
I'm tempted to remove it from the autobuilt readme and just make that section say "see camnotes.txt for camera specific notes". Then we wouldn't need to build the readme any more either.
Patch to localize the remaining module names (not included in the previous patch (https://chdk.setepontos.com/index.php?topic=13154.msg133096#msg133096) due to false perception of the existence of "system modules").
- Added strings:
- "RAW Operations"
- "Shot Histogram"
- "Hex Number Editor"
- "Text Box"
- Replaced "dll" names with existing menu strings.
- Included Russian translation.
Thanks. I'll update CHIMP as soon as it's merged.Merged to 1.4
The problem is that some cameras have quite useless notes.Yes. FWIW, this is an area where non-developers could make a significant contribution, updating each one to at least note camera specifics like the default alt button, features defined in platform_camera.h and a link to the development thread.
Merged to 1.4
Yes. FWIW, this is an area where non-developers could make a significant contribution, updating each one to at least note camera specifics like the default alt button, features defined in platform_camera.h and a link to the development thread.
Done.Added now that 120f dump has been posted.
+ fw 120f.
Patch to localize the remaining module names (not included in the previous patch (https://chdk.setepontos.com/index.php?topic=13154.msg133096#msg133096) due to false perception of the existence of "system modules").Something is wrong with this patch file, saved in some unicode format maybe?
This replaces the previously posted one, since the "Compute hash" submenu is no longer relevant.This one too.
Something is wrong with this patch file, saved in some unicode format maybe?
As far as the partition info patch goes, I don't understand what the underlying problem was, or why the proposed patch is a valid solution.
Patch to fix the partition type being incorrectly reported by get_partitionInfo() as discussed (https://chdk.setepontos.com/index.php?topic=13091.msg133505#msg133505).
The latter derives from the former, so you may do a direct diff from master.I'm not going to go digging around your github to try to figure out what you wanted added. If you want to submit a change, please post a patch that can be applied to the current trunk.
Since this seems to be a recurring issue (https://chdk.setepontos.com/index.php?topic=13174.msg133464#msg133464), I shall take this opportunity and urge you to migrate CHDK to a modern VCS. If you find git too complex, go for hg, which is what both SDM and ML have been using.In the abstract, a VCS like git would probably be a better fit for CHDK, but switching would involve a significant amount of time and effort.
As for the patches, they are indeed Unicode, which is what Git for Windows seems to be generating. I will see if removing russian.lng helps.This sounds like a mis-configuration or bug. CHDK not support unicode or use unicode encoded files in the source tree. The text of lang files has to be encoded for the appropriate code page. This will cause "mojibake" when viewed in other encodings, but that is not a problem. A good editor will let you select the appropriate encoding when editing those files.
Patch to fix the partition type being incorrectly reported by get_partitionInfo() as discussed (https://chdk.setepontos.com/index.php?topic=13091.msg133505#msg133505).
If you find git too complex, go for hg...
I recommend rejecting this patch, as IMHO the current code is working - although perhaps not doing what dmitrys want.
Changing behaviour that could have unexpected side effects is not a good idea, no matter how innocuous it might seem.
See - https://chdk.setepontos.com/index.php?topic=13091.msg133556#msg133556
Patch to localize the remaining module names (not included in the previous patch (https://chdk.setepontos.com/index.php?topic=13154.msg133096#msg133096) due to false perception of the existence of "system modules").
- Added strings:
- "RAW Operations"
- "Shot Histogram"
- "Hex Number Editor"
- "Text Box"
- Replaced "dll" names with existing menu strings.
- Included Russian translation.
Patch to fix the partition type being incorrectly reported by get_partitionInfo() as discussed (https://chdk.setepontos.com/index.php?topic=13091.msg133505#msg133505).
I fixed the partition size as well. I'll post an updated patch as soon as we settle on backwards compatibility (https://chdk.setepontos.com/index.php?topic=13179.msg133545#msg133545).
Patch with a backward-compatible implementation attached.
For a dual partition card, this appears to change the 'size' value returned by luaCB_get_partitionInfo from the size of the large partition where photos will be saved, to the size of the small (bootable) partition.
Phil.
Patch to localize the remaining module names (not included in the previous patch (https://chdk.setepontos.com/index.php?topic=13154.msg133096#msg133096) due to false perception of the existence of "system modules").
- Added strings:
- "RAW Operations"
- "Shot Histogram"
- "Hex Number Editor"
- "Text Box"
- Replaced "dll" names with existing menu strings.
- Included Russian translation.
Attached are two separate patches - one without the russian.lng changes and a separate one with those isolated.
As for the File Browser localization patch, I suggest that I submit it along with the revamped File Browser (https://chdk.setepontos.com/index.php?topic=13178) changes.
For a dual partition card, this appears to change the 'size' value returned by luaCB_get_partitionInfo from the size of the large partition where photos will be saved, to the size of the small (bootable) partition.
Phil.
That's partially correct. That value has nothing to do with partition info (it doesn't even return the size of a partition). Anyway, this should "fix" that.
AFAIK, the ModuleName field, for modules with a type of 'MTYPE_EXTENSION', is not used in the core CHDK code.
In this case, moving these strings to the language file(s) serves no purpose, and just wastes memory.
Phil.
The return value from GetTotalCardSpaceKb is the size of the photos partition in kilobytes - how is that not the size of the partition?
Patch is in unicode (again).
AFAIK, the ModuleName field, for modules with a type of 'MTYPE_EXTENSION', is not used in the core CHDK code.
In this case, moving these strings to the language file(s) serves no purpose, and just wastes memory.
Phil.
Purpose. (https://chdk.setepontos.com/index.php?topic=13154.msg133054#msg133054)
As for memory use, do these couple of dozens extra bytes really matter?
If I may remind you, the entire main menu is kept in memory for reasons that are still beyond me.
No purpose for CHDK.
If I may remind you, you are dealing with people who have thousands of hours of experience with CHDK.
Be polite or risk getting banned.
For a dual partition card, this appears to change the 'size' value returned by luaCB_get_partitionInfo from the size of the large partition where photos will be saved, to the size of the small (bootable) partition.
Phil.
That's partially correct. That value has nothing to do with partition info (it doesn't even return the size of a partition). Anyway, this should "fix" that.
Although this could be done by simply extending the table returned from get_partitionInfo, I think it is also worth renaming the fields to make it clearer what they are (doing this in get_partitionInfo makes it incompatible).
Field name changes could be (suggestions welcome):
- count --> partition_count
- active --> bootable_partition
- type --> bootable_partition_type
- size --> photo_partition_sizeMB
Great idea overall, but may I politely offer my remarks?I see three options:Although this could be done by simply extending the table returned from get_partitionInfo, I think it is also worth renaming the fields to make it clearer what they are (doing this in get_partitionInfo makes it incompatible).
I'm not sure if field renaming alone warrants an entirely new interface, but I suppose that's a matter of personal taste.
QuoteField name changes could be (suggestions welcome):
- count --> partition_count
- active --> bootable_partition
- type --> bootable_partition_type
- size --> photo_partition_sizeMB
I'd suggest boot_partition and boot_partition_type, since "bootable" could be interpreted as signifying the presence of the bootflag.
Either way may cause some level of confusion. If partitions have been swapped on a dual-partition card then this is no longer the 'boot' partition; but it is still potentially the auto-bootable partition (although may not be). This is why I chose 'bootable' rather than 'boot'. Perhaps something else entirely might be needed; but I can't think of an alternative.
I see three options:FWIW, we do have @chdk_version to handle #2. If it's only a matter of more/renamed fields, a <=1.4 compatibility wrapper would be trivial. I'm pretty agnostic whether this is better, though all else being equal I'd rather not proliferate functions that return similar info.
- keep existing field names and extend get_partitionInfo. Main issue is that the field names are confusing.
- rename fields and extend get_partitionInfo. May break existing scripts.
- leave get_partitionInfo alone and add new function with new interface. Doesn't break anything and allows us to create a more intuitive interface.
I see three options:FWIW, we do have @chdk_version to handle #2. If it's only a matter of more/renamed fields, a <=1.4 compatibility wrapper would be trivial. I'm pretty agnostic whether this is better, though all else being equal I'd rather not proliferate functions that return similar info.
- keep existing field names and extend get_partitionInfo. Main issue is that the field names are confusing.
- rename fields and extend get_partitionInfo. May break existing scripts.
- leave get_partitionInfo alone and add new function with new interface. Doesn't break anything and allows us to create a more intuitive interface.
That's another option, I forgot about the version wrappers. If the changes are applied to both 1.4 & 1.5, then it probably only needs a wrapper in wrap13.lua.I was thinking wrapper for <= 1.4, with the new function only existing in 1.5. Changing the interface for scripts using @chdk_version 1.4 would not be good, since the "stable" in stable release is mostly the interfaces.
That's another option, I forgot about the version wrappers. If the changes are applied to both 1.4 & 1.5, then it probably only needs a wrapper in wrap13.lua.I was thinking wrapper for <= 1.4, with the new function only existing in 1.5. Changing the interface for scripts using @chdk_version 1.4 would not be good, since the "stable" in stable release is mostly the interfaces.
Making this change only for 1.5 doesn't help dmitrys problem though, which would argue for a separate function. Even that's pushing the definition of bug fixes only. We could still replace the old interface with a compatibility wrapper in 1.5
Will this work or am I still missing something?
Will this work or am I still missing something?
This will probably work, but will be of little to no use as far as CHIMP is concerned, due to the fact that the latter still has to support existing versions. This also applies to my patch, albeit with one distinction: mine was a relatively small and isolated change.
Can you not check the build number?
Can you not check the build number?
If get_partitionInfo() returns nil, the card isn't partitioned.
Otherwise, if count == 1, the card isn't partitioned.
Otherwise, if active == 1, the card is partitioned, and the service partition is active.
Otherwise, the card is partitioned, and the photos partition is active.
Aren't these correct regardless of the build number?
Yes, but prior to the build with any changes (either yours or mine), the type and size values may be wrong - I thought you needed these values?
Technically, if get_partitionInfo returns nil, then the port does not support partitioned cards in CHDK. The card could still be partitioned outside CHDK; but there is no way to tell in the CHDK code. This applies to post 2011 cameras that can boot from FAT32 partitions - these don't need to implement partitioning support.
It is also possible to have up to four partitions on the card - the swap_partitions function allows the user to rotate though them.
So none of these changes are really needed then?Yes, but prior to the build with any changes (either yours or mine), the type and size values may be wrong - I thought you needed these values?
They could be handy, but since they are unreliable, I can do just fine without them.
Better yet, if type != 1, I may safely assume that there is no service partition.Umm no - most cameras can autoboot from FAT12 and FAT16 partitions. So at least types 1 and 6 and probably 4, possibly others.
Or could be all partitions - to use partition swapping on a dual partition card you need to copy at least the firmware update file to all partitions that you want to swap to. That way when the camera is restarted you can use the firmware update boot method to get back into CHDK.QuoteTechnically, if get_partitionInfo returns nil, then the port does not support partitioned cards in CHDK. The card could still be partitioned outside CHDK; but there is no way to tell in the CHDK code. This applies to post 2011 cameras that can boot from FAT32 partitions - these don't need to implement partitioning support.
I thought they did regardless. I'll have to add a check to the install logic.QuoteIt is also possible to have up to four partitions on the card - the swap_partitions function allows the user to rotate though them.
Presumably the CHDK directory is either on the first or on the second one, depending on the "active" value?
So none of these changes are really needed then?
QuoteBetter yet, if type != 1, I may safely assume that there is no service partition.Umm no - most cameras can autoboot from FAT12 and FAT16 partitions. So at least types 1 and 6 and probably 4, possibly others.
QuotePresumably the CHDK directory is either on the first or on the second one, depending on the "active" value?Or could be all partitions - to use partition swapping on a dual partition card you need to copy at least the firmware update file to all partitions that you want to swap to. That way when the camera is restarted you can use the firmware update boot method to get back into CHDK.
The 'active' value could be anything from 1 - 4 depending on how many partitions and how may swaps have been done.
By "service partition" I was referring to a partition that should get the files from / and _HDKMETA/PS/, but not from CHDK/.
Patch to add m3_120f to camera_list.csv.Thanks for catching that. Added.
NHSTUB(GetDrive_FreeClusters, 0xFF871E90 -> 0xff871e90NHSTUB(DoAFLock, 0xFF87A910 -> 0xff8382e4
NHSTUB(UnlockAF, 0xFF87A920 -> 0xff83831c
NHSTUB(PutInNdFilter, 0xFFB2056C -> 0xffab69c8
NHSTUB(PutOutNdFilter, 0xFFB205A4 -> 0xffab69ec
NHSTUB(ScreenLock, 0xFFA1356C -> 0xffa13354
NHSTUB(GetImageFolder, 0xFF94337C -> 0xff94345c
NHSTUB(MoveFocusLensToDistance, 0xFFB2289C -> 0xffb228b0
NHSTUB(SetScriptMode, 0xFF810F6C -> 0xff895904
DEF(zoom_status, 0x0000315B -> 0x0000cea4
DEF(recreview_hold, 0x0000780E -> 0x00003a20
Attempting to use LiveView does not crash but the image is unusable. Fixing this looks like much more work than I have time for right now - the ixus300_sd400 has what appears to be a somewhat unique extra wide LCD.
Thanks for that!Attempting to use LiveView does not crash but the image is unusable. Fixing this looks like much more work than I have time for right now - the ixus300_sd400 has what appears to be a somewhat unique extra wide LCD.From photos on the web, the LCD looks similar to the IXUS 310.
There's less than 12 months between their release dates, so the viewport values I used for that might help.
Updates for ixus300_sd4000 based on recent issues identified by Robert1975.Thanks, added in trunk 4863 and release-1_4 4864
Second patch for the ixus300_sd4000.Thanks. Added in trunk 4867, release-1_4 4869
Move all code from platform/ixus300_sd4000/sub/100d/lib.c to platform/ixus300_sd4000/lib.c as it's not firmware version specific (the sub/100d/lib.c file can be deleted - didn't do that as I was not sure it that would affect the autobuild)In general, can be removed as long as you remove it from Makefile too. However, I moved a couple functions back to the sub lib.c because they directly access firmware variables. Purely cosmetic in this case since there's only one sub, but maybe less chance of someone using it as an inappropriate example.
Here is current_fb_d patch for EOS M3. Not tested on fw 120f but should work.Thanks. Added in trunk 4870.
P.S.Yes.
Does setting of address 0x1011C to 0x00000001 enable focus peaking on G7X?
However, I moved a couple functions back to the sub lib.c because they directly access firmware variables.Thanks for that - makes sense.
Final clean-up and testing of "ToDo" items from ixus300_sd4000 port.Thanks. Added in trunk 4874, release-1_4 4875 and beta status removed.
I hereby suggest removing the BETA status from this port. It's never going to be perfect but I'm done and I think it's pretty darn good. Props to pixeldoc2000 (https://chdk.setepontos.com/index.php?action=profile;u=3152) for creating the port.
New platform_camera.h files updated for better DNG exif data for SX50hs, S100, G10.Added, trunk 4876, release-1_4 4877
#define PAUSE_FOR_FILE_COUNTER 250 to correct issues with saving DNG identified by Robert1975 (https://chdk.setepontos.com/index.php?action=profile;u=29494) here Re: CHDK on SD4000/IXUS 300 HS (https://chdk.setepontos.com/index.php?topic=13160.msg133997#msg133997)Patch to add the following to capt_seq.c for the ixus300_sd4000 :Added. Trunk 4882, release-1_4 4883
Patch for SX60HS to use transfer_src_overlay instead of display_busy logic in lib.c as discussed inThanks, added in trunk 4893. Hotshoe override is also enabled (discussed in the porting thread https://chdk.setepontos.com/index.php?topic=12532.msg133613#msg133613)
Patch for EOS M3 to use new screen refresh method and dark frame control.Thanks. Added in trunk 4894
Fix for zoom issue found in ixus300_sd4000.Added in trunk 4904, release 4905
Another zoom related patch for the ixus300Added in trunk 4906, release 4907
(ref https://chdk.setepontos.com/index.php?topic=13160.msg134493#msg134493)
Fix for two grid issues reported here : Re: Grids : issues and challenges (https://chdk.setepontos.com/index.php?topic=13239)Thanks. Added in trunk 4911-4912, release 4913.
I changed the fix for the crash make it self contained in the module.That was my original fix too. But then I wondered about a race condition where the module gets unloaded before grid_loading = 1 is executed?
That was my original fix too. But then I wondered about a race condition where the module gets unloaded before grid_loading = 1 is executed?In theory maybe, but that's how most of the other modules with a "running" state work. If we need to resolve that, we should add some kind of delay or to the module_tick_unloader process.
I think in practice the window for problems there is nanoseconds, where the original grid loading could take tens of milliseconds and involved blocking IO calls that would yield to other tasks.Good enough. I noticed that the bug occurred much more frequently on my older cameras and also with larger files. All leading me to the race condition conclusion.
Hello!Thanks. Is the ?? intended in #258?
Attached is an updated lang file for Polish language.
Thanks!
258 "W??czenie Lua Native Calls pozwala\numozliwia uszkodzenie aparatu.\nJesli nie jestes pewien\nNIE WLACZAJ TEJ OPCJI.\nJestes pewien wlaczyc Native Calls?"
I thought it might be an encoding issue, but it looks like it's really ASCII '?' in the file. (The file should be in windows 1250 encoding)
Thanks. Is the ?? intended in #258?
Indeed, this was a mistake, thanks. Here is the corrected file.Thanks, added in trunk 4916
Port for the G16 attached. :xmas I've probably procrastinated long enough about releasing this.Added in trunk r4958, with some cosmetic cleanup in r4959
Patch file to update G16 port per G16 Porting Thread (https://chdk.setepontos.com/index.php?topic=13054.msg135619#msg135619)Thanks. Added in trunk 4961.
Patch for JPEG setting not available in menu, build 1.4.1-4976 on A480/A490 (https://chdk.setepontos.com/index.php?topic=13342.0)Added, trunk 4987, release 4988
Patch for possible UHS SD Card issues per this post : https://chdk.setepontos.com/index.php?topic=13054.msg136417#msg136417Added in trunk 5002
attached is a patch to include sx60hs/sub/100h. I have had no further feedback re any problems. Thread is here:Thanks, added in trunk 5027, enabled in autobuild labeled alpha.
https://chdk.setepontos.com/index.php?topic=12532.new#new (https://chdk.setepontos.com/index.php?topic=12532.new#new)
Source code for sx610hs, firmware version 100a.Added, trunk 5034.
Source code for ixus170/elph170, firmware version 100a.Thanks, I checked it in (https://app.assembla.com/spaces/chdk/subversion/commits/5056), with autobuild disabled.
The JPEG dimensions for sx710hs is wrong. The attached patch fixes it.Oops :-[ thanks for catching that.
Propset11 from this post:Added in trunk 5123
https://chdk.setepontos.com/index.php?topic=13569.msg138526#msg138526
Source code for sx420is, firmware version 100a.Checked in, trunk 5124. I left it disabled in the autobuild, let me know if you think it should be enabled.
Source code for sx430is, firmware version 100b.Checked in, trunk 5127. Note I disabled FI2 building in makefile.inc until I can verify the autobuild has the right key. You'll need to comment out the override OPT_FI2= line if you want to build an FI2 locally.
Patch for finsig_thumb2 & capdis to work with capstone version 4.Thanks for doing this. Checked in, trunk 5169
Tested with unpatched version of capstone 4.0.1 library on MacOS and Mint LMDE3 - all stubs rebuild ok (although I can't test SX60HS 1.00h since I don't have the FW dump).
Also tested capdis with extracting G5X code from the FW dump - seems to work ok.
CAPSTONE_TOOLS_LINK=-Ld:/devel/capstone-4.0.1-win32 -lcapstone_dll
CAPSTONE_TOOLS_INC=-Id:/devel/capstone-4.0.1-win32/include/capstone
msys and msys2 compilers didn't like the supplied static library. This means the DLL has to be on the path.This removes the calls to malloc & free for the header/desc buffers and the memcpy for the palette data.That's a good idea.
There does not seem to be any negative impact from adding another send_data call on cameras with 256 palette entries; but I'm not sure of the impact on cameras with only 16 palette entries (64 bytes).I'd expect it's negligible compared to the time required to send the actual framebuffer.
I wondered if stack size might be a concern, since the header is moderately large (36 bytes per buffer desc, plus 32 for header), but PTPSession seems to get a pretty generous size: 0x1000 on a540, 0x1800 on g7x and the stock PTP handlers are pretty complicated.
I missed a couple of initialisations when sections are not being sent - updated patch attached.Seems fine to me.
If you're happy with this I'll check it in.
Index: core/gui.c
===================================================================
--- core/gui.c (revision 5293)
+++ core/gui.c (working copy)
@@ -2401,7 +2401,7 @@
}
//-------------------------------------------------------------------
-static gui_handler *gui_mode=0; // current gui mode. pointer to gui_handler structure
+static gui_handler *gui_mode = &altGuiHandler; // current gui mode. pointer to gui_handler structure
static int gui_osd_need_restore = 0; // Set when screen needs to be erase and redrawn
static int gui_mode_need_redraw = 0; // Set if current mode needs to redraw itselfI just pointed to one of the existing gui_handler instances, thought the pointer gets updated immediately anyway.
Spytask dereferences a NULL pointer during its startup.Without testing/digging too much, I think I'd use defaultGuiHandler, since the camera normally starts in non-alt mode. Or figure out where the initialized value is used. Or adjust gui_set_mode to deal with null old_mode.
gui_init() -> gui_set_mode() -> the gui_mode pointer is NULL initially
Does the following patch look good enough to fix this?Code: [Select]Index: core/gui.c
===================================================================
--- core/gui.c (revision 5293)
+++ core/gui.c (working copy)
@@ -2401,7 +2401,7 @@
}
//-------------------------------------------------------------------
-static gui_handler *gui_mode=0; // current gui mode. pointer to gui_handler structure
+static gui_handler *gui_mode = &altGuiHandler; // current gui mode. pointer to gui_handler structure
I think I'd use defaultGuiHandlerThat would not work very well because gui_init() would fail to initialize the gui mode.
Or adjust gui_set_mode to deal with null old_mode.I tried that first and failed due to my insufficient knowledge about the inner workings of the CHDK GUI. Also, any change there would lead to an increase in core size.
Yeah, that makes sense, I didn't think through the if mode == current mode logic.I think I'd use defaultGuiHandlerThat would not work very well because gui_init() would fail to initialize the gui mode.
If it works, that's good enough for me. It should be better than the current behavior. My initial reaction was that I'd prefer not to have it initialized in an inconsistent state (that is gui_mode is "alt" but various other gui and alt state variables initialized as non-alt).QuoteOr adjust gui_set_mode to deal with null old_mode.I tried that first and failed due to my insufficient knowledge about the inner workings of the CHDK GUI. Also, any change there would lead to an increase in core size.
Using &altGuiHandler as initial value of that pointer would mean no increase in core size. This does not mean CHDK would start in ALT mode, that struct would only provide values that (IMO) allow a successful transition to default GUI mode.
I don't think I see any related glitches on the M100.
Currently, the first few words at address zero are used as initial value when members of that struct are accessed.
Yeah, that makes sense, I didn't think through the if mode == current mode logic.I think I'd use defaultGuiHandlerThat would not work very well because gui_init() would fail to initialize the gui mode.QuoteIf it works, that's good enough for me. It should be better than the current behavior. My initial reaction was that I'd prefer not to have it initialized in an inconsistent state (that is gui_mode is "alt" but various other gui and alt state variables initialized as non-alt).QuoteOr adjust gui_set_mode to deal with null old_mode.I tried that first and failed due to my insufficient knowledge about the inner workings of the CHDK GUI. Also, any change there would lead to an increase in core size.
Using &altGuiHandler as initial value of that pointer would mean no increase in core size. This does not mean CHDK would start in ALT mode, that struct would only provide values that (IMO) allow a successful transition to default GUI mode.
I don't think I see any related glitches on the M100.
Currently, the first few words at address zero are used as initial value when members of that struct are accessed.
FWIW, I'm not at all concerned about increasing core size by a few hundreds of bytes if it makes things clearer or easier to maintain.
One thing that might thinking about more is if any of the gui_mode stuff might be accessed in other tasks before gui_init is run, since that happens quite late after the filesystem is ready and CHDK settings have been initialized.
The fact that your solution works on M100 suggests it isn't on that camera. One possible exception is cameras with touch screen support (n, ixus310, ixus240) which reference it in the touch task. I doubt your change will hurt those, but it would probably be better to have chdk_process_touch immediately return if gui_init hasn't run yet. I don't think this needs to be done to check your change in.
Startup scripts are run from spytask after gui_init, so they shouldn't be a concern.
I can't see any other cases - am I missing anything?Perhaps stating the obvious, but I assume the ones srsa_4c is hitting is the ones gui_set_mode where it references old_mode->... on 2474 and 2477
I can't see any other cases - am I missing anything?Perhaps stating the obvious, but I assume the ones srsa_4c is hitting is the ones gui_set_mode where it references old_mode->... on 2474 and 2477
It seems like those could just be skipped if old_mode is null, though I'm not immediately sure whether redraw / restore stuff should be called on the first call.
gui_set_mode also returns old_mode, which would be NULL in this case, but the value isn't used in gui_init.
I can't see any other cases - am I missing anything?Perhaps stating the obvious, but I assume the ones srsa_4c is hitting is the ones gui_set_mode where it references old_mode->... on 2474 and 2477
It seems like those could just be skipped if old_mode is null, though I'm not immediately sure whether redraw / restore stuff should be called on the first call.
gui_set_mode also returns old_mode, which would be NULL in this case, but the value isn't used in gui_init.
Good point, missed that case.
Setting a default for gui_mode makes more sense now - I'm not fully comfortable with the idea of using the alt mode handler though.
Perhaps a dummy handler struct for startup until gui_init is called might work.
Phil.
Alternate patch attached.That seems OK to me. Tested booting to play and rec without issue on digic 4 (elph180) and digic 6 (sx710)
- Adds a dummy handler for the initial value of gui_mode.
- Remove the gui_get_mode() function in favour of camera_info.state.gui_mode
camera_info.state.gui_mode != 0
for get_alt_mode(). This should not have any issue with the patch, since script shouldn't be able to run before gui_init. (I assume it doesn't use camera_info.state.gui_mode_alt because script is technically a different gui_mode, even though it has alt and non-alt states)
Alternate patch attached.That seems OK to me. Tested booting to play and rec without issue on digic 4 (elph180) and digic 6 (sx710)
- Adds a dummy handler for the initial value of gui_mode.
- Remove the gui_get_mode() function in favour of camera_info.state.gui_mode
One thing I wondered is if there is code that relies on gui_mode == 0 being "none". The closest I found was script, which usesCode: [Select]camera_info.state.gui_mode != 0for get_alt_mode(). This should not have any issue with the patch, since script shouldn't be able to run before gui_init. (I assume it doesn't use camera_info.state.gui_mode_alt because script is technically a different gui_mode, even though it has alt and non-alt states)
Anything that might use camera_info.state.gui_mode before gui_init is called should be unaffected (I think).Yes, my mistake, I was thinking GUI_MODE_STARTUP would appear in camera_info.state.gui_mode before init, but of course it won't.
Alternate patch attached.Seems to work OK for me too.
I can't see any other cases - am I missing anything?Perhaps stating the obvious, but I assume the ones srsa_4c is hitting is the ones gui_set_mode where it references old_mode->... on 2474 and 2477
It seems like those could just be skipped if old_mode is null, though I'm not immediately sure whether redraw / restore stuff should be called on the first call.
gui_set_mode also returns old_mode, which would be NULL in this case, but the value isn't used in gui_init.
Good point, missed that case.
Setting a default for gui_mode makes more sense now - I'm not fully comfortable with the idea of using the alt mode handler though.
Perhaps a dummy handler struct for startup until gui_init is called might work.
Phil.
Alternate patch attached.
- Adds a dummy handler for the initial value of gui_mode.
- Remove the gui_get_mode() function in favour of camera_info.state.gui_mode
Phil.
Is it worth adding to the release-1_4 branch?AFAIK was only needed because digic 7 crashes on NULL pointer reads, so shouldn't be required.
Question on revision 5294 for Ixus 220.Thanks for catching that. I just missed running code gen on that sub, the MMIO should be the same for all. Checked in now.
This changed both code_gen.txt and boot.c for 1.00c, 1.01a and 1.01g; but only changed code_gen.txt for version 1.01c.
Index: core/shooting.c
===================================================================
--- core/shooting.c (revision 5331)
+++ core/shooting.c (working copy)
@@ -1053,7 +1053,7 @@
int fl = get_focal_length(zoom_point);
short f_focus_ok = shooting_get_focus_ok();
short f_hyp_calc = 0, f_dist_calc = 0;
- short min_av96_zoom_point = min_av96_zoom_point_tbl[zoom_point];
+ short min_av96_zoom_point = 0;
short av96 = shooting_get_user_av96();
short curr_av96 = shooting_get_current_av96();
short prop_av96 = shooting_get_av96();
@@ -1063,8 +1063,10 @@
min_av96_zoom_point_tbl = (short *) malloc(zoom_points * sizeof(short));
if (min_av96_zoom_point_tbl) {
memset(min_av96_zoom_point_tbl, 0, zoom_points * sizeof(short));
- min_av96_zoom_point = 0;
}
+ else {
+ return;
+ }
} else min_av96_zoom_point = min_av96_zoom_point_tbl[zoom_point];
if (min_av96_zoom_point==0 && shooting_in_progress()) {
Found yet another case of a dereferenced null pointer.That existing code :o :-X
Question is the usual, does the following fix look okay?
Your fix looks OK to me.Thanks, committed (https://app.assembla.com/spaces/chdk/subversion/commits/5342). Fortunately, it was a rather benign bug - as long as malloc succeeded.
Source code for ixus275_elph350, firmware version 100a.Thanks, added in trunk r5435
Source code for sx620hs, firmware version 100b.Thanks. Added in trunk 5448
Index: core/shooting.c
===================================================================
--- core/shooting.c (revision 5449)
+++ core/shooting.c (working copy)
@@ -135,7 +135,7 @@
int shooting_get_digital_zoom_mode(void)
{
int x=shooting_get_prop(PROPCASE_DIGITAL_ZOOM_MODE);
-#if CAM_PROPSET == 7 || CAM_PROPSET == 9 || CAM_PROPSET == 10|| CAM_PROPSET == 11
+#if CAM_PROPSET == 7 || CAM_PROPSET == 9 || CAM_PROPSET == 10 || CAM_PROPSET == 11 || CAM_PROPSET == 12
if(x==1) {
return 0;
}
Index: platform/generic/wrappers.c
===================================================================
--- platform/generic/wrappers.c (revision 5449)
+++ platform/generic/wrappers.c (working copy)
@@ -95,7 +95,7 @@
long set_property_case(long id, void *buf, long bufsize)
{
// ignore set on fake prop
-#if CAM_PROPSET == 7 || CAM_PROPSET == 9 || CAM_PROPSET == 10 || CAM_PROPSET == 11
+#if CAM_PROPSET == 7 || CAM_PROPSET == 9 || CAM_PROPSET == 10 || CAM_PROPSET == 11 || CAM_PROPSET == 12
if(id==PROPCASE_SHOOTING) {
return 0;
}
The second one is clearly needed, not sure about the first one (no digital zoom here).
Two propset 12 related changes from my m100 patch that are not in trunk yet.Thanks for catching those, checked in. I wondered how I missed the wrappers one, since sx730 is tested OK, but it turns out I only missed the set_ call :-[
The second one is clearly needed, not sure about the first one (no digital zoom here).
Updated patch for G16 simple_movie_status variable.Thanks. Added in r5469
https://chdk.setepontos.com/index.php?topic=14035
Source code for ixus265_elph340, firmware version 100c.Thanks. Added in trunk r5511.
Fix for issue with G16 not entering shooting mode on long press of power button reported here (https://chdk.setepontos.com/index.php?topic=14048.msg143663#msg143663).Thanks, g16_boot_r7.patch added in trunk 5606
Tested on 101c - code for other versions hand checked in disassembly.
EDIT : patch file update
//SX410
+ { 2, KEY_ZOOM_IN ,0x00000080 }, // full speed
+ { 2, KEY_ZOOM_IN ,0x00000020 }, // low speed
+ { 2, KEY_ZOOM_OUT ,0x00000040 }, // full speed
+ { 2, KEY_ZOOM_OUT ,0x00000010 }, // low speed
//SX420
+ { 0, KEY_ZOOM_IN ,0x00000100 }, // full speed <------\ /----
+ { 0, KEY_ZOOM_IN ,0x00000200 }, // low speed <-------/ \--- ?
+ { 0, KEY_ZOOM_OUT ,0x00000800 }, // full speed
+ { 0, KEY_ZOOM_OUT ,0x00000400 }, // low speed
SX410IS -Corrected order for zoom keys in keymap.Thanks, added in trunk 5614. Also set status to BETA and enabled in autobuild.
SX420IS -Added keys for slow zoom speed in keymap.
???Please, if you have a question or comment, just use words. I guess you think the values are reversed or wrong for some reason, but if you can't explain, it's really not helpful.
sx530hs- added exp_drv_task for very short exposures.Thanks. Added in trunk 5690, stable 5691
Tested by Davo in https://chdk.setepontos.com/index.php?topic=14169.msg144746#msg144746
EDIT: added patch file :D
Source code for EOS M3, firmware version 121a.Thanks, added in trunk 5859, enabled in autobuild as alpha.
I noticed the included strub_entry_2.s did not exactly match the output I got rebuilding stubs in the current trunk.
Do you mean difference with other firmware versions?I meant between the stubs_entry.S included in your patch, and what I generated rebuilding stubs for the 121a firmware using the current trunk source.
stubs_entry.S was generated a week ago using finsig_thumb2 which was built a week ago...The differences aren't in the found sigs (funcs_by*.csv are identical) but in the modemap and sigs that are set in stubs_entry_2.s.
cd trunk/lib/lua
wget 'https://sources.debian.org/data/main/l/lua5.1/5.1.5-8.1/debian/patches/0004-Fix-stack-overflow-in-vararg-functions.patch'
patch -p2 < 0004-Fix-stack-overflow-in-vararg-functions.patch
It fixes a security problem with Lua. A more detailed explanation is here: http://www.lua.org/bugs.html#5.2.2-1As far as security goes, using a stack overflow when poke() is right there would seem to be making things hard on oneself ;)
sx430is - correct power on behavior
Patch to make HDMI output on the G16 work correctly.Added in trunk r6033
see : Re: Display (bitmap overlay) (https://chdk.setepontos.com/index.php?topic=12788.msg147565#msg147565)
Here is a patch to enable fmath library for hostlua:Thanks. I've added in trunk r6035 with a small modification to make os.listdir and os.idir compatible with table options added with CHDK long filename support. Of course, hostlua doesn't actually control long filenames being returned or not, but the option table is handled correctly.Successfully tested on windows.
- add "divide by zero" check for divisor in fmath_new()
- re-enable os_listdir(), os_idir() for hostlua with old code from trunk 3415
- add lfmath.o to hostlua Makefile
rudi
add "divide by zero" check for divisor in fmath_new()Mostly, CHDK ignores divide by 0 (see around https://chdk.setepontos.com/index.php?topic=11316.msg124312#msg124312) but I think in this case it makes sense to error, since it's new functionality and the code easily allows throwing an error.
I've added in trunk r6035 with a small modification ...Perfect, thank you.
Here are two tested patches:
- the missing rebuild of stubs_auto.S for trunk 6109
- simplified SVN revision extraction including language independence
the goal are:procedure of patch:
- independence of different messages from different svn versions
- independence of svnversion languages
- no error message in case of missing svnversion
- redirect any subversion error to null device, eg. svnversion is missing
- keep only digits and colon, this change any result stings to an empty value
- get valid revision number if is possible
- the result is revision number or empty value
- if result empty then use default revision 'DEF_SVN_REF' from buildconf.inc
Source code for sx600hs, firmware versions 100d and 100f.Thanks. Added in trunk r6240, as-is except for running rebuild-firmware-crc and removing some trailing whitespace.
Autobuild is skipped for firmware version 100d because no tests were done.
Source code for ixus180_elph190, firmware version 100a.Thanks. Added in trunk r6245 with minor modifications (firmware CRC, whitespace, and note filewrite task not implemented in notes)
Ixus180_elph190 implemented filewrite_task and fix in shooting.cThanks. Added in trunk r6246.
Source code for sx620hs ,firmware version 110a.Thanks. Added in trunk 6264.
Source code for ixus190_elph200 ,firmware versions 100d and 110a.Thanks. Added in trunk 6265. I've left autobuild disabled for now since I'm not clear what the status of this port is, and haven't yet done any code review.
Thanks. Added in trunk 6265. I've left autobuild disabled for now since I'm not clear what the status of this port is, and haven't yet done any code review.Thanks.
We have a typo in camera_list.csv file, we miss the last comma in SX620HS, 110A, Alpha,Source code for sx620hs ,firmware version 110a.Thanks. Added in trunk 6264.
We have a typo in camera_list.csv file, we miss the last comma in SX620HS, 110A, Alpha,Thanks, fixed.