In chdkptp r1141, I added a devutil command 'dptpdevino' 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
!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
