bringing chdkde and chdk back together discussion - page 2 - General Discussion and Assistance - CHDK Forum
« previous next »
Pages: 1 [2] 3 4 5 6   Go Down

bringing chdkde and chdk back together discussion

  • 52 Replies
  • 29976 Views
*

Offline reyalp

  • ******
  • 14125
Re: bringing chdkde and chdk back together discussion
« Reply #10 on: 04 / February / 2012, 19:40:17 »
Advertisements
Possible downsides: is if a new color gets added (or definition changed, which has happened before) there's a lot more to change, and it's harder to know which cameras use equivalent values.

OTOH, many of the cameras using the "same" pallets are probably not actually the same. I'm not saying you shouldn't do this... it's a mess no matter how we cut it.

It might be worth keeping the oldest ones  (palette 1) unified (include / palette_common.h or something) since AFAIK all the early generation cameras really were pretty much the same.
Logged
Don't forget what the H stands for.
*

Offline rudi

  • ***
  • 129
  • A590IS_101B, SX260HS_100B
Re: bringing chdkde and chdk back together discussion
« Reply #11 on: 05 / February / 2012, 05:25:42 »
Quote from: philmoz on 04 / February / 2012, 16:46:48
- work out what to do with platform/generic/lib.c and then align the lib.c files
/generic/lib.c is from early ptp state. CHDK had only for ported cams an entry in lib.c and in CHDK-DE put it for all in /generic/lib.c.
Today use CHDK /generic/wrappers.c for that. I would like change to CHDK implementation. Then are deleted all #include "../generic/lib.c" in lib.c and CHDK-DE /generic/lib.c is clean for now. Then we will see.
I think that the easyest solution for /generic/lib.c.

rudi
Logged
*

Offline rudi

  • ***
  • 129
  • A590IS_101B, SX260HS_100B
Re: bringing chdkde and chdk back together discussion
« Reply #12 on: 07 / February / 2012, 07:03:48 »
Now, /generic/lib.c is empty (rev. 942) and merging sys_mempart_id to CHDK-DE is also done (rev. 946).

rudi
Logged
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: bringing chdkde and chdk back together discussion
« Reply #13 on: 08 / February / 2012, 06:26:33 »
Quote from: rudi on 05 / February / 2012, 05:25:42
Quote from: philmoz on 04 / February / 2012, 16:46:48
- work out what to do with platform/generic/lib.c and then align the lib.c files
/generic/lib.c is from early ptp state. CHDK had only for ported cams an entry in lib.c and in CHDK-DE put it for all in /generic/lib.c.
Today use CHDK /generic/wrappers.c for that. I would like change to CHDK implementation. Then are deleted all #include "../generic/lib.c" in lib.c and CHDK-DE /generic/lib.c is clean for now. Then we will see.
I think that the easyest solution for /generic/lib.c.

rudi

Quote from: rudi on 07 / February / 2012, 07:03:48
Now, /generic/lib.c is empty (rev. 942) and merging sys_mempart_id to CHDK-DE is also done (rev. 946).

rudi

Thanks for that, I'm continuing to merge the platform changes into CHDK.

Will commit another update soon.

Still not sure what the best approach for the palettes is:
- update one of the gui_draw.h files to match the other, or
- create a palette.h file for each camera in the platform directory

Phil.
Logged
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)
*

Offline msl

  • *****
  • 1280
  • A720 IS, SX220 HS 1.01a
    • CHDK-DE links
Re: bringing chdkde and chdk back together discussion
« Reply #14 on: 09 / February / 2012, 06:00:02 »
Quote from: philmoz on 08 / February / 2012, 06:26:33
- create a palette.h file for each camera in the platform directory

Good idea (also for new ports).

Maybe platform_camera.h is also a good place. So we have all camera-dependent definitions in one file.

msl
Logged
CHDK-DE:  CHDK-DE links
*

Offline rudi

  • ***
  • 129
  • A590IS_101B, SX260HS_100B
Re: bringing chdkde and chdk back together discussion
« Reply #15 on: 09 / February / 2012, 15:34:22 »
Quote from: philmoz on 08 / February / 2012, 06:26:33
Will commit another update soon.
Yes, but part for part. I need time for look-up and tests.
Newest: Rev. 948 -> luascript.c less memory, get_meminfo() and camera.h defines, twice lua FUNC(get_av96) deleted
intend: your /generc/lib.c

Quote from: philmoz on 08 / February / 2012, 06:26:33
- create a palette.h file for each camera in the platform directory
Is this not too much? I think the difference is only one camera.

