CHDK PTP interface - page 125 - General Discussion and Assistance - CHDK Forum  

CHDK PTP interface

  • 1241 Replies
  • 479529 Views
*

Offline reyalp

  • ******
  • 14072
Re: CHDK PTP interface
« Reply #1240 on: 21 / February / 2022, 00:35:34 »
Advertisements
In chdkptp r1141, I added a devutil command 'dptpdevinfo' to display PTP information like supported opcodes, events, properties and so in.
 Constants and names are largely from current (as of Feb 2022) gphoto source with Canon opcodes supplemented from @coon's list  (I also used this combined list to update the CHDK sig finders in trunk r6071)

As usual, devutil is activated using
Code: [Select]
!require'extras/devutil'.init_cli()
After that, dptpdevinfo without options gives reasonable output. Adding -ptpevp calls InitiateEventProc0 before querying deviceinfo, which will add the related opcodes to the supported list. However, it won't work on cameras that expect a different handshake, or non-canon devices.

Output for my cameras and an iphone is attached.

Some observations:
- Cameras starting with early DryOS (D10, r31, at least) support MTP, explaining why they report a Microsoft extension ID (6) rather than Canon's own ID (11). Gphoto comments suggest that 0xffffffff may also identify MTP, but I haven't seen it. The 0x980x opcodes are MTP. The PTP native extension system doesn't really support multiple / layered extensions, so there's no PTP standard way to identify a Canon's approach of supporting MTP and a bunch of their own opcodes, aside from theirs being outside the 0x980x range. MTP actually does define a mechanism (using the  VendorExtensionDesc string) but Canon doesn't use it.
- Most Canon operation codes are identified, although I don't know how reliable the names/descriptions from Gphoto are.
- Some of the known opcodes and properties might be useful or interesting for reverse engineering
- Aside from minor variations in order, returned info is essentially identical Wifi or USB.
- Calling MTP.GetObjectPropsSupported puts the camera in "black screen" state, like GetObjectHandles
« Last Edit: 15 / January / 2023, 14:36:20 by reyalp »
Don't forget what the H stands for.

*

Offline reyalp

  • ******
  • 14072
Re: CHDK PTP interface
« Reply #1241 on: 01 / February / 2024, 01:23:29 »
Over in @RaduP's Camera Connect thread, I noted that when using PTP/IP on SX730 through the mobile phone option
Oddly, the CHDK PTP opcode isn't reported as supported on the initial connection, although it's available subsequently and works.
The cause of this appears to be
- CHDK starts init_chdk_ptp_task in spytask at startup.
- init_chdk_ptp_task sits in loop sleeping for 250 ms until it successfully adds the CHDK handler, or more strictly, until add_ptp_handler doesn't return 0x17
- The 0x17 return is based on a variable that isn't set until PTP is initialized for the first time.

When a USB cable is used, the firmware initializes PTP when it detects a USB host (more or less), so the odds of starting a PTP connection within 250ms are extremely low, at least if connecting manually (could possibly be an issue if anyone makes a CHDK client that runs from udev).

For wifi in the cases where the UPnP handshake is required, PTP seems to be initialized based on the UPnP handshake. Again, very hard to connect within 250ms

For the direct connect without the UPnP handshake, PTP appears to be initialized when it sees the first PTP/IP packet, so CHDK has a very good chance of not adding its opcode before the client fetches device info.

It would be "better" for CHDK to hook into the stuff that registers all the other PTP handlers, but it's easy enough to work around in chdkptp by waiting 250ms and refreshing the devinfo if the CHDK opcode isn't detected the first time. This will slightly slow down connections to devices not running CHDK, but that should be a rare case.
Don't forget what the H stands for.

 

Related Topics