CHDK PTP interface

belahe

1

Re: CHDK PTP interface

« Reply #240 on: 04 / August / 2010, 11:30:55 »

Advertisements

Is there an implementation of PTP for SX120 ?

Logged

yvesson

209
A540 SX10IS

Re: CHDK PTP interface

« Reply #241 on: 14 / August / 2010, 17:10:28 »

Quote from: mweerden on 20 / July / 2010, 18:03:25

Here's a patch with my proposed changes.

Hej,
anything new about this ?

Logged

fudgey

1705
a570is

Re: CHDK PTP interface

« Reply #242 on: 26 / August / 2010, 17:00:35 »

Maybe it's time to do something about this while the patch is still valid for current trunk

...some comments about the PTP proposal patch:

- http://chdk.wikia.com/wiki/PTP_Extension lists memory read/write and remote function calls as excluded from the patch but they appear to be included in the proposal patch ptp.c anyway.

- I added a570 ptp startup to platform/generic/main.c and don't know how to do it any other way. The proposal patch adds code for ixus870_sd880 in each sub's boot.c because apparently some asm magic is required. I can only assume my addition interferes with it. How to deal with this?

- It would be easier to review the patch if tools/ptpcam stuff would be in a separate diff.

- Script command reboot() should be in a separate diff because it's not related to PTP.

- Maybe switch_mode_usb() lua command should be renamed to something like set_record_during_ptp or maybe set_record() could be given another option to signal that this alternative functionality is desired.

- What is PTP_CHDK_TempData?

Logged

fudgey

1705
a570is

Re: CHDK PTP interface

« Reply #243 on: 26 / August / 2010, 17:03:19 »

I've built CHDK binaries of trunk 926 with PTP patches for a570 (both 100e and 101a). They are based on mweerden's PTP proposal patch, ported to a570. I didn't make a special vanilla build for publication so these binaries have some of my patches and selections applied to them in addition to the PTP stuff. Download (binaries+diffs) available at http://drop.io/a570_chdk_ptp.

The binaries were authored this way:

1) patch -p0 < ptp_proposal-20100721-mweerden.patch
The patch is for trunk rev 913 but it applies fine to trunk 926.

2) applied my old changes from http://chdk.setepontos.com/index.php/topic,4338.msg42384.html#msg42384 but this time I also wrote an implementation of the switch_mode_usb() rec/play switching command because set_record(true) in Lua seemed to cause a crash after shoot() command right after switching to rec if camera was originally powered on to rec mode with DNG enabled. So, I added entry points for PB2Rec, Rec2PB and DisableNotificationPTP for a570 100e and 101a to make it work and modified camera.h too. See a570_ptp.patch (to be applied after the ptp proposal patch).

3) added my localbuildconf.inc (removes curves, calendar, sokoban, mastermind, enables native calls in Lua):
# disabled components (overrides buildconf.inc)
OPT_GAME_SOKOBAN=
OPT_GAME_MASTERMIND=
OPT_CURVES=
OPT_CALENDAR=
# enabled components (overrides buildconf.inc)
OPT_LUA_CALL_NATIVE=1

4) added some of my patches (full zebra osd restore, add continuous mode tv adjustment, fix debug mem browser for vxworks cams, greatly reduce battery voltage display filtering) and built using gcc 3.4.6.

Example usage:

1) Power on camera with USB cable attached and rec/play switch in 'play' position.
2) Connect PTP from a PC using 'ptpcam --chdk'
3) send commands such as

upload something.lua A/CHDK/SCRIPTS/something.lua -- test file upload
lua set_record(true) -- switch to REC mode
lua shoot()
lua press("shoot_half"); sleep(2000); press("shoot_full"); sleep(10); release("shoot_half"); release("shoot_full")
lua set_record(false); sleep(3000); shut_down() -- switch to PLAY mode and power off

If you need to power on the camera remotely, you need to use the power button permanently taped down trick and toggle external power supply to power on.

