Adding new cameras, applying patches into trunk (with source code prepared) - page 61 - General Discussion and Assistance - CHDK Forum
« previous next »
Pages: 1 ... 56 57 58 59 60 [61] 62 63 64 65 66 ... 169   Go Down

Adding new cameras, applying patches into trunk (with source code prepared)

  • 1685 Replies
  • 857714 Views
*

Offline waterwingz

  • ******
  • 12140
    • Waterwingz
Re: Adding new cameras, applying patches into trunk (with source code prepared)
« Reply #600 on: 08 / January / 2012, 19:47:14 »
Advertisements
Quote from: stefantalpalaru on 08 / January / 2012, 12:41:18
Please add to trunk the IXUS 220HS 1.01G port described here:
http://chdk.setepontos.com/index.php?topic=6341.msg79508#msg79508
along with the necessary line in camera_list.csv
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.

Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline stefantalpalaru

  • *
  • 7
Re: Adding new cameras, applying patches into trunk (with source code prepared)
« Reply #601 on: 09 / January / 2012, 05:34:53 »
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.
Logged
*

Offline msl

  • *****
  • 1280
  • A720 IS, SX220 HS 1.01a
    • CHDK-DE links
Re: Adding new cameras, applying patches into trunk (with source code prepared)
« Reply #602 on: 09 / January / 2012, 06:23:48 »
Quote from: stefantalpalaru on 09 / January / 2012, 05:34:53
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

Attached is a patch file against branch release1.0 - untested.

msl
Logged
CHDK-DE:  CHDK-DE links
*

Offline outslider

  • *****
  • 762
Re: Adding new cameras, applying patches into trunk (with source code prepared)
« Reply #603 on: 10 / January / 2012, 18:13:36 »
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.
Logged
if (2*b || !2*b) {
    cout<<question
}

Compile error: poor Yorick
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: Adding new cameras, applying patches into trunk (with source code prepared)
« Reply #604 on: 10 / January / 2012, 18:48:40 »
Quote from: outslider on 10 / January / 2012, 18:13:36
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.

The problem with this approach is you now have two meanings for the color values numbered 0 - 17.

Color values are stored in the config file that can be overridden by the end user - these store two values (background and foreground color) as two bytes packed into a 16 bit value.

How will the system know whether a color value from 0 - 17 is a 'uni' color or a real palette color when it is loaded from the config file?

I think the CHDK 'uni' colors need to be values > 255; but this requires more changes in the CHDK code (increasing the color size from 8 to 16 bits will cause problems in the config files, plus all the hard wired code that assumes a color is stored in a byte).

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 outslider

  • *****
  • 762
Re: Adding new cameras, applying patches into trunk (with source code prepared)
« Reply #605 on: 10 / January / 2012, 19:34:25 »
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.

In compare about what we have now - there is a default color scheme (in the meaning - all things have their default colors). So for example for selected item is COLOR_RED which in one camera might mean 0xA0. But user can change it to whatevet 0-255 value, but then he's only responsible of which color he will have in which mode...

After this change default value would be COLOR_UNI_RED which in source would mean 'uni_color(3)', where value is predefined for each palette (like COLOR_RED now). And user can change it in whatever he want, just like now.

Remember, that all draw_xxx functions will still see 0-255 values. Is no matter, wheter this is predefined as COLOR_RED or it's returned by COLOR_UNI_RED which means the same as uni_color(3) :) The difference is that the value is not hard-written by preprocessor but it's run-time calculated.

However, I understand that some problems with config might appear. And this way I think that config should have 0-255 values as now.

Maybe it's better idea to try to work on this a little bit more and present version that can use config. I hope I'll do this in a way that will be compatible with current CCHDK.CONF. (However to not afraid of breaking the compatibility was one of the advantages of separate unstable 1.1 branch :))

Current patch does not break any compatibility (but I understand that if nothing will be done in future is a little bit useless...).

When I'll have some more results I'll start a separated thread. Or if you like to add some more suggestions or possible solutions please do this. I'm open to all discussions and like to just a little bit clean up complicated colors system in CHDK.

PS. Note that having this function we would not have to export all color defines for modules as it's now, but only uni_color() function!

EDIT

I made a small but important mistake in first sentence. There was written 'There is now two...' and should be 'There is no two...' - Now is correct...
« Last Edit: 10 / January / 2012, 19:40:13 by outslider »
Logged
if (2*b || !2*b) {
    cout<<question
}

Compile error: poor Yorick
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: Adding new cameras, applying patches into trunk (with source code prepared)
« Reply #606 on: 10 / January / 2012, 19:57:00 »
Quote from: outslider on 10 / January / 2012, 19:34:25
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.


An example of what I mean - in the current conf.c file the color config values are initialised from the COLOR_xxx values. You would not be able to initialise them from the COLOR_UNI_xxx values because the system has no way to know when the config file is loaded what type of color value it was.

One enhancement I am looking at is allowing modules to have their own config files, for example many of the zebra config files are only used by the zebra code in the module - having a zebra config file for these would simplify the core CHDK. However this would require the ability to initialise colors with constant values.

I suggest moving this to a new topic.

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: Adding new cameras, applying patches into trunk (with source code prepared)
« Reply #607 on: 13 / January / 2012, 20:59:37 »
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.
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline waterwingz

  • ******
  • 12140
    • Waterwingz
Re: Adding new cameras, applying patches into trunk (with source code prepared)
« Reply #608 on: 14 / January / 2012, 12:30:08 »
First patch file for v2 USB remote code.  Submitted now to prep the main dev trunk for pending changes.  Will not break existing builds.

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.
« Last Edit: 14 / January / 2012, 15:32:35 by waterwingz »
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: Adding new cameras, applying patches into trunk (with source code prepared)
« Reply #609 on: 14 / January / 2012, 16:37:05 »
Quote from: msl on 09 / January / 2012, 06:23:48
Quote from: stefantalpalaru on 09 / January / 2012, 05:34:53
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

Attached is a patch file against branch release1.0 - untested.

msl

Added to release-1.0 (changeset 1547) and trunk (changeset 1548).

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)
Pages: 1 ... 56 57 58 59 60 [61] 62 63 64 65 66 ... 169   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal