supporting USB remote and PTP communications concurrently - page 2 - General Discussion and Assistance - CHDK Forum

supporting USB remote and PTP communications concurrently

  • 33 Replies
  • 14938 Views
*

Offline reyalp

  • ******
  • 14080
Re: usb remote w/ptp
« Reply #10 on: 15 / August / 2014, 22:14:12 »
Advertisements
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.
I think I prefer having a separate script function to enable the "sharing" behavior.

Using USB remote + PTP is a pretty niche application, I would rather not add additional side effects to switch_mode_usb just for that. switch_mode_usb is also declared weak in the expectation that some cameras need to override it. Currently none do AFAIK, but there are several that have issues with mode switching.

I'm also not convinced that enabling "shared" USB automatically when someone switch to rec mode in USB is desirable. Someone not using the remote might want the normal behavior if the USB is unplugged.
Don't forget what the H stands for.

Re: usb remote w/ptp
« Reply #11 on: 15 / August / 2014, 23:38:27 »
I think I prefer having a separate script function to enable the "sharing" behavior.
Thanks for taking the time to look at both.  After several years here,  I was pretty much expecting you might lean that way.  So I'll make one try to defend the other version. 

Quote
Using USB remote + PTP is a pretty niche application, I would rather not add additional side effects to switch_mode_usb just for that.
Quite frankly,  just using chdkptp is niche as well.  I'd venture to suggest the number of multicam rigs (stereo up to bullet time) out weigh devs like you and I (plus web cams replacements)  using chdkptp in single camera mode?  Call it a toss up?

Quote
switch_mode_usb is also declared weak in the expectation that some cameras need to override it. Currently none do AFAIK, but there are several that have issues with mode switching.
Not sure why that matters?  As I said,  the whole thing needs to be enabled on a "per camera" basis - if somebody is also doing an overload of the _weak_ definition then it's up to them how they handle (or ignore) the shared_usb_port flag ?

Quote
I'm also not convinced that enabling "shared" USB automatically when someone switch to rec mode in USB is desirable. Someone not using the remote might want the normal behavior if the USB is unplugged.
I'll buy that.  But on the balance,  do you think there are more than three or four people in the world who could even tell you what happens today if the USB is unplugged normally?  Does this really introduce a side effect that will ever matter to anyone?

I thought about this quite a bit prior to going to the effort of reworking the second patch.  IMHO the script function adds complexity.  Fixing switch_mode_usb() removes the possability of making a script mistake.  The possability that someone will not like how the camera performs if there is an abrupt removal of the USB cable seems kind of minor.  I'd bet that if we go with the first option, most scripts will have switch_mode_usb() followed immediately by share_usb_port() anyway.

Either way .. (having written both patches) ... I can't "lose".  My vote is the second patch. But either gets a "to do action item"  off my list so I'm happy.   If we go with the first,  the code for kbd.c and usb_sync.c in the second version has a better workflow so I'd merge that back into the first patch prior to committing to the trunk.
« Last Edit: 15 / August / 2014, 23:43:57 by waterwingz »
Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline reyalp

  • ******
  • 14080
Re: usb remote w/ptp
« Reply #12 on: 16 / August / 2014, 01:26:35 »
Quite frankly,  just using chdkptp is niche as well.  I'd venture to suggest the number of multicam rigs (stereo up to bullet time) out weigh devs like you and I (plus web cams replacements)  using chdkptp in single camera mode?  Call it a toss up?
As far as I know, there are only a handful of people working on serious multicam rigs. I like to think there's quite a few more chdkptp users than that, but I don't actually know how many.
Quote
if somebody is also doing an overload of the _weak_ definition then it's up to them how they handle (or ignore) the shared_usb_port flag ?
Sure, but having generic stuff that needs to be reproduced in camera specific files is a source of pain, as you must know from dealing with kbd.c. I'd rather not multiply it.

Quote
Does this really introduce a side effect that will ever matter to anyone?
My concern is that it adds another layer of potential weirdness. You used switch_mode_usb and suddenly  the USB connection is handled differently.