In the patch there is an alternative command for rec/play switching:
lua switch_mode_usb(0) -- switch to PLAY mode
lua switch_mode_usb(1) -- switch to REC mode
These may or may not be required for crash free mode switching in some cases (possibly PLAY->REC switching if camera was powered on to REC mode instead of PLAY mode; you may want to do that if it turns out that playing around in REC mode with rec/play lever in play position causes trouble with some Canon or CHDK features). But these commands may also fail to work (they may bounce back to the mode you tried to get away from). More testing required.

Logged

mweerden

194

Re: CHDK PTP interface

« Reply #244 on: 27 / August / 2010, 08:44:54 »

Quote from: fudgey on 26 / August / 2010, 17:00:35

- http://chdk.wikia.com/wiki/PTP_Extension lists memory read/write and remote function calls as excluded from the patch but they appear to be included in the proposal patch ptp.c anyway.

Indeed. I corrected the wiki.

Quote

- I added a570 ptp startup to platform/generic/main.c and don't know how to do it any other way. The proposal patch adds code for ixus870_sd880 in each sub's boot.c because apparently some asm magic is required. I can only assume my addition interferes with it. How to deal with this?

There's no magic involved.

I just added it where SpyTask is created, but your methods seems to be fine as well (as long as it's platform independent, I guess). It seems a few different approaches are in use.

Quote

- It would be easier to review the patch if tools/ptpcam stuff would be in a separate diff.

I'm not sure I see why. In the patch itself all the non-ptpcam stuff comes first and if applied, it creates a new directory for ptpcam. But if you want I can split the file.

Quote

- Script command reboot() should be in a separate diff because it's not related to PTP.

Perhaps. I tend to see it as primarily useful in the context of (debugging via) PTP.

Quote

- Maybe switch_mode_usb() lua command should be renamed to something like set_record_during_ptp or maybe set_record() could be given another option to signal that this alternative functionality is desired.

W.r.t. consistency in naming you're absolutely right. Though set_record is a horrible name in my opinion.

I did use usb instead of ptp because the additional code seems to be USB specific and not so much directly related to PTP. Perhaps it's also useful in non-PTP communications some day.

Quote

- What is PTP_CHDK_TempData?

It's a command to temporarily store data or receive such data. It's useful in cases like downloading where you have to specify a filename but cannot transmit it in the same transaction as the actual download (due to the limited PTP arguments and the fact that each transaction can only send data in one direction).

Logged

fudgey

1705
a570is

Re: CHDK PTP interface

« Reply #245 on: 29 / August / 2010, 05:15:32 »

Quote from: mweerden on 27 / August / 2010, 08:44:54

Quote from: fudgey on 26 / August / 2010, 17:00:35
- http://chdk.wikia.com/wiki/PTP_Extension lists memory read/write and remote function calls as excluded from the patch but they appear to be included in the proposal patch ptp.c anyway.
Indeed. I corrected the wiki.

I think remote function calls should be disabled by default like they are in Lua, e.g. using buildconf.inc (OPT_PTP_CALL_NATIVE). Maybe even poke?

Quote from: mweerden on 27 / August / 2010, 08:44:54

There's no magic involved. I just added it where SpyTask is created, but your methods seems to be fine as well (as long as it's platform independent, I guess). It seems a few different approaches are in use.

I'm not an expert here I'm afraid but if the code in platform/generic works on many cameras and only some or none require platform or sub specific code, this definitely should be done in the generic code whenever possible, right?

Quote from: mweerden on 27 / August / 2010, 08:44:54

Quote
- It would be easier to review the patch if tools/ptpcam stuff would be in a separate diff.
I'm not sure I see why. In the patch itself all the non-ptpcam stuff comes first and if applied, it creates a new directory for ptpcam. But if you want I can split the file.

I didn't know there wasn't any chdk stuff among the ptp files, which made reading the patch slow...(I use a text editor for this, no dedicated tools). When committing this stuff to svn, the changeset diff view in assembla web interface could suffer from the same problem.

