Disabling Eyefi card

I managed to convert the eyefi code into a flt.
I briefly tested it and noticed no differences in behavior.
Here is the patch (included a small addition for the G15 regarding key mappings).
Let me know if it seems to make any sense

Typically better not to mix patches - I'd suggest seperating them.   You could just delete the first two entries in the patch file.

The process at this point is to post the patch file(s) here:

http://chdk.setepontos.com/index.php?topic=650.0

with a link to the appropriate forum thread describing what's been done.

Typically better not to mix patches - I'd suggest seperating them.   You could just delete the first two entries in the patch file.

The process at this point is to post the patch file(s) here:

http://chdk.setepontos.com/index.php?topic=650.0

with a link to the appropriate forum thread describing what's been done.
[/quote]

I followed your instructions, separated the modifications and posted them to the forum. Thanks for being so helpful. Hope I got it right

As mentioned in the patch thread, this has been added to the 1.3 trunk. Thanks to everyone who contributed.

Feedback from anyone who has these cards is welcome.

Also, if someone can add documentation to the 1.3 manual on the wiki http://chdk.wikia.com/wiki/CHDK_1.3.0_User_Manual that would be helpful. You can use chdkptp to make screenshots of the menus.

It occurs to me that being able to control the eyefi from script might be a useful addition.

As mentioned in the patch thread, this has been added to the 1.3 trunk. Thanks to everyone who contributed.

Feedback from anyone who has these cards is welcome.

Also, if someone can add documentation to the 1.3 manual on the wiki http://chdk.wikia.com/wiki/CHDK_1.3.0_User_Manual that would be helpful. You can use chdkptp to make screenshots of the menus.

It occurs to me that being able to control the eyefi from script might be a useful addition.

Looks good - a couple of comments on the module implementation:
- the module does not unload if there is no eye-fi card present
- the 'default_libeyefi' structure is not complete, calling any function without calling 'init' first will crash. Dummy entries should be added for all functions.
- duplicated code in gui.c functions could be re-factored to save space. At first glance some of the code in gui.c looks like it should belong in the module (but I haven't looked at it closely enough to say for sure).

Phil.

- the module does not unload if there is no eye-fi card present

can you give me a hint on how to do it?

- the 'default_libeyefi' structure is not complete, calling any function without calling 'init' first will crash. Dummy entries should be added for all functions.

Ok. Are really dummy entries to be put in or stubss that load the module and call the actual function? (like in the init case)

- duplicated code in gui.c functions could be re-factored to save space. At first glance some of the code in gui.c looks like it should belong in the module (but I haven't looked at it closely enough to say for sure).

Ok, I will hammer it a bit

Quote from: philmoz on 09 / October / 2013, 06:16:39

- the module does not unload if there is no eye-fi card present

can you give me a hint on how to do it?

If the _module_can_unload function returns non-zero then the system will unload the module. Modules like DNG.C use an internal 'running' flag to determine if they are still performing operations or can be unloaded.
The _module_unloader function will be called just before your module is removed, perform any needed cleanup here (freeing memory, etc).

Quote from: philmoz on 09 / October / 2013, 06:16:39

- the 'default_libeyefi' structure is not complete, calling any function without calling 'init' first will crash. Dummy entries should be added for all functions.

Ok. Are really dummy entries to be put in or stubss that load the module and call the actual function? (like in the init case)

The dummy entries just do nothing in the case that someone calls the function before the module is loaded - prevents crashes if someone tries to use the code in an unexpected manner.

Alternatively you could implement some or all the default functions to load the module and call init automatically - that way any of the functions can be safely called at any time.

Phil.