To me, the two functions aren't really related. switch_mode_usb exists to switch between rec and play. Controlling how the usb bit is masked is something completely different.
Quote
I'd bet that if we go with the first option, most scripts will have switch_mode_usb() followed immediately by share_usb_port() anyway.
For the handful of people building USB remote triggered multicam rigs, no doubt. I don't see many other people using it.

Sorry to be argumentative again, but as you know, I have opinions ;)
Don't forget what the H stands for.

Re: usb remote w/ptp
« Reply #13 on: 16 / August / 2014, 06:49:43 »
Sure, but having generic stuff that needs to be reproduced in camera specific files is a source of pain, as you must know from dealing with kbd.c. I'd rather not multiply it.
Unfortunately, the change to kbd.c needed to make this work will continue to be a pain.

Quote
Sorry to be argumentative again, but as you know, I have opinions ;)
Not a problem - the code gets better when this kind of discussion happens.   I'm okay with adding a script command.

If we go with the first,  the code for kbd.c and usb_sync.c in the second version has a better workflow so I'd merge that back into the first patch prior to committing to the trunk.
I should probably expand a bit on this (and rant a bit).   Currently, USB remote menu setup is partially coupled to how the USB remote scripting commands work.  The USB remote enabled menu setting affects how some of the underlying code works but not other parts of it. Which can be confusing as  the whole remote thing essentially works differently if you are in <ALT> than when you are not.

With my second patch,  I probably make this worse. Or start to make it better, depending on how you look at it.   

The first patch only works if the USB remote is enabled in the CHDK menu.  Which is annoying if you are trying to use PTP. 

So the second patch enables sharing use of the USB port and the precision sync functionality without needing the remote to be enabled.   But it still requires the sync menu item to be selected.   

This all works fine if you understand the precedence but I can see where it will be confusing (as it already is - the whole remote thing essentially works differently if you are in <ALT> than not).   

So the question is whether to go with the second (more convenient) method or not ?
Ported :   A1200    SD940   G10    Powershot N    G16


*

Offline srsa_4c

  • ******
  • 4451
Re: usb remote w/ptp
« Reply #14 on: 16 / August / 2014, 08:13:09 »
Sure, but having generic stuff that needs to be reproduced in camera specific files is a source of pain, as you must know from dealing with kbd.c. I'd rather not multiply it.
Unfortunately, the change to kbd.c needed to make this work will continue to be a pain.
He might mean that it would be better to reduce the change in camera-specific kbd.c files to an added function call, and do the actual work in a single generic routine.

Re: usb remote w/ptp
« Reply #15 on: 16 / August / 2014, 11:29:51 »
He might mean that it would be better to reduce the change in camera-specific kbd.c files to an added function call, and do the actual work in a single generic routine.
Pretty much.  I was sure we had talked about this earlier so I searched harder and found it :
   http://chdk.setepontos.com/index.php?topic=11779.msg115254#msg115254
   http://chdk.setepontos.com/index.php?topic=11779.msg115289#msg115289

@reyalp :  would you please move everything from
     http://chdk.setepontos.com/index.php?topic=11583.msg115720#msg115720
onwards to
    http://chdk.setepontos.com/index.php?topic=11779
where it should have been in the first place ? TIA

EDIT :  added the merged patch file - new script command giving support for precision sync with PTP without the need to have the USB Remote enabled  (but you do need sync enabled in the USB Remote menu)
« Last Edit: 16 / August / 2014, 12:17:02 by waterwingz »
Ported :   A1200    SD940   G10    Powershot N    G16

Re: usb remote w/ptp
« Reply #16 on: 16 / August / 2014, 15:24:39 »
Sorry to be argumentative again, but as you know, I have opinions ;)

ultimately, opinion is all that we have

Re: supporting USB remote and PTP communications concurrently
« Reply #17 on: 16 / August / 2014, 15:42:22 »
at least comment hasn't been closed  :lol ;)