Related to this, ptpcam sources should probably somehow state from which version of the original ptpcam it was forked. Committing the original in one patch and then your CHDK'ed ptpcam changes in another changeset would leave a cleaner track I suppose?

Quote from: mweerden on 27 / August / 2010, 08:44:54

Quote
- Script command reboot() should be in a separate diff because it's not related to PTP.
Perhaps. I tend to see it as primarily useful in the context of (debugging via) PTP.

A reboot() command would be highly useful in long term (in time or in number of shots or both) timelapse use to get around problems with ticker wrapping and file table ROM hogging.

Quote from: mweerden on 27 / August / 2010, 08:44:54

Quote
- Maybe switch_mode_usb() lua command should be renamed to something like set_record_during_ptp or maybe set_record() could be given another option to signal that this alternative functionality is desired.
W.r.t. consistency in naming you're absolutely right. Though set_record is a horrible name in my opinion. I did use usb instead of ptp because the additional code seems to be USB specific and not so much directly related to PTP. Perhaps it's also useful in non-PTP communications some day.

Agreed...

Logged

mweerden

194

Re: CHDK PTP interface

« Reply #246 on: 29 / August / 2010, 08:36:12 »

Quote from: fudgey on 29 / August / 2010, 05:15:32

I think remote function calls should be disabled by default like they are in Lua, e.g. using buildconf.inc (OPT_PTP_CALL_NATIVE). Maybe even poke?

This is something I'm not opposed to, but I do wonder why.

Quote

I'm not an expert here I'm afraid but if the code in platform/generic works on many cameras and only some or none require platform or sub specific code, this definitely should be done in the generic code whenever possible, right?

Ideally, yes. At the moment it seems the opposite is (mostly) the case.

Quote

I didn't know there wasn't any chdk stuff among the ptp[cam] files, which made reading the patch slow...(I use a text editor for this, no dedicated tools). When committing this stuff to svn, the changeset diff view in assembla web interface could suffer from the same problem.

Ok, I can see that this might not be clear. I guess I just assumed that it was clear that it's a completely separate tool (code wise). One could indicate it in the commit message, but I guess committing them separately would be clearer.

Quote

Related to this, ptpcam sources should probably somehow state from which version of the original ptpcam it was forked. Committing the original in one patch and then your CHDK'ed ptpcam changes in another changeset would leave a cleaner track I suppose?