Comment to SetFileAttributes: CHDKLover created a lua function for Eye-Fi card download in "selectiv transfer mode". Since DRYOS R47 signature failed. (Description, Thread with example)

rudi
Logged
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: bringing chdkde and chdk back together discussion
« Reply #16 on: 09 / February / 2012, 16:33:39 »
Quote from: rudi on 09 / February / 2012, 15:34:22
Quote from: philmoz on 08 / February / 2012, 06:26:33
Will commit another update soon.
Yes, but part for part. I need time for look-up and tests.
Newest: Rev. 948 -> luascript.c less memory, get_meminfo() and camera.h defines, twice lua FUNC(get_av96) deleted
intend: your /generc/lib.c

The latest commit for CHDK contains mostly white space and cosmetic changes to the platform files - apologies for it being a large change (and difficult to validate); but after this the changes should be mostly functional and we can focus on the areas where the two systems have different code.

The generic/lib.c is one such area - the CHDK version contains code that is common to some vxworks cameras; but has no use for dryos. My preference would be to get rid of it as you have done.

Quote
Quote from: philmoz on 08 / February / 2012, 06:26:33
- create a palette.h file for each camera in the platform directory
Is this not too much? I think the difference is only one camera.

Comment to SetFileAttributes: CHDKLover created a lua function for Eye-Fi card download in "selectiv transfer mode". Since DRYOS R47 signature failed. (Description, Thread with example)

rudi

The goal was to automate the creation of the palette.h files with a script (like I did with camera.h/platform_camera.h) - doing it manually would be a pain. There are advantages and disadvantages to each method, reyalp pointed out some earlier. My view is a palette.h file for each camera would be a better long term solution since new cameras all seem to have different palettes (the number may grow quickly from now on).

There's an extra palette entry in CHDK-DE which changes the palette number for all later cameras, it's not a huge issue to fix if that's the preferred approach.

I will look at SetFileAttributes to see if I can fix the signature finder for R47 and later.

Phil.
Logged
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)
*

Offline waterwingz

  • ******
  • 12140
    • Waterwingz
Re: bringing chdkde and chdk back together discussion
« Reply #17 on: 09 / February / 2012, 20:53:28 »
Quote from: msl on 04 / February / 2012, 17:44:40
For a better overview I made a first list of the differences (from the end-user perspective):
...
  • script start via usb remote
...
@msl : I remember you mentioning this here :
http://chdk.setepontos.com/index.php?topic=7127.msg79552#msg79552

I've read through the change file in the CHDK-DE svn and the CHDK-DE forum links referenced there.

Is this what happens :  When the camera is in CHDK <ALT> mode and the USB remote is enabled,  activation of the USB power via the remote switch will cause the currently selected script to start running  ? ( i.e.  the same thing happens as would occur if you full-pressed the camera's shutter button at that point) ?

In the current code,  this only works in "Alex Scriptless Remote" mode. If you have the syncable remote mode enabled then you do not see this behavior.  I assume that was for simplicity of coding ?  In the new version,  should this action happen for all remote devices ?

Also, should this be a menu-enabled option ?


Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline rudi

  • ***
  • 129
  • A590IS_101B, SX260HS_100B
Re: bringing chdkde and chdk back together discussion
« Reply #18 on: 10 / February / 2012, 03:29:16 »
Quote from: philmoz on 09 / February / 2012, 16:33:39
I will look at SetFileAttributes to see if I can fix the signature finder for R47 and later.
Sorry, I think the current signature is wrong for R47 or later.

rudi
Logged
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: bringing chdkde and chdk back together discussion
« Reply #19 on: 10 / February / 2012, 04:14:02 »
Quote from: rudi on 10 / February / 2012, 03:29:16
Quote from: philmoz on 09 / February / 2012, 16:33:39
I will look at SetFileAttributes to see if I can fix the signature finder for R47 and later.
Sorry, I think the current signature is wrong for R47 or later.

rudi

How important is this SetFileAttributes function?

The function found for the G12 (based on the IXUS200 signature) does not match the definition and usage in lolevel.h and wrappers.c

The definition and usage assumes _SetFileAttributes in the firmware takes an open file descriptor as the first parameter - the G12 function takes the file name instead.

Phil.

Edit: Looks like the function changed in DryOS R39 (like SetFileTimestamp). Working on updated signatures and function def in wrappers.c that should match better.

Edit2: Changeset 1657 has a fix for SetFileAttributes and signature finder working for all cameras.

« Last Edit: 10 / February / 2012, 15:53:02 by philmoz »
Logged
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)
Pages: 1 [2] 3 4 5 6   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal