supporting USB remote and PTP communications concurrently

  • 33 Replies
  • 5169 Views
supporting USB remote and PTP communications concurrently
« on: 03 / August / 2014, 12:06:23 »
Advertisements
Some time ago I posted a simple hack to allow the USB remote to work in conjunction with PTP so that precision sync could be used.

http://chdk.setepontos.com/index.php?topic=8769.msg105488#msg105488

While simple, it requires a custom build to use.  I've had several requests for customized CHDK versions implementing that hack so maybe it's time to roll it into the dev trunk ?   And make it so that the hack can be enabled/disabled at run time.

I believe that the options at this point are :
  • Do nothing.  Custom hacks are the way to go.
  • Add the hack as a build option.
  • Make the hack something that can be enabled/disabled in the CHDK Settings or USB Remote menu.
  • Add a script function that enables / disables the hack.
  • Add a ptp only function that enables / disable the hack.

Obviously, the first two options have big support and compatability problems with being obsolete days after they are created.

The third option (CHDK menu) adds a very specialized function of limited use to most people.  Not that CHDK does not already have more than a few of those but why continue to do that?

Option four is promising and option five is really just a subset of option four without the need to document and support the function.  Although option five would require support from the PC client so generic PTP programs would not be able to use it.

One big draw back to all this is that the hack currently happens in the kbd.c file for each camera.  It's going to be quite a bit of edit / script work to update all those files.   But is has been done before.

Code: [Select]

int ptp_and_usb_remote_play_nice_together_flag = 0 ;

void my_kbd_read_keys() {
    kbd_prev_state[0] = kbd_new_state[0];
    kbd_prev_state[1] = kbd_new_state[1];
    kbd_prev_state[2] = kbd_new_state[2];
    _GetKbdState(kbd_new_state);
    _kbd_read_keys_r2(kbd_new_state);
    if (kbd_process() == 0) {
        // we read keyboard state with _kbd_read_keys()
        physw_status[0] = kbd_new_state[0];
        physw_status[1] = kbd_new_state[1];
        physw_status[2] = kbd_new_state[2];
    } else {
        // override keys
        physw_status[0] = (kbd_new_state[0] | KEYS_MASK0) & (~KEYS_MASK0 | kbd_mod_state[0]);
        physw_status[1] = (kbd_new_state[1] | KEYS_MASK1) & (~KEYS_MASK1 | kbd_mod_state[1]);
        physw_status[2] = (kbd_new_state[2] | KEYS_MASK2) & (~KEYS_MASK2 | kbd_mod_state[2]);
    }
        usb_remote_key() ;
        if (conf.remote_enable) {
                physw_status[USB_IDX] = physw_status[USB_IDX] & ~(SD_READONLY_FLAG | USB_MASK);
                if ( ptp_and_usb_remote_play_nice_together_flag )
                        physw_status[USB_IDX] = physw_status[USB_IDX] | USB_MASK ;  // NEW : make it look like 5V is there no matter what
        } else {
                physw_status[USB_IDX] = physw_status[USB_IDX] & ~SD_READONLY_FLAG;
        }
}

Maybe there is a simpler / more elegant way to do this ?

edit : fixed spelling on subject line
« Last Edit: 03 / August / 2014, 20:16:35 by waterwingz »
Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline reyalp

  • ******
  • 11514
Re: supporting USB remote and PTP communictions concurrently
« Reply #1 on: 03 / August / 2014, 16:41:20 »
I would say option 4 is the best bet. Anyone needing this is probably going to be using script anyway.

Quote
One big draw back to all this is that the hack currently happens in the kbd.c file for each camera.  It's going to be quite a bit of edit / script work to update all those files.   But is has been done before.
It would be more work initially, but the physw_status manipulations could probably be abstracted out into generic code. Essentially, you should just need to make the masks and indexes available to the generic code. This could be camera.h defines, const ints or something with a generic include. I think this would be useful beyond just this particular instance.
Don't forget what the H stands for.

Re: supporting USB remote and PTP communictions concurrently
« Reply #2 on: 03 / August / 2014, 17:50:50 »
2It would be more work initially, but the physw_status manipulations could probably be abstracted out into generic code. Essentially, you should just need to make the masks and indexes available to the generic code. This could be camera.h defines, const ints or something with a generic include. I think this would be useful beyond just this particular instance.
At that point, the two or three (IIRC) versions of my_kbd_read_keys() could just go into common code ?  Or are there a lot more version difference than I remember ?
Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline reyalp

  • ******
  • 11514
Re: supporting USB remote and PTP communictions concurrently
« Reply #3 on: 03 / August / 2014, 18:23:36 »
At that point, the two or three (IIRC) versions of my_kbd_read_keys() could just go into common code ?  Or are there a lot more version difference than I remember ?
I think it's a bit more than that, but I'd have to go digging to be sure.
Don't forget what the H stands for.


Re: supporting USB remote and PTP communictions concurrently
« Reply #4 on: 03 / August / 2014, 20:01:30 »
I think that there is a option 4a that might make sense.  Or at least make sense from an effort vs payback perspective. 