If you wish to be able to distinguish the code I've written from the original, yes. Otherwise a line in README or the commit message should suffice. Personally I wouldn't (and didn't) bother because I'd call the link with the original ptpcam "accidental".

Logged

fudgey

1705
a570is

Re: CHDK PTP interface

« Reply #247 on: 29 / August / 2010, 17:47:38 »

Quote from: mweerden on 29 / August / 2010, 08:36:12

This is something I'm not opposed to, but I do wonder why.

Because having it enabled by default would make it possible for a psychopath to e.g. author a malicious program that clears the ROM of your camera once connected to a windows computer and distribute it on the internet under the name "l33t appz0r to double the mpiX3lz on ure powash00t lawl.exe". I.e. sort of the reason why it's disabled for Lua by default, but squared since you can actually review Lua scripts you run on your camera but you can't do that for binary malware that runs against your will.

Quote

Ideally, yes. At the moment it seems the opposite is (mostly) the case.

Okay, I suppose cams like a570 that can live with the generic code should then have something like #define PTP_GENERIC_STARTUP 1 in camera.h?

Btw, I added a command line interface to your CHDK-ptpcam. It's a quick&dirty hack of course, it does what the interactive interface does but always just one command that can be given on the command line. To start interactive version, you may still run 'ptpcam --chdk', but now you can also give one command as an argument to the chdk switch, for example 'ptpcam --chdk="lua shoot()"'.

My Ubuntu uses PTP for normal camera USB access, which interferes with ptpcam. Basically the first ptpcam connection attempt nearly always fails, but retrying solves this. So I changed ptpcam to retry before giving up.

I also changed the 'luar' command a bit. It used to be like the 'lua' command except that luar modified the script by placing 'return' in front of it. Unlike the 'lua' command, it then reads the return value from Lua. That means 'luar 2*21' returned 42. I found that to be rather limited, since you can't place complex scripts on a Lua return line. After my tiny little change you need to add that return statement yourself, but it since you can put it anywhere in the script, you can now do things like

ptpcam --chdk="luar a=10; b=20; c=a+b; return c"
or
ptpcam --chdk="luar propcase=require(\"propcase\"); return get_prop(propcase.USER_TV)"

The modified files are CHDK/tools/ptpcam/ptpcam.c and ptp.c. You can find them and a simple example usage shell script in http://drop.io/a570_chdk_ptp file ptpcam-climod.zip.

Logged

mweerden

194

Re: CHDK PTP interface

« Reply #248 on: 29 / August / 2010, 19:55:21 »

Quote from: fudgey on 29 / August / 2010, 17:47:38

Because having it enabled by default would make it possible for a psychopath to e.g. author a malicious program that clears the ROM of your camera once connected to a windows computer and distribute it on the internet under the name "l33t appz0r to double the mpiX3lz on ure powash00t lawl.exe". I.e. sort of the reason why it's disabled for Lua by default, but squared since you can actually review Lua scripts you run on your camera but you can't do that for binary malware that runs against your will.

I don't think those are very good examples. I'll keep it on security for the paranoid and the off chance that cameras with CHDK become so widely used that people will want to display ads on them or something.

Quote

Quote
Ideally, yes. At the moment it seems the opposite is (mostly) the case.
Okay, I suppose cams like a570 that can live with the generic code should then have something like #define PTP_GENERIC_STARTUP 1 in camera.h?

Isn't this already taken care of by CAM_CHDK_PTP? (As far as I know the other cameras don't call task_start_hook.)

Quote

Btw, I added a command line interface to your CHDK-ptpcam.

Nice. This has been on my todo(-butnotlikelytoeverbedone)-list for some time.

Quote

My Ubuntu uses PTP for normal camera USB access, which interferes with ptpcam. Basically the first ptpcam connection attempt nearly always fails, but retrying solves this. So I changed ptpcam to retry before giving up.

If it works, great. I think it's also useful when rebooting; I've noticed that my just-wait-a-few-seconds approach didn't always work so well.

Quote

I also changed the 'luar' command a bit.

My intention was that you'd be able to type luar 2*21 and get 42 back without having to add return. If I understand the Lua semantics correctly, and I believe I tried it as well, without the return you don't get 42 back. Also, having more complex commands (or actually commands that take more time) can have undesired effects due to the fact that the PTP handler waits for completion.

I do understand the use of your version, but I'd probably either use (my) luar (function () body end)() (not tested) or make another command for it.

Logged

mweerden

194

Re: CHDK PTP interface

« Reply #249 on: 30 / August / 2010, 04:36:23 »

Quote from: fudgey on 29 / August / 2010, 17:47:38

The modified files are CHDK/tools/ptpcam/ptpcam.c and ptp.c. You can find them and a simple example usage shell script in http://drop.io/a570_chdk_ptp file ptpcam-climod.zip.

In ptp.c, the malloc/sprintf is now pretty useless; I'd remove that (together with the later free). As for ptpcam.c:

Apparently you have some automatic style changer or something. Diffing your version with mine gives a lot more than one wishes. (Deja vu! J/k )
It seems open_camera tries a (MAXCONNRETRIES+1)th time or, in case of success before, always calls ptp_opensession another time. Perhaps moving the call in the condition and the code after (and just before) the loop inside (into a "big" if) is a solution.
How about just a char *buf = chdkarg; in chdk()?
Something to be aware of for the CLI is that the reboot commands try to reconnect after issuing the reboot. It's probably still the right behaviour as it gives you the result of the reboot (without having to look at the camera).

Logged