Thanks.
« Last Edit: 16 / August / 2014, 15:44:36 by andrew.stephens.754365 »


*

Offline reyalp

  • ******
  • 14080
Re: usb remote w/ptp
« Reply #18 on: 16 / August / 2014, 15:55:26 »
Thanks for the additional detail
I should probably expand a bit on this (and rant a bit).   Currently, USB remote menu setup is partially coupled to how the USB remote scripting commands work.  The USB remote enabled menu setting affects how some of the underlying code works but not other parts of it. Which can be confusing as  the whole remote thing essentially works differently if you are in <ALT> than when you are not.

With my second patch,  I probably make this worse. Or start to make it better, depending on how you look at it.   

The first patch only works if the USB remote is enabled in the CHDK menu.  Which is annoying if you are trying to use PTP. 
So PTP would be ignored until you set the sharing setting? That would definitely ugly for people who primarily wanted to control via PTP.

Quote
So the second patch enables sharing use of the USB port and the precision sync functionality without needing the remote to be enabled.   But it still requires the sync menu item to be selected.   

This all works fine if you understand the precedence but I can see where it will be confusing (as it already is - the whole remote thing essentially works differently if you are in <ALT> than not).   

So the question is whether to go with the second (more convenient) method or not ?
I think the second method sounds better. I guess the alternative would be to make the "share" setting a config option.  This could still be set from script, and would make it explicit. (edit: not saying it should be this way, just thinking out loud)


Another thing occurred to me this morning. There's another situation where you might want to trick the camera into thinking there is a USB connection when there isn't, separate from the remote:
If you you switch modes with USB connected, and then disconnect / reconnect USB, things get weird. If you want to have a camera that is occasionally connected to USB (e.g. to download photos from a camera in the field, or a setup where the USB host is only powered on some of the time) one way to do it would be to make it think USB is always there. Then (usb) mode switching would work as normal.
Don't forget what the H stands for.

Re: usb remote w/ptp
« Reply #19 on: 16 / August / 2014, 16:22:41 »
So PTP would be ignored until you set the sharing setting? That would definitely ugly for people who primarily wanted to control via PTP.
I think I explained that right but I'm not sure it's as bad as you are thinking.  After all, that's how it works today - if you have the USB Remote enabled, you can't do PTP.

So without my second version,  the sequence for ptp with precision sync is :
  • make a ptp connection
  • switch to shooting mode via switch_mode_usb()
  • enable USB remote (and sync if it's not already set) by poking the CHDK menu item
  • call share_usb_port(1)
  • shoot
  • drop the USB 5V line
  • restore the USB 5V line
  • repeat steps 5 to 7 until happy
  • call share_usb_port(0)
  • disable USB remote by again by poking the CHDK menu item
  • profit

With the second version,  the sequence for ptp with precision sync is :
  • make a ptp connection
  • switch to shooting mode via switch_mode_usb()
  • enable sync if it's not already set by poking the CHDK menu item
  • call share_usb_port(1)
  • shoot
  • drop the USB 5V line
  • restore the USB 5V line
  • repeat steps 5 to 7 until happy
  • call share_usb_port(0)
  • profit

Quote
I think the second method sounds better. I guess the alternative would be to make the "share" setting a config option.  This could still be set from script, and would make it explicit. (edit: not saying it should be this way, just thinking out loud)
I offered that one up earlier in this thread but it didn't make the cut.

Quote
Another thing occurred to me this morning. There's another situation where you might want to trick the camera into thinking there is a USB connection when there isn't, separate from the remote:
If you you switch modes with USB connected, and then disconnect / reconnect USB, things get weird. If you want to have a camera that is occasionally connected to USB (e.g. to download photos from a camera in the field, or a setup where the USB host is only powered on some of the time) one way to do it would be to make it think USB is always there. Then (usb) mode switching would work as normal.
That would work too with either patch.
« Last Edit: 16 / August / 2014, 16:45:33 by waterwingz »
Ported :   A1200    SD940   G10    Powershot N    G16

 

Related Topics