What if we add the script function but only mod the camera kbd.c files "on request"?  The script function would return a "failed" code on non-modified cameras.

My thinking here is that it seems unlikely that anyone is going to build a big multi-camera rig using anything based on VxWorks or anything "off the market" for more than two years.  And while it would be fun to see a 50 camera bullet time rig built with G1X's or G15's,  it doesn't seem to likely unless it's Paul Allen funding the build.  So the number of requests we actually have to deal with might be three or four per year?    And any new ports could make the patch available by default.

I guess stereo rigs might benefit if we made this available for every camera and there are apparently a lot of those using everything from old A series models to the S100/S110's.  But don't think this is that big a deal for them - they are simply not managing enough cameras and images for it to be an issue.

So adding the two or three lines to kdb.c files when requested is not a big deal as long as the script function to enable/disable is in the standard build.

Lazy way out I know.  But there are other projects I'd rather work on right now.



Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline reyalp

  • ******
  • 11514
Re: supporting USB remote and PTP communictions concurrently
« Reply #5 on: 03 / August / 2014, 20:11:20 »
What if we add the script function but only mod the camera kbd.c files "on request"?  The script function would return a "failed" code on non-modified cameras.
I think this is a good solution. I'd rather not have a major rework of the keyboard code before 1.3 release anyway.
Don't forget what the H stands for.

Re: supporting USB remote and PTP communications concurrently
« Reply #6 on: 03 / August / 2014, 20:16:02 »
I think this is a good solution. I'd rather not have a major rework of the keyboard code before 1.3 release anyway.
Agreed.   Getting the MF stuff finished could be bad enough. 

Now all I need to do is learn to spell "communictions" correctly.
Ported :   A1200    SD940   G10    Powershot N    G16

usb remote w/ptp
« Reply #7 on: 15 / August / 2014, 00:46:25 »
Not sure where this fits best in - there are several multicam / ptp threads running at the moment. I think it's time to make the ptp / usb precision sync hack a permanent addition to the trunk.

Therefore, attached is a patch file to add the ptp/precision sync hack that I first proposed here :
http://chdk.setepontos.com/index.php?topic=8769.msg105488#msg105488

The patch adds a new script function ( share_usb_port( 1/0 ) ) that is called to enable / disable sharing of the USB port between precision sync and ptp communications.

On cameras where the feature is not enabled,  the function returns 0 to indicate that nothing happened.  On cameras with the feature enabled the function return 1.

The patch enables this functionality for the A1200 (so I could test it) and the A2500 (as that seems to be the camera of choice at the moment for bullet time rigs).  As discussed on IRC,  other cameras can be quickly added on request.

Also attached are a Lua & uBASIC script demonstrating the use of the function.

Edit :  for this to work,  the CHDK USB remote needs to be enabled.  If that is done prior to calling the new functions, PTP communication will be disabled.  So the work flow sequence is going to be important here if controlling the cameras over PTP.   I suppose the patch could be changed to assume the USB remote is enabled whenever the sharing mode is enabled.
« Last Edit: 15 / August / 2014, 00:51:06 by waterwingz »
Ported :   A1200    SD940   G10    Powershot N    G16


Re: usb remote w/ptp
« Reply #8 on: 15 / August / 2014, 09:05:46 »
Edit :  for this to work,  the CHDK USB remote needs to be enabled.  If that is done prior to calling the new functions, PTP communication will be disabled.  So the work flow sequence is going to be important here if controlling the cameras over PTP.   I suppose the patch could be changed to assume the USB remote is enabled whenever the sharing mode is enabled.
On reflection, there may be a much cleaner way to do this.

Why not just add the functionality of share_usb_port() to switch_mode_usb()?  Rather than add a new function and deal with using that in a script,  what if the flag set by share_usb_port() is instead set/cleared by switch_mode_usb() ?  As near as I can tell,  you only need the functionality when using ptp and you currently only get into shooting mode when ptp is active by issuing a switch_mode_usb().  So cameras that have the mod will also "lock" the USB bit so that remote sync can use it but everything else thinks its "on".

The only drawback I can see here is if the USB cable is pulled in shooting mode.  The camera will stay in ptp mode as it will not see the USB plug go away.  Is this a serious limitation or something we can live with ?

edit : s/set_mode_usb/switch_mode_usb/g*
« Last Edit: 15 / August / 2014, 18:10:19 by waterwingz »
Ported :   A1200    SD940   G10    Powershot N    G16

Re: usb remote w/ptp
« Reply #9 on: 15 / August / 2014, 20:45:23 »
New version - implemented as per my previous post.  No more script function - just a simple change to switch_mode_usb() that I think should work for everyone.

If this looks good,  it might make sense to enable all the recent ports ( 2012-2014 ) with this functionality. After that it can be added by request. I'll add a "note for porting" about how to do that.

Ported :   A1200    SD940   G10    Powershot N    G16

 

Related Topics