supplierdeeply
« previous next »
Pages: 1 ... 26 27 28 29 30 [31] 32 33 34 35 36 ... 114   Go Down

CHDK PTP interface

  • 1136 Replies
  • 149764 Views
*

Offline ultimA

  • ***
  • 137
  • Publish
    Re: CHDK PTP interface
    « Reply #300 on: 29 / November / 2010, 14:21:54 »
    Advertisements
    If I want to implement new PTP-query in the camera that returns only a single number or two, is my understanding of the code correct that I only need to do the following?

    1) Add a new enum value to ptp_chdk_command
    2) Extend the switch in handle_ptp(...)
    3) Write ptp.num_param/.param1/.param2 with the return value
    4) Do nothing else. PTP will return the params in the ptp structure "automatically" because of the data->send_resp( data->handle, &ptp ); line at the end of the function.
    Logged
    *

    Offline mweerden

    • ***
    • 194
  • Publish
    Re: CHDK PTP interface
    « Reply #301 on: 29 / November / 2010, 17:34:43 »
    Quote from: fudgey on 23 / October / 2010, 03:38:13
    For windows, the easiest route is this one (I'm not 100% sure if this matches proposal patch version functionally):
    http://www.mweerden.net/download/chdk-ptp/libptp2-chdk-win32.zip
    I'm pretty sure it doesn't match. I can't quickly build a new version at the moment, but let me know if it's needed. I'm guessing that others have more up-to-date versions.

    Quote from: ultimA on 29 / November / 2010, 14:21:54
    If I want to implement new PTP-query in the camera that returns only a single number or two, is my understanding of the code correct that I only need to do the following?
    It seems so, yes.
    Logged
    *

    Offline rudi

    • ***
    • 123
    • A590IS_101B, SX260HS_100B
  • Publish
    Re: CHDK PTP interface
    « Reply #302 on: 29 / November / 2010, 18:28:19 »
    Thanks for your informations, but I would give only a hint for return value of the lua-api function. I think the current implementation is wrong. We can't get the success result from "switch_mode_usb()". Sorry for my bad description.

    For your information: We had on CHDK-DE version some problems with download/upload files (eg. on IXUS100 and A610). The reason is the constant buffersize. CHDKLover have written a solution. He calculate the max. RAM-buffersize. 50% from that is the ptp-buffersize. He found also a solution to make all vxworks-cams ptp-ready incl. mode-switching (see DE-Trunk 465 and up). But OPT_LUA_CALL_NATIVE is required.

    EDIT:
    I think, I found the answer for "switch_mode_usb()"-result. It is a tricky tri-state result (mode-val on stack for switching ok and nil for any error at switching). Is that correct?

    rudi
    « Last Edit: 30 / November / 2010, 11:15:01 by rudi »
    Logged
    *

    Offline reyalp

    • ******
    • 9957
  • Publish
    Re: CHDK PTP interface
    « Reply #303 on: 19 / December / 2010, 17:06:32 »
    Some ptp changes here http://chdk.setepontos.com/index.php?topic=5793.msg58335#msg58335

    I've attached a win32 build of ptpcam, along with source patches. This isn't really useful as is but it shows how to use the new commands.

    edit:
    patches are against mweerdens github source.
    « Last Edit: 19 / December / 2010, 18:34:04 by reyalp »
    Logged
    Don't forget what the H stands for.
    *

    Offline reyalp

    • ******
    • 9957
  • Publish
    Re: CHDK PTP interface
    « Reply #304 on: 19 / December / 2010, 18:41:50 »
    Quote from: rudi on 29 / November / 2010, 18:28:19
    I think, I found the answer for "switch_mode_usb()"-result. It is a tricky tri-state result (mode-val on stack for switching ok and nil for any error at switching). Is that correct?
    Seems so.

    I think switch_mode_usb should not exist. set_record should know if PTP is active, and call C code switch_mode_usb if needed. Many older cameras don't need any special code.

    (I agree set_record is a bad name, but I didn't want to confuse with shooting modes which already had get_mode and set_capture_mode...)
    Logged
    Don't forget what the H stands for.
    *

    Offline rudi

    • ***
    • 123
    • A590IS_101B, SX260HS_100B
  • Publish
    Re: CHDK PTP interface
    « Reply #305 on: 20 / December / 2010, 12:57:41 »
    Hello,

    for mode-switching in ptp (mode-command) we use for VxWorks the canon event functions. Can we this also use for DryOS-cams?

    successful tested with A590:
    Code: [Select]
    //equal levent_set_record();
    <conn> lua post_levent_to_ui("PressRecButton");post_levent_to_ui("UnpressRecButton")

    //for example make a shoot
    <conn> lua shoot()

    //equal levent_set_play();
    <conn> lua post_levent_to_ui("PressPBButton");post_levent_to_ui("UnpressPBButton")
    The best is, all cams use only one routine. We don't need to find entrypoints for set_control_event, PB2Rec and Rec2PB on DryOS-cams. I think the two methods are a little bit different and the event-method is a better way (feel stable on tests).
    The downside is OPT_LUA_CALL_NATIVE is required for OPT_PTP, but for VxWorks-cams it is already required.

    rudi
    Logged
    *

    Offline ultimA

    • ***
    • 137
  • Publish
    Re: CHDK PTP interface
    « Reply #306 on: 20 / December / 2010, 15:18:54 »
    @reyalp: I saw the changes you made to the patch. While implementing, at first I also thought of using a bitfield. But the reason I didn't do that, and why I think it is not a good option right now, is that in my oppinion it complicates code for no foreseeable benefit. I understand that this theoretically makes adding new scripting languages possible, but as I have seen (I think it was this thread earlier) there is really no interest in adding UBasic support to PTP. And I also see no realistic chance of adding a third scripting language later on.

    The reason it complicates code so much is that because you start supporting "scripting interfaces", as noted in the code comments. So to truely stay correct and open to future additions in the future, for every script-related PTP command you would need to supply a "target interface" as an argument (=an argument to state which scripting interface you are communicating to). This adds a lot of related problems, like what if there are multiple interface targets specified, how do you handle returning different errors in these cases and so on. And as stated, I cannot foresee supporting a scripting language in PTP other than LUA at the moment. So is this all worth it?

    A relatively unrelated note: Maybe it would be better, instead of a ScriptSupport command, to have a general FeatureQuery command, that could return supported features of the current CHDK & camera in a bitfield. Not only for scripting, but games/zoom/native_calls/and other features.
    Logged
    *

    Offline reyalp

    • ******
    • 9957
  • Publish
    Re: CHDK PTP interface
    « Reply #307 on: 20 / December / 2010, 16:37:24 »
    Quote from: rudi on 20 / December / 2010, 12:57:41
    The best is, all cams use only one routine. We don't need to find entrypoints for set_control_event, PB2Rec and Rec2PB on DryOS-cams. I think the two methods are a little bit different and the event-method is a better way (feel stable on tests).
    The downside is OPT_LUA_CALL_NATIVE is required for OPT_PTP, but for VxWorks-cams it is already required.
    I don't understand why native call is required, you can use without levent native call.

    It looks like the code you are using is identical to lua set_record, which doesn't work on (most ?) dryos cameras when USB is connected. I know I tried a bunch of things on D10 and couldn't get it to switch using levent.

    @ultimA it seemed to me there was some interest in ubasic support, there are already some constants there for it. ExecuteScript already takes a type option (which is just a constant, not a bitfield) PTP_CHDK_SL_LUA

    One reason to use ubasic is cameras with very little memory. Once your scripting optional stuff is done, people will have the option of ubasic only, and might still want ptp.

    The way things are now, the "supported" bit will be (1<< (executescript number)). I thought about changing ExecuteScript to use the bitmask values, but as you say it doesn't make sense to pass more than one.

    I would assume that if multiple script interfaces are supported, you can only use one at a time, at least until a major protocol change.
    Logged
    Don't forget what the H stands for.
    *

    Offline hwntw

    • ***
    • 132
  • Publish
    Re: CHDK PTP interface
    « Reply #308 on: 20 / December / 2010, 17:13:18 »
    Deleted by a craven coward
    « Last Edit: 28 / January / 2011, 18:09:44 by hwntw »
    Logged
    Ixus 300HS S100 G9


    Windows XP SP3
    *

    Offline ultimA

    • ***
    • 137
  • Publish
    Re: CHDK PTP interface
    « Reply #309 on: 20 / December / 2010, 22:20:37 »
    Quote from: reyalp on 20 / December / 2010, 16:37:24
    One reason to use ubasic is cameras with very little memory. Once your scripting optional stuff is done, people will have the option of ubasic only, and might still want ptp.
    But this argumentation is only valid if OPT_LUA_CALL_NATIVE is not made a requirement for OPT_PTP.

    Quote from: reyalp on 20 / December / 2010, 16:37:24
    The way things are now, the "supported" bit will be (1<< (executescript number)).
    What is "executescript number"?
    Logged
    Pages: 1 ... 26 27 28 29 30 [31] 32 33 34 35 36 ... 114   Go Up
    « previous next »
     

    Related